05-830, User Interface
Software, Spring, 1998
Lecture 5, February 2,
1998
Copyright © 1998 - Brad
Myers
Previous
Lecture . . .
Next Lecture
- Why tools?
- What kinds of tools are there?
- What each kind is good for.
- 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.
- 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.
- 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.
- 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
- 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
- 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.
- 3-D output model from Silicon Graphics, for other platforms
- Standard part of Windows NT
- Powerful rendering capabilities
- CORE, GKS (older)
- PHIGS (PEX: PHIGS + 3-D for X)
- Don't support "modern" graphical interfaces very well.
- Why? Wait for particular kind of input
- 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 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?
- Kernal, OS calls
- Network protocol
- Send messages to the process
- X, NeWS
- + Processes can display on remote machines.
- + Different programming languages
- - Less efficient
- 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
- How the user can control the windows.
- Mouse and keyboard commands
- Menus, buttons, etc.
- 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?
- 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.
- 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"
- 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
- Collections of interaction techniques with a particular
look-and-feel
- Can be copyrighted, patented
- 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
- 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
- Just show what looks like
- Note: differentiate from term "rapid prototyping"
- Some support for behavior
- Like a movie of the interaction
- Goal: see some of interface very quickly (hours)
- Often no possibility of migrating to real application
- May not use "real" widgets
- Examples:
- Bricklin's Demo (PC)
- MacroMind Director (Macintosh)
- Hypercard (Macintosh)
- SILK - bridges to implementation
Silk Examples:
- Lay out widgets to make windows
- Provide a palette of widgets
- Select widget, put in a window
- Set some properties
- Design menus, palettes, dialog boxes, controls
- Put in ``graphics'' pane for main application window
- Easy to use, but limited
- Create actual application code
- Examples:
- Menulay (1983-research system)
- NeXT Interface Builder (NeXT)
- UIMX (X)
- BlueSky's WindowsMaker (MS Windows)
- Visual Basic
- ... (literally hundreds of others)
- Object-oriented libraries that help develop applications
- Provides base classes from which applications are developed
- Programmer creates sub-classes
- Supports entire application, not just widgets
- Often contain Interface Builders
- Examples:
- MacApp
- Amulet
- Microsoft Foundation Classes
- Note: not Visual C++ -- is just the compiler
- MetroWerks PowerPlant
- Support insides of application windows
- E.g., for CAD, other graphical application
- Often includes ``Application Frameworks''
- Usually also support what Interface Builders do
- Design time, run-time, after run time
- Many different approaches:
- State transition diagrams (when simple)
- BNF grammars (for command lines, text input)
- Event languages (write event handlers)
- Pieces of code executed on incoming events
- Research systems: automatic creation
- Older name: User Interface Management Systems (UIMS)
- Examples:
- MacApp (Macintosh)
- Amulet (CMU - C++)
- Garnet (CMU - Lisp)
- IDE / Rapid/USE (SunTools, X)
- ... (some others)
- Many of these are areas of active research
- Object oriented languages
- Constraints: relationships that are declared once and maintained by the
system.
- Drawing application-specific objects and assign or demonstrate behavior
- Automatic creation of parts of interface from a specification
- Built-in support for Help, undo, abort
- Help with evaluation of resulting user interface
Back to 05-830 main page