The MentorWizard User Interface
Previous  Top  Next

The MentorWizard Frame

Each step in a MentorWizard task is presented within an outer window or frame. The MentorWizard runtime engine displays and manages this outer frame. If so requested, this frame can be displayed inside a main window (as shown below), with a simple menu to support the usual GUI application functions such as Open and Close. It may also be displayed in a sub-window embedded in another application.

The following example shows my preference for text labels over icons (I am definitely not a Mac person). However, the visual effects can be changed to suit different tastes. For example, the tool bar could be fashioned as a row of small buttons with icons and no text. I put the tool bar at the bottom to give the user a top to bottom flow of activity, though the tool bar could be placed in its traditional position just below the menu. These and other cosmetic variations in the MentorWizard frame should be provided as user-selectable options.


MentorWizard Frame Widgets

The steps that make up an application are displayed within the central panel. The surrounding widgets help the user control the steps and display the status of a task to the user. The MentorWizard user interface frame widgets are described in the following table:

User Interface Element
Task Cache Display
This text display area (upper left in the sample, above) shows the most recent data added to the Task Cache (described below).
Click on this button to pop up a display all of the data currently held in the Task Cache.
Click on this button to display a map of all steps visited while performing the current task.
Step Panel
The central area of a MentorWizard holds the widgets in the current step. This area and the layout of its widgets adjust automatically when the size of the main MentorWizard window changes size.
Tool Bar
The MentorWizard tool bar is at the bottom of the main MentorWizard window. It holds the seven buttons that the user needs to operate MentorWizard.

The tool bar buttons operate as follows:

Tool Bar Button
Pend Task
Click on this button to save the state of the current task. The saved task can be identified by the name of the task, the user's name, the current date and time, and a name supplied by the user.
Resume Task
Click on this button to display a selectable list of all pended tasks by all users with the same role as the current user. Select a task from the list to reload the task in the same state as when it was saved. Note that if any context rules (described below) are based on the current date/time, they will be re-evaluated before the current step is displayed.
Cancel Task
Click this button to undo all the way back to the first step in the current task or sub-task.
Click on this button for more information about the current step.
UnDo Step
Click to undo the last step taken in a task. This button will be enabled only when you have taken steps that can be undone.
ReDo Step
Click to cancel the last undo. This button is enabled only after you have clicked on the UnDo button to undo one or more steps.
Next Step
Click to move to the next step in a task. This is enabled only for steps that ask the user to enter multiple items (typed data or items selected from lists).

MentorWizard Steps

The central panel in the MentorWizard frame displays steps that make up a task. The user interacts with each task step in turn. Steps behave like typical GUI dialogs: the user may enter free-form text, select items from lists, set options, or ask to see another dialog. However, MentorWizard steps always appear within the outer frame, one at a time. When a user has completed a step, it disappears and the runtime engine displays the next step immediately. The rapid presentation of simple steps makes performance support applications more efficient and effective than traditional GUI dialogs.


MentorWizard applications are constructed with a number of tasks and sub-tasks, each of which is partitioned into discrete steps. Steps can be used in more than one task, and any task can be invoked from any step. In this way, tasks and steps can be reused. The total collection of steps in an application are thus organized into a network rather than a hierarchy or fixed sequence. As will be discussed below, application developers can use various techniques to craft applications that respond dynamically to user input so that the traversal of an application's tasks and steps is usually different each time the application is executed.

Selector Widgets

Much of what the user sees in the MentorWizard user interface is common to GUI applications in current use. Any of the familiar widgets such as buttons, check boxes, scrolling lists and trees can be used wherever they are appropriate. However, one special user interface action in MentorWizard is new: a "button" that supports training-free applications and not only invokes some application logic but also triggers the display of a new step. The special MentorWizard button is called a "Selector" widget. The following examples illustrate the way Selector widgets are used in MentorWizard applications.

At the beginning of most MentorWizard applications, the user will be asked to specify what he or she wishes to do. Which task do you wish to perform? What constraints do you wish to apply to this task? Some refer to this activity as "navigation" to the place where the user's real work begins. In a traditional GUI application, this navigation is often performed via pull-down or drop-down menu selections. In a MentorWizard application, steps help the user to navigate. The step at the top level of a navigation network usually has a list of the available tasks within an application.

While these navigation options could be presented in a menu, MentorWizard offers them on steps so that the user is able to perform common tasks easily without recourse to training. This approach is also much faster than menu-based navigation. The options are presented with enough text for anyone with minimal knowledge of the domain vocabulary to perform each step.

In some applications, several sub-tasks must be carried out in order to complete a task. The user is expected to perform each sub-task and, only when all sub-tasks have been completed, go on to the next step. For example, an application that supports the preparation of tax returns might have a step with selections for various sub-tasks such as Schedule A, Schedule B, and so on. After the user completes one of the schedules, this step will be displayed again so the user can select another schedule. When this step is re-displayed, the Selector widgets that have been selected previously look different from those that have not yet been selected. The appearance of the Selector widgets needs to tell the user which sub-tasks have already been performed so the user doesn't inadvertently re-select a schedule.

These examples illustrate that navigation in MentorWizard applications is based on the following Selector widget behaviors:

1.   Display self-explanatory guidance to the user in the form of a text phrase or complete sentence that sometimes may be hundreds of characters in length.  

2.   Indicate when the widget is selected (via a mouse click or key tap). For example, this could be provided by a modification in the 3D shadowing to indicate that the widget is depressed. This user feedback is important whether the user selects a Selector widget via a mouse click, a tap on a touch screen, or an accelerator keystroke.  

3.   Display the label of the accelerator key that the user can tap to select the Selector widget. This will usually be a capital letter or number.  

4.   Provide a visual indication that a widget has been selected on a previous visit to the step during execution of the current task.  

The combination of these behaviors in a single user interface widget is significantly different from those of current GUI widgets. For example, a button typically has a cryptic text caption and a standard check box is limited to a single line of text.

In many respects, affordances provided by the Selector widget are available with standard GUI menus. However, menu selection sequences are more difficult navigate, they typically do not have self-explanatory text labels, and they do not facilitate sequential selections. Finally, menu execution sequences get in the way of user flow. That is, they do not allow the user to move through the user interface so effortlessly that the user is able to concentrate totally on the task at hand and ignore computing overhead.

Selector Widget Visual Behavior

The Selector widget is a powerful control. It has some of the affordances of buttons, radio buttons, check boxes, and menus. Since a Selector widget may be "pressed" like a button, the Selector should have a 3D outline much like a standard GUI button. This outline makes the Selector appear as if it extends above the surface of the step panel on which it resides. When the Selector is "pressed" via a mouse click or key tap, it should appear to move down into the panel surface. This depressed state should remain visible for 100 to 150 milliseconds, after which the current step will be cleared in preparation for the display of the next step.

The text for a Selector can be displayed inside the raised edges of the widget as in a classical GUI button. When the text doesn't fit on a single line, the Selector's height will automatically increase and the text will wrap to additional lines as needed.

Radio buttons display a circle or diamond with an internal dot to represent selection while check boxes display a square with a check mark or cross to represent selection. The Selector needs to display a selection indicator that does not confuse users, for example a triangular marker when not previously selected and a check mark when previously selected. In addition, when the Selector has not been "selected" the triangle could be filled with green; when it has the check mark might be shadowed with yellow. Therefore, the user sees both a change in shape and a change in fill color to show that a Selector was previously selected.

Three sample Selector widgets are shown below:


The first is an unselected, single line Selector. The second is a multi-line Selector that has not been previously selected, while the third sample shows the second widget, as it would appear if the current step were redisplayed after this same widget had been selected. Notice how the first widget is shorter: its text did not need the entire horizontal space available. The other widgets would have been too long if their text were displayed on a single line. Therefore, for these widgets, the height has been increased and the text wrapped to a second line.

Often an expert user will be familiar with a sequence of MentorWizard steps and will not want to read the text before making a selection. Such a user may not want to click on each selection with the mouse, preferring to use the keyboard instead. Traditional GUI buttons and menu items that can be selected with what are called "accelerator" keys indicate the key by underlining a letter in the display text. To help users make selections with accelerator keys, the Selector widget displays the label of its accelerator key between the widget identifier icon and the label text. The accelerator key should work independent of the states of the shift keys.

Since Selectors can be invoked by un-shifted keystrokes, an expert who knows the sequence of keystrokes needed to execute a commonly used sequence of steps can type these keys rapidly. The steps should be executed as if they were displayed and the user clicked on each selector with a mouse; however, these steps don't actually appear if the keystrokes come faster than the runtime engine can display them. Thus a user is able to "type ahead" to perform a number of familiar steps rapidly.

Selector Widget Logical Behavior

The Selector widget logic is, for the most part, identical to that of a normal button. When a Selector is "clicked", it executes the actions defined by the application builder. These actions may include one or more of those provided by the MentorWizard runtime module (see below), as well as custom actions written in a scripting language such as Python or JavaScript.

After all of the actions defined by the application builder have been executed, one final, automatic action is invoked. This Selector-specific action performs two functions (described in more detail below):

1.The fact that this Selector has been invoked is stored in the user's Task Cache. This information is used if the current step is redisplayed again before the current task is completed. In this case, the appearance of the Selector indicator is modified: for example, a small yellow circle is displayed at the left instead of a green triangle.  

2.   The current step goes away and the next step appears.