Programmer describes the operation of the system or the user interface in
a specification language = the "model".
model is a high-level description
usually declarative (listing parts and relationships)
System automatically creates the interface
Uses a low-level toolkit for the widgets
Specifically not interactive tools
Goals:
High-level description of an interface is easier to write than low-level
toolkit code
Automatic generation may produce better UIs than programmers
Allow separation of UI design (embodied in rules) from UI contents (supplied
by the programmer)
Support dynamic creation of objects
define templates or prototypes
Increase re-use since design rules shared by multiple applications
Tools can reason over the specification to produce extra stuff:
Automatic generation of help, undo, etc.
Transform interface into different but functionally equivalent interface
Enabling and disabling of widgets
Enforcement or checking of design guidelines- consistency, completeness
Enforces consistency since rules will pick similar objects for similar situations
Automatic adjustment to different screen sizes, etc., since rules can take
this into account
Automatic analysis for quality
NGOMSL analysis (Kieras, UIST'95)
New project of Scott Hudson and Bonnie John (Hudson, John, Knudsen,
Byrne, "A Tool for Creating Predictive Performance Models from User Interface
Demonstrations," UIST'99. pp. 93-102.
Related to the "Declarative" approach discussed in
previous lecture
but here system has some intelligence or knowledge so less
has to be specified by the programmer.
Different types:
Dialog box creators: Mickey, DON, Jade (lots of others)
Representations of the full UI: ITS, UIDE, Humanoid, MasterMind
string = text input field
number = slider
one-of-many = radio buttons or pop-up options
many-of-many = check boxes or checks in a menu
commands = menu
arrange widgets
based on look-and-feel guidelines
where OK goes
which commands go in which menus
based on good graphic design principles.
set variables
to reduce the number of callbacks necessary
Maybe related to 4GL's ?
Mickey
Dan R. Olsen, Jr., "A Programming Language Basis for User Interface Management,"
Proceedings SIGCHI'89, Austin, TX, Apr, 1989, pp. 171-176.
Programmer specifies UI by putting special comments in a Pascal file.
Uses the Apple Macintosh guidelines
Pre-processor to parse the Pascal code and generate the Macintosh resources.
Maps Procedures into Menu items.
If parameter is one of a standard set, pops up appropriate dialog box or
waits for input
File to be read, file to be written
New point, line or rectangle
Variables:
Enumerated types mapped to check lists separated by lines. Sets the variables
when changed.
Enumerated types with 2 choices mapped to name changes
Booleans: single checked items
Records generate dialog boxes
will pop up if a parameter to an invoked procedure, or if explicitly requested
"Guard" routines allow setting variable to bold to also set property of the
selected item.
are "Demon" procedures
Graying out items using a built-in procedural service routine
Evaluation
+ Don't have to worry about resources, etc.
+ Easy to keep code and resources in sync.
- Very limited range
- Generation Rules hardwired, so if UI not good enough, have to edit the
generated code or resources.
- Settings are right in the code, so can't be changed by user or
internationalized.
- Have to learn special comment forms and commands.
- Long pre-process, compile, link, test loop.
Pictures from Mickey, CHI'89 pp. 172-4
Jade
Brad Vander Zanden and Brad A. Myers, "Automatic, Look-and-Feel Independent
Dialog Creation for Graphical User Interfaces," Proceedings SIGCHI'90:
Human Factors in Computing Systems. Seattle, WA, April 1-5, 1990.
pp. 27-34.
"Judgement-based Automatic Dialog Editor"
Given a textual specification of just the contents and their types, creates
a dialog box
Separately specify which look-and-feel (not part of the specification)
Defines mapping from types to widget selection
Graphic design rules for "nice" layout
Graphical editor can be used afterwards to add decorations
Retained if the specification is edited since refer to higher-level abstractions
of specification
Also designed to support dynamic creation of dialog boxes when a program
generates the contents list.
Can specify constraints to compute "enabled" based on values of other widgets
"Stop-action" for call-backs
Evaluation
+ Don't have to worry about layout, etc.
- Have to use rigid syntax for specification
Pictures from Jade, CHI'90 pp. 28, 32
DON
(Won Chul Kim & Foley, InterCHI'93, pp. 430-437)
Ultimate in dialog box layout
Kim's PhD thesis
Works with OpenLook and devGuide
Allows interactive designer guidance (preferences) on sizes, layout, widget
choice, etc.
Can also choose among proposed layouts
Sophisticated 2-D layout
Tries to balance dialog box
Groupings of related items
Effective use of white space (even margins, minimize wasted space)
Generates multiple designs and uses an evaluation metric to choose.
Generating Full UI
These tools require a specification of the full UI
Usually have rule-based components
Specifications are in a special language
Interactive Transaction System (ITS)
Bennett, et.al., UIST'89 pp. 67-75
Wiecha, et.al. CHI'89, pp. 277-282
Wiecha, et.al., ACM TOIS, 8(3), Jul'90, pp. 204-236
Goal: capture designers knowledge as style rules
So unlike other systems, designer is required to edit the rules, not just
the specification
All of UI must be created by editing the rules
no interactive editing of generated interface (since then the knowledge about
why the generated interface wasn't good enough would be lost)
Like dialog-box systems, separate specification of content and style
Style-independent tags associated with content
"Style expert" programs the style for each tag
Styles include both output (display) and input (interaction techniques)
specifications
Can handle dialog boxes, forms, node-link diagrams, kiosk frames, etc.
Used for a number of internal IBM applications
Used for all the information services at Expo'90 in Spain
Information, maps, restaurant reservations, etc.
IBM researchers and content experts were in Spain for months
Evaluation
+ Full representation of design may increase re-use
- Design specification ends up containing many specific "hacks" used to achieve
specific effects in single interfaces
- Complex formal language for specification and rules
Pictures from ITS, TOIS, 8(3), pp. 213, 215, 217
The User Interface Design Environment (UIDE)
Foley, et. al. CHI'88, pp. 67-72
Foley, et. al. IEEE Software, Jan'89, 25-32;
Sukaviriya, et. al. InterCHI'93, pp. 375-382
Long-term project of Foley's at George Washington and Georgia Tech