(based on Myers Lecture 5 and Shneiderman Chapter 5)

Higher quality because:

• Consistent UIs across applications if they are created using the same tool.
• Multiple UIs possible for the same application.
• Tool represents "best practice" (large effort goes into its development).
• Variety of specialists can be involved in UI design (less technical expertise required)

More economical because:

• Less code to write
• Better modularization (separate UI from app)
• Less expertise required (tools hide much of the complexity)
• Higher reliability (code generated automatically)
• Easier to port (device dependencies are abstracted by UI tool)

Things UI tools can do

Notice that UI tools may operate at different times:

• During UI design/implementation (to facilitate these activities)
• During run-time (for adaptive interaction)
• After run-time (for UI evaluation)

Brad Myers (reference above) layered software architecture, with UI support italicized.

Windowing systems provide run-time support.

Tookits provide design/implementation support.

Higher-Level tools can provide support at any time: design/impl., run-time, post-run-time

Purpose: manage multiple interactions by separating them into different parts of the screen.

Can break down into :

1. Window system
2. Window manager

Window system

• Programming interface
• Input: get mouse/keyboard input from user
• Output: provides graphics operations to draw to a window
• Examples: PostScript, Open-GL

Window manager

• User interface to windows themselves (runtime management)
• Decorations on windows (such as borders, icons, tiled/overlapped)
• Mouse and keyboard commands to control windows

X distinguishes the two.

Most other systems do not, and refer to the whole as "window manager"

Library of interaction techniques ("widgets") that can be called by application programs.

Toolkits contain procedures to do menus, scroll bars, buttons, dialog boxes.

Procedural interface, so programming expertise required

Can be very difficult to use:

• hundreds of library procedures
• thousands of manual pages
• very few guidelines

Examples:

• Macintosh Toolbox
• Windows Toolkit
• xtk for X (Motif and OpenLook)
• Interviews for C++ and X
• tk part of tcl/tk
• Amulet
• Java AWT

Toolkits may be organized in two layers:

• Intrinsics
• Widget set

Intrinsics

• Procedures or objects
• Independent of "look and feel"
• X terminology
• Macintosh Toolbox is procedure-oriented
• Java AWT, Smalltalk, tk are object-oriented

Widget set

• Implements "look and feel"
• Can be copyrighted and patented

Separation allows same semantics to appear visually different
(Java AWT as example: rendering depends on host system e.g. Mac or Win)

A tool to make UI toolkit use easier

UI development 10-50 times faster than by using toolkit directly

Can also provide run-time support (UIMS)

Post-run-time support for UI evaluation possible but rarely built into tools

Myers classifies higher-level tools based on technique designer uses to specify UI.

(see "UIMSs, Toolkits, Interface Builders", Brad Myers)

• Language-based (the originals)
• State transition networks
  - good for specifying behavior of low-level widgets
  - not good for modeless (many choices available at a time) or concurrency
• Context-free grammars
  - specify UI using BNF
  - suitable only for textual command languages
• User action notation (from Shneiderman)
  - extention of grammars, and suitable for DMI
  - Specify user task using notations for various actions (such as clicking, dragging, mouse up/down, cursor move) in context with objects manipulated and system response.
• Event languages
  - UI programmed as set of event handlers
  - Visual Basic has this flavor
  - can handle modeless interaction
  - however system structure is flat so doesn't scale up
• Declarative languages
  - describe UI through specification (such as widget layout)
  - limited to static widgets, or at least static aspects of UI
• Constraint languages
  - specify relationships between widgets through constraints
  - runtime support required to enforce constraints
  - example constraint: labels must be centered within boxes.
• Screen scrapers
  - provide GUI front end to old text-based programs w/o having to modify them
  - use memory buffer between front end and application
  - application thinks the buffer is a character terminal.
• Visual programming
  - e.g. techniques for specifying state transition diagrams, data flow diagrams
  - you do not draw the interface itself, just the specification!
  - Visual Basic does not fall squarely into this category (code still textual)
• Application Frameworks
  - motivation: guide programmers toward "correct" use of widgets
  - OO library of classes for important UI parts (main windows, commands)
  - derive subclasses for specialized app behavior (window contents, which commands)
  - MacApp was the first, to guide programmers using Macintosh Toolbox.
  - Microsoft Foundation Classes is another example
• Model-based generation
  - UI generated automatically
  - may be based on high-level specification of application (not interface)
  - may be based on set of rules for UI layout
• Interactive graphical specification (specify UI through direct manipulation of widgets)
• Prototyping tools
  - can be used by nonprogrammer for visual design
  - support development of sample screens but do not generate UI code!
• Cards
  - UI is sequence of forms (or "cards")
  - designer places widgets on form (some cause transfer to other forms)
  - HyperCard is famous example
• Interface builders
  - select pre-defined widgets from palette and place on window using mouse
  - set widget properties from property sheet
  - can specify some sequencing (like dialog box to appear when button pressed)
  - creates application code
  - Visual Basic is most famous example
  - literally hundreds of such tools exist

Comprehensive user interface tools

Provide support for more than one activity (e.g. design and run-time both)

Once known as User Interface Management Systems (UIMS)

UIMS generally refers only to run-time UI control

UIDEs can support UI evaluation by:

• UI specification metrics (how many widgets and how arranged)
• Run-time monitoring of user activity
• Run-time or post-run-time analysis

Last reviewed: 8 October 1998