As documentation is more and more built directly into the interface, and as technical communicators move into interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information will be conveyed at any moment. We can build on basic principles of cognitive psychology to help us make these decisions. We start from a question: Why should users be aware of the difference between interface and documentation when all they want is to get something done?
As documentation is more and more built directly into the interface, and as technical communicators move into areas of interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information should be conveyed at any moment.
Context-sensitive Help is assistance that is appropriate to where the user is in the software application, and what they are trying to do. Carol Johnston's article describes what programmers and technical authors need to know about Context-sensitive Help.
This question was raised on a programmer's group recently and I was intrigued. The programmer's point was that with many web applications these days there is no print documentation distributed to end users, and even if it existed, many users won't read it although this makes me wonder who's buying all those how-to books I see in the bookstore. The programmer suggested that applications should be designed without documentation and wondered about the impact that would have on design.
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.
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.
A colleague has made me realize that user assistance writers are codependents of bad UI design. Because we explain how the UI really works, we somehow leave our developers and companies feeling like they're "covered" when the users have a bad experience.
An innovative approach to enhancing ease of use and learning for novel user interfaces is described. Instructive interaction comprises a body of techniques based on a learning-by-doing model that is supported by three design principles: explorability, predictability, and guidance. Taken together, these principles form the basis for creative designs that can support highly efficient production use by experienced users while also enabling new users to understand and make effective use of an unfamiliar system almost immediately. The underlying principles of instructive interaction are presented here and an assortment of specific techniques based on these principles is described.
Here are some 'truths' we've all heard: 'Documentation is just a band-aid for poor design.' 'Real users don't read manuals.' 'Super users never read anything.' 'Help doesn't.' But are they really true? I've seen some signs of life in the use of documentation for digital products recently.
Sometimes, you need to quickly come up with new or alternative text for error messages and user interface label. One of the easiest ways to do this is for a technical communicator to brainstorm ideas solo It’s a very effective technique, and can usually produce something that’s better than just usable very quickly.
Experts say that a person’s behavior on the web is highly goal-driven. People have things they want to accomplish, whether it’s making a purchase, finding a recipe or learning how to do something new. Inherent in many web page designs, therefore, is information to help a user perform an action. For example, if you design a button that must be clicked to reach a desired goal, such as placing an item in a shopping cart, then shadowing the button so it appears to be raised will help your audience understand that the shape is a clickable object. In addition to these types of visual cues, we often write instructions to assist users in knowing what to do next. These instructions guide the eyes and minds of the individual to look at the appropriate place and to take the appropriate action.
As I write the 'how to' documentation based upon the in-process design, the weaknesses of my original design become apparent and I go back and forth from writing text to designing the software until it all flows.
User interface (UI) patterns have the potential to make software development more efficient. The prospect of such efficiency gains has led to interest in user interface (UI) patterns by individuals and organizations looking for ways to increase quality while at the same time reducing the costs associated with software development.
If you’ve been reading this blog for a while, it’s no secret to you that I’m not a big fan of tri-pane help. I think it’s dated and is associated in people’s minds with unhelpfulness. But in our search for a tool that will give us a more robust Web output, I’ve discovered the main reason I don’t like tri-pane help. Tri-pane help appears to have been invented as a way to provide booklike documentation—that is to say, linear documentation. The table of contents, index, glossary are all carry-overs from when all documentation was in hard-copy manuals. While a book’s material isn’t necessarily linear, it still reflects linear thinking.