HTML Creator, as the name suggests, is simply a utility for creating web pages. It is not a WYSIWYG editor like Adobe GoLive, but it is also not simply a text editor with macro functionality to add tags. Instead, HTML Creator takes an innovative approach: the creation of web pages is facilitated through the use of informative, step-by-step assistants.

Because of the program's flexibility, there are a few different paths the user can follow to create a web page. In this review, I will try to cover each of these different paths, more or less in the order the user will discover them.

Opening the Program

Because this is a shareware program, the first window the user sees is a shareware notice (figure 1). Three buttons allow the user to order a registration code, enter the code, or continue with using the program; however, the last option is delayed by a ten second countdown. Since this timer essentially locks the user out for ten seconds, it might be considerate to include a "Quit" button as well in case the user need immediate access to another program. The first button, "Online Ordering" might be more clearly labeled with a command: "Order Online."

Once the shareware dialog is dismissed, the screen clears; the program is running, but no document is open. While a document can be created through the File menu, it is standard procedure to open a new, blank document when the program is opened.

The Toolbar

There is actually one window in view at this point: the toolbar at the top of the screen. The items on the toolbar are disabled, implying that they are not yet applicable. The window style is that of a utility window, and moving the window by its title bar allows the user to relocate the window. Well, not really, because the window immediately snaps back to its original position! If it were necessary for this toolbar to be fixed in one location, it would probably be better to use a window with no title bar. However, I can see no reason to prevent the user from moving this window to a different spot on her screen.

Creating a New Document

The New submenu under the File menu offers four different ways of creating a new document: "Document...", which utilizes the expert interface to set up the web page; "Document Guide", which takes the user to the step-by-step assistants for page design; "Document (Clipboard)", which creates a new window with the contents of the clipboard; and "Document (Blank)", which creates a new blank window.

Since the Document Guide is the easiest method for novices, this should be the top most menuitem. (It should also be what comes up automatically at startup.) It might be wise to rename these options to alleviate confusion and to maintain consistency in other parts of the program. Since the first two items allow the creation of a web page (complete with HTML structure), perhaps the following names would be clearer:

• Web Page using Assistant
• Web Page
• Document from Clipboard
• Blank Document

Selecting "New" -> "Document Guide" yields the New Document Assistant window, shown in figure 2. Because this window is an assistant, and therefore directed at novice computer users, we must be especially careful with regards to interface design. Here are some specific points:

• The title graphic is attractive, and while it is not extremely functional, it does reflect current interface style and gives the window a warmer feel. However, the term "Step by Step Guide" seems a bit general. Why not use a title that specifically describes what this assistant does? Also, this window has two different titles: one in the title bar and one in the graphic. Do we really need both?
• The Note icon is unnecessary in this context. The alert icons (the talking head, the exclamation point, and the stopping hand) should be used only when the program is seeking the user's attention. Since, in this case, the user expects the window to appear, there is no need to get the users attention.
• The system fonts (Charcoal, Techno, Chicago, and so on) have a very heavy weight and are not meant for large blocks of text. The legibility of this window will be improved if the Application Font (usually Geneva 10 point) is used instead.
• Consider the terminology in this window. The term "document" is pretty general, and in some cases (like word processors) it is the only term that accurately describes what the user is creating. However, we know in this case that the user is creating a web page! We can take advantage of this, and use the term "web page" rather than "document."
• Rather than referring to the "New Document Dialog," it might be easier for the novice user if we refer to the menu and menu item used to bring up the appropriate dialog.
• Double check this dialog for spelling, grammar and punctuation. Also, there is no need to use the term "please" in this context; the instructions are already written politely, and using the term please gives the feel of begging.

On the second page of the assistant (figure 3) as well as the following pages, the labels underneath each field are helpful. However, on first glance it is unclear whether they describe the fields above or below. A small spacing change on each of these pages will easily fix this problem.

On the fourth page of the assistant (Figure 4), the checkbox at the top of the window is a little unclear. Changing the text to "Use Cascading Style Sheets" would make its function immediately apparent.

Creating a Page without the Assistant

Choosing "New" -> "Document" from the File menu allows us access to the expert interface for creating a web page, and brings up the New Document Dialog (figure 5). This dialog and those that it spawns are all well-designed; the following notes pertain to minor issues.

• In the Meta Tags dialog, the instructions should indicate what to use to delimit the keywords (probably a comma).
• The Advanced button in the New Document Dialog should be changed to "Advanced Tags," which matches the title of the window it opens.
• The bottom of the instructional text in the Advanced Tags dialog is cut off.
• There is no need to use the term "Please" in the Advanced Tags dialog.
• "Margins" and "Background Image" should probably be separated into their own group boxes, since they are completely different things.

• Some of the text in these dialogs define terms, and others tell the user what to do in the dialog. It might be better to do one or the other (or both, if it can be done succinctly) to maintain consistency.
• Buttons should include ellipsis if they do not have an immediate effect on the file being edited.
• In this part of the program, it is possible to have up to three layers of dialog boxes on the screen. Is it possible to avoid this, perhaps through the use of a tab panel?

The Document Window

Whether we go through the assistant or the expert setup interface, we eventually reach the document window (figure 7), where we can see the fruits of HTML Creator's labor. At this point, we are free to edit the HTML either directly or by using the many assistants available in the menu. Following are some comments about this window:

• It's worth noting that in my case, the text is automatically displayed in my preferred font, Adobe Garamond. This was either an extremely lucky guess or (more likely) as a result of looking up the preference in the Internet Control Panel. A very nice touch!
• Overall, this is a well-designed window, and the button bar is nicely implemented. The only spacing issue that I noticed was that the text at the lower left of the window (which is replaced by the pathname when the file is saved) is a little cramped vertically. Perhaps reducing the font size to 9 point would solve this.
• And actually, how necessary is the information below the text field? One of the "holy grails" of Macintosh interface design has always been figuring out what to do with that area to the left of the resize rectangle. Some programs have very useful items that fit in this spot perfectly, but designers must be careful not to put things in this area for the sake of filling the void. A pathname can be unwieldy and confusing to the novice; the name of the document in the title bar will usually suffice. The version number of the program is a bit misplaced, since it pertains to the program, not the document. For an elegant idea of what to do with this area when you have nothing to put in it, check out Apple's SimpleText.

Revisiting the Toolbar

Now that we have a document open, the toolbar has leapt to life. Let's take another look at it:

• A bit of color might make the buttons a little more obvious when they are enabled.
• The Color icon is a little baffling, even to those who are familiar with graphics programs. Perhaps a color wheel or something similar will be more clear? If it is important to have an image that works in black and white, how about a painter's palette?
• The Insert Symbol and Insert Character windows have immediate effect on the document, and thus should not be modal windows.
• The divider lines in the Header menu can be removed.
• Any time the program asks for a file location (as in the Insert Image dialog), provide a method besides having the user type in a pathname. Pathnames are not intuitive to the beginning user, and even advanced users have trouble with them. This can be avoided simply by providing a "Select..." button which displays a Navigation Services window. In addition to this, allowing drag and drop from the Finder is a good idea.
• Watch out for the fine details in the toolbar icons; for example, the crossbar in the 'A' on the formatting button is almost non-existant.

Menus

HTML Creator has a very interesting approach to help in the menu bar: the first item in many menus is a help item which describes the menu's functions. This has the effect of replacing balloon help, which is not used in HTML Creator. Should these items be replaced by balloon help? At one point I would have said yes, but since Balloon Help is not included in OS X, perhaps this is a good replacement.

Of course, the dialogs that appear to describe these menus should not be red-bordered (which implies impending data loss) and should not beep when opened (which implies an incorrect action by the user).

The Insert menu inserts items into the document, which makes sense. However, the JavaScript menu also inserts items into the document; should it be added to the Insert menu? That makes the Insert menu even longer, which is a problem. Can this be remedied using more submenus? The Extras menu also inserts items into the document; in fact, each item is preceeded by "Insert." It might be worth reorganizing these three menus so they are grouped more evenly or spread out among more menus.

HTML Creator allows for the creation of shortcuts, which is very helpful for pasting in the rare HTML features that the program does not support. The ability to name these shortcuts (and have the names appear in the Shortcuts submenu and on the Shortcuts palette) would make this tool much more useful.

A Few More Random Things

Here are just a few items that didn't fit elsewhere in the review:

• In each of the dialogs—specifically, those that insert new tags into the document—it is important to be consistent with the placement of the instructional text. Generally, use the text at the top to tell the user how to use the dialog, and include further help-related text at the bottom.
• Kudos to the developer for implementing unlimited undo, a feature which represents a very high level of forgiveness and comfort for the user.
• In the Preferences dialog (figure 8), the tabs need to be bigger to handle the 12-point text.

• When closing an unsaved document, the "Save Changes" dialog should appear in the middle of the document window or in the middle of the main screen, not in the upper left hand corner of the screen.
• The Scratch Pad (figure 9) is nicely done. However, the menu at the lower right looks more like a part of a scroll bar than a menu. Perhaps a bevel button would work more effectively in this case?

• The Zoom Window command doesn't mimic the zoom button entirely; in fact, in only works to enlarge the window, and not to restore it to the original size.
• There are several spelling errors and grammatical mistakes throughout the program, some of which make it difficult to understand the help text.

Conclusion

While non-WYSIWYG HTML editors are fairly common, HTML Creator's assistant-based interface causes it to stand out from the crowd. The interface issues I've presented here are largely superficial, and do little to detract from the innovative design as a whole. With a little bit of interface polish, this already useful program will be made even more useful and intuitive.

[an error occurred while processing this directive]

The Interface Mafia - www.interfacemafia.org
News - About Us - Articles - Reviews - Submit Software - Links - The Mafiosi

this page last updated on Thursday, November 1, 2001
site design by tobyrush.com - web space by westhost.com
follow this link for copyright information