Part One: Minimalism Revisited

The first glance at a Minimalist piece of art usually baffles the viewer, but it also arouses intrigue; the viewer wants to solve the puzzle. Artistic Minimalism demands that the viewer completes the work of art for the artist. The sculptor only hints at the detail, and the viewer, equipped with imagination, builds upon the stark lines and pared-down modeling. To a certain degree, this interaction is involuntary; the viewer naturally seeks completion of the work. It is instinctive.

Minimalist technical instruction makes a similar demand upon the user. Technical documents are no longer works of reference; they are calls-for-action. The text invites the user to take an active role in learning by denying the user a complete picture. John M. Carroll's The Nurnberg Funnel (1990), analyzes people's response to a wide range of computer hardware and software documentation. He does not limit his theory to any particular genre and draws examples from users' guides, quick-reference cards, tutorials, manuals and online help systems. He develops a theory for learning that one can apply across several genres. Carroll's interest lies in how well people learn when faced with a new technology, and through this venture, he builds the theory of Minimalism. At the heart of Carroll's work is the acceptance that learning computer technology is not like learning anything else. With computers, people face a context that is very difficult to pin to the experiential world.

Minimalism

Take An Action-Oriented Approach

The most successful tools in our society are those that one picks up and uses intuitively. While no tool is utterly intuitive, there are some that come very close. Consider the drinking glass, hammer, or door knob. The primary vehicle for learning how to hammer a nail, drink a glass of water or open a door is trial and error. At the heart of Minimalism sits the notion that learning through doing is better than learning through reading.

Technical documentation is dull and to expect people to read in preparation for learning a task is unreasonable. It is far more reasonable to tap the creative energy of the user by giving her something to do rather than read. Carroll isolates the problem of postponing action:

Training manuals often try to respond to the problem of learners being initially overwhelmed by placing a "read only" overview at the beginning of the book, intended to help orient the learner to the system. It often reviews names for hardware components, particulars of keyboard layout, and so on. Typically, it previews what the learner will be doing. Learners, however, don't seem to appreciate overviews, reviews and previews, they want to do their work. they come to the learning task with a personal agenda of goals and concerns that can structure their use of training materials. (Nurnberg 26)

It is very important to build the documentation around the learner's need to dive into the task. If a trip to the grocery store meant memorizing a list of each item and its geographic location on a floorplan, then shopping would involve training sessions and user manuals. By placing food in categories under labelled aisles, the shopper has the immediate opportunity to act. Software programs with a don't do-anything-until-you-have-read-everything attitude are not only daunting for the user, they are also illogical (Carroll, Nurnberg 26). A typical "read me" file, placed on the desktop during the installation, contains compatibility issues and troubleshooting notes; it is a list of things that could go wrong. It may contain new and confusing technical jargon and problems that the user had not even considered. Addressing problems before they arise is too much for a user who is new to a piece of software; it crushes the user's energy to wade into learning a new piece of technology. The Minimalist message is to cut any pre-doing activities down to the essentials (Carroll, Nurnberg 26; Carroll and Van der Meij 244).

Carroll also insists that by encouraging doing over reading, users learn more. He highlights what he calls the "paradox of sense-making" (Nurnberg 74). A user who jumps into a task and begins is already learning more than the written documentation can provide. Step-by-step instruction, or systems-style instructional design, curbs learning:

It is surprising how poorly the elegant scheme of systems-style instructional design actually works....Everything is laid out for the user. All that needs to be done is follow the steps. But as it turns out, this may be both too much and too little to ask of people. The problem is not that people cannot follow simple steps; it is that they do not. People are thrown into action (Winograd and Flore, 1986) they can understand through the effectiveness of their actions in the world. People are situated in a world more real to them than a series of steps (Suchman, 1987), a world that provides rich context and convention for everything they do. People are always already trying things out, thinking things through, trying to relate what they already know to what is going on, recovering from errors. In a word, they are too busy learning to make much use of the instruction. This is the paradox of sense-making (Nurnberg 74).

Minimalism is most appealing because it accepts the user and all his/her foibles. It structures the documentation around the fact that people do not like manuals and if they read them, they do it haphazardly (Rettig). Minimalism garners the energy of the task at hand; users are already doing things when it comes to learning and documentation should address that "rich context". Most importantly, Minimalist theory addresses the paradox that "to learn, [users] must interact meaningfully with the system, but to interact with the system, they must first learn" (Nurnberg 77). Step-by-step instruction does not provide meaningful interaction, but submerging the user in a task is far more conducive to learning.

Aim for Guided Exploration

By watching how people typically handle learning new software, Carroll concludes that self-exploration is a successful method of computer-based training. He constantly highlights the notion of "guided exploration" (Nurnberg 103) as a model for documentation. He looks to the example of computer games to prove his theory that if the software piques the user's interest enough to explore, then learning occurs simultaneously.

Computer games depend on the user's desire to succeed or win and so mastering the software is crucial. Yet, computer games are notorious for their short and often cryptic instructions. Rather than a "how-to" manual, computer games come with a declaration of the "point" of the game. For example, the screens below represent the complete online instructions for the game Spectre by Velocity:

Figure 1, The first help screen from Velocity's Spectre

The first screen offers no steps for the user to follow and the game depends on the user's understanding of the scenario. It is important that the user knows where she is before she knows what she is doing. The game sets the context of a virtual world and positions the user at the point of view of a battle craft. The text states that battle craft roams the landscape, but it never mentions whether the user controls the roaming or the game itself. However, the game communicates the user's activities through the metaphor. Placement in a "computerized arena" immediately summons the idea that the user is in competition and has control. There is no need for more explanation. Working from this metaphor, the text invites the user to "survive" and then issues a series of imperatives, "Shoot your enemies, collect ammo and flags, and race on to higher levels". This screen never mentions how the user should do these things, because it is not important. Understanding the metaphor is crucial for the success of the game, and the creators know that trial and error will take care of the how.

Spectre has a second help screen which acts as a map to the keyboard:

Figure 2, The second help screen from Velocity's Spectre

The point of some of these "controls" is obvious (Sound and Pause Game); however, others are meaningless until one tries the game. One wonders what is moving forward, zooming in and out, and switching views. According to the conventions of good technical documentation (Brockman and Horton), these screens are faulty. They do not support the user, they merely provide a place from which to jump into the software. And yet, these games come highly recommended from reviewers (MacWorld and MacUser) who consider documentation when reviewing. Game designers want users to begin unfettered by overviews and explanations. They exploit the fact that movement of the game through successive levels of difficulty entices the beginner to learn through gratification. The user fights the "software", the opponent, and graduates to more difficult scenarios moving in a repetitive cycle from vulnerability to confidence. In this case, failure only entices the user. Minimalism grasps the gameplayer's ability to explore and fail and applies this ability to user documentation.

Carroll acknowledges the difference between playing computer games and learning software by extracting key elements. First, games give the user control over strategy and goals, while computer-based learning usually withholds this sort of control from the user, squelching motivation and enthusiasm (Nurnberg 107). Second, as one moves through a game, one always has an ultimate goal in mind (e.g., get to the final screen, kill all the little green men); while step-by-step instruction dissects the goal into little unrelated parts. Sustaining the metaphor or context motivates the user to fill in the gaps by reasoning through a problem, which, in turn, heightens the capacity to learn. Last, Carroll stresses the fact that games let the user fail without any serious result. He draws conclusions from the game Adventure:

Much critical information in the game is hidden; the game provides incomplete hints, some of them riddles, as instructions. Random events play a significant role in structuring the action in the game; for example, dwarfs attack and a marauding pirate steals treasure. Against this background of uncertainty, the game projects the attitude that it is all right to take action anyway, that failure is likely and forgivable. For example, stumbling into a pit is a fatal failure but one not taken too seriously:

'You fell into a pit and broke every bone in your body! Oh dear, you seem to have gotten yourself killed. I might be able to help you out, but I've never done this before. Do you want me to try to reincarnate you?' (Nurnberg 107)

Learning is intimidating; but by letting the user fail, or reassuring the user that failure is inevitable, learning software becomes less painful. Overall, the notion of guided exploration sets the tone for the Minimalist learning style. Keeping the user active, interested and challenged is far better than giving him all the answers.

Position the Documentation in the Task Domain

The text of the Spectre game help screen insists "shoot your enemies", not "click the mouse at moving objects on the screen". R. John Brockman, an advocate of Carroll, integrates Minimalism with his theories for online and paper documentation. He claims that "software is not a tangible product; it is only experienced through communication about it. . . the product does not exist separately and distinctly from language, sounds, graphics, music, etc., used to describe it" (54). Brockman is getting at the idea that users form mental models to decipher the workings of the software because they have limited sensorial experience with it. Brockman quotes Heckel who elaborates on the idea of mental models:

The reality of what our programs do is of no importance to the user. Only the mental model of what they do is important. Our task as designers is not so much to design and create software that carries out a function as it is to design and create a believable communication illusion or model for our users. (55)

Developing the mental model in the software and supporting it in the documentation is the most effective way to deliver help to the user. The notion of email is a good example. Many email programs superimpose the model of postal mail upon the tasks dealing with electronic mail. The technology involved with email, the connection of two or more computers over a phone line bears no resemblance to that of regular mail, the physical transportation of paper. Yet, in terms of the user's task, email and postal mail are very similar. The user of either must write text, gather and store contact information for the future, send and receive mail. The user interface and documentation communicate things like messages, addresses, checking for incoming mail and sending outgoing mail. However, designers have to deal with abstract elements that do not exist in the realm of postal mail. In this case, they stretch the mental model. For instance, deleting an email message from one's desktop is permanent. In order to remedy the user's discomfort with this situation, the designers of the Qualcomm's Eudora email program designed a trash system which holds the messages in the trash for specified time periods. In the actual world, a waste basket is comforting because one has more time to change one's mind about throwing something out. Paper documents do not vanish the way that electronic files do when one deletes them. Eudora designers created a solution that works within the task domain of sending postal mail, and they stretched the mental model when necessary.

It is important to consider the task domain in the help content as well as the user interface. Carroll and Van der Meij summarize the importance of linking instructions to the task domain:

It is important to remember that users will be able to recognize an activity as genuine only to the extent that they have had adequate prior experience in the task domain to underwrite such a judgment. Therefore, to most effectively capitalize on the user's interests in and knowledge about the task domain, instructions must build on their prior skills, knowledge, and experience by directly recruiting those scenarios and procedures of the task domain that are familiar to the user. (249).

Put into practice, their point is quite simple. Instead of suggesting that users "key text into a Eudora document", encourage users to "write messages". Rather than informing users that "Eudora stores messages in a database structure", tell users that "they can store messages in personalized mailboxes". The use of gerunds in headings (e.g., sending, checking, writing) constantly reminds the user of the task at hand, and it is much more logical than organizing actions by software command (e.g., The Check Mail command) (Carroll, Nurnberg 250). Minimalism recognizes the fact that the user never approaches software in an isolated manner, the user always has a reason for learning rooted in a task domain.

Support Error Recognition and Recovery

Making an error is the most intimidating result of an action for a user, yet it is also the most valuable for learning. Error sits paradoxically between being the means to understanding and being the reason that people give up. Errors must be made and analyzed or "the learner will lack the raw material to construct an understanding that discriminates between errors and nonerrors" (Carroll Nurnberg 87). The key is to let learners falter ever-so-slightly, so that they can correct themselves and emerge with a clear notion of success and failure. In this sense, it is very important that users recognize their errors.

At the same time, Minimalist philosophy encourages users through motivation not frustration. If the user makes an error, focus shifts to extracting understanding from the experience and getting the user back on track. It is important to include ample text that supports error recovery, even though this appears to run counter to the less-is-more doctrine. Ample text can take the form of meaningful error messages, extensive trouble-shooting guides and an encouraging outlook on the mistake. This safety net motivates the user to continue without hindering the desire to explore.

Carroll outlines three categories of error. Semantic errors occur "when a method that cannot possibly achieve a given goal is chosen" (Carroll and Van der Meij 251). If a user tries to bold a piece of text with the cut tool, this is a semantic error. Syntactic errors occur when "a correct method is followed, but its execution is performed improperly" (Carroll and Van der Meij 251). If a user tries to bold a piece of text with the bold tool, but fails to highlight it first, this is a syntactic error. Last, slip errors are small mistakes that occur at the keystroke level like making typos or accidentally selecting the cut tool to bold the text, with the immediate awareness that it is a mistake. Syntactic errors are the easiest to predict because the user has a clear understanding of the task, something has gone wrong between A and B, and it is just a matter of getting the user back on the correct path. Semantic errors are difficult to support because it is difficult to predict where the user has strayed and what the original task entailed. Slip errors are also hard to support because of the infinite number of forms they take.

It is important to build the safety net with these categories of error in mind and there are several ways to do this. First, designers can integrate much of the trouble-shooting into the program; Carroll calls this "defensive programming" (Carroll and Van der Meij 252). Most word processing programs prompt the user to save changes before closing a document.

Figure 3, Save changes prompt from Microsoft's Word

This sort of prompt prevents slip errors, but it also trains the user to become aware of saving a document. Programs could use more of this sort of hinting. One should work hinting into the documentation in areas where mistakes are commonly made. If case-sensitivity is mandatory when typing in a field, for example, one should make the user aware of this through a hint. Second, errors occur when actions stray from real-world tasks (Carroll and Van der Meij 253). While it is important to stretch the "mental model" over tasks that do not occur outside of computing, the error information in these areas should be liberal. Configuring one's personal information for an email account has no correlation to sending a letter in the mail. Semantic and syntactic errors occur when one cannot rely on the task domain and reason through a task on one's own. Careful instruction in these areas is very important, rather than relying solely on user exploration. Third, one should provide on-the-spot error information. One should not store error information at the back of a manual or in a separate online file because the contextual situation aids in the recovery. Minimalism calls for segmenting and dispersing error information throughout the manual so that the user sees it in context. This positioning allows users to catch mistakes before they grow into bigger ones. Problem diagnosis occurs within a logical frame of reference, which makes it easier for users to distinguish between error and non-error. Carroll claims that users, made aware of certain errors, practice making mistakes and recovering from them as part of exploration (Carroll and Van der Meij 254). Error information excites the curiosity and builds confidence, but this process is only possible when error information is chunked throughout the document in context.

In summary, people make mistakes and Minimalist philosophy is one of the few that acknowledges the value of error. It is important to make users aware of their errors and it is essential to get them back on track quickly and efficiently.

Design For Non-linear Reading

Much of Minimalist design theory grew out of the way that people read manuals (Carroll and Van der Meij 255). According to Carroll and Van der Meij, less than fifteen percent of readers actually read a manual cover-to-cover. Even though this group moves through the documentation in a linear fashion, it also displays recursive reading behaviour. These users reread chapters and move forward and backward through the text after the first linear reading (Carroll and Van der Meij 255). A second group of readers makes an attempt to read from the start in a linear fashion, but abandons this process after a while. These users end up randomly scanning the text to get the pertinent information (Carroll and Van der Meij 256). A third group of users only picks up the manual as a final solution when they get stuck on something. They browse the text like the second group, but rely heavily on the table of contents and the index to find the information that they need. This group ignores superfluous information like overviews and summaries (Carroll and Van der Meij 256). The overwhelming conclusion is that no one reads a manual in a truly linear fashion; people move through technical information in all directions. Minimalism accepts this trait in readers and builds outward from this position.

Consequently, design strategy becomes extremely complex, since one cannot rely on users to read A before B, B before C and so. There are a number of ways to ensure that users access the necessary information while supporting non-linear reading:

Keep the overall size of the document small. — It is "vitally important to avoid giving the manual a massive appearance" (Carroll and Van der Meij 256). Documentation should be psychologically inviting and large manuals only intimidate the reader.

Make the table of contents hierarchy meaningful. — Break down chapters by tasks and sub-tasks so that users can skip over irrelevant chapters and find what they need (Brockman 91).

Give chapters closure. — Users gain confidence by actually completing a task within a very short space of time (Carroll and van der Meij 257). For example, begin and end chapters with the computer being turned on and off respectively. Closure also encourages users to jump into any chapter without fear that they are missing something from a previous chapter

Keep chapters brief. — Design chapters so that they are concise units. By keeping chapters to two or three pages, one discourages the user from skipping around within the chapter (Brockman 97; Carroll and van der Meij 256). By paring down chapters to the minimum necessary information, the user moves in a linear fashion at this level.

By respecting the user's resistance to linear reading and working with it, the writer has a better chance of conveying information and ensuring that the user gets what he needs from the document.

Embrace the Motto: Less Is more

Minimalism calls for leaving procedural information incomplete; this is one of the more controversial aspects of this philosophy. The ultimate goal of the Minimalist manual is to get people to act; leaving things out is one way to ensure interaction with the computer program:

Rather than explaining or showing it all to users, writers can use pointers and prompts to have users infer things. A key principle for not spelling out everything is to omit information that can be inferred easily (Carroll and Van der Meij 256).

Certain actions are obvious and if the outcome of these actions is different from what the user expects, then the user learns. Rather than describing the outcome of the Enter key, let the user try it out. The user must move toward dependency on the program for instruction rather than the documentation. Carroll suggests leaving the "screen information" incomplete when describing operations in the manual. Manuals that thoroughly document each aspect of the screen, encourage fixation on the manual instead of the task. It is better to have the user flip attention between the screen and the help text actively drawing conclusions from both. The documentation should shift the user's confidence to the screen with prompts like "Look at the screen to see what further actions you should perform" (Carroll and Van der Meij 257). Ultimately, the writer cannot document every single experience that the user may encounter. It is more responsible for documentation to transfer the user from being a reader to being a doer.

A Practical Critique of Minimalism: Does it really work?

When one ponders Minimalist treatment of users, one cannot help wondering if it will really work. It is somewhat akin to the waterbabies movement in the 1970's, whereby parents and instructors plunge babies into swimming pools to arouse their instinctive ability to swim. While the theory sounds good, the practical application seems frightening.

A significant core of technical writing practitioners applies Minimalist design to its work and some Minimalist principles are commonplace (e.g., task-oriented writing). Other principles are unpredictable and practitioners typically ignore them (e.g., leaving information incomplete). Even the architects of Minimalism recognize its practical problems. Carroll and Van der Meij wrote "Principles and Heuristics for Designing Minimalist Instruction" in 1995, citing the reason that "practitioners find it hard to develop Minimalist instruction because of a lack of specific guidelines" (243). By studying the gap between Minimalist theory and practice, one can pinpoint where to apply innovation. It is possible that a readjustment of Minimalism and its applications can solve some of these problems.

Do We Want To Learn Or Just Get Something Done?

Minimalism assumes that the best way to get something done is to learn about it (Carroll Nurnberg 74). However, most people would claim that there are times when one wants to learn a program and there are times when one wants to use it to complete a single task (Draper 5). Practical problems arise when the technical communicator has to decide to write for learning or doing. Stephen Draper, a psychologist and lecturer in Human Computer Interface, considers Minimalism useful, but difficult to put into practice:

. . .is a "minimal manual" aiming to be a reference manual to support work or a tutorial that can direct the user to do tasks to achieve an optimal training sequence? People hired as experimental subjects for research labs, and users on a training course for software, may have some patience for tutorial instructions; many others do not and expect to get useful work done (5).

Draper makes two interesting points in this passage. First, he distinguishes between manuals that support work and others that act as tutorials supporting people. Carroll collapses these ideas into one claiming that in order to get work done, one must teach people. Second, Draper calls into question Carroll's research suggesting that paid trainees put up with tutorials because they place themselves in a learning role. However, the "real-world" does not tolerate tutorials. There are instances when it is simply better to concentrate on doing rather than learning; Cooking is a good example. Recipes mete out step-by-step instructions that often seem illogical. The subject blindly follows these instructions, switching bowls and preheating the oven, without any knowledge of why this is necessary for making the perfect cheese soufflé. This style of instruction does not teach the subject anything, it just gets the subject through the task successfully. Recipe-style instruction (step-by-step) may be a better way to do some tasks.

Explanation Or Guided Exploration?

Minimalism downplays the need for explanation; it calls for cutting definitions, commentary, introduction, and overviews. Except in the case of error recognition and recovery, it encourages the user to explore. Again, one has to call into question Carroll's research, or perhaps his angle of observation, for coming to this conclusion. Exploration is an interesting notion; it generally implies a physical experience. It usually means that the subject has sensory exposure to the thing being explored. Where visual experience fails, one resorts to tactile experience. Interaction with computers is less physical as they limit humans to using only the visual and aural senses. Much of what goes on within a software program is invisible and silent. Does the user really have the opportunity to explore the workings of software? As Draper points out, "there are a few cases where [explanations] are vital to allow the user to understand some hidden pattern in action procedures (e.g., hidden buffers linking the effects of cut and paste)" (5). When faced with invisible software workings, new users typically exclaim "what's happening?" and this response rarely motivates the user to explore further. Guided exploration sounds better than weighing down the text with explanation, but can it really stand on its own?

What About Audience Range?

One of the most fundamental problems for the technical communicator is the range in audience. No matter how much audience analysis one does, one has to create a stereotypical user who is a conglomerate of the real audience. Keynote speakers fumble over whether to define the Internet at conferences, and user guide writers question whether everybody understands how to use a mouse. Dealing with audience range is messy. By cutting the detail in a Minimalist document, one provides less support for this range. Although usability testing accompanies the slashing of content, a Minimal manual has less depth. Carroll draws heavily on a user's first encounter with software. He focuses on the initial stages of learning rather than how users evolve. Each person, over the course of using the software, has the potential to be a beginner, novice, intermediate and advanced user. Can a Minimalist manual, which is a very good jumping off point, service the user over time? Carroll does distinguish between beginners and experts: "Experience transcends merely knowing more; it implies more deliberate, or metacognitive (Flowell, 1979) management of one's own interactions" (Nurnberg 94). Experts not only absorb more content, they process the interaction with software better. They acquire skills that they can apply to completely new software. How will a Minimalist manual support a person with accelerated learning skills?

Does Minimalism Run Counter To Good Writing Style?

Minimalist manuals are very difficult to write. No university writing course promotes incompleteness, open-endedness, and a rejection of chronological ordering. Standard technical writing texts suggest overview and preview as essential facets of a good technical document. M. J. Killingsworth, in his Information In Action: A Guide to Technical Communication, describes the importance of forecasting:

Like speakers, good technical writers prepare their audiences for what to expect. By forecasting your main points, you allow readers to skip irrelevant information, and you prepare their minds to receive information in a structured form. To use a popular metaphor from cognitive science (the mind as computer), you create empty arrays, mental slots in the reader's mind for sorting information. (184)

Most technical writers forecast because people like to think chronologically. Minds read information that does not pertain to them and they move on to relevant information in a step-by-step process. For instance, if a user is able to install and independently get up and running on any program, then a Getting Started section is irrelevant. The section is not a hindrance, the mind simply fills that slot and moves onto the next chronological step. Filling these mental slots is motivational and confidence-building. Does the Minimalist rejection of chronology cause the user to feel haphazard and lost?

Are There Ethical Considerations?

The word documentation implies thoroughness; it leads the user to believe that all the information about something is accessible. In the past, manuals and user guides were written by software developers and they included detailed notes about each feature and button. While this style is not a good way to handle technical communication, there is still the expectation that the written material holds all the information. To a certain extent, the genre demands a complete explication of the product. Minimalist principles rest on the notion of incomplete tasks to motivate people to learn on their own. However, how can a technical communicator be certain that she has provided enough information to keep the user from harm? People rely on documentation in their jobs. Is it ethical to equip users with a learning model of documentation when their jobs depend on how fast they complete tasks? There are some crucial procedures that one cannot leave open to user exploration. One technical communicator describes the architecture of an online help system used for highway safety. She points to a situation when Minimalism simply would not work:

To code each of the variables, the coder must make a series of progressively more specific categorization decisions. Since it is important that the coders follow this procedure without skipping any steps, we structured the help text for these variables as a "question and answer" tree. Whereas the paper version cannot prevent coders from skipping to the end, which could lead to errors, the online version asks the right questions in the right order and reinforces that order in the coder's mind. In this way, using hypertext links allowed us to dictate what path the user should take to arrive at a given piece of information. (Alciere 72)

If the quantity of procedural variables outnumbers that which the human mind can learn or remember, then step-by-step instruction is the only choice. If it is crucial that one completes steps in order, then there is no choice but to limit the user to chronological actions. The technical communicator must question the context: if it involves the safety of human life, can one let the user learn through failure?

One also questions whether Minimalist manual writers will be more open to liability challenges (Brockman 101). While this fear leads to some of the worst technical documentation — when writers mention every single possible procedural outcome — at least one can be certain that the information is in the document. Today, software controls safety sequences in manufacturing plants, monitors quality control in the making of automobiles and reports on the hazardous levels of toxins in the air. Technical communicators must consider the ethical ramifications of not equipping users with all the information that they may need.

Rethinking Minimalism

Minimalism is not the guiding principle by which all manuals are written; yet, it appears to be the most user-oriented theory put forth in the area of computer-based training. It accepts the fact that manuals are boring, and that users rarely read them. It embraces user's foibles and absorbs them into the design. It stresses the user over the software and over the developer. But why do technical communicators still write step-by-step, how-to texts? Why are manuals laden with overviews and reviews? Why are training modules organized as brain-dumps whereby trainees sit and soak up information rather than experiment on their own? Part of the problem is that Minimalism seeks to widen user interest with a let them be attitude, an attitude that conflicts with the goal-oriented world in which users exist. Carroll's vision, above anything else, puts the user first. He places the learning subject in the centre and demands that a limitless world of exploration surround this subject.

Yet, there are times when Minimalist documentation is inappropriate. It is equally detrimental to users to assume that they always have the time and motivation to learn every task. J. John Brockman offers compromise. His work, Writing Better Computer User Documentation: From Paper To Hypertext, analyzes several models of technical communication including Minimalism. He draws on what he considers the best features of each model and gives concrete examples for implementing them. This is one way to handle difficulties with Minimalism. However, by combining models, Brockman takes away the full impact of each. Another alternative is to offer two completely different sets of documentation, a manual for learning and one that documents all features and tasks in a step-by-step manner. This is a better solution for the user, but it is not practical for the vendor. A third alternative is a help system that simultaneously delivers both learning and doing instruction. The technology now exists to make this possible.

HTML-based help is a medium through which one can build viable Minimalist documentation without depriving the user of the comfort of system-style instruction. One compromises neither philosophy with this system. HTML-based help grows out of technology developed on the World Wide Web. The motivations behind the WWW, a user-centric technology, converge with Carroll's treatment of users. One can easily embody Minimalism in an HTML-based help system because they both make the same claims about learning. What one does in theory, the other offers through technology.

Part Two: Creating Minimalist HTML Help Systems

Many of the philosophical underpinnings of the World Wide Web place the individual first. The Internet is a global network of computers. The World Wide Web is a way to view documents and publish information on the Internet. It springs from a communal decision. Masses of users agree to display information on the Internet in the same way according to the same standards. The Web grew and grows out of the individual's need to partake in a communal whole, and this growth is organic. Like a living organism, the Web has parts or organs which draw from and contribute to the whole. Integration with the whole is essential, because without it, parts simply fall off. As each part strives to become compatible with the whole, it still maintains a separate function and identity. Users feed this organic growth and this concept is revolutionary in itself. To a certain extent, the WWW stands in defiance of the forces that normally forge change in the world of computing.

While multinational corporations, like Microsoft, continue to develop Web software, they face the extraordinary reality that users control the Web. This situation runs counter to natural marketing patterns, which usually involve technological control over the user. For example, there is a thrust in the market to achieve cross-platform compatibility because the Web demands it. In this case, cross-platform compatibility means that computers running different operating systems (e.g., UNIX and Windows), can read the same Web page. Different users run on different systems and software vendors must consider all users, and the systems that they run, when designing components for the Web. The need for cross-platform compatibility affects developers and causes a movement toward programming languages that simultaneously support multiple platforms (e.g., Java). More simply, this means that a developer writes one program that supports Windows and MacOS, instead of writing one for each platform. The Web insists on dedication to all users through each stage of development. A final result in this example, is an increase in negotiation and information-sharing between software vendors. The industry must accept the fact that one user buys or downloads software from many different vendors and that the pieces must work together. The same user may have several different computers, that are running on different platforms and must be able to communicate across a network. To a certain extent, the Web inverts the user-vendor relationship; the vendor conforms to the user instead of the opposite. Interestingly, user control of the Web has been highly productive. Web pages proliferate across this environment breeding new software and massive amounts of information and no incentive by a commercial party has ever produced anything as big. The Web expands not only into the world of computing, but it changes the way we view communication and the nature of information.

Many of the advantages of HTML-based help stem from membership in the greater Web environment and the spirit of compatibility. HTML-based help is more than a new brand of online help; it is a transformation of what online help really seeks to accomplish. First, rather than simply supporting a piece of software, HTML-based help lets the user define the nature of the help system. The focus returns to the needs and wants of the user instead of on a piece of software. Second, HTML-based help uses Web technology, which moves quickly and voluminously. Therefore, HTML-based help can live parasitically off a greater body of technology preventing neglect and obsolescence. Third, HTML-based help systems have the potential to be "hooked up" to the Web, intermingling the user's desktop and the Web at large. Corey Bridges, NetHelp product manager for Netscape Communications, Inc, comments on the bridge between the user and the Web:

What I envision from help systems in the next few years is much greater connectivity between the end-user and the application vendor. To me, the biggest thrill about Internet-client-based help technology is not all the really cool multimedia whiz-bang stuff that you can do — you know, with Shockwave or Live3D or what have you. It's that an end-user can connect — through his or her help system — to, say, a tech support newsgroup, or a real-time online chat area with other users, or a support agent application that offers troubleshooting or usability tips. Hook that in with the ability to check the application vendor's site for updates to the application and the help, and you've got something really helpful. (Zubak NetHelp interview)

HTML-based help sits on the boundary between the user's finite world and the ever-growing network. Thus the user can go beyond the limited help content on her own system.

What Exactly Is HTML-Based Help?

HTML-based help is a type of online help. It is similar to Winhelp or the help system that ships with any computer program. More specifically, HTML-based help lets you:

Provide context-sensitive help for HTML-based intranet and Web applications. This means that you can add an HTML-based help system to any page on the WWW or an intranet that uses Web software.

Provide context-sensitive help for compiled binary applications without recompilation. This means that you can add HTML-based help to software that is not on the WWW. Software designers can add this help system to any program on nearly every platform, including Windows, Macintosh, UNIX systems.

HTML-based help is a combination of:

HTML

Components that extend HTML

Standards

Browser software

HTML

HTML-based help borrows from standard HTML (the technology that you see out on the Web) and it enriches it with more capabilities. HTML-based help looks and acts like pages on the Web, but it can do more.

Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another or from one operating system to another (e.g., from Windows to Mac). HTML is really just a way of displaying information.

For example, HTML tags tell browsers to make titles bold and centred:

This is a Title

Here is the HTML code used to create the line above :

<H2 ALIGN=CENTER><B>This is a Title</B></H2>

Here is an explanation of the HTML characters:

Components that extend HTML

HTML is a robust markup language, but there are several scripting, automating, and layout features that it cannot provide. If you want to do something fancy such as add sound, video or animation to your document, then you need to draw on components outside of HTML. Here are some of the components that extend the capabilities of HTML:

JavaScript

Javascript is a scripting language developed by Netscape. It is based on C++ and Java programming languages (Randall and Jones 492). It allows you to program interactive behaviour and craft responses to a variety of events, and user actions. It gives you greater control over playing different sounds, video and animation in a Web page. Javascript's central function is to bind other elements with your HTML like ActiveX controls, Java applets, and plugins.

VBScript

Visual Basic Script is a scripting language developed by Microsoft and based on Visual Basic and Visual Basic for Applications (Randall and Jones 443). It works in conjunction with Microsoft's web browser, Internet Explorer. VBScript serves the same functions as Javascript; it binds other elements to your HTML.

ActiveX Control

The ActiveX control, developed by Microsoft, is based on OLE (Object Link Embedding) technology. The ActiveX control enables certain features that HTML cannot provide. For example, HTML-based help uses navigational features like a table of contents and an index, that you find in WinHelp, or in the Macintosh Guide. You can create these features by adding the ActiveX control to the HTML. At the moment, only Microsoft's Internet Explorer Web browser supports the ActiveX control. However, Netscape has committed itself to making the Navigator line of Web browsers compatible.

Java and Java Applets

Java is a programming language like C++. An applet is just a little Java application that is easily transferred over the Internet (Randall and Jones 301). The HTML applet tag lets you embed these Java applets into your Web page. Embedded applets serve extra functions. You could use an applet to make a string of text appear and dissolve in an advertisement. For example, as the pictures below replace each other, one appears to dissolve into the next:

The sophistication of Java applets constantly increases and they are used for quite fancy enhancements to Web pages.

Plugins

Plugins mainly heighten the sensory experience of the Web. You can embed objects like sounds or video into your Web page and download plugins so that you can access sounds or video clips. Third-party software companies distribute these plugins and most browsers incorporate some plugins with the initial installation. You can download most plugins from each particular vendor's site on the Web.

There are many ways to enrich standard HTML. The point is that HTML-based help can always draw from this proliferating area of technology. Put simply, if you see it out on the Web, you can add it to your HTML help system.

Standards

Several parties embrace HTML-based help and have their own standards. They are standards because you do not need to use an authoring tool to create them. You just need to understand all the parts that comprise them. Several software vendors have made authoring tools to create these systems, but they are standards first. There are three HTML-based help architectures that exist in some phase of development, yet none of them have delivered on all promised features. They are Netscape's NetHelp, Microsoft's HTML Help and Sun Microsystems' JavaHelp. All root the technology in HTML, but they use different extending methods. Microsoft uses the ActiveX control to achieve certain HTML Help features, NetHelp relies on Javascript and JavaHelp on Java applets. The focus of this report will rest on Netscape's NetHelp, although all the standards are discussed in general.

Browser Software

Browser software displays HTML code so that you can view pages on the Web; it provides the graphical user interface. HTML-based help requires a browser as well and you must ship one with the help system. Microsoft's Internet Explorer must be shipped with HTML Help, Netscape Navigator is required for NetHelp and JavaHelp is slated to run on Internet Explorer, Netscape Navigator, and Sun’s own HotJava.

What is NetHelp?

NetHelp grew out of the Netscape ONE developer's environment. The NetHelp Software Developer's Kit (SDK) (http://www.netscape.com/eng/help/) is a component of the Netscape ONE SDK, a collection of application program interfaces (APIs) and standards for developing on the Netscape platform. This relationship means that NetHelp draws from a much larger pool of technology. All developers working on the Netscape platform, drive this pool, not only online help developers. NetHelp grew in response to complaints about Microsoft's WinHelp, a popular help system (it is built into the Windows operating system), which is not always well supported by Microsoft. NetHelp's Product Manager Corey Bridges points out "that with NetHelp you no longer have a half-neglected technology from a company that only grudgingly supports it. What you have with NetHelp is the full free market force of all the Web developers in the world" (Zubak NetHelp interview).

The NetHelp SDK claims that "NetHelp works on any platform that Navigator runs on, and the current uncompiled file design allows the same source files to be read by any Navigator on any platform "(SDK). The point is that NetHelp is a single-source solution, you only have to create one help system, and it runs on any computer that can run Navigator. Navigator supports 17 different platforms, including Windows 95, Windows NT, MacOS, and Unix. The NetHelp team created this standard because they were frustrated with having to write documentation for so many platforms and they needed one solution.

The NetHelp SDK describes how you create NetHelp systems and it provides sample Javascript that you can copy. If you are building a system that is fairly standard and does not include many extensions (e.g., Java applets), then the SDK gives you enough information. NetHelp is an open standard and Netscape encourages third-party software companies to develop tools to aid in the conversion and building of NetHelp systems. Several companies are already working on authoring tools for NetHelp and this will make it even easier for you to develop it. Blue Sky Software and several other companies provide conversion tools so that you can convert existing WinHelp files to HTML-based help. Companies that have already invested in WinHelp do not have to start from scratch when converting over to HTML-based help.

NetHelp uses frames technology and each help system contains a frameset file. A frameset file is really just a document written in HTML. When loaded by a browser, it divides Web pages into multiple, scrollable regions or frames so that you can display information in a more useful fashion. Each frame has a distinct URL (Uniform Resources Locator), which means that it can link to and be targeted from other frames within the same window. The Appendix provides a breakdown of the actual HTML tags used to create this NetHelp frameset file.

Using Netscape Communicator as a model, the picture and descriptions below give you a brief overview of the NetHelp user interface and its five frames:

Figure 4, Netscape Communicator's NetHelp System

1. Control Selection Frame

You are given 3 ways to search for a topic.

Contents — View a table of contents that gives you a list of all the top-level headings . When you click an item, the information appears in the Help topic area (4).

Index — Scroll through a list of the indexed keywords or search for them in the Look field. Neither NetHelp nor HTML Help, supports full-text searching on other pages within the help system and this is a serious drawback. If the Index is thorough, this minimizes the problem.

Find — Find words in the text of the help topic that is displayed (4) and you are given various options to limit the find, including Case Sensitive, Wrap Search and Find Backwards.

Figure 5, The Find On Page Window in NetHelp

2. Navigation frame

When you click on one of the radio buttons (Contents, Index or Find) in the Control Selection area, the Navigation frame adapts to your choice. For example, if you click Contents, the Table of Contents appears.

3. Header frame

You can use this area to help navigate through the help content. NetHelp has nearly abandoned the use of menus and most of the information that you need is visible, instead of being buried in the software. Graphics, in the form of icons, minimize the amount of language needed to describe the help category. Netscape Communicator is made up of several smaller programs; each icon represents one of these programs. For example, the pen and paper icon symbolize Composer the composing and editing section of Communicator. Because the system uses HTML, the header frame is customizable, which means that you can design your own icons and buttons. You can specify the destination of links according to chapters or categories of information, or you could simply omit them.

4. Help Topics frame

This area holds the help content, or the text, which is divided into topics. NetHelp provides the potential for context-sensitive help. Context-sensitive help is help content associated with the current task. It appears in context so that you don't have to search for it through navigation features like a table of contents. Many online help systems provide context sensitive help through a help key on the keyboard, NetHelp is only called through a button embedded in the software. You attach Javascript and a unique number to each button. That number relates to one of the help topics which also includes Javascript. When you click the button in the software, NetHelp opens with the correct topic showing in the Help Topics frame.

5. Utility frame

This frame lets you navigate the help system itself. The arrows take you forward and backward through the system. The print icon lets you print the help topics. The X icon lets you exit the system.

In summary, NetHelp is really a conglomerate of elements from various sources:

Figure 6, An Outline of the various parts that contribute to the NetHelp system.

NetHelp is all of these things. Third-party software simplifies the creation and conversion to NetHelp. Web technology enhances the online help and you are free to integrate whatever components you like. The SDK shows you how to create the five-frame interface, organize the context sensitive topics and include the Javascript so that you can embed the help buttons in your native applications or Web pages. The result is that no two NetHelp systems are the same. The developer has a great deal of room to mold the help technology to the needs of the user and the application.

Some Guiding Principles For Creating Minimalist HTML Help Systems

HTML-Based Help Lets You Support Learning and Doing

There is no reason why a help system can’t support a user who wants to learn, the minimalist prototype, and one who wants to simply get something done (Hughes 58). It is important to design systems that allow for vacillation between wanting to learn and needing to do. For instance, if you decide to order tickets for the ballet at the Web site of the local venue, you need step-by-step instruction to complete the task. You may never order tickets from this site again and it is a waste of time to learn the process. On the other hand, you may be forced to use several programs in the workplace and you want to learn how to use them thoroughly. HTML-based help gives you a great deal of control over the user interface, so that you can adapt the system to suit these needs. For example, HTML-based help makes it easy for the writer to provide both a learning sequence and a step-by-step instruction for each task that a user faces. It can be integrated in very simple ways, such as, by providing a Learn button and a Help button in each interface window. Using Javascript behind these buttons to call the NetHelp window, the writer can attach unique context-sensitive topics.

The picture below depicts the Preferences window from Netscape Communicator, but with the addition of a Learn button:

To extend this example, the figure below depicts the context-sensitive content that actually appears when you click the Help button:

The Help button is there to hold the user's hand as it gives step-by-step instruction for filling out each field in the Window. It is important to include this sort of help for those who do not want to explore. It is also important to include tutorial style information in each window for those who want to learn.

The figure below serves as an example of how you can integrate Minimalist tutorial information with even very simple configuration choices. (Note that this is a suggested way to improve this HTML-based help and the following example does not appear in the actual version of Communicator's NetHelp):

The Learn button could link to a set of exploratory sequences for the user to carry out, demonstrating the benefits of each set of customized preferences. The Learn button is there to challenge users who want to be challenged. It is not important how you provide tutorial information, whether you integrate it with regular help or offer it as a separate entity. It is important to provide this outlet so that users have constant opportunity to expand their knowledge base.

Hypermedia Environment

Minimalism calls for learning through exploring. HTML-based help offers you the ability to work within a hypermedia environment, which is highly conducive to exploration. Rather than just reading text, the learner moves in, navigates through, and absorbs help content. Hypermedia applications have certain criteria (Garzotto, Mainetti and Paolini 74):

Content

The content is the sum of the information. It includes pieces of static information like text strings and graphics, and active or dynamic media like sound, animation and video (made possible by extensions to HTML mentioned earlier).

Piet Westendorp writes about learning efficiency and the use of text, pictures and animation in computer-based instruction. In a number of tests, he concludes that users take longer to follow animated instructions than text-based ones. However, when they return to do the same task again, those who learned through animation are much quicker to repeat the task (401). The intermingling of active and static information can service different users for different reasons. Also, by mixing the two, you provide the sensory stimulation to keep the user interested.

Structure

This is the over-arching organization of the content. Some hypermedia applications encourage a "wandering through the clouds" structure (Thüring, Hannemann and Haake), while others constrain the learner within a building-style infrastructure. Microsoft's Art Gallery CD-ROM, for example, offers both experiences. The user can roam the halls of London's National Gallery stumbling into hundreds of images or take a guided tour of the art from a particular era (Garzotto, Mainetti and Paolini 76), complete with a lecture from an art expert. There is no reason why a help system can't offer an integrated structure suited to more than one type of exploration.

Presentation

There are different methods of showing the content to users. For instance, the system displays static information like text, while it plays active information like video.

Dynamics

Hypermedia is interactive. Dynamics govern how users interact with the pieces of information and move among them or navigate them. It is the control of the playing or linking. William Horton's Designing and Writing Online Help offers extensive suggestions for organizing dynamics in a help system. He describes how to create hyperlinked environments based on grids, hierarchies and webs (151). He is really designing the path through the help system as he presupposes the user's every interactive move. He notes that "users expect the writer to lead them through the jungle of information. They may not like being controlled or manipulated, but they do expect the writer to blaze trails for them" (160). Hypertext linking is not a new phenomenon, but HTML-based help allows for linking beyond the sphere of the desktop, (which is discussed in the next section) and this is new to online help.

While traditional online help systems are also hypermedia applications (e.g., Macintosh guide), support for HTML provides the potential for a richer hypermedia environment for these new systems. The Web constantly churns out easier ways to handle multimedia files that work across most platforms. This flexibility means that organizations running computers on different platforms can access one help system rich with multimedia content. It has always been relatively easy to share text. Now you can easily integrate graphics, sound and video across a network.

From the Desktop to the Intranet to the Internet

HTML-based help lets you explore within a collaborative community.

Figure 10, Help content is no longer limited to your desktop.

Because HTML-based help is rooted in Web technology, you can design help systems across networks. This system lets you click the Help button from a word processor and draw help content from your own computer. But it also provides hypertext links to content stored on the local intranet and on the Internet. An intranet is like an internet contained within one organization limited to specific individuals. You access it using Web browser software.

The picture below illustrates how you can use the Desktop to Intranet to Internet architecture:

Figure 11, Desktop to Intranet to Internet architecture

You can use this decentralized help architecture to store information in different places:

Content on the Local Desktop

The Desktop should hold information that users must have to complete everyday tasks. In the event that networks or connections go down, the user must be left with a core of the help content on his own local computer. Also, accessing the local hard drive is much faster than accessing information over a network. If speed is an issue, then store this information locally.

Example: A factory safety procedure should be stored on every local computer.

Content on the Intranet

Place volatile information on the intranet. In the past, one of the most cumbersome problems with online help or printed documentation was the fact that it was never up-to-date. Immediately following the release of a manual or system, it is inevitable that changes are made to software, departments shuffle, and work processes alter. By linking to content on the intranet from the local hard drive, you can keep things up-to-date.

Also, instead of reissuing a new help system to every user, you simply change the content of one file on a server. Distributing the help system is often expensive and time-consuming and convincing users to update software on their own computers is not always easy. Changing the content at the destination of a link is easier than changing it on every user's desktop.

The intranet lets users tap into the organization's knowledgebase (Zubak Moving From Winhelp ). By sharing information, organizations draw the most out of each user's experiences and work. You can store things like employee handbooks, departmental guidelines, white papers, product specifications, press releases and events calendars on the intranet (Bluesky 70). In this way, the intranet becomes the brain of the organization.

Example: The new procedure for calculating the value of a stock in a brokerage house changes daily, therefore, it should be stored on the intranet.

Content on the Internet

Linking to established sites on the Internet opens up a world of knowledge. HTML-based help gives the user access to software vendors and any online help that they provide for their customers. The Adobe Web site (www.adobe.com), for example, is a massive database of searchable information. You can get updates to printed manuals for Adobe software. You can peruse white papers, product specifications and style guides. An HTML-based help system can designate direct links to this free infomation. The Internet, a massive library of technical information becomes an extension of the local help system.

While many organizations already make use of the Internet, HTML-based help puts that connection into context. When you run into trouble, the online help produces a context-sensitive response. This means that the links out to the Internet are also sensitive to your particular context. You don't need to close your program, open a Web browser, locate a search engine and sift through various search hits when trying to solve a problem. The help system does this for you. By tapping the Web for information, you expand problem-solving possibilities and you support error recovery in a much more thorough way. You limit the chance of a "brick wall".

Example: If an individual needs to create a company newsletter, she can connect to Microsoft's Web site and download a newsletter template for Microsoft Word.

Information Types

One of the most difficult problems with any help documentation, print or otherwise, is the diversity among users or learners. One writer, Liz Ruest, complains that current trends in online documentation have alienated advanced users. She singles out Minimimalist design as a key culprit:

Minimalist trends in documentation are putting advanced computer users at an unnecessry disadvantage. If your application targets advanced users to any significant degree, consider some compromises before following the minimalist trend. In view of the needs of your experienced audience, more content, more reference material, more features, and more navigation might be appropriate. (12)

As mentioned, expert users do not need enticement, nor do lengthy procedures dissuade them. They expect documentation to be complete and Minimalism may be nothing more than frustrating for them. Information Types, a technology introduced with HTML-based help, addresses the problem of audience range in a very practical way. It gives you the ability to present content for a diverse audience simultaneously. The result is that one help system delivers several different types of help; beginners work through learning-style help, while experts, use reference-style. The browser appears to be intuitive because once you declare yourself a particular type, the system adjusts to your needs. The same help system caters to the person beside you in a different way according to his experience and needs.

Designers can also use Information Types to customize the form of help content. If you like to follow step-by-step instruction, then you can designate a particular style as an information type. If you prefer help to come in the form of pop-up reminders, then you can configure it that way.

A disadvantage is the fact that the writer has to create custom topics for each information type, which can be time-consuming. However, there are several good reasons for spending the time. First, no two members of one audience are really the same and generalizing the help content has never been an ideal solution. Second, the writer is delivering a system that supports a user's evolution from beginner to novice to expert. With Information Types, the help system is valuable and relevant to a greater number of users.

At the moment, only HTML Help, Microsoft's standard, supports features relating to Information Types. The help writer flags headings in the table of contents as a certain type. When a user selects that type, the entire table of contents adapts to that choice. Microsoft defines three different kinds of Information Types:

Exclusive — You can only choose one exclusive type at a time. Languages are commonly set up this way. For example, you could choose to view the help system solely in English, Spanish, or French. Or, you could gear it to a Mac or Windows user.

Inclusive — You can choose more than one inclusive type at a time. For example, you can designate yourself a beginner, which is one type and you can specify that the help is tutorial-style, which is another type. You may be in the marketing group and it is not necessary for you to view the Help designed for the Engineering group. If you select the marketing group type, then you have selected three different types at one time. HTML Help allows 50 information type definitions.

Hidden — In this case, the help designer selects the Information Type because the choices are hidden from the user. Sometimes information is confidential and you can hide the content for particular users without them being aware of it. If your help system is serving as a sales tool, you can hide some of the more laborious tasks.

Microsoft is working on organizing Information Types under categories, which would act as sets of Information Types. Ralph Walden, Microsoft's, lead developer for HTML Help, explains the impetus for creating Information Types:

Once we started getting feedback about what people wanted to do with Information Types, we realized that there could easily be too many Information Types to display to the user in a single list. Categories allow the author to group Information Types together. Since the user chooses Information Types from a wizard, each category gets converted into a wizard pane. For example, you might have a product category, a job description category, and a user level category. Each category could have any number of Information Types associated with it. You can have categories for inclusive or exclusive Information Types, but not for hidden Information Types (since they are never presented to the user). (Zubak Moving From Winhelp)

In the future, some Information Types will be configured upon installation of the software. A series of questions will be posed to the user and the answers will orient the configuration of the help system. By recording a user profile from questions like, Are you familiar with the Windows interface? or, Have you set up your own email account?, the help system can determine the user's level of ability. Overall, Information Types are valuable. They demonstrate an acceptance of the user as an individual learner with individual needs, however, they are efficiently contained within a single-sourced help system.

Embedded Help

The NetHelp and HTML Help standards are multi-window systems; when you click the help button, a separate help window appears on the desktop. HTML-based help can be embedded directly in an application window so that it is always showing.

The figure below gives a simple illustration of the concept of embedded help:

Figure 12, A mock-up of the Canvas Save As dialog outlining a possible area for embedded help.

Embedded or docked help is placed in the user interface, rather than in a separate window. There are several advantages to placing the help in the application. Minimalist design theory suggests that help content should be designed for non-linear reading, so that you can pick it up and extract the information that you need without reading it chronologically. Many online help systems are context-sensitive (e.g. Winhelp), but by embedding the help, you are providing ever-present context sensitive help (Zubak Developing Embedded Help). The help content supporting a particular window is in the window.

Embedded help overcomes the problem of learning a new interface. Michelle Corbin Nichols and Robert Berry pinpoint this problem and explain that "when users go to a help system, it is because they have reached an impasse and require assistance. If they must learn another interface just to use the online help, they are likely to be dissatisfied and further frustrated" (247). It also eliminates the problem of shuffling two windows on the desktop. If the help and the application are in the same window, then you do not have to move from one to the other when you have a problem. Embedded help blurs the distinction between the software interface and help, so that it is less jarring to move from one to the other (Rettig 22).

You can use embedded help for error recognition and recovery. Minimalism suggests that you should not scrimp on information that rescues the user from a problem. For certain programs, you can embed troubleshooting information so that the user doesn't have to leave the program at stressful times. If you can eliminate an annoying venture into a print manual or online help system by joining the written documentation and the program, you have achieved Minimalism. You have given the user the requisite amount of help content and a seamless vehicle through which to explore.

Merging HTML-based Help With the Interface

The ultimate goal for Minimalist computer-based instruction is to educate the user without the user being aware of it. If you want the user to explore, and draw the most out of instruction, then you must merge learning with completing the task. You can go one step further than simply embedding a distinct help window into an interface window. Instead of delivering tutorials, users guides and manuals that are separate entities, extract the bits and pieces of the online help system that are necessary and build them into the software product. Because HTML-based help is only a standard, you can customize the help system to suit any situation. By using HTML, you have the technological freedom to use elements that are useful and ignore the rest.

Most current software merges interface and help with things like pop-up button reminders. Although pop-up reminders are effective, you can do more to hide the help and still deliver assistance. The key to building a product that seamlessly incorporates a help system is to limit the system to necessary parts (e.g., don't include an index, if it's an encumbrance).

Netscape's Javascript Authoring Guide is an excellent example of how you can merge Program and Help.

Figure 14, Javascript Authoring Guide when neither Contents nor Reference is showing.

The Guide is so closely intermingled, with the help system (navigational features, buttons, support information and placement within the WWW itself) that you cannot distinguish between the two.

Authoring guides are an essential part of Web-based technology because the Web is built on standards rather than software. To a certain extent, authoring guides take the place of authoring tools, as they release each new standard. In that sense, Netscape's Javascript Authoring Guide is a tool; you can use it to create Web elements, and its navigational features are the help system. More and more, help systems will be concerned with getting the user the information necessary to create products.

The Javascript Authoring Guide uses three frames:

1. The left-hand frame is a scrolling navigational area. The information displayed here switches between Contents (Table of Contents) and Reference (a list of Javascript tags and syntax) , depending on the buttons you click across the bottom. In either case, when you click on a link, the content that you select appears in the right-hand frame.

Figure 15, the left-hand frame of the Javascript Authoring Guide displays the Reference.

2. The right-hand frame holds the authoring guide information. The Contents leads you to information about Javascript and how you can use it. Reference provides a description of Javascript syntax in alphabetical order. Notice that within this frame, there are internal links to each chapter. This lets you skip from subheading to subheading. For instance, under Using windows and frames, you can jump to Using frames and skip the others.

3. Across the bottom frame, you find only two buttons. They let you choose what you see in the navigational area. There are three viewing modes, and the buttons alter according to your choices.

By merging the help system and program, as well as the documentation and interface, you never feel like you are searching for help. And these buttons are truly Minimalist in that they are completely self-explanatory and task-oriented. You can only view one of three modes at a time, so the system only presents the other two choices. There is no superfluous information. The verbs Show and Hide buttons are the help system as they instruct and guide the user through the information. The buttons are also more sophisticated than offering three radio buttons because they communicate the action that is taking place. Radio buttons list the features, but they do not guide the future action of the user.

The Javascript Authoring Guide incorporates as much of a help system as it needs. You need to get around in this tool and find pertinent information, but you do not need every single bell and whistle. With an HTML-based help system you can adopt the entire standard (Netscape's or Microsoft's), but it is also easy to pare down the standard to the elements that you need.

Last, the Javascript Authoring Guide is a Web document which means that you have the Internet at your fingertips. You can move outward to other resources and Web sites for information that is not covered in this particular guide.

Conclusion

The term Minimalism does not capture the essence of the philosophy bearing its name. The industry often mistakes it to mean less words. Minimalism reduces the intrusion of documentation in the user's world. By doing this, the user experiences the freedom to learn and explore. Minimalism addresses users' motivation. Working from the premise that people do not read manuals for the sake of reading manuals, Carroll and his colleagues piece together a learning style that considers the environment of the user. Users complete tasks with software because they have jobs and they exist in a task domain. Working with the energy of the task at hand, instead of against it, is a better way to handle documentation. Lastly, Carroll investigates reading styles and concludes that reading in a non-linear fashion is common among all readers. Technical documentation is not like fiction, users move backwards and forwards through the text to draw out meaning. The Minimal manual, Carroll's ideal, sweeps away any hindrances to learning.

HTML-based help seeks to do the same. It provides a much broader outlook on the user and the user's membership in the World Wide Web. It gives the user a chance to learn through exploration rather than instruction. Non-HTML-based online help systems limit the user. They are finite packages of software and the information grows obsolete the moment it leaves the vendor. HTML-based help works against this predicament. The technology treats dynamically changing information as such.

HTML-based help is flexible because it is made up of components rather than a program. It is a very powerful set of Lego whereby designers can pick and choose from objects that all fit together. One can build the standard or create something wildly different. Customizing online help for a particular task domain is very easy with HTML-based help. It is finally possible to deliver different help to different users within one online help system.

Lastly, HTML-based help systems are hypermedia documents. One can take full advantage of hypertext, graphics, animation, sound and video provided through WWW-generated technology. Creating context-sensitive help that is rich with these components may enhance the learning process (Westendorp). In the past, working with hypermedia was usually a team effort between designer, developer and writer. HTML-based systems empower the writer because these hypermedia components are much easier to develop than they are with traditional online help (e.g. WinHelp) (Welinske). The writer, who has more communication with the audience, will be able to mold the technology to suit the application.

So far, HTML-based help is the best vehicle for embodying Minimalism in a technology. However, like any piece of technology, it will not show its value until people embrace it. NetHelp and the other HTML-based help standards are just infiltrating the world of computing now. Very few programs actually use it. As the WWW creeps into the private world of the user's desktop, HTML-based help will become more prevalent.