Introduction

This paper describes and evaluates The Help Program, a Macintosh application that has been created with the REALbasic programming language. The Help Program has four main purposes:

Commercial software packages are continuously upgraded with new features, making them more useful, but also has been making them more difficult to use than ever before. The vast array of menus and button bars found on even the most widespread software packages make them inaccessible to novice users. Extensive online help systems have become a necessity as applications have grown increasingly complicated and confusing. Unfortunately the "more is better" aesthetic has taken hold not only in the design of software, but in the presentation of online help as well. People sometimes complain that the help provided by commercial applications is of no benefit. The help is often just as confusing as the bloated applications themselves.

In its currant state, The Help Program addresses a number of problems found in conventional help systems. The Help Program is better than other help systems because it is more user-friendly, and because the help it provides is of a higher quality.

The Shifting Goals of The Help Program

The goals of this project have changed drastically during its development. The Help Program began with a different name and a different intention. Hastur’s Workshop, as it was originally called, was to be a program for assisting users of two applications called Forge and Anvil. Forge is a program which is used to create levels for the game Marathon Infinity. Anvil is another utility used in conjunction with Marathon Infinity. Over time, these programs have proven to be difficult to use, and they are ridden with bugs. Frequently discussions in the alt.games.marathon newsgroup deal with the problems people have using Forge and Anvil. For these reasons it seemed logical to create a comprehensive Forge and Anvil help system. The name Hastur’s Workshop was borrowed from a Web site designed by a company called Double Aught, the makers of the game Marathon Infinity. The site, which is located at http://www.doubleaught.com/hastur/index.shtml, describes how to use Forge effectively. The Hastur’s Workshop application featured the same lavish graphical style that appears in the Web site, which is displayed below.

Figure 1: Hastur’s Workshop online: The inspiration behind The Help Program

Two fictitious characters whose pictures appeared on the web site were also included in the application. These creatures, named Hastur and Grendel, acted as tutors, showing the user how to use Forge and Anvil. Their purpose was similar in the Hastur’s Workshop application. The tutorials featured in the application conveyed the teachings of these characters, reflecting their sometimes volatile personalities. During the early stages of development, the program’s interface was continually enhanced with more bells and whistles, in order to make it similar to the Web version. Much of this superfluous eye candy provided entertainment value without actually contributing to the effectiveness of the application itself. Eventually the program evolved to have an interface all of its own. Its appearance gradually became more polished. Eventually many of the more excessive graphics and animated sequences were removed to make the program simpler, more usable, and more stable. The interface retained several pictures of the host character, Grendel. This gave the program a distinct visual personality. The images below represent the program in the final stages of its development.

Figure 2: The main options screen in Hastur’s Workshop

As the above screen image indicates, all the options offered on the Main Options screen were hard-coded into the application. Since the programs Forge and Anvil were very limited in scope, only a small number of tutorials were needed in order to convey everything that needed to be learned. Therefore it was possible to include the tutorial content in the application itself, instead of making the program refer to separate data files containing tutorial content. "Hard coded" content proved to be easier to create than "soft coded" tutorial files.

Hastur’s Workshop delivered tutorial content via a global floating window, which included forward and backward arrow buttons for stepping through tutorials. Also included was a "Leave me Alone" button for quitting the program, and a "Main Topics" button for accessing a list of additional tutorials. Figure 3 shows this floating help window.

Figure 3: The GrendelPod, a global floating window used to give tutorials.

This floating window appeared on the screen in conjunction with Anvil, the program it provided help with. The window provided step-by-step instructions, which the user would follow. At any time, the user could switch to a different tutorial or tell the program to "Leave Me Alone", which would make the floating window disappear and allow the user to work within Anvil on their own.

In its final form, Hastur’s Workshop was a slick, stable application with a purpose. That purpose however proved to be too narrow. The number of people who needed help with Forge and Anvil turned out to be far lower than had been anticipated. Furthermore, another person had been working on an electronic document explaining all the information Hastur’s Workshop had to offer and more. Although it was not as sophisticated as Hastur’s Workshop, this text document proved to be an efficient way to provide helpful information about Forge and Anvil to those who needed it. The person who wrote that document evaluated Hastur’s Workshop and suggested that the program should be expanded so that it could provide help with other applications, not just Forge and Anvil. The concept behind Hastur’s Workshop was solid, but it needed an audience.

Hastur’s Workshop was slowly converted into an application that could help users of all kinds of software- business applications, graphics programs, and even Web browsers. As the goals of Hastur’s Workshop shifted, several changes became necessary. Those changes included removing all references to the characters Hastur and Grendel, stripping the interface of the remainder of its eye-candy, and establishing a plug-in format for tutorials, since the expanded scope of the program meant that tutorials would be too numerous to be hard-coded into the application itself. In order to assist developers of tutorials encompassing every application from SimpleText on up to Photoshop, a tutorial editor was created. Soon it was realized that a distribution method was needed for user-created tutorials. A tutorial file server was established and Internet features were built into the program so that users could send and receive tutorials. Meanwhile, with the Hastur and Grendel theme having been removed, the program lost its visual appeal, and become uninteresting graphically. This made it necessary to add a skins feature, so that the program could once again achieve a dynamic look. The skins that were created for the program provided a variety of interface designs, each of which were just as distinct as the original Hastur and Grendel theme. Lastly, the name of the program had to be changed to the all-encompassing title "The Help Program."

The development of Hastur’s Workshop was a big programming challenge. But even so, it did not prepare me for task of converting it to a program that could assist users with all applications. Of the several different goals that this program has had during the various stages of its development, the one goal that has remained constant has been for me to use the experience to learn something about programming. That goal has certainly been met. While creating this program I learned about a variety of things that I knew nothing about beforehand, such as methods, properties, loops, file streams, and memory management, all within the context of REALbasic.

A complete log of the development process of The Help Program can be found at the end of this paper. It is a good way to see how the program evolved, and how the goals of the program shifted over time.

Features of The Help Program

The main purpose of The Help Program has finally been nailed down: The Help Program exists to teach people how to use other applications. For example the program could give a step-by-step tutorial on how to check e-mail, how to find a lost document, or how to save a photo as a JPEG image. In addition to providing helpful assistance, the program allows the user to create their own tutorials. Users will be encouraged to contribute with their own knowledge so that the number of tutorials constantly increases. This ever-growing collection of information will in turn make the program more and more useful to more and more people.

The Help Program also gives the user access to collections of tutorials online. The purpose of this online collection is to provide a central repository of information that can be downloaded and expanded. This is the distribution center for the tutorials that users create. The idea is that users will be more interested in contributing to the collection since their contribution will be instantly available to all other users of The Help Program.

In addition to those features, the program also provides the user with a choice of several interface layouts, or "skins", which are meant to make the program more visually appealing and more fun to use. Skins can make the appearance of the program conform to the user’s personal preferences. One of the included interface designs is cartoon-like. Another is bland and business-like. Another is designed to occupy as little screen space as possible. Each will appeal to a different type of user. The more creative users will enjoy the ability to design their own skin. Creating skins is a straightforward process because the skin file format is simple and accessible. Skins are stored as a series of PICT files accompanied by a text file that serves as a script, bringing all the information together.

Using The Help Program

Upon launching The Help Program, the Floating Help Window is shown. This window is the most important part of the application. It serves as a main menu and as a way to present content. It contains tutorial text messages, forward and backward arrow buttons for progressing through tutorials, and three other buttons, for quitting the program, for editing tutorials, and for accessing additional help. Figure 4 shows the Floating Help Window as it normally appears.

Figure 4: The Floating Help Window

This floating window remains on the screen whenever The Help Program is running. Forward and Backward arrows are used to move through each step of the selected tutorial. The Get Help button reveals the Tutorial Browser, where a different tutorial can be selected. The Edit Tutorials button allows the user to modify a tutorial or create a new tutorial from scratch.

After reading the welcome message, the user may click on any of the window’s three main buttons. In the most likely scenario the user will need assistance with an application, so he or she would click the Get Help button. This button brings up the Tutorial Browser, which is shown in figure 5.

Figure 5: The Tutorial Browser

This window displays a hierarchical list of tutorials to choose from

The tutorial browser is a large window containing a pop-up menu and three list boxes. The pop-up menu allows the user to select the program or Web site that they need help with. After a selection has been made, the list box on the left fills up with general topics pertaining to the selection. Clicking on one of these general topics causes the center list box to fill up with more specific topics. After a specific topic has been chosen, the list box on the right fills up with the names of tutorials that coincide with the specific topic that has been selected. After selecting a tutorial and clicking the OK button, three things happen: the Tutorial Browser window closes, the application that corresponds to the selected tutorial is launched, and the selected tutorial begins in the Floating Help window.

The Help Browser’s system of three list boxes were inspired by a preview version of Mac OS X, which featured a similar navigational system. In future versions of the Macintosh operating system, this navigation device may replace the Finder as we know it.

Figure 6: The Mac OS X Navigational System

This substitute for the Finder inspired the layout t of the Tutorial Browser in The Help Program.

Normally a tutorial begins as soon as the corresponding application has been launched. In the event that the application can not be found, a window appears asking the user to locate it (See Figure 7.)

Figure 7: Associated Application Message

This message appears if the application that is associated with a specific tutorial can not be found.

Clicking the OK button on this window brings up the standard Open... dialog box so that the user can define the location of the appropriate application. After the user tells The Help Program where the needed application is, the program will remember the absolute path to that application, and it will be launched as needed during subsequent tutorials. The Options... button allows the user to select a Web page to coincide with the selected tutorial (see Figure 8.)

Figure 8: URL selection box

Normally tutorials coincide with specific applications. For example a tutorial that teaches the user how to manipulate an image would automatically launch Adobe Photoshop. It is possible however for a tutorial to be designed with the intent of providing help with a specific Web site. In this case the user can enter the URL of a Web page to be displayed while the tutorial in question is in progress.

The user completes a tutorial by following the instructions given by the Floating Help Window (See Figure 9.) Instructions may be spoken aloud if speech is available. If speech is available and activated, the voice that has been selected in the Speech control panel will be used to read the tutorial aloud.

The instructions given in tutorials are sometimes accompanied by small images, which are meant to help the user focus their attention properly. For example a picture of Photoshop’s airbrush tool might accompany instructions telling the user to select the airbrush from the tool palette. Such images are displayed in a movable, global floating window directly above the Floating Help window.

Figure 9: A Tutorial in Progress

When the final step of a tutorial has been reached the forward arrow on the Floating Help window will become disabled. The user may use the back arrow at any time to review previous steps. The Get Help button may also be clicked at any time. This causes the Help Browser window to reappear, providing access to other tutorials. The Edit Tutorials button may also be clicked at any time. This brings up the Tutorial Editor window, which is at first similar in appearance to the Tutorial Browser. Although it looks similar, it serves an entirely different purpose: the Tutorial Editor is used to manage the user’s collection of tutorials. Figure 10 shows the Tutorial Editor in action.

Figure 10: The Tutorial Editor

This window provides a selection of editable tutorials. Clicking on the Floating Help Window’s "Edit Tutorials" button displays the Tutorial Editor. The buttons along the bottom of this window provide various options for editing the selected tutorial and for making changes to the hierarchical organization of tutorials.

Navigation throughout the Tutorial Editor is handled in exactly the same way here as in the Tutorial Browser. Clicking on a category in the first list box makes a list of subcategories appear in the next list box. Eventually an actual tutorial is reached. A strip of buttons along the bottom of the Tutorial Editor window allows several operations to be performed to the selected item. On the lower left is the Applications button, which brings up the Applications Manager window, shown in figure 11.

Figure 11: The Application Manager

The Application Manager is a feature of the Tutorial Editor that allows the user to define which applications he or she wants help with. The information stored within this list ensures that whenever a tutorial begins, the corresponding application or Web page will open automatically. If a needed application is not listed here, the user will be prompted to locate it before the tutorial begins.

The Applications button is used to select the applications that the program should provide help with. When an application is added via the Application Manager, the absolute path to that application is stored in a preferences file. This path information is called upon whenever a tutorial runs, so that The Help Program will be able to automatically launch whichever program it is providing help with. It may be necessary to use the Application Manager to update an application’s path information if that application has been moved to another location on the hard drive. This can be done by removing the name of the moved application from the list, and then adding it again.

Next to the Applications button on the Tutorial Editor window is the New Category button. This allows a new folder to be created within the hierarchical file structure, providing organization for the hundreds of tutorial files that are likely to exist on a typical user’s computer. When a new folder is created the user is be asked to name it. The folder is created inside one of the three list boxes. The list box that it appears in depends on which of the three list boxes has the "focus."

The organizational structure of the three list boxes reflects the file structure within the Data Folder (the Data Folder is located in the same folder as The Help Program itself.) Because of this, it is perfectly acceptable to organize a collection of help files using the Finder instead of the Tutorial Editor.

The Modify button, which is also located on the Tutorial Editor window, performs a different function depending on which item is selected. If a category is selected, then the Modify button brings up a window, allowing the user to change that category’s name. If the name of a tutorial is selected on the other hand, then the Modify button makes available a much wider variety of options. These options appear within a window called the Tutorial Text Editor. This editor allows the name of the selected tutorial to be changed. It also offers a preview of the lines of text that are associated with each step of the selected tutorial. This text can be modified with the Tutorial Text Editor (see Figure 12).

Figure 12: The Tutorial Text Editor

This window allows the user to change the name of the selected tutorial. A list box provides a sample of each line of text contained within the tutorial. These lines of text are editable.

Expanding the Disclosure Triangle at the bottom of the Text Editor window reveals the text that goes along with the selected step of the tutorial (See figure 13.) A pop-up menu provides the user with the option of selecting a picture to go along with the current step of the tutorial. When an image is included in a tutorial, it will be displayed on the screen above the Floating Help Window. Images will be included in the Text Editor’s pop-up menu as long as they are located in the same folder as the tutorial that is being edited. If additional images are needed, they can be added by clicking on the Hard Drive button to the right of the pop-up menu. There are two compatible image formats: GIF and PICT.

Figure 13: The Text Editor (disclosed)

The lower part of the window is revealed by clicking the disclosure triangle. It lets the user edit the selected line of text. A corresponding image can be chosen as well. This image will be shown along with the text when the tutorial is being given.

The features made available by clicking on the disclosure triangle can also be made available by double-clicking on one of the lines of text in the window’s upper list box. This brings up a separate window where text can be edited and a corresponding image can be chosen. The advantage of making these changes in a separate window is that since the separate window does not display a preview of each line of tutorial text, enough room remains on the screen to display a preview of the selected image (see figure 14.) In the example below, the user is creating a tutorial that explains how to shop online. The user is adding an image depicting the button bar in Netscape Communicator. In the chosen image, the Shop button is hilighted, so that the person using the tutorial will know that in order to shop over the Internet, they must click the Shop button. This is an example of how to use an image in a tutorial effectively.

Figure 14: The Tutorial Text Editor (double-clicked)

Double-clicking on a line of text in the Tutorial Text Editor window provides the same options as expanding the window’s disclosure triangle. Double-clicking reveals a new window providing an image preview in addition to the standard text editing and picture selection options.

The ability to create a tutorial is very important, because it lets users contribute their knowledge meaningfully. It is likely that a knowledgeable, interested user will be able to write a far more informed, comprehensive tutorial than an uninterested employee in a large, faceless software company. An employee faced with the repetitious task of writing help content during the crunch period of a software product’s development cycle can not be expected to do as good of a job as an independent person who is unpressured by deadlines, and genuinely interested in what he or she is writing about.

Another important issue is the user’s ability to deliver these custom-made tutorials to those who need them. That is why The Help Program provides direct access to a "Central Server", which is a powerful computer in a secret location that contains collections of tutorials. These collections can be freely retrieved and updated by the user. A collection of tutorials can be uploaded to the Central Server by choosing Upload to Central Server... from the Online menu. Figure 15 shows the Upload dialog box. A pop-up menu in that window contains the names of all all the applications and Web sites that pertain to the tutorials the user has installed. Choosing an item from the pop-up menu and clicking the Upload button begins the upload process.

Figure 15: Preparing to Upload a file

After a collection of tutorials has been chosen, the collection is automatically compressed, encoded, and uploaded to the Central Server. If an older set of tutorials for the selected application or Web site already exists, it is replaced with the newer collection.

There are a few steps to the uploading process, all of which are handled automatically after the user has selected a collection of tutorials to upload. First the selected collection is compressed by a custom helper application. This application copies the collection into a Stuffit archive, using the .sit compression format. The resulting archive is then encoded into the .hqx format. This process normally takes only a few seconds. Once the collection has been compressed and encoded, the resulting file is sent to the Central Server. After the file has been moved to the server, the .sit and .hqx versions, still on the local computer, are deleted.

Uploading is a way for a user to share their creations. But this information sharing process is not truly complete until someone else has downloaded the file. The Online menu provides this capability. The Download Tutorials... command makes the window shown in figure 16 appear. Inside the window a progress bar indicates that the program is connecting to the Central Server.

Figure 16: Connecting to the Central Server in preparation for a download

If Internet traffic is at normal levels, the window soon fills with a listing of collections of tutorials for a variety of applications and Web sites (see figure 17.)

Figure 17: The list of tutorial collections that can be downloaded

A collection of tutorials may be downloaded by clicking on the name of the collection and then clicking the Download button. Alternatively the desired item can be double-clicked. Just like with other Internet-related operations, the speed of the tutorial download process is affected by both the amount of Internet traffic and by the size of the tutorial collection that is being downloaded. If a collection contains a lot of images it is likely to take much longer to download than if it is composed of series of tutorials containing only text. Figure 18 shows the download process.

Figure 18: A download in progress

When the download is complete, The Help Program automatically decodes and decompresses the file. Then the resulting collection of tutorials is sent to the Data Folder, and the compressed version is deleted.

If at any time during the download process, the user interrupts the file transfer by closing the Download window, a dialog box is displayed asking the user if they are sure they want to stop the transfer (see figure 19.)

Figure 19: Online warning message

If the user attempts to exit the program while a collection of tutorials is being uploaded or downloaded a warning message will appear.

After an item has been downloaded, it is automatically decoded and decompressed. This process converts it into a standard folder, full of additional folders and text and image files, all of which are interpreted by The Help Program as an organized collection of tutorials. As soon as the collection has been decompressed, it is automatically moved into The Help Program’s Data Folder. The compressed version of the collection is promptly deleted. From that point on the collection of tutorials is available for use.

The Central Server is merely the default server. Although it is likely to remain the largest source of free tutorials, the user can change the server at any time by choosing Preferences... from the Edit menu and selecting the Online tab. (see Figure 20.) Four fields request the name of the alternative server, the specific directory being accessed, a user name, and a password. Any FTP server that the user has access to can be used to store tutorial collections.

Figure 20: The Online Preferences dialog box

The Online tab of the preferences dialog box allows the user to change the server that tutorials are uploaded to and downloaded from. The default Central Server is always available as an option, and it never requires a password to be entered.

Another tab of the Preferences dialog box is used for changing the visual theme, or "Skin" of The Help Program. Skins provide complete visual overhauls, and are capable of changing the interface of The Help Program substantially. For example the Floating Help window can be made larger or smaller and the font used by the program can be changed. Even the buttons on the screen can be moved. Figure 21 shows the instant effect of changing the "skin." Even the appearance of the Preferences window itself can been altered by choosing a new skin.

Figure 21: Skins Preferences dialog

The Skins tab of the Preferences dialog box box allows the user to select a different visual theme for The Help Program. Skin previews are provided as soon as the user clicks on the name of a different skin.

After clicking OK, the skin choice is confirmed and the more profound effects of the new skin are soon visible. The Green Blob skin, for example, changes the background of the Floating Help Window, as shown in figure 22. It also changes the labels on the buttons. A new "welcome" message appears. More importantly, this skin reveals an additional capability of the program that remained untapped by the default skin: an animated character appears. Its behavior changes depending on what the player does. Clicking the forward arrow button makes the Green Blob look to the right. The back arrow makes him look to the left. Other buttons make him do other things. He becomes unhappy if you click the "Leave Me Alone" button. This adds some much-needed entertainment value to the program.

These animations are stored as Quicktime movies. This means that very intricate and lengthy animations can be created to give life to whatever characters might be conceived of for additional skins. Naturally the Quicktime format allows for sound effects and music, as well as for moving images.

Figure 22: The effects of a different Skin

Changing the program’s Skin has an instant and substantial effect on the appearance and behavior of The Help Program. As this image shows, skins can feature character personalities and altered window text. In addition, skins can change the size and shape of windows themselves.

Of course skins could cause the user to become distracted if they have too many bells and whistles. The best skins do not simply look good; they make the program more functional. The Compact Skin, as shown in figure 23, is designed to make efficient use of space. Smaller fonts are used, unnecessary interface elements have been eliminated, and there is no host character and no eye-catching details. It is purely functional. Anyone with a small computer monitor would probably prefer to use this skin instead of the hulking, 640-pixel wide Green Blob skin.

Figure 23: The Compact Skin

This skin illustrates the use of a skin for functional improvements as well as for aesthetic modifications. The Compact Skin displays all help information in a window half the size of the default skin. This will appeal to users with small computer monitors.

Skins are stored within a special "Skins" folder, located in the same folder as The Help Program itself. As long as a skin is inside the Skins folder, it can be selected from the Preferences dialog box. Skins are stored not as single files, but as a folder full of the various components that together define the skin. If all the components of a skin had been located together in a single file it would have been very difficult format to modify. Modifying a skin of that format may have required a specialized skin editing application with a level of complexity approaching that of The Help Program itself. Instead, the components of each skin are readily accessible from within the Finder. Each skin is made up of one text file, several PICT files, and several Quicktime movie files. The text file contains over 100 lines full of numbers that determine the placement of buttons and other interface elements within the program’s windows. Other information within the text file determines which fonts are used by the program, which Quicktime movies to play and when, and which images are used as backdrops for the various windows within the program. In total the text file has 150 lines of data. The PICT files and Quicktime movies that are also contained within the skin folder have simpler purposes. They are called upon by the text file to provide a distinctive "look" for the program. Inside the Green Blob skin for example, is a simple green PICT image, to be used as the background of the Floating Help window.

Besides allowing the user to change file servers and skins, the Preferences window also lets the user turn speech on and off (see figure 24) If the Enable Speech check box is checked, the computer will speak the names of categories and tutorials whenever they are selected in the Tutorial Browser. Clicking the Speak All Tutorial Text Check box makes the computer read aloud all the text displayed on the screen as a tutorial progresses.

Figure 24: Speech Preferences dialog

The Speech tab of the Preferences dialog box allows the user to control whether the computer speaks tutorial names and tutorial text.

One potential advantage of enabling both speech options is that the user would no longer have to read the text that is shown in the Floating Help window. Instead he or she could simply listen to it. This would allow the user to devote all their attention to the problem at hand. In fact, a special skin could be be created that does not display any text at all within the Floating Help Window. Without text to read, the window could be even smaller than the window provided by the "Compact" skin.

Using The Help Program is a straightforward process. The program provides many advanced features for accomplished users, while hopefully retaining enough simplicity to make it appeal to novices as well.

Help System Precedents

Help programs have existed for years. Common applications have featured online help for at least ten years. Since 1992, the Macintosh has offered Balloon Help, a highly effective but underused method of assisting people with software. For several years in fact, the Mac OS has offered a help system that looks and operates similarly to The Help Program. Mac OS 8.5 introduced additional features. It uses a separate application called the "Help Viewer," which vaguely resembles a Web browser. It lets the user search for helpful information by typing in a keyword, or by browsing through lists of topics. Unfortunately once a tutorial has been arrived at, this system often puts all the step-by-step information onto the screen at once rather than breaking it up into small, manageable tasks. An inexperienced computer user might be overwhelmed by the large quantity of information that they are forced to digest all at once. The Help Program lets the user use a similar "browser" to find the desired topic, but once a topic has been chosen, it uses the more favorable step-by-step approach, in which each step is given independently of the others, so that the user is not confronted with an overabundance of information.

Many commercial software programs utilize a separate application for help which is similar to the Help Viewer. This utility is called "QuickHelp." It also lets the user type in a keyword or browse through a list of topics. Just like Apple’s Help Viewer, it features robust searching capabilities. It is also similar in that it displays all the help content for a particular topic on one screen, instead of guiding the user through a procedure one step at a time.

How is The Help Program better

The Help Program has a few main selling points that make it more useful than conventional help systems. The most important aspect of the Help Program is that it forgoes the help that ships with commercial software in favor of user-created help files. Since users of the program are capable of submitting their own tutorials, it is likely that The Help Program’s tutorials will be of a much higher quality than the tutorials that are hastily written by uninterested programmers just before an application is set to ship. The notion that users can contribute to the improvement of a product is a common idea among software developers. Linux users enjoy an ever-improving operating system that is enhanced by its users’ contributions. The Mozilla project is slowly producing an open-source Web browser that is shaping up to be a substantial improvement over current browsers. Apache software powers most of the world’s Web servers, and it is also open-source. if people are willing to contribute their time and efforts to projects as overwhelmingly complicated as these, then they can certainly be expected to contribute some effort to the creation of a better help system.

The tutorial creation capabilities of The Help Program are supported by built-in access to a "Central Server", which takes the idea of tutorial creation a step further by allowing the user to submit their creations to the central repository of tutorial collections. The process of submitting a tutorial is exceedingly simple. The program automatically handles the task of compressing and encoding a tutorial collection to ready it for upload. Similarly, the user can access the server to download the files that others have contributed. It is thus possible to have a rapidly growing, continuously updated collection of tutorials written by people who put care into their work.

Another way in which The Help Program improves upon other help systems is the Skins feature. The skins used in The Help Program are capable of adjusting the interface to suit a wide range of tastes. In addition to making the program look better, skins can make the program more functional. As explained earlier, a skin that makes the Floating Help window smaller effectively makes the program more useful on a computer with a small monitor.

The most basic improvement The Help Program makes over conventional help systems is also one of the most important. The Help Program forgoes the standard full-sized window approach to displaying content in favor of presenting it in a smaller window. When help is displayed in a large window, the application that the user needs help with is partially hidden. This makes it necessary to switch back and forth between applications while following instructions- and multitasking is a skill that novice computer users do not posses. For this reason it is important that the help window be small enough so that the user can see both the help text and the application they are working in. To ensure that both The Help Program and the application that the user is receiving help with are both entirely visible at all times, the Floating Help Window is just that- a small, global floating window that is never obscured by overlapping windows. Another benefit of having a small window is that it must contain less text. The less text the user is required to digest at once, the less likely it is that they will become overwhelmed. In accordance with this concept, The Help Program limits each line of tutorial text to no more than 300 characters.

Shortcomings and Suggested Improvements

The Help Program suffers from one overriding problem; it is not an intelligent piece of software. In a book describing a powerful help technology called EUROHELP, two important requirements for a successful help system were listed. Both of these needs are missing from The Help Program:

These requirements are difficult to fulfill. The Help Program would have to be heavily modified in order to communicate directly with another application. It would be difficult mainly because the format of the information that defines an application’s state is different from one application to the next. Therefore it is hard for one application to decipher what another application is doing. Analyzing the contents of the screen to determine the state of a program is not a feasible option, because when windows are moved by the user the screen image changes drastically, making the state unrecognizable to software.

The other requirement listed in the EUROHELP book, the need to intercept and interpret all input and output between the application and user, is also a challenge. When a given application is in the front, it is the first to receive keystrokes and mouse clicks. Perhaps a system extension could intercept and analyze user input before sending it to the application. Doing the same with output is potentially much more difficult, because a program’s output is nothing more than a screen image. A specific screen image can not be anticipated and then modified by the help system because there are an infinite number of ways for an application’s screen output to be displayed, depending on variables such as where the user has placed the program’s windows, which Kaleidoscope theme is being used, etc. It would be more feasible however, for the help system to analyze the states of the properties within the application itself- but that analysis would have to be completed before those properties have a chance to influence the application’s output. These properties are simple strings and integers, and therefore they are more predictable.

For example, assume a given application has presented a dialog box with the message "Sorry, but an error has occurred." This would be a great time for the help system to kick in and give the user more information on what has gone wrong. Analyzing the screen image (if that is even possible) only returns the fact that something has gone wrong. No additional details can be extracted from a reading of the screen. But if the help system could find out what the values are contained within the variables that the application has loaded into memory, then it would be possible to extract information that could benefit the user.

Even this is difficult, because in order to decipher the format of values stored in memory, the help system would have to be geared specifically toward the application that it is helping with. An ideal help system should not have to be rewritten every time a new application is released. In fact, the ideal help engine should already be compatible with still unreleased applications. This is an immense problem, and it seems as though the only way for a communication to exist between the help program and the application, without an excessive amount of work on the part of the programmer of the help system, is to have the application talk to the help system, instead of having the help system probe the application for information. This would force the designer of the application to conform to a set of standards by which all applications are supposed to relay information to the help system. The burden of work would be shifted to the designer of the application. It would seem that in order to implement this communication, so much additional work would have to be done by the application programmer that he or she would probably opt to forego compatibility with the help system in favor of providing built-in help. An even more likely scenario would be for the programmer to forget about a help system altogether and instead focus on releasing the software on time and on budget.

The Help Program is lacking in many other ways, but most of the necessary improvements should be far easier to accomplish than the task of getting the help system to carry on a meaningful dialog with the target application. The Apple Help Viewer and the QuickHelp application both offer many useful features that are not found in The Help Program. The most important of these is the capability to search for information by entering a keyword. With some modifications, The Help Program could ask the user to enter a word or phrase, and then search through all of the items in the Data Folder, looking for items whose names match the word the user entered. Something that would be just as useful, but more difficult to create, would be a Find by Content feature, similar to what Sherlock offers. Using some of the same programming procedures that were used to allow The Help Program to extract tutorial content from Data Files, the program could be made to search through the content of files, looking for specific text within the tutorials themselves. It would be a real programming challenge however, to create an application that could parse text files at the word level, as opposed to the line level, which is something that it is currently capable of doing.

Another great feature found in both QuickHelp and the Help Viewer is a system of hyperlinks, linking one help document to another. This would be very difficult, but not impossible, to implement in The Help Program. One potential stumbling block is having links in the middle of a passage of text. It may not be a good idea to force the user to choose between multiple paths while a lesson is in progress. This path-choosing should be done while in "browsing mode." The confusion caused by putting a branching path in the middle of a tutorial could be eliminated by offering links to relevant topics only at the end of each tutorial. If the links were always at a uniform location it would be easier to add hyperlinks from a programming standpoint.

One frustrating problem with the program cropped up unexpectedly during its development. The tutorial browser was originally meant to work in the following way: depending on the number of layers of categories required to organize a particular program’s tutorials, a different number of columns in the browser would fill up before a tutorial itself could be accessed. If a collection of tutorials for a basic program like SimpleText was made, then perhaps the leftmost column might contain all of the tutorials associated with that application. But if a complex program such as Ray Dream Studio had a collection of tutorials made for it, the number of tutorials would be too large and unwieldy to fit into a single column. Therefore the left column would contain general categories. Once a general category had been selected, the center column would fill up with more specific categories. After a selection had been made from the categories listed in the center column, the right column would fill up with actual tutorials.

Unfortunately this system does not work all the time. The tutorial browser acquired a bug that makes the program crash whenever tutorials are listed in its left column, meaning that all tutorials must appear in the center column or in the right column, and only after one or more categories have been selected first. This means that the tutorials must be located two or three levels removed from the root level of the Data Folder. The left column of the tutorial browser is consequently reserved as a place for categories that lead up to tutorials in the other columns. Most software is so complicated that one or more layers of categories are needed to organize the associated tutorials, making this bug irrelevant. Some programs are so simple, however, that it would be beneficial to have tutorials whose names are displayed in the left column of the tutorial browser. In any case, the program does not currently allow the user to create a tutorial in the left column, eliminating the possibility of a crash.

User-Suggested Improvements

Several sources have contributed information on how The Help Program might be improved. I myself suggested the first improvements; those suggestions have led to additional features, bug fixes, and continuous interface refinements throughout the development of the program. More recently I received feedback from users. The program’s testers have suggested both minor fixes and very broad changes to the program. I did not recognize the need for any sweeping changes while I was working on the program. That is probably because of the fact that most of the time I spent working on The Help Program was devoted to small details, and the work was done without regard to the program as a whole. I became so intimately involved with each minute aspect of the program that it was impossible to see the big picture. I knew all along that I would not have wanted to look at the big picture for fear that any sweeping change, however necessary, would render hours of delicate work inconsequential. This problem can be related to other fields; in art classes I have been told not to work on a single section of a painting or a drawing for too long, because that would destroy the integrity of the image as a whole.

I collected information from users in a couple of ways. First, I led them through common procedures such as retrieving help for a specific program, creating a tutorial, and uploading a collection of tutorials. I asked them to give feedback throughout the process. Most of the feedback came in the form of suggestions for interface design improvements. Users also questioned the organization of the program as a whole. The other way I gathered information from users was just by observing them, to see what aspects of the program they were stumbling over. Even if someone did not make a verbal complaint, I was able to see what parts of the program seemed troublesome.

Almost all of the suggestions that users made were unexpected, as were the problems they ran into. As the designer and programmer, I was unable to see for myself which parts of the program were poorly designed. The designer/programmer is undoubtedly the worst program tester. Since they know how everything about how to use the software, they will not be likely to notice any problems that make the program hard for others to use. For example I became so well aware of a specific bug in the program that I learned avoid it, while promising to myself that I would soon fix it. I slowly forgot about its existence, and became aware of the bug again only when someone else experienced it. The same problem that seemed unimportant to me was of great importance to other users.

Here then are the problems that testers have found, along with some suggestions as to how the program could be improved:

•The instructions given by the program are not bold enough to capture the user’s attention. This could be solved easily enough, through the use of a skin that changes the Floating Help window’s typeface to a large, bold font.

•When the program launches for the first time, the user is presented with a dialog box asking him to select the applications that he wants help with. Although the program does not let the user proceed until at least one application has been chosen, this should in fact be an optional procedure. This process defines the path to applications so that they they may be automatically launched as needed. Whenever a needed path can not be found, the user is given the option to restore that path. The path definition process should not be mandatory the first time the user has launched The Help Program.

•An icon-driven interface is preferable to an interface full of static text. It may help to make all the buttons larger and with more descriptive icons. The Tutorial Editor’s Modify button currently has a nondescript icon that looks like a letter A. The purpose of the A was to indicate that clicking the button would bring up a text editor, but the A is more confusing than helpful, since it has nothing to do with the word Modify.

•The three columns in the Help Browser window are initially empty. This proved to be confusing. Users did not know that a selection had to be made with the pop-up menu before the three list boxes could be used. One user complained "Why are there three list boxes when there aren’t even enough items to fill a single list" It is apparently not obvious from the outset that the three list boxes form a hierarchical system. Perhaps a single hierarchical list box would be better. The hierarchical structure of files would have to be handled by disclosure triangles, like in the Finder’s "List View."

•The Help Browser and the Tutorial Editor both utilize a pop-up menu in addition to three list boxes. The relation between these two different kinds of interface controls is unclear to some people. The pop-up menu is simply another way to make a selection, leading deeper into the file hierarchy. The exact same set of options could have been provided through the use of a fourth list box, located to the left of the first list box.

•The dialog box asking the user to locate the application corresponding to the chosen tutorial was troublesome. Occasionally this dialog box would appear behind a window belonging to a different application, making it invisible, and causing all mouse clicks to register a system beep (since it is a model dialog.)

Figure 25: Associated Application Message

Additionally, the standard Open dialog, used for location the corresponding application, also caused trouble. Navigating an Open/Save dialog is a skill that is difficult for novice computer users to learn. Once the needed program has been located, the next step, which is to click the "Open" button, is not at all obvious, since the user has been instructed to simply find the application, not to open it. This is more of an operating system deficiency, however.

•The function of the "Modify" button, found in the Tutorial Editor window (shown in Figure 10) changes depending on whether a tutorial or a category heading has been selected. This can lead to confusion when the user is expecting a consistent response from the program. As explained earlier, if a tutorial has been selected, the Modify button brings up the Tutorial Text Editor, whereas if the name of a category has been selected the button brings up a simple dialog box asking for a new name.

•When creating a new tutorial, it is not obvious to the user which list box the new tutorial is going to appear in. There is no explanation saying that the new tutorial will appear in whichever list box has the focus. On a related note, the significance of changing the focus is not immediately apparent.

•Once a tutorial has been created, it is not possible to move it to a different location in the file hierarchy. Actually this can be accomplished from within the Finder, by physically moving the tutorial file to a different folder. Users did not always realize that the organization of files in the Tutorial Browser reflects their organization in the Finder.

•The Text Editor section of the Tutorial Editor provides simple instructions, telling the user to enter the first line of text for the tutorial they are creating. A message in the window asks the user to enter that line of text on top of the instructions, as shown in the screen below.

Figure 25: The current text editor

A more elegant interface design would be to provide instructions above the text entry box, so that the user will never find themselves in the position of wondering "What did those instructions say to do" after he or she has already typed over them.

Figure 26: A concept for an improved text editor

•In the window that provides a selection of lines that may be edited, each line is truncated (see below.) The Mac OS’s way of dealing with lines of text that are too long to fit in their respective list boxes is to compress words together so that as much of the line can fit in the box as possible. This makes it more difficult to identify the line of text.

Figure 27: The Text Editor window currently provides no instructions.

Making the situation somewhat worse is the lack of instructions telling the user what to do. In this case, instructions actually do exist- the Floating Help Window explains exactly what to do. The problem is that since the Floating Help Window is separate from the Text Editor window, it is easily ignored. Simple instructions at the top of the text editor window would be very helpful.

It may actually be most helpful of all to do away with the current text editing system entirely and replace it with a more user-friendly system. One way to increase the user-friendliness of the text entry system may be to allow lines to be edited from within the list box they are displayed in, instead of forcing the user to enter another window to edit the selected text. This would not be a perfect solution, because only a small portion of the text would be visible at a time. A larger word processing window is preferable for text editing. Still another solution may be to utilize the Floating Help Window for editing text. The Floating Help window’s static text display could be replaced with an editable text field. The forward and backward arrows would retain their function- moving back and forth between the tutorial’s various steps. The downside to this approach would be that users may become confused, thinking that the Floating Help Window is in "Get Help" mode when in fact it is in "Edit Tutorial" mode.

This same type of confusion is currently being caused in another part of the program. Due to the visual similarities between the Help Browser window and the similar-looking Edit Tutorials window, (Figures 5 and 10, respectively) users are sometimes confused, thinking that one is actually the other. On the other hand, differentiating the two by using two windows that utilize two complexly different navigational systems would inevitably complicate the learning process. The user would be forced to master two systems instead of one.

•Most of the program’s commands can be accessed via buttons on the Floating Help window. Some commands however, can only be accessed via a pull-down menu. The menu-based nature of these commands make them inaccessible whenever the user is working in another application. All the commands that reside on the Floating Help window can be chosen even when a different application is active, since the Floating Help Window is a global floating window. It remains on the screen regardless of which application is active.

•Occasionally downloaded collections of tutorial files fail to move themselves into the appropriate Data folder. This sometimes happens whenever a folder of the same name already exists in the Data folder. It is important that this bug be fixed because it is useful to download a collection that already exists in one’s Data folder, so as to upgrade to the most recent collection of help files.

•The program utilizes a large number of windows and dialog boxes. This number should be reduced as much as possible in order to avoid confusion. One solution may be a complete redesign of the interface, so that the entire program uses only one window. Below, a mock-up of this interface shows a row of buttons along the left side of a window, and a large context-sensitive area to the right. This area could be used for choosing tutorials, viewing tutorial content, editing tutorials, uploading tutorial collections, downloading tutorial collections, and selecting preferences, depending on which option is selected from the list on the left.

Figure 28: A concept for a single-window interface

At first only the basic options would be shown. A disclosure triangle would provide access to advanced options, such as the tutorial editor and the online features. The potential problem with this concept is that cramming all of The Help Program’s options into one window might make that window so large that it would obscure whatever other program the user might be working in.

Figure 29: A concept for a single-window interface, with additional options

The above paragraphs have all dealt with problems that are all related to the function and structure of windows used in the program, and more specifically, the design of the interface within those windows. Other problems that were brought up by users are performance-related, and still others are the result of simple bugs that remain to be squashed. At this point however, the benefits of fixing any small bugs are slim if any of the suggestions calling for monumental changes to the program are to be carried out. Nevertheless, the performance issues are definitely worth mentioning.

The program is slow to draw graphics to the screen on any pre-G3 computer. This is especially apparent when images are being drawn to the screen. When images are used in conjunction with tutorials, the image appears in a window directly above the Floating Help window. The size of the window that contains the image is adjusted automatically to accommodate the picture that is being displayed. This size adjustment forces the window to be redrawn, which causes a portion of the screen to flicker momentarily. It was disturbing on a variety of different 601- and 603-powered computers, but it was barely noticeable on a G3.

Since The Help Program was created by an inexperienced programmer, using an inherently slow programming language (REALbasic), it is obviously much less efficient than it could be. The PowerPC build of the program is 1.8 megabytes. A "fat" version, compatible with both 680x0 and PowerPC computers is a whopping 2.9 megabytes. The fact that the source code for the program is less than ten thousand lines in length (or 240 kilobytes) indicates that a lot of space is being occupied by the REALbasic interpreter and/or extraneous code that is causing program bloat (the program’s resource fork occupies only about 150 k.) The program’s memory requirements are also large. At least 5 megabytes of RAM are required to ensure the program will not run out of memory and quit (or crash.) Memory is purged automatically in REALbasic, meaning that the programmer has no control over how the program uses memory. It is therefore difficult if not impossible to reduce memory requirements without removing vital features from the program. The overall speed of the programs leaves much to be desired as well, at least on an older computer.

For these reasons The Help Program should probably be recreated in a potentially faster and more efficient language like C. Fortunately, continuous improvements in computer hardware will soon make REALbasic’s performance issues irrelevant. On a brand new, top of the line computer, The Help program shows no signs of inefficiency.

Project Log

Spring 1999

Began work on my CS211 (Digital Interface Design, with Slavko Milekic) class project: an application meant to guide the user through the process of editing Marathon physics model files with Bungie Software’s Anvil; Created an elaborate interface mimicking the style of the Marathon Web site.

Added a tutorial browser so users could select the topic they wanted to learn about. The tutorial browser consists of a hierarchical list box full of options (something which proved to be very challenging to create.) Created a series of tutorials stored within the program, meaning that the program is not extensible. The good part about this is that the program is kept simple, since it does not have to refer to external files.

Added a feature where a small dot flashes on the screen, directing the user’s attention to a specific location on the screen.

June 1999

Added completely new tutorial browser that allows the user to access tutorial files stored externally. The tutorials are now stored as plain text files that can be modified with SimpleText. The program is now extensible, giving it an advantage over help programs like QuickHelp, which use help files that are not editable by the end user. My program however, still is meant to provide help with only one application, the Physics Modal editor Anvil.

Removed most of the gratuitous eye-candy associated with the program’s interface, making it considerably more stable.

July 1999

The program now has the ability to display PICT images to assist with instruction. Images are stored in a special image folder, and are called upon by a tag within the tutorial file. The addition of tags greatly complicates the process of reading tutorials into memory and properly displaying them on the screen. This is the most troublesome programming challenge I have taken on so far.

August 1999

I made the program available for downloading on my Web site. I received a lukewarm response from users due to bugs (I had not tested it thoroughly on a variety of system configurations.) In addition I received constructive feedback from users questioning the value of a help program designed to provide help with only one application (one which already utilized Balloon Help.)

Removed the remainder of the program’s elaborate interface, so as to make it more stable and to make it operate more quickly.

September 1999

I decided to continue on with this as my CS Div-1 project even though Slavko had left to teach elsewhere. I incorporated it into the Learning Revolutions class.

Expanded the scope of the program to make it work with all applications, not just Anvil; this required major changes to the tutorial browser and file structure. Accordingly I removed Anvil-specific interface elements.

Added speech capability; file names can be spoken as you browse through them.

October 1999

10/3/99

Added a tutorial editor, allowing users to make changes to tutorial files from within the program. The tutorial-editing window has buttons used for editing existing tutorials, creating new tutorials, creating new directories to organize tutorials, and for deleting any of the above.

10/6/99

Added an application manager so that the user can define exactly which applications he or she wants help with. A preferences file remembers the locations of each application, so that it can be launched automatically when it needs to be used in conjunction with the chosen tutorial.

Images that are used by tutorials are now stored alongside the tutorial itself instead of being stored in a special Images folder. This means that entire tutorials are stored as single packages, making them portable.

10/9/99

Changed the format of tutorial files. The new format allows for simpler, less buggy application code. Now pictures can be displayed and removed from the screen much more efficiently and reliably. The file format now allows for future enhancements such as the addition of sound effects, Quicktime videos, and any other features that may be needed eventually.

10/10/99

The tutorial text editor has been greatly improved; now no scripting is needed to display images during the tutorial. Instead the user chooses the desired image from a pop-up menu. Images that do not appear in the pop-up menu can be added with the click of a button.

Unsupported characters like carriage returns are automatically removed from the script before being saved to the tutorial text file.

A 300-character limit is imposed for each line so text does not run off the bottom of the screen when someone is trying to read it.

Removed additional bugs that appeared while I was adding the new features

10/11/99

Added Internet features! Tutorials can now be uploaded to and download from a central server. Users can now share their contributions with each other very easily.

I had a tough time deciding to what extent users would have control over the tutorial server. I decided to create a system that was not moderated, because I do not have the time to facilitate a continuous file exchange. I figured that an online system that was not moderated would have to be very simple so that the users did not screw anything up. For this reason I am not giving users access to multiple directories on the server. In addition users are not allowed to delete files. Since I can get to the same server using a standard FTP program I will be able to delete irrelevant files from time to time. This will be very simple since all the tutorial files reside in the same folder.

Before allowing a file to be uploaded, the program checks to make sure it is a properly compressed collection of tutorial files related to a specific application.

10/13/19

Started making variables that will come into play when "skins" are used to change the appearance of the program. I hope to build an editor into the application, which will let users create their own visual themes, just like in programs such as Mac Amp and Soundjam MP. The editor will be used to define over 200 variables, each of which control the appearance of the program in subtle ways.

Today I also swatted a major bug that prevented users from editing certain types of tutorial files.

10/14/99

Defined 120 variables used to determine the appearance and placement of various objects on the screen.

I spent a long time trying to decide how to store the "skin" files, which store information that determines the appearance of the program. My hope was to store skins as proprietary data files until it became apparent that storing text, numerical coordinates, and images within a single data file was going to be extremely difficult. Next I attempted to store skin materials within resource files, editable with ResEdit. This would eliminate the need for an editor program, since ResEdit would be suitable for the job. However REALbasic can only read and write PICTs and Quicktime movies from resource files, and skins have a great deal of textual and numerical information associated with them. My currant plan is to store skins as directories containing one text file, which contains text and coordinates, and several separate PICT files. This scheme will allow for complete skin editing with only a text editor and Photoshop (or some other image-editing program.) I will still make a skin editor, which I will build into the application itself, to make things as easy as possible for the user. The directories that hold skin materials will be located within a folder called "Skins," inside the application’s folder. Skin directories will have custom skin icons, which will conceal the fact that they are folders and not files.

10/15/99

Tested the latest build of the program on two Macs in the science building, just to make sure it worked on a variety of system configurations. Everything works great! It now definitely works on these systems:

Each skin will obviously have a different visual theme, and it will be up to the designer of that theme to decide whether to include a host personality (something similar to the paper clip guy in Microsoft Office.) For themes that include such a character, it will be necessary to have short animated sequences. Because of this I created a series of Quicktime variables, which allow the program to display different character animations as the user interacts in different ways. This will allow for positive feedback whenever the user does one of the following:

10/16/99

I am creating three "skins" for the program. As I enable more variables within the application, the skins are gaining more and more control over the look and feel of the program. There is still enough default information within the program so that it operates with no included skin files, but I may remove that capability in order to cut down on the size of the application itself. It currently stands at 1.9 MB, with about 215k devoted to the default skin. This number used to be closer to 500k, before I indexed the images.

10/17/99

Swatted another bug. Not sure if it’s dead yet but it has definitely stopped buzzing. Implemented 17 new variables today. 39 variables are now fully functional. There are 101 to go…

10/18/99

Created a plain default skin for the application, fixed more bugs, and removed the final traces of what had once been the original visual theme. This theme will be recreated as one of the skin modules later on.

I got the program to work properly when compiled for the 68k as well as for the PPC. Previously it had crashed when run in 68k mode.

I also streamlined the process of creating the list of applications that the program refers to when offering help options. This is something that should be done the first time the program is launched, and it can be done voluntarily any time thereafter. It is a mandatory procedure upon startup if the program detects the absence of preferences file data defining paths to the needed applications.

10/19/99

The floating help window now remains on the screen to assist the user in the edit tutorial mode.

10/20/99

Images used in tutorials can now be in the GIF format, as well as the standard PICT format.

10/21/99

After two days of attempts, I have gotten the online feature to work more intuitively. Instead of having to decompress collections of tutorial files after downloading them, the program handles this automatically. Furthermore, the decompressed collections are moved directly into the program’s data folder, eliminating the potentially troublesome task of using Stuffit Expander and then manually relocating a folder.

Similarly, uploaded files no longer need to be compressed by hand before being sent to the "Central Server." The user simply chooses which collection of tutorials to submit from a pop-up menu and the program handles the rest.

There are still some bugs to work out; sometimes files are not relocated, and sometimes-unneeded .hqx files are not automatically deleted. I will try to fix this, but this whole part of the program has been extraordinarily difficult to create. I think it’s going to be worth it though.

10/22/99

I worked the bugs out of the download/upload system. Now automatic compression, decompression, and file transfer seem to work flawlessly.

The size of the application, along with file compression utilities, is now just over 3 MB. I’m really happy to have finished this part of the program!

Created an image preview area at the bottom of the tutorial text editor window, so that when editing text, a preview of the associated image is displayed along with it. From within the same window, the user can select a different picture.

Global floating windows now disappear instead of obstructing modal dialog boxes that they would otherwise cover.

10.23.99

Made some interface improvements to ensure that everything will fit on a 800 x 600 screen

Fixed a bug that prevented the deletion of categories.

Created an option allowing the program to speak tutorial text to the user. This allows for the creation of very compact skins that do not waste screen space displaying text. Instead all information can be conveyed through audio.

Upon quitting, the program now deletes fragments of any extraneous compressed files that are created during aborted upload processes. Compressed files that are made during completed upload processes are deleted much earlier.

Added the capability to display a tutorial that guides the user through the process of navigating specific Web pages; in this case the preferences file that normally contains the path to the relevant application instead contains a URL. I still have to make a URL tutorial editor.

Created a set of variables allowing for the removal of what I think are the final remnants of the default built-in skin. Now the skin creator can control audio and textual messages that are delivered when the user clicks on the mascot character.

10/24/99

I Deleted some Internet features that I decided the user should not have access to, such as creating FTP directories and deleting them. I also removed several unneeded windows and combined the functionality of previously separate windows into single windows. This has reduced the size of the source code by 56k.The size of the final application has been reduced by 223k. The length of the source code has been reduced from 10,000 lines down to less than 9,000.

The program now allows you to define the URL associated with tutorials that do not have a corresponding preferences file indicating which Web page they should launch. For tutorials that do have defined paths, if the path starts with "http://" then a web page is launched. Otherwise an application is launched

10/25/99

Implemented ten more variables defined by skin plug-ins. These variables all relate to the position and appearance of the number that tells which step you are on while you are engaged in a tutorial.

Refined the interface on the multi-tabbed Preferences dialog box.

10/29/99

Implemented variables that can change the appearance of the error message boxes and the content editor box.

Ensured compatibility with Kaleidoscope.

10/31/99

I made several of the more complex skin-related variables functional. There are now 84 variables that function very well. There are 55 more variables to enable, but 53 of them will be very quick and easy to implement. I may want to add to the list of 84 in order to eliminate all aspects of the program that are not currently affected by the application of skins. The Internet features and the preferences dialog box are not enhanced by skins, and I would like them to be.

When choosing skins, a preview of the selected skin is now provided as soon as the user clicks on one of the choices. All of the planned features are now in place and only a small amount of bug testing remains to be done. The program is close to being finished. Now it can finally be evaluated...

Program Specifications:

Size of finished application: 1.8 MB

Length of source code: 9,483 lines of code

Size of a typical skin: 500 K

Memory required for operation: 3 MB

Reference:

Breuker, Joost. EUROHELP: Designing Intelligent Help Systems. Copenhagen: EC, 1990.