| PREVIOUSLY
I described my approach to designing an electronic document as imagining myself within the document and traveling around in it as though in a car or plane. I also pointed out that electronic media release us from the constraints of traditional document organization and that my documents are organized as centers of information, viewed through an interface something like a vehicle's control center.
This month I'll describe how I go about setting up a WinHelp online manual for software; but first a few words for those uncomfortable with the idea that they may be called upon to design something. DESIGN is finding functional and (possibly) esthetic solutions that meet the requirements set before us. These requirements could include what our customer or boss expects from us as well as personal goals we may set for ourselves, such as producing a better product than the previous one. Whatever the requirements, the process involves making decisions, each of which can be influenced by decisions we've already made and can influence ones we have yet to make. If we don't keep our eye on the whole, we can easily design ourselves into a corner. As a beginning architectural student many years ago I did just that while working on my first design project. My professor, a wise old gentleman, remarked that "it was unfortunate the [element] got so good so fast" because I wanted to hang onto it, even though doing so prevented me from solving the overall problem. I ended up abandoning this first attempt and starting over. The lesson learned:
Through my school years and succeeding professional years, this principle has saved me numerous times and remains the best lesson I learned as a student. The principle works in all walks of life, for writers, comedians, artists, politicians, business people, military strategists, and so forth. Some gifted people seem to do this naturally - rethink even the most basic tenets by which we live - but the rest of us have to remember to do this whenever we get stuck.
THE POINT OF ENTRY is where I usually begin my design for an online project. For a context-sensitive software help project this is likely to be any window or any tab on a window. My goals are to provide the user with a sense of orientation in relation to the entire project, to provide the user with the means to go somewhere else in the project and to provide an indication of what to expect at this other location, and to provide direct or unambiguous near-direct access to the information the user most likely entered the help module to acquire. I also keep the help window smaller than the screen, try to limit the amount of vertical scrolling the user must do, and try never to require horizontal scrolling. My success can usually be measured in degrees. I'm always looking for a better way. (Famous industrial designer Raymond Loewy titled his autobiography Never Leave Well Enough Alone. 'Nuff said!) The text of the buttons will be color coded. Each button will have a gray (dimmed) counterpart for insertion where applicable. The color coding is consistent for all headers related to that button. What isn't as clear at first glance as it might be is that the <Overview>, <Window/Tab List>, and <Instructions> buttons lead to information or summary lists for the group of windows or tabs to which the current window/tab belongs; not for the entire project. To make the buttons more explicit would require additional words somewhere or some clue - such as an icon - that distinguishes local from overall. So far, these buttons have been in use for a year now and no one has commented. Also, it becomes clear upon first use that these buttons are local. The <Home> button takes you home for the entire project. Previously the <Home> button was a <Menu> button. Home is a new center for this update. More to follow.
I've included descriptions of all tabs belonging to a parent window on the initial displays. This gives the user a capsule view of the window and all its tabs. Each non-displayed tab in the window is hot-linked to its own information center, where the summary of tabs is again displayed. I could have collapsed the tab descriptions to save space (they're not all as brief as the ones illustrated) and had the descriptions appear as pop-ups. I suspect that if I had done so, not many people would bother to exercise those pop-up links.
The lists of buttons, fields, and options are often displayed without scrolling. Each name on a list is hot-linked to a pop-up description. I expect these hot-links to be exercised frequently because they contain the information that most people are likely to want.
You may notice that the underlined words have different colors. That's because I color code my future links. I use teal for jumps and violet for pop-ups. Later, when I come back to do my linking, I know exactly what I had in mind. The final rendition for links is the default green with solid underlining for jumps and broken underlining for pop-ups. I also make a point of using identical wording for source and destination, thereby avoiding confusion for myself as well as the user.
I haven't illustrated my pop-ups, but they contain one item worth mentioning. Every pop-up has an end marker. I learned the hard way some years ago that pop-ups don't scroll. If the user has a small screen, or has set the screen resolution low, a pop-up that appears fine on your screen may have truncated content on your user's screen. The end marker is a confirmation that the entire pop-up is visible. It is also useful to check your project by setting your monitor to a low resolution.
Most of my design effort is focused on this point-of-entry information center. In a context-sensitive system, users will almost always arrive first at one of these centers. They may go elsewhere at some time during their stay, but this is their arrival point and most-used jumping off point. It is important to check this information center's usefulness against your project requirements and have others check it as well. I always create a functional mockup with "most likely" and "critical condition" scenarios, and let unsuspecting people test it. I also like to have the developers test it. If their work is still in progress they may have some plans up their sleeves that they haven't told me about because their plans are not finalized. This is an important time for the developers to tell all.
I HAVE OTHER CENTERS but don't need to discuss them in great detail. The <Window/Tab List> button takes the user to a list of related hot-linked windows or tabs (example: all the windows or tabs related to System Information Model). Similarly, the <Instructions> button takes the user to a list of related instructions. The instruction list lets a user select instructions by task (example: Create something, Modify something, Delete something, and so forth). The instructions are arranged so that a user can go through them sequentially, as if they were part of a tutorial. Each task contains hot links that let a user continue to the next logical task as in a tutorial. I haven't provided a smaller secondary window for the instructions, as I sometimes do, because the main help window on this project is relatively narrow to begin with and can be displayed without completely obscuring the user's open application below.
I've touched on some basic considerations that go into setting up an online document. My goal has been to describe an approach, a way of going about things, not to present a universal solution. The other project I'm currently working on looks decidedly different from the one I've just described because the software is decidedly different. There is simply no one right way to do these things. Space doesn't permit greater detail or more thoroughness, but you can reach me by email at abarten1@yahoo.com if you have questions.
NEXT MONTH
This is the third in a series of four articles. A variation of the first article was published in the Nov/Dec 1998 issue of Boston Broadside, newsletter of the Boston Chapter of the Society for Technical Communication. |
In one of the projects I am now working on, the point of entry - my most important information center - is inspired by an airplane cockpit. It is compact and provides quick, clear access to all the information and controls I need. In the illustration (figure 1), I've fictionalized the content somewhat to protect the innocent (a.k.a. me). The angle-bracketed tags (example: <Home>) will be replaced by buttons drawn in PowerPoint. Everything above the horizontal rule is fixed and does not scroll. Everything below the rule is scrollable when necessary. I maintain alignment through the "make into help" process by putting everything but the header and buttons into a table.
THE HOME CENTER is a first for me. I'm introducing it with the next update to this project. Home has come to be an expected location on a web site. Introduction is something of a counterpart in a paper manual. The essential difference is that with a web site, Home is usually where a visitor starts and almost always goes at some point during a visit. With a paper book or manual, Introduction is a place some people never visit, or rarely visit more than once. In the illustration (figure 2), you can see that Home for this project is not so cozy as a real home might be, but it serves an essential purpose. Most people are going to come here because they are lost, want the ultimate overview or starting point, or are curious. With the Home center, I was able to make a strong distinction between the main content of the project and information about the help system. I was able to conveniently elevate this latter, often obscurely located information, to a place of prominence where it stands a better chance of seeing the light of day.
All roads lead from home. The most useful link in the example is XYZ functions. The destination, XYZ functions, is illustrated in figure 3. Previously, the material at this destination was covered in the introduction and, excluding the linked material, took three screens of scrolling to view. It now takes one and a half.
In the next illustration (figure 4) we have jumped to System Information Model overview. The interesting thing about these last two illustrations is the way in which they achieve my goal of compactness. Instead of listing related links after a paragraph (such as overviews in the first illustration and nodes in the second), I put them to the right of the paragraph. This not only, on average, reduces space, but lets me provide a summary of topics discussed or referred to in the paragraph. If appropriate, I also list topics that are completely covered in the paragraph and have no links to further information. This arrangement makes it easy for a user to scan for topics. Hot-linked topics to the right of the paragraph are detail topics, often pop-ups. Hot-linked topics within the paragraph body are related topics, often outside the immediate vicinity.