The toolkit’s appearance is different from classical UI designs. The toolkits GUI is designed with the following paradigms in mind:
• Monotony • Modelessness • Visibility
• Conditional Availability
All actions that can be done can be done in one way only. The reverse is also true. The button column on the right has the main controls to eidt WHy-Because Graphs. There are no shortcuts, context menus or drop down menus. This has been criticized by some users, who are mostly power users with a computer science background. Having a monotnous interface makes the UI simpler to use and assures, that all users use the UI in the same way. This has implications on debugging and ond supporting susers. Debugging is easier, becasue it is easier and less ambiguous to describe the actions that lead to a software fault. In support all users do actions tha same way, which reduces the gap between power users and normal users. Power useres tend to make use of all shortcuts available, but then lose their ability to support users who prefer simpler, but slower access to actions.
Buttons obviously are not entirely modeless. They are enables if the toolkit is in a state that allows the action a button offers and they are disabled if the state does not allow the button’s action. But all actions offered by the buttons always work in the same way. There is no button which changes its behaviour in dependence of the state of the toolkit.
Modelessness ensures that a selected action will conform to the expec- tations of the user, because it will not choose between different functions depending on the state of the software.
There are no drop-down menus and no context menus. The reason is that all actions should be visible to the user. There are exceptions, such as selection using the mouse. The software also has as few modal windows as possible. There are no actions, except for file operations and colour choosing, where modal windows are used. Java’s Swing GUI framework provides ready to
12.2. GRAPHICAL USER INTERFACE 115 use colour chooser and file operations dialogues, so there was comparatively less utitily in reimplementing them.
The main advantage over conventional drop-down and context menus is that users can see at a glance all options they have. They do not need to search menus and submenus and then remember the paths to find a specific action. And users do not need to search every submenu to be sure that an action they search for is not present.
The same goes for properties of data objects. All properties can be viewed and edited using the tabbed panes in the several subviews. That way no popup wizards are needed and the user can change faster from one view into another, because everything is directly accessibele.
Having no popup windows means that there are no ”are you sure” dia- logues, which is compensated for by the Undo/Redo functions (see following paragraphs).
12.2.4 Conditional Availability
Buttons and widgets, with which data objects can be manipulated, are only enabled and editable if the selection state of the data objects is such that the actions executed by the buttons or widgets is sensible. Each time the selec- tion state, or sub-selection states, change all buttons and widgets re-evaluate the preconditions neccessary for their execution. If all preconditions are met, then the button or widget becomes enabled or editable. This eliminates the need for popup windows informing the user that some condition neccessary for a requested action is invalid. A list of preconditions for all buttons and widgets can be found in the software toolkit’s reference manual in B.4.3.
12.2.5 Undo and Redo
All graph authoring actions are undoable and redoable if undone. The undo history is not limited, but is reset every time the software is quit or a project is activated.
Having an Undo relieves the user of all inhibitions to just use actions for fear of destroying work unrecoverably. Editing actions with far reaching effects usually check the user’s intention by modal dialogues featuring ”are you sure?” questions. Havin a reliable Undo/Redo lets the user see what has actually happened and then just revert the last state (or anyone before that) if the user is not satisfied with the result.
12.2.6 Graph Rendering
The software uses the dot rendering engine to draw the Why-Because Graph. The dot rendering engine is an automaitc layout engine, which takes a speci- fication of nodes and which noded to connect with edges and then computes a graph with a minimum of edge crossings.  The user does not have
to arrange the nodes and edges, which is very tedious work if a graph gets larger than approximately 20 nodes. Dot itself is not an interactive tool. The dot interface library Grappa is used to read and write data to and from dot, the interactivity is implemented in the toolkit itself.
From personal conversation I know that students at the TU Braun- schweig used MS Visio to draw graphs. In one special instance a student drew a graph of circa 80 nodes, which took several days just to lay out. Just layouting the same graph using the toolkit takes less than one hour.
12.2.7 User Reception
The software has been used in industrial tutorials and in the University courses. As mentioned, some power users missed shoftcuts, but otherwise all users could fully concentrate on their analyses, and not on operating the software, after they had a brief introduction which consisted of no more than 15 minutes of performing a small Why-Because Analysis. Questions on how to use the software to achieve certain goals were virtually zero.