Widgets
I. Definition: A widget is a small interactive object that performs some
editing or input task.
A. Buttons
1. Command Buttons: When pushed they call a method
2. Radio Buttons: They typically allow one option to be chosen from
a set of choices (e.g., small, medium, large)
3. Check Boxes: They typically allow multiple options to be chosen
from a set of choices (e.g., bold-italic-underline)
B. Sliders and Scroll Bars: Designed to manipulate a discrete bounded
range of values
1. Typically provide controls for both fine and course adjustments
C. Menus: Designed to select a choice from a potentially large
number of possibilities
D. Text Boxes: Allow the user to enter a string of characters.
II. Abstract Devices
A. A taxonomy of devices
1. Physical devices
2. Virtual devices
3. Logical devices
B. Acquire/Release: Because screen space is limited, not all widgets
may be displayable simultaneously. In this case widgets may need
to share screen space or physical devices. This sharing requires
that they acquire and release resources.
C. Enable/Disable: Even if a widget acquires resources, it may not
be acceptable as input.
1. UI design principle: Prevent errors rather than report errors
2. We could force the widget to release its resources but that would
make for an inconsistent presentation of widgets
a. An expert user could not exploit spatial locations
b. A naive user might search other places for the widget
3. Best solution is to allow a widget to disable itself.
D. Active/Inactive: When a widget is being acted on, it should provide
feedback that allows the user to know that it is accepting the
user's input and acting on it.
E. Feedback (Echo): When a user is finished acting on a widget, the
widget should display its current state using some visual means.
III. Design tips
A. Place related widgets into physical proximity by using structural
groupings, such as menus, button groups, or dialog boxes
B. Be consistent: Use similar widgets to accomplish similar types
of tasks
C. When designing presentations of any type, keep the following items
in mind
1. Light objects take precedence over dark objects
2. Objects with detail and texture take precedence over plain
or uniform objects.
3. Objects with high contrast take precedence over objects with
little contrast.
4. Large objects take precedence over small objects.
5. Varied objects take precedence over regular or uniform objects.
D. Menu Design
-Semantically similar commands should be grouped together
-If there are a large number of menu items, it may be best to
put the most commonly occuring ones on one menu and have
a second display that shows the rest (generally a human keeps
7 items, plus or minus 2 in short term memory).
-If multiple items can be selected, there should be some visual
or verbal way of expressing this to the user (e.g., Motif has
a certain look for multiple item menus). If there is a limit
to the number of selections, this should also be indicated.
-Multiple menus: If they can all be placed on the screen at once
in a comfortable way, that is preferable to popping them up
one at a time.
-Menu trees: Breadth, the number of items per level, is preferable
to depth, the number of levels. In general, try to limit menu
trees to no more than three levels.
-If space permits, using a menu map that shows the first few
levels of the tree is helpful.
IV. Notes on Java Widgets
A. Revalidate/pack methods
1. In order to get a window to resize itself properly if a
subcomponent is resized by the user (e.g., you load a new
board with a new size), you must call both revalidate and
pack. If you do not call pack then revalidate will try to
resize the component while keeping the size of the window
constant. The pack command cause the window to both layout
its components and resize itself if necessary.
2. Make sure that when calling revalidate that you call it on the
correct component. It is easy to call revalidate on the wrong
component, in which case the window may not resize at all or
may resize in a strange way.