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.
Best case, UI-based documentation is confusing because instructions on
accomplishing any task that uses multiple parts of the UI is scattered
around so the user has to figure a lot out for themselves.
Worst case, it's just a narrative of the UI that adds no value. I've
thrown out a lot of docs like that and rewritten them from scratch.
"For context sensitive, UI based - you hit help on a screen and you
want to know what THAT screen does and what the different fields are."
It's not nearly that simple.
1. You don't know how the user got to the topic. Maybe they pressed
F1, maybe they searched the help, maybe they clicked a link in another
topic, maybe they're browsing the TOC, if the help is on the web maybe
they got there from Google.
2. Maybe the user knows how to use the thing and is just looking for
the menu sequence to get to it.
3. Maybe the user is doing something that uses more than one part of
the UI and is trying to figure out where to go next to accomplish the
rest of the task.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
