05-830, User Interface Software, Spring, 2000
Lecture 5,   February 7, 2000
Copyright © 2000 - Brad Myers

Overview of User Interface Software and Tools

• Why tools?
• What kinds of tools are there?
• What each kind is good for.

Why Tools?

• The quality of the interfaces will be higher. This is because:
  • Designs can be rapidly prototyped and implemented, possibly even before the application code is written.
  • It is easier to incorporate changes discovered through user testing.
  • There can be multiple user interfaces for the same application.
  • More effort can be expended on the tool than may be practical on any single user interface since the tool will be used with many different applications.
  • Different applications are more likely to have consistent user interfaces if they are created using the same user interface tool.
  • A UI tool will make it easier for a variety of specialists to be involved in designing the user interface.
• The user interface code will be easier and more economical to create and maintain. This is because:
  • Interface specifications can be represented, validated, and evaluated more easily.
  • There will be less code to write, because much is supplied by the tools.
  • There will be better modularization due to the separation of the user interface component from the application.
  • The level of expertise of the interface designers and implementors might be able to be lower, because the tools hide much of the complexities of the underlying system.
  • The reliability of the user interface will be higher, since the code for the user interface is created automatically from a higher level specification.
  • It will be easier to port an application to different hardware and software environments since the device dependencies are isolated in the user interface tool.

What should tools do?

• help design the interface given a specification of the end users' tasks,
• help implement the interface given a specification of the design,
• help evaluate the interface after it is designed and propose improvements, or at least provide information to allow the designer to evaluate the interface,
• create easy-to-use interfaces,
• allow the designer to rapidly investigate different designs,
• allow non-programmers to design and implement user interfaces,
• put features in the interface that allow the end user to customize the interface,
• provide portability across different machines and devices, and
• be easy to use themselves.

This might be achieved by having the tools:

• automatically choose which user interface styles, input devices, widgets, etc. should be used,
• provide sets of standard UI components
• guide the implementation
• help with screen layout and graphic design,
• validate user inputs,
• handle user errors,
• handle aborting and undoing of operations,
• provide appropriate feedback to show that inputs have been received,
• provide help and prompts,
• update the screen display when application data changes,
• notify the application when the user updates application data,
• deal with field scrolling and editing,
• help with the sequencing of operations, and
• insulate the application from all device dependencies and the underlying software and hardware systems.

Components of UI Software

Windows

• Manages and controls multiple contexts by separating them into different physical parts of the screen.
• Can be part of a program (Smalltalk), part of operating system (SunTools), or a separate program (X)
• "Window System"
  • Programming interface
  • Provides output graphics operations to draw clipped to a window = Output Model
  • Channels input from mouse and keyboard to appropriate window = Input Model
• "Window Manager"
  • User interface to windows themselves
  • Decorations on windows
  • Mouse and keyboard commands to control windows.
    
• Many systems combine WS+WM
  • SunTools, Macintosh, Windows, NeXT
• Others allow different WM on same WS
  • X, NeWS
  • Allows diversity and user preference
• Different WS on same hardware
  • SunTools, X, NeWS on Suns

Window System: Output Model

• Graphics commands that the programs can use
• All usually go through window manager so clipped
  • Usually can only draw what WS provides
• Older systems (SunTools, etc.) simple primitives
  • Draw Rectangles, text
  • "BitBlt" or "RasterOp":
  • Move a rectangle of the screen (memory)
  • + Easier to implement
• Newer (Macintosh, X, etc.) more sophisticated
  • Filled polygons, splines, colors, clipping
  • Still, all 2-D objects
  • + Prettier images and easier for application

Postscript:

• Language invented by Adobe for sending pages to printers
• Is a complete, textual programming language
• Provides:
  • arbitrary rotation and scaling (even fonts)
  • Complete hardware independence (coordinates are floats)
• Used as an output model:
  • NeWS, Display Postscript: NeXT, DEC, etc.

Open-GL

• 3-D output model from Silicon Graphics, for other platforms
• Standard part of Windows NT
• Powerful rendering capabilities

Other graphics standards:

• CORE (~1977), GKS (1985)
• PHIGS (1988) -- PEX (1991): PHIGS + 3-D for X
• Don't support "modern" graphical interfaces very well.
  • Why? Wait for particular kind of input

Window System: Input Model

• How input from user is handled.
  • Most only support keyboard and mouse
• All systems use same model:
  • Events generated and passed to applications
• Record (struct) containing type, (x,y) of mouse, time, etc.
• Asynchronously sent
  • For key down/up, mouse button down/up, cursor enter/leave window, window refresh.
• Problems:
  • Application must be almost always willing to accept events.
  • Race conditions, since asynchronous
  • Not device independent
  • No ^S (pause output), ^C (abort process)

Window System: Communication

• Window system often protected process
  • So bad application won't kill whole machine
  • (Isn't on Macintosh and regular MS Windows)
  • Is on Unix, Windows NT
• How do applications communicate with window system?
  • Special system calls
• Kernal, OS calls
  • SunTools, Macintosh
• Network protocol
  • Send messages to the process
  • X, NeWS
  • + Processes can display on remote machines.
  • + Different programming languages
  • - Less efficient

Window Manager: Window Decorations

• How the windows are arranged and decorated.
• Tiled vs. Overlapping
  • Whether windows can be on top of each other
  • Don't see tiled much any more:
  • Cedar, MS Windows 1.
  • Overlapping was first, current
• Smalltalk (1976)
• X
• Decorations:
  • Window borders, titles
  • Icons
  • Screen background

Window Manager: Commands

• How the user can control the windows.
• Mouse and keyboard commands
• Menus, buttons, etc.
  • Sometimes use a toolkit
• Listener or Focus:
  • Only one keyboard and mouse
  • How decide which window (process) to give it to?
  • "Click to type": Macintosh
  • "Mouse position"
  • Implications on user interface
  • E.g., which menubar is for?
  • which window to ``find'' in?

Toolkits

• A library of interaction techniques that can be called by application programs.
• An interaction technique is a graphical object which can be manipulated using a physical input device to input a certain type of value.
  • Also called "widget"
• Toolkits contain procedures to do menus, scroll bars, buttons, dialog boxes.
• Used only by programmers, only procedural interface
• Examples:
  • Macintosh Toolbox
  • Windows Toolkit
  • xtk for X (Motif and OpenLook)
  • Interviews for C++ and X
  • NeXTStep for NeXT
  • tk part of tcl/tk
  • Amulet
• Important
  • Consistent Look and Feel
  • Re-use of code
• Can be hard to use:
  • Very large libraries
  • Very large manuals
  • No help with when and how to call what
• Two layers:
  • Intrinsics:
  • How the widgets are implemented
  • Widget set:
  • Particular "look and feel"

Toolkits, Intrinsics

• Procedure-oriented:
  • Library of procedures that can be called
  • Macintosh Toolbox, SunTools library
    + Simple to implement

• Object-oriented
  • Library defines standard classes
  • Programmer can make sub-classes
  • Need an OO language
  • Xtk, Interviews, Garnet
    + Natural way to think about organization: widgets on screen "seem" like objects
    + Easier to make customizations
    - Requires special (single) programming language

Toolkits, Widget Sets

• Collections of interaction techniques with a particular look-and-feel
• Can be copyrighted, patented
  • Look and feel lawsuits
• Different look-and-feels on same intrinsics
  • Athena, OpenLook and Motif on Xtk

• The same look-and-feel can be implemented on different intrinsics:
  • Motif on Xtk, Interviews, Amulet, tcl

• Interface to applications: usually "call-back procedures"
  • Application supplied
  • Widget calls
  • Problems
    • - can be hundreds or thousands,
    • - hard to deal with Undo, etc.
    • - modularization compromised
• Amulet uses command objects instead
  • Also used by MacApp on Macintosh

Virtual Toolkits

• Thin layer above existing toolkits that hides the toolkit dependencies.
• Allows applications to be more easily ported to different toolkits
• As opposed to a toolkit that runs on different environments
• Problems:
  • Toolkit-specific style features
  • Drawing routines must also be provided
• Examples:
  • XVT (eXtensible Virtual Toolkit), supports Motif, OpenLook, Windows, PM, Macintosh, and character displays
  • Galaxy (from Visix Corp). Re-implements the widgets

Higher Level Tools

• Since toolkits are hard to use, need higher-level support.
• Prototyping tools
  • Quickly see how UI is going to look and act
• Interface Builders
  • Lay out widgets
  • Create menus, dialog boxes
• User Interface Development Environments
  • Comprehensive support for UI Software
• Tradeoffs:
  • Range of interfaces vs. amount of help (if narrow, can provide more support)
  • Ease of use vs. power
• Evidence that interactive tools 10 to 50 times faster than coding with toolkits

Tool list

• I maintain a list of many commerical and research tools
• http://www.cs.cmu.edu/~bam/toolnames

Back to 05-830 main page