TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I consider the meaning of a field more important than any itemized steps listing:1. Enter a value for the Foo field2. Enter a value for the Bar field3. Enable the Baz option...
The first thing we do is use tooltips heavily to document each field. Maybe the user doesn't even need to open the docs.
Once in the docs, the overview for the topic describes what you can do with the particular dialog/screen/group of controls. If I need specific use cases, then I can list them -- if they're small and obvious they can fit in the overview. If not, then I use separate topics.Â
Instead of an itemized procedure, I take a picture and say, "Make it look like this". If one set of controls can have different settings to achieve different results, then I usually give that as a matrix in a table.
In the docs themselves (as opposed to the tooltips) I expand on field descriptions, especially if they require consideration, or have dependencies. This usually makes up the bulk of the "text" for a topic.ÂÂ
Gone are the days when we need to tell people how to use a GUI. A GUI is a language -- the grammar is generally standard. It's the meanings of the nouns, adjectives, and verbs that people need. My opinion.
cud
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
