A directory of resources inthe field of technical communication.

Gryphon Mountain

61 found. Page 1 of 3.

About this Site | Advanced Search | Localization | Site Maps
 

1 2 3  NEXT PAGE »

 

1.
#37273

Adobe Community Help and AIR Help: A Disconnect?

I’ve used Adobe Community Help when trying to get answers regarding Creative Suite products. I like the emphasis on searching and the integration of results that aren’t within Adobe’s domain. I think Adobe Community Help is a great example of what help can be: pulling answers and information together from various sources and formats and then showing context in search results.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Online>Help

2.
#36304

Anticipatory Search in Context-Sensitive Help

What if online help could be configured to be context-sensitive in a different way than usual? What if, when the user launches the help system, instead of opening to some assigned help topic, it instead runs a preprogrammed search on keywords assigned to that topic?

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Help>Search

3.
#36618

Becoming the Friendly Neighborhood Tech Writer

Since much of technical writers do is gather information from other people, be respectful of their time. Don’t ask for a minute unless you literally want 60 seconds of their time or less. If I have what I think is a brief question requiring a brief answer, I ask, “Hey Dan, do you have a few minutes to answer a question, or should I come back later?” They’ll usually be honest about whether they need to finish something first or if they can give me their full attention right then.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Collaboration>SMEs

4.
#33689

Blogging: A Way to Give a Bit More Meaning to Life

I’ve realized that having a blog helps me think more about my professional activities and interactions than I would otherwise. I give them more thought because I think about whether they’re something I can write about.

Gryphon Mountain (2009). Articles>Writing>Technical Writing>Blogging

5.
#36364

Case Study: Communication Problem vs. Programming Problem

In looking at my documentation, I found a couple of inaccuracies, and it’s possible that they were the direct cause of the data problem we ended up with. I haven’t verified this yet because at this point, it looks like it hardly matters (as long as I correct the inaccuracies). If my documentation led to the problem, it has led us to analyze a bigger problem that’s really at the heart of our customer’s difficulty. The discussion has been about what needs to happen in our system vs. what is actually happening. We think the programming and the data model have fallen short in some ways; fortunately, the wiring can probably be fixed with relatively little pain. It’s a matter of making sure we know what the customer wants to happen so it will be programmed the right way.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Quality>Technical Writing

6.
#34776

Consistency Leads to Trust in Information Sources

When we start talking consistency, we often think of our documents’ formatting. Consistency is important from the serial comma all the way up to the arrangement of information.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Writing>Rhetoric

7.
#38160

The Core Component of Technical Communication

The optimal way to structure information isn’t dependent on a tool. That’s probably why our team lead kept steering us away from thinking about whether aspects of our authoring approach and information architecture would be supported in Author-it. There were parts of our discussions that blurred the lines—we would sound like we were talking about the tool, but we really weren’t.

Minson, Benjamin. Gryphon Mountain (2011). Articles>TC>Software

8.
#36127

Documentation Needs Usability Testing, Too

All documentation can stand some usability testing. We technical communicators like to claim that we’re user focused and user advocates. I like to believe that myself. However, sometimes we can be more like developers than we want to admit.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Usability>Testing

9.
#37165

Documentation Sprawl, or What Happens When There's No Documentation Plan

The documentation strategy over the course of some development projects has, unfortunately, resembled a building with several add-ons rather than a single, unified structure—wings added, walls moved, different materials used. Where I live, no one builds like this, except in residential neighborhoods and on college campuses. This approach doesn’t exactly make for a consistent experience for users. It’s what I’d call documentation sprawl.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Planning>Technical Writing

10.
#36880

Don’t Leave Any Room for Doubt

I’m working on a little style guide for direct and concise technical writing. One pointer is to avoid the use of should or shouldn’t when what you really mean is do or don’t. Saying something like “shouldn’t” makes it sound optional. In other words, shouldn’t leaves a little room for doubt. Don’t, well, doesn’t.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Diction>Technical Writing

11.
#36759

The Effect of the Organization’s Culture on Conversational Technical Writing

Lately, when I’m writing for training, I’m thinking of actually having a conversation, of talking to a real person. When I write other documents, for some reason I’m not thinking this way. It’s a problem because my user assistance content probably comes out dry as a desert in summer. In addition to not being as conscious of users as I should, perhaps there are a couple of organizational factors affecting my mindset.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Business Communication>Organizational Communication>Technical Writing

12.
#36155

Explaining Your Contribution as a Technical Communicator

Technical writers sometimes find it difficult to explain what they do in a few words. Maybe it’s not so bad when you’re talking to your uncle, but if you’re unable to explain this to your project manager, it can be awkward.

Minson, Benjamin. Gryphon Mountain (2010). Articles>TC>Collaboration

13.
#36036

Findings from an Online Help Usability Test

I conducted some context-sensitive online help usability testing with four users of a Web application. This post discusses the results (without getting overly academic in tone, I hope).

Minson, Benjamin. Gryphon Mountain (2009). Articles>Documentation>Usability>Testing

14.
#36264

First Principles of Technical Writing

After a review of some documents last week, a subject-matter expert told me essentially that one of the first principles of technical writing is to assume that the reader knows nothing about the subject matter. I saw a couple of things wrong with this, and so I would revise the SME’s statement to make two corresponding and related basic principles of technical writing.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Writing>Technical Writing

15.
#35803

Five Skills for Managing Documentation Projects in an Agile Environment

Sometimes, the Agile software development methodology seems like it could be renamed the “Fly by the Seat of Your Pants” methodology. But really, it means that you need a somewhat different set of project management skills for your documentation. I could certainly improve in these skills, but here are a few I rely on in an Agile environment.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Documentation>Technical Writing>Agile

16.
#32764

Four More Reasons Your Company Needs Technical Communicators

A few months ago I posted seven reasons an organization needs technical communicators. This week, a program manager I work with provided a few more ways that technical writers provide value to organizations and projects, so I wanted to pass along his wisdom—with my own discussion, of course. Because I gave seven reasons before, I’ll start with number eight.

Gryphon Mountain (2008). Articles>TC

17.
#35194

Get Passionate about Technical Communication

Introverted people aren’t normally considered passionate. Even if you’re an extrovert, would you consider yourself passionate about technical communication?

Minson, Benjamin. Gryphon Mountain (2009). Articles>TC>Professionalism

18.
#33606

Giving the Instructions a Fair Shot

We as technical communicators ought to afford each other the courtesy of using each other’s materials when the need arises. As the writers, we know how valuable it can be, and if we don’t use it when the need arises, we’re contributing to the prevalent concept that “no one reads it anyway.” By doing so, we shoot our own profession in the foot.

Gryphon Mountain (2008). Articles>Documentation>Technical Writing

19.
#34340

“Good Enough” Really Isn’t

I’m enough of a perfectionist that I mentally wince every time I find myself thinking, “It’s good enough.” It sounds like a cop-out. It sounds like avoidance of responsibility and ownership. It sounds like I’m indifferent.

Gryphon Mountain (2009). Articles>Documentation>Quality>Technical Writing

20.
#33157

How a Teacher Reminded Me Why I’m a Writer

I enjoy creating content. I like to take words and arrange them to convey ideas, paint pictures, spur thought, and give guidance. I like thinking about what arrangement of the words will bring the best impact. I write not necessarily because the world turns on ideas or because information is a buyable product, but because words have a lasting effect on people.

Gryphon Mountain (2008). Articles>Writing>Education>Technical Writing

21.
#36064

How Dropdown Hotspots Can Make Online Help Topics Less Intimidating to Users

After some deliberation, the thought came to me to try two levels of dropdown hotspots. This screen is divided in sections, so I rearranged the information so that I had a hotspot corresponding to each section. Each hotspot would expose another set of hotspots and any other information about that section in general. This would allow the user to navigate directly to what they want rather than having to scan and scroll through a bunch of text.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Documentation>User Interface>Help

22.
#38034

How Help Can Be Structured to Look Like a Website

Why would people be nine times more willing to go to a website than an online help system? Since this may have been explained in the webinar but all I have regarding it is Sarah’s tweet, my initial guess is that people tend to think a help system is static and easily outdated (they don’t know about the Agile technical writer?), while a website is fresh and frequently updated. Whether those things are actually true isn’t as important as the fact that the audience perceives them as being true. This led me to thinking that all is not lost for help authoring tools, though. I’m sure with some effort, I could make an online help system look like a website.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Documentation>User Interface>User Centered Design

23.
#33419

Important Players in the Content Review Game

One of the things that makes quality documentation on a product is a review process. I think many technical communicators would agree with me, however, that sometimes the process becomes more cumbersome than beneficial. The more people involved, the harder it is to meet deadlines.

Gryphon Mountain (2008). Articles>Documentation>Collaboration

24.
#33688

Informal Help via Electronic Conversation Can Lack a Certain Professional Quality

Much documentation and training is delivered in one direction—the writer provides content, and the user consumes it. Perhaps this is one reason that technical communicators are looking for ways to create a conversation. It’s easier to address user problems when you can ask follow-up questions and get details. In a one-way delivery, you have to hope that what you provide will cover what’s needed. In a conversation, you can constantly get more information and react accordingly. Still, in an instant message, chat, or forum conversation, it can be hard to be clear.

Gryphon Mountain (2009). Articles>Documentation>Wikis>Social Networking

25.
#35312

Intellectual Property and the Not-So-Free Web

When you think of the free Web in the context of not having to pay for something, remember that there’s another aspect: Nearly everything that’s on the Web belongs to someone. And because the Web is so widely accessible, it’s entirely possible that if you abuse someone’s rights regarding their intellectual property, they will discover it and exercise their rights.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Intellectual Property>Copyright

 
 NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon