next up previous
Up: Critiquing Rules in Previous: Tool Integrity

Window Layout

Rule1

This rule checks for crowded windows in knowledge-acquisition tools. The rule warns the user of windows that contain too much information in relation to their size. Such window layouts can make it difficult for the user to find the relevant information, and to use the controls on the windows. The rule definition instructs the developer that increasing the window size or changing its content can alleviate the problem. For example, the developer can group parts of the window content in a separate subwindow. The rule operates by calculating the sum of the widget areas, and by comparing the widget total with the window area.

Widget and window area are not equivalent to information content, however. We tested this rule on several preexisting knowledge-acquisition tools. The rule signaled several crowded windows in these tools, and, on manual inspection, many windows did not appear crowded. Thus, the initial version of the rule was inconsistent with what the human eye perceived.

The performance of the rule increased when we introduced weighted areas for different types of widgets. Nevertheless, the weighted area could be misleading. For example, consider a window that consists of a single large text-entry field. In this window, the widget occupies most of the window area, but most users do not consider the window crowded because it contains a large blank area. (The window layout is comparable to layouts found in many text editors.)

Distinguishing between the active area of a widget and its physical boundaries can achieve better rule performance potentially. Large text-entry fields can have a large area in terms of their boundaries, but the active area for user manipulation (e.g., scroll bars) is often relatively small. Although text and picture areas can be active, they do not contribute much to the complexity of the window layout per se. On the other hand, widgets such as push buttons typically have a large active area in relation to their boundaries.

Rule3a

This rule checks for labels placed close to widgets that have labels on them. In the NeXTstep window system, for instances, developers can label list browsers (i.e., by providing a column title). Placing a separate label close to an already labeled widget would be inappropriate, because the user might misinterpret the function of the widget. The rule recommends the user to remove the extra label, because the widget in question already has a label.

Rule3b

This rule detects situations where multiple labels can be associated with a widget. In such cases, the user might misinterpret the function of the widget if it has several labels. The rule simply checks if there is more than one label within a certain radius of a widget, and, if so, recommends the developer to remove extraneous labels.

Rule3c

This rule checks for unlabeled widgets. Many widgets, such as text-entry files, require labels to be comprehensible to the tool user. Such unlabeled widgets can make it difficult for the user to interpret the function of the widget. If the number of labels near the widget is zero, the rule recommends the developer to insert a title or label for the widget.

Rule 100

This rule checks for widgets that are located outside the window area. Developers should avoid such layouts, because widgets outside the window area are invisible, and are inaccessible to the user. The rule suggests that increasing the window size or adjusting the widget positions can avoid this problem. In DASH, the developer can create problematic window layouts deliberately by first positioning the widgets, and then shrinking the window size so that some widgets are left outside the window. However, bugs in the automatic layout and custom-tailoring algorithms of DASH can also cause this problem.

Rule 101

This rule checks for widgets that are partially outside the window area. Because users can have difficulties operating widgets partially outside this area, developers should avoid such layouts. If widgets are partially outside their window, the rule suggests that increasing the window size or adjusting the widget positions can avoid the problem.

Rule 102

This rule checks for widgets that are too big for the window. Although this situation is rare, it is a serious problem, because it is impossible to operate widgets larger than the window. The rule informs the developer that increasing the window size or adjusting the widget sizes can correct the problem of oversized widgets. Usually, developers do not create layouts with oversized widgets, but bugs in the custom-tailoring algorithm of DASH can cause this problem under certain conditions.

Rule 103

This rule checks for windows that are too large for the screen. Large windows are difficult to manage (e.g., move and position), and the user can only examine and operate partial windows. (However, utility programs that provide a virtual desktop allow the user to handle such windows technically, but with some difficulties.) The rule suggests that decreasing the window size can alleviate this problem. Also, consider dividing the window into several smaller windows. Typically, the problem with oversized windows occurs when the developer custom tailors a knowledge-acquisition tool on one computer and then transfers the tool to another computer with a different screen size. The rule is based on heuristics in the sense that it assumes that the screen size of the development machine is the same as the screen size of the target machine. Currently, CT is unaware of the target screen size, because PROTÉGÉ-II does not record the type of the target machine. Thus, the rule may fail to report oversized windows for small target screens, and may alert the developer unnecessarily about big windows for large target screens.

Rule 104

This rule checks for situations where the title bar of a window is outside the screen area. DASH allows the developer to custom tailor the initial position for windows in the knowledge-acquisition tool. In the NeXTstep window system, the user cannot move the window easily when the title bar is outside the screen. In such situations, the rule reports that adjusting the window position at the custom-tailoring stage can avoid the problem. Because PROTÉGÉ-II is unaware of the target machine, the rule checks the title-bar position with respect to the screen size of the development machine.



next up previous
Up: Critiquing Rules in Previous: Tool Integrity



Henrik Eriksson