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 »



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


“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


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


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


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


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


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


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



Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon