A directory of resources inthe field of technical communication.

Minson, Benjamin

51 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


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


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


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


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


Keys to Being a Trusted Source of Information

The issue of building trust with the audience is core to technical communication. If the user doesn’t trust your instruction, it’s worthless—no matter how well researched, thought out, and reviewed it is and how much time, effort, or problems it will save.

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


A Process for Developing Regular Release Notes

In my project portfolio, our release manager—the one who instituted release scrums—wants to standardize on release notes across applications. Many of the projects are in a maintenance period, so releases are planned for each project every month or two on something of a rotating basis. These releases will include small enhancements and bug fixes. One of the challenges of standardizing on release notes is coming up with a release notes process that can efficiently turn out these documents within about a week.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Project Management>Scrum


QA of Product Design

Quality isn’t found solely in working code. Quality is found mainly in the experience. Technical communicators are immersed in the experience of a product because we have to understand it. We have to see it as the user sees it. As a result, we can provide quality assurance for product designs beginning in the early stages of design and development.

Minson, Benjamin. Gryphon Mountain Journals (2010). Articles>TC>Quality>Workflow


Quick-Start Guides Require a Minimalist Mindset

The point of a quick-start guide is, as the name says, to help the users get on their feet as fast as possible. This requires the writer to ask, “What is the absolute minimum that someone needs in order to get started?” The next best question is “What is the user going to do the most often?”

Minson, Benjamin. Gryphon Mountain (2008). Articles>Documentation>Technical Writing>Quick Reference


Realistic But Hypothetical Examples

One of the reasons that technical communicators ought to know the business processes of their users (or at least the reasons they’re using the product) is to generate effective examples in the documentation.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Writing>Technical Writing>User Centered Design


The Reason I Haven’t Embraced Single Sourcing

The field of technical writing is making a push toward single-sourced content. This involves authoring in one place and being able to chuck the content into different formats, such as help systems and manuals. It’s supposed to make things better for content management, as well as for localization because you have only one set of content that has to be translated. I personally haven’t bought off on this yet.

Minson, Benjamin. Gryphon Mountain (2008). Articles>Single Sourcing


Release Scrums: An Important Resource for the Agile Technical Writer

Scrums are part of the particular flavor of Agile methodology project teams use in the portfolio I work in. The managers recently borrowed the scrum concept for release preparation because the projects in this portfolio are interrelated and often have to be released together. This means that a lot of coordination is needed so that there are no surprises for anyone. Because technical writers enjoy surprises as little as anyone else, I get invited to these scrums. This lets me know how much time I have to put release notes together and whether there are any last-minute changes I need to make to them or to any other documentation.

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



Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon