| LAST MONTH
I suggested that we could take better advantage of the electronic medium for online documents if, when designing the documents, we imagined ourselves within the document. This gives us the vantage point of the user, who, like someone driving an automobile through an unfamiliar landscape, has only the guidance we as designers provide.
I also postulated that an electronic document should be built around information centers with arrays of information, rather than the traditional hierarchical format of paper. This month I want to elaborate on these points and relate them to different types of documents. Next month I'll explain how I go about setting up a project. A DISADVANTAGE of an electronic document is that we cannot hold it in our hands to ascertain its magnitude, organization, and content. The most frustrating thing for a user is to scroll text when the amount of scrolling that's going to be required is unclear; or to pursue a series of links that don't clearly and quickly lead to the desired goal. As designers, we have to find ways to provide this missing information by chunking our information into palatable sized bites, providing readily available access to site maps or organizational charts, providing visual clues, and providing navigational devices such as buttons or hot-linked icons that take us immediately to familiar places that serve as bases for exploration or take us to "higher ground" to give us an overview.
You don't want to overdo this, but it's not out of the question to give certain areas in your document a distinguishing look, just as the real landscape varies. For example, headings for instructions could be dark red and headings for descriptive material could be dark blue. You could do more, but tread wisely. I have some more elaborate thoughts for a web site, but the theme of the site is a rail trip, so the varying "landscape" for different topics has some justification.
AN ADVANTAGE with electronic documents is that we are not restricted to the linear nature of paper document organization. If we imagine ourselves immersed in the document, it becomes clear that the document needs to be organized into centers with groups of information laid out in front of us and provided with convenient ways to get to other centers. It may also be helpful to provide previews of what to expect in other centers (e.g., how is center X related to the present center). A schematic for a paper document inevitably looks like a formal outline. A schematic for an electronic document is more likely to look like a European railroad map - a somewhat random grouping of cities, towns, and villages linked as needed to one another either directly or by way of one another. If we were to zoom in on one of these locations we would find categories of information radiating from the center. If we zoomed in on other locations we would find the same or similar information categories, though different information. WE CAN APPLY these concepts to all forms of electronic documents, though it's obvious that the simplest documents - single paragraph e-mail messages, for example - may look exactly like their paper counterparts.
It is quite possible for an electronic document to have only one center. A report from a business meeting, for example, would most likely be it's own center. It's unlikely that any of us is going to rush out and start putting meeting reports into anything but the simplest format. BUT, consider what you could do if you wanted to. Most meeting reports have several kinds of information: an identifying title and/or purpose, a date, a place, a list of participants, an associated project, topics covered, and resulting action items. It would be very easy to put all this information - or the necessary linked headers - onto a single computer screen. When we come upon this screen we know quickly, if not immediately, what, where, when, and who. We could have a fixed frame that displays a list of hot-linked topics and perhaps a button that displays another list of action items. The action items could also be accessed individually from within the topic detail to which they apply. This may sound like a lot of work, but suppose we created a template in Word which put key elements into a table so that our formatting would always be consistent, and then filled in the template for each meeting, saved that meeting as a file, and imported the file into a RoboHelp project dedicated to business meetings. With each new import we could insert the necessary hypertext links and compile the project. We would then have an executable file that was an interactive, searchable record of all our business meetings. Pretty cool!
Unless we are working on web pages, most of our online documents are help manuals, and most of these are for software. So it is with my work. I have two large projects that I'm working on more or less simultaneously. Actually, one is huge, but it's a conversion from 1500 pages of paper and is being spread over two years because parts of the software are being revised. My deliveries, therefore are partial. The other is an update to an existing online manual I created a year ago.
Both projects are similar yet different. Both are context sensitive. Both are database applications - one for military logistics, the other for automotive diagnostics. The larger project, because the software was first written on the Windows 3.11 platform, does not yet employ tabs. It also has some very crowded windows - 30 or more data fields on a screen is not uncommon. The other project - Windows 95 all the way - uses tabs, and has very clean, simple windows. The first project - the one without tabs - is context-sensitive at the window level. Each window is a potential point of entry for my users and is therefore an obvious center of information. The project with tabs is context-sensitive at the tab level. Thus each tab is a potential point of entry and is an information center. None of this was fortuitous - I set it that way.
As a user, I usually turn to online help when I want specific information quickly. Most often I want to know what a specific button does or what the significance is of the data I enter into a field or what the full impact is of any option I may select. I sometimes also want to know something conceptually about the area of the software I'm working in. I may want to know where the window I'm using stands in relation to other windows - how I got to where I am and where I can expect to go when I leave. I may even want to climb higher for an overview. I also may want specific instructions.
In my information centers, I provide direct-line access to all this information. I use pop-ups for the information on buttons, fields, and options; and I use buttons to go to other centers or overviews. On one project I'm using a button to take me to the instructions; on the other I list instructions by task and let the user bring up the detailed task in a smaller, secondary window. I provide all necessary navigational options in this secondary window so the user can collapse the main help window and have the instructional window still available while looking at the application to which the instructions apply.
For the project with crowded windows, I link the words Buttons, Fields, and Options to lists of these features. The user can click any item in a three-columned list to get a pop-up definition. For the project with simple windows, I'm able to list these features immediately because there are so few. I also provide at each information center cursory explanations for each tab on the associated window - not just the one the user has open.
I've given only the barest sketch of what my systems look like. This is partly because I'm not at liberty to provide screen shots, but more importantly because I strongly believe that each project should be designed according to its own requirements, merits, and limitations. The more literal my presentation, the more I prejudice your own efforts. As with any other form of design, there are always tradeoffs. It's seldom possible to have the ideal setup for every aspect of your system. That's why you need to explore all the possibilities of your information center before you do anything else. Then test it with others. The information center is your building block. It's the place where you begin your project. You need to get it right.
NEXT MONTH
This is the second 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. |
