WIMP interfaces have been dominant since the late eighties. At the present time there seems to be no end in sight to this reign.
The acronym WIMP stands for Windows, Icons, Menus and Pointing device. The invention of the WIMP interface is credited to Douglas Englebart and the Human Augmentation Project at SRI in the late sixties. At the SRI lab, located in the area of California which came to be known as Silicon Valley, Englebart experimented with a number of clumsy-looking wooden mouse prototypes for selection and highlighting, menus, and text-based windows.
The development of WIMP interfaces continued at Xerox PARC. The PARC research team, which included notables such as Alan Kay and Adele Goldberg, designed most of the elements that we associate with WIMP interfaces: a bit-mapped display with movable/resizable windows, buttons and pop-up menus, the desktop metaphor, and an object-oriented software architecture and development library. The Smalltalk language/development environment (1970-) was the research testbed for OOP and WIMP interfaces. The Xerox Star workstation (1981) was the first production computer to use the desktop metaphor, productivity applications and a three-button mouse.
Steve Jobs and a team from Apple paid an infamous visit to Xerox PARC. The result was the Lisa (1983) computer and the Macintosh (1984), the first mass-produced WIMP-based machines. A small company, Microsoft, got the contract to develop the first suite of productivity applications to be bundled with the Macintosh. By 1985, Microsoft proposed Windows, which they intended to run on a wide variety of platforms. The reader can fill in the blanks. With the rapid rise of Microsoft Windows, WIMP interfaces have become the dominant interface paradigm.
In general, WIMP interfaces can be considered
a type of direct manipulation interface. However, a WIMP interface
may just offer direct access to controls (buttons/menus) but not
necessarily manipulate the objects of interest directly. For example,
one may click a button to put an item in a shopping cart rather
than dragging the item to the cart. The distinction can be subtle.
Supports Wide Range of Users
Some types of common actions are not easily
done, e.g. wildcard specifications.
A number of approaches are recommended. The tasks to be done are listed, and put into groups. These groups become the basis of menu design.
Menu items are generally of two types: actions and attributes.
Actions are performed on an object or on the current document immediately and permanently. Action items are verbs and their effect can be implicitly put into sentence or verb phrase form, e.g. save the file, rotate the selected picture, copy the highlighted phrase.
Attributes change some property of an object. They can be turned off or on at any point. Attribute items are adjectives and can be put in phrases of the form 'Make the selected object xxxx', where xxxx is Bold, Italic, Filled, etc.
Hence the menu items in a WIMP can be said to conceptually describe a very simple command language.
Can be ambiguous or take longer to recognize than equivalent text. This can be ameliorated somewhat by having accompanying text labels or text pop-ups.
Window functionality can be used in a number of innovative ways. Apart from the display of text and/or graphics, and other contents found in single windows, multiple or split windows can be used to display different parts of a document simultaneously. For example, one section can be used as a magnification of another picture/map, different parts of a long text document can be viewed together.
Scroll bars can be enhanced to display page
numbers, to record and display place markers, and to jump for
predefined intervals.
Beginning with the Macintosh, standards have been established for GUI's/WIMPs. Apple took the main ideas of the PARC interface, which was basically an internal research project, and made it into a commercial product with strict guidelines.
The Macintosh guidelines (1992) are quite comprehensive. They start with a number of overall objectives:
They also add considerations for internationalization.
A number of enhancements are provided for those
with physical differences. For example the screen can be magnified,
error sounds can be visually displayed, and keypress combinations
can be done in sequence.
A number of guidelines are described, some
of which users take for granted and others they might not notice.
For example, menu items are executed immediately unless followed
by an ellipsis (...) which indicates that further input is required.
For readability, all menu items are in lower case but start with
a capital letter.
The guidelines for toggled items may not be
noticed but are extremely useful. A toggled item or items indicate
state, i.e. if an attribute is on or off. An item which says 'Grid
On' is could mean that the grid is on or that selecting the item
will turn the grid on. To avoid confusion, the guidelines state
that one should either
There are also precise specifications for the
sequence of actions required to select menu items, invoke applications,
and for the behavior of controls, all of which form part of the
standard 'graphical language' of Macintosh applications.
The design and appearance of dialog boxes used
for settings, yes/no decisions, informative notes, and warnings
are specified.
Perhaps the most heavily criticized aspect
of the Macintosh interface is that menu selection requires dragging.
This is tiring for users but hard for young children, elderly
and physically challenged users. Task switching requires menu
selection unless windows from the target application are visible.
There are also few keyboard shortcuts and no way to navigate menus
or dialog boxes via the keyboard. These behaviors can be overridden
with third-party system additions which are sometimes imperfect.
Another critique is that users may not notice that an application is open if it has no associated windows. Documents from other applications may be visible and the user can try to invoke the menus from such an application on the windows of another. Inactive windows have a different titlebar appearance which novices often overlook. A small icon shows which application is active, but users may miss this as well. The Mac OS uses the first 'line' of the screen as a menubar area for all applications (for perceived stability), and this is the main source of confusion.
Notable differences include:
Clicking in a window does not bring it to the forefront - one must click on its titlebar. Again, Open Look is an exception.
Pop-up menus are used extensively, and keyboard
navigation and shortcuts are not well established.
The event-driven architecture waits on user actions (events), enqueues them and processes them.
WIMP programs have associated data - window
and menu descriptions, icon data, pictures, sounds, etc. These
are stored with the program as resources. Resources Each
platform has standard resource formats which can be interpreted
by the application and the OS.
Each Macintosh program has a main event loop.
The basic architecture is followed exactly.
Windows
Windows applications assume an implied loop.
The programmer writes the body of the loop. This prevents errors
due to improperly coded loops.
X-windows
The event-driven architecture in X supports
distributed displays and submission of events.
The complex behavior of WIMP elements mandate
extensive library support. The libraries are called toolkits,
toolboxes or API's on various platforms. They feature function
calls to recognize, interpret and process events and manipulate
resources. The supporting OS handles some things, such as displaying
menus, moving windows, etc. but the application must handle all
but the basic actions. Learning how to use these libraries generally
takes some time. Class libraries or frameworks are often superimposed
on the API to make programming tasks easier, but they often have
a learning curve of their own.
Visual Interface Tools
In the earlier generation of programs, screens
were drawn using code - a tedious task. WIMPs have associated
resource editors for entering text for menus, specifying window
features, etc.
Resource editors have generally given way to
visual interface design tools such as dtbuilder and Visual Basic/C++,
which allow interface elements to be tested as well as 'drawn'.
A number of industry leaders have complained
that there has been little progress in interface development since
the Mac WIMP. Some have challenged the assumptions such as consistency
for widely differing applications. WIMP interfaces seem here to
stay in the near future. The likely scenario is that other developments
will be integrated into the WIMP framework.
Shneiderman, Ben., Designing the User Interface: Strategies
for Effective Human-Computer Interaction, 2nd. ed. Addison-Wesley
(1992).
Comprehensive, readable coverage of interface theory from a
leader in the field.
Cox, K. and Walker, D. User Interface Design, 2nd. ed.,
Prentice-Hall (1993).
A practical book on software and interface design.
Mayhew, Deborah J., Principles and Guidelines in Software
User Interface Design. Prentice-Hall (1992).
Good reference for Human Factors, Do's and Don'ts in design,
and integrating user interface design into the software life cycle.
Dix, A., Finlay, J., et.al., Human-Computer Interaction.
Prentice-Hall (1993).
Has interesting material on Task and Interaction design and measurement,
Formal design methods, User Interface Management System Architecture,
particularly X Windows, Groupware and CSCW.
Apple Computer, Inc. Macintosh Human Interface Guidelines,
Inside Macintosh: Overview, Inside Macintosh: Toolbox Essentials,
Programmer's Introduction to the Macintosh Family. Addison-Wesley
(1992).
Describes the various aspects of the Macintosh System: The design
rationale, software, hardware and operating system architecture.