ics206: spring 2003model-based user interfaces model-based interfaces ics206: spring 2003 baolinh le...

ICS206: Spring 2003 Model-based User Interfaces

Model-Based Interfaces

ICS206: Spring 2003Baolinh Le

A. Bryce Carder


Introduction (pp. 443-445)

• Interfaces are deployed in diverse environments:– I/O devices of varying capability– Variance in nature & frequency of use– Users with different perceptual & cognitive ability

• Technological Answer:– Toolkits (ex: Software libraries)

• Promote reuse & consistency• Mix interface code and application code

– User Interface Management Systems (UIMS)• Aim to separate interface code and application code


Tools & Techniques

• Idea behind the papers is to describe “Tools & Techniques” that:– Assist the designer– Decrease the time and experience required

to create a User Interface– Differ from current UI Toolkits by:

• Separating dialog control from application code• Separating presentation style from the toolkit

libraries

– Differ from UIMSs by:• Making a finer-grained distinctions• Using more powerful design tools


The Papers

• ITS: A Tool for Rapidly Developing Interactive Applications – Authors: Charles Wiecha, William Bennett, Stephen Boies, John

Gould, and Sharon Greene • Beyond Interface Builders: Model-based interface

tools – Authors: Pedro Szekely, Ping Luo, and Robert Neches

• Model Based Automated Generation of User Interfaces – Authors: Angel R. Puerta, Henrik Eriksson, John H. Gennari,

and Mark A. Musen • Teallach: A Model-Based User Interface Development

Environment for Object Databases – Authors: Tony Griffiths, Peter J. Barclay, Jo McKirdy, Norman

W. Paton, Philip D. Gray, Jessie Kennedy, Richard Cooper, Carole A. Goble1, Adrian West and Michael Smyth


ITS: A Tool for Rapidly Developing Interactive Applications

• Introduction• Related Work

– User Interface Management Systems

– Toolkits

• ITS Architecture– Overview– UIMS and Toolkit Layerin

g– Usability of Design Tools

• Action Layer• Dialog Layer

• Rule Layer• Style Program Layer• EXPO 92• Discussion• Conclusion

Next Paper


Introduction

• Purpose:– Address problems that application developers deal

with such as users, equipment, configurations.– Create interface styles that are:

• consistent with other applications• conform to guidelines for presentation and interaction

behavior

• History:– Two types of layered architectures; UIMS and

Toolkits.

• ITS:– Four layer architecture; back-end computation,

dialog control, definition of interface style, implementation of style


User Interface Management Systems

• ~DBMS, Two Layers:– Application Layer

• Computation– Interface Layer

• Details of interface presentation and interaction• Seeheim architecture – connection to application,

dialog of flow control, presentation style.

• Goals of Separation– Reuse of application– Consistency amongst family of applications– Independent tools for application and interface– Problems:

• Inadequate tools for interface developers• Insufficient decomposition of the interface layer


UIMS (2)

• Examples that:– Refine presentation layer

• UIDE – layers include data objects, commands, control

• U of A*– Separates dialog control from interface style

– Allow designer control over style• Manual editing with WYSIWYG or constraint based

editors• Automatic generation using style rules


Toolkits

• Common libraries of interface components– Windows, dialog boxes, menus, dials, etc.

• Do not separate code for user interaction from application code.

• Success of toolkits– Reduce the complexity of programming an interface– Support consistency and standards

• Problems– New interaction techniques require new toolkits.– Do not define when to use each interaction

technique (i.e. rules for use only exist in hardcopy format, style guidelines)


ITS Architecture:Overview

• Four layers:– Action

• Read and write data (do computations)• Written in C

– Dialog• Content of logical frames• Control flow

– Style Rules• Written by interface designers• Composes style programs into interaction techniques

for objects in the dialog (ex: radio button or action bar)– Style Program

• Manages run-time changes to dialog.• Includes: Text formatting, row and column table

layout, menus, etc.


ITS Architecture:UIMS & Toolkit Layering

• Split between action (application) and dialog (interface)

• In ITS, further split into:– Style-independent Dialog – Definition of Style– Implementation of toolkit objects

• Benefits:– Dialog can be mapped into any style (by changing a

rule)– Interface designers control style– New interaction techniques are generated out of

existing toolkit objects by style rules (not programming)


ITS Architecture:Usability of Design Tools

• Aim: Nonprogrammers should be able to create an application with minimal application or style programming support (lack of tools)

• Four roles in ITS:– Application expert

• Knows the problem domain -> design specifications• Typically does not program, not an IS person.• The dialog author

– Application programmer• Implement the design specification

– Style expert• Poorest tool support (graphic artist, human factor)

– Style programmer


Action Layer

• Data Sharing between Action and Interface– Data tables store information– Communication via passing of values in data tables– Data pool = all data tables in application– When values are changed by actions, dialog objects

are notified (by the dialog manager)

• Calling Actions– User events trigger calls to actions

• Examples: frame initialization, selection, keyboard input, etc.

– Events and Parameters define actions– Conventional C Library functions


Dialog Layer

• Content of the Interface– Data Tables

• Tables that describe data in the data pool.• Forms = Set of fields• Lists = Set of forms• Tables = templates for fields in each list and form• Fields – have name, and set of attributes

(datatype, size, message)

:form table = flight_info

:fi field=destination, rangename=cities, size=20

:fi field=departure_time, size=10

:eform


Dialog Layer (2)

– Dialog• Content of a set of frames• Flow control between the frames

– Activated frames are put on “run-time stack”– Stack = a tree of frame activations– The attachto attribute indicates where a frame is

placed in the execution stack

• Frames can be bound to different data depending on where it exists in the stack

• Dialog Objects - Session, Frame, List, List Item• Dialog Attributes – Action, Purpose, Structure


Rule Layer

• Conditions– When a rule will be executed– May test the type of dialog statement or a dialog

attribute – If more than 10 fields exist, create a next button to

see more.

• 5 Types of Results Statements– Units: Create & Modify Dialog Structure– Set or Conditions: Control Nested Rules– Kids: Collect or match on characteristics of children.– Attributes: Set defaults for style attributes– Content: Generate dialog under style control


Rule Layer (2)

• Creating & Modifying Dialog Structure

Choice

Ci Ci Ci

VertGroup (Choice)

Title HorzGroup

Text (Ci) Text (Ci) Text (Ci)


Rule Layer (3)

• Matching on Characteristics of Children– Kids statement collects groups of children based on

conditions being met

• Setting Default Values for Style Attributes– Style Attributes: control appearance and behavior of

units• Example: TopMargin <integer> • Attributes are assigned to units by labeling the unit

with a type.– Significant features:

• Attributes are defined independently of the interaction techniques that use them.

• Unit Hierarchy allows parent to control types for subtree. Different frames can apply different rules.


Style Program Layer

• Space Negotiations– Request and allocate screen space– Per unit based on its requirements– 3 Step Process

1. Determine space requirement for each unit(by doing a depth first, left-to-right traversal of a frame)

2. (optional) Adjust space for children3. Assign a specific location to each object

(a second tree traversal, top down process that assigns each unit a position)


EXPO 92 Visitor Information System

• What will it do?– Offer information:

• Maps and directions for navigating• Up-to-the-minute schedule of events• Background information on participants

– Offer services:• Person-to-person and group messaging• Automated restaurant reservations• Public opinion polling• Lost family member locator• Networked games for offpeak hours


EXPO 92 Visitor Information System (2)

• User Requirements– Support multiple languages– Work for inexperienced computer users– Operable with little or no training– Visually attractive, use multiple types of media (text,

graphics, images)

• Developer Requirements– Integrate application functions developed in

geographically dispersed locations (NY, Seville)– Maintain working prototypes that promote an image

of a high quality product.


EXPO 92 Visitor Information System (3)

TitleNavigation/

Options

LanguageChoices

Hotspot


Discussion

• Layering– Address the problem of creating:

• Application-specific interaction techniques• Generating all interface in the UIMS

• General-Purpose Production Systems– Style rules are not simple to write and

understand– Easier than general purpose expert systems

(OPS-5)

• Dialog Workbenches– Some additional work on making application

work for the application expert easier.


Conclusion

• ITS Architecture = four layers – Action– Dialog– Style Rules– Style Program

• ITS is capable of highly interactive applications• Dialog and style rule layers can be extended

– Dialog -> more powerful language– Rule -> new type mechanism (algorithm for

recognizing general types instead of exact matches)


Beyond Interface Builders: Model-based interface tools

• Introduction• HUMANOID Overview

– Modeling Language– Designer’s Interface

• Related Work• Application Model• Presentation Templates

– Adding Parts– Specifying Part Input– Specifying Layout

• Behavior Templates• Iteration• Conditionality• Conclusions


Introduction

• Purpose:– To create a better interface builder– Why? Current interface builders don’t do

enough (only menus and dialogue boxes)– Satisfy Complex Interface Requirements:

• Data with Complex Structure• Heterogeneous Data• Variable Amounts of Data• Time Varying Data

– To make interface builders more expressive


Introduction (2)

• HUMANOID Contribution– Supports the afore mentioned interface

requirements– Modeling Language that has:

• Abstraction Mechanism• Composition Constructs• Iteration Constructs• Conditional Constructs


Humanoid Modeling Language

• Declarative Modeling Language• 5 Semi-independent Dimensions

1. Application semantics• Objects and operations• Defines the domain• Referenced by 2-4

2. Presentation• Defines visual appearance of interface

3. Behavior• Defines input for each object• And their effect on the application

4. Dialogue sequencing5. Action side-effects


Designer’s Interface

• Multi-Window Layout (Figure 2):– Part Editor– Presentation Template Structure– Layout Editor– Object Browser (data structures)– The Interface (in it’s current state)

• Designed such that:– All features of design are visible and changeable– Example interfaces are editable views of the model– All views of the design are linked together

(interactive design)


Related Work

• Expressivity and Usability Dimensions– Expressivity

• Defines the class of interfaces that can be specified

– Usability• Captures designer’s level of expertise to use a tool

Low Expressivity High Expressivity

Low UsabilityHigh Usability

Interface Builders Programming Languages

Demonstration Tools

Model-based Interface Tools


Application Model

• Objects – types and slots• Commands – inputs, preconditions, call-

back procedure• Advantages over Interface Builders:

– Generates a default interface & provides facilities to modify/customize the layout

– All aspects of the design are visible• Example – Edit command is usually a hidden

notion in an interface builder. • Dialog sequencing constraints


Presentation Templates

• An abstraction to model the characteristics of display elements.

• Templates represent the following information:

Is-A Refinement of existing template.

Input Data The type of information that can be displayed.

Widget Graphical object that is produced by the template.(menu, button, column, row, table, etc.)

Application Conditions

Predicates that define the context for use.

Parts Decomposition of complex displays into simpler ones.Each part consists of input data and template for presenting data.

Behaviors Input behaviors that can be invoked by the display elements in a template.


Adding Parts To Templates

• Creates a hierarchical decomposition of the display.

• Two ways to add a Part:– Edit the model

• Designer selects a template in the Presentation Template Structure window

• Is prompted to specify the name and default presentation template for the part

– Edit a generated example• Specify the template (in either the presentation model

view or in the example display)• Select the default presentation styel from a library

palette (like in an interface builder)• Draw the part in the example window.


Specifying Part Input Data

• Data is a function of the data presented in the parent or an ancestor.

• The HUMANOID Interface– Resembles entering data into a spreadsheet– Provides commonly used functions– Allows for snippets of code (new formulas)

• Important Benefits– User familiarity with spreadsheets– Dependencies are recorded, therefore if

data in a formula changes, the display is updated.


Specifying Layout

• Idea: Rather than specifying exact coordinates of objects, specify methods for a layout of objects

• Library of templates for commonly used layout methods (such as rows, columns, tables, etc.)

• Basically, designers extend/define specializations of existing libraries

• Custom layouts created in a way similar to that of interface builders


Behavior Templates

• Accomplished in HUMANOID by filling in options in a dialogue box

• Based on Myers’ Interactor Model– 7 classes of parameterized interaction for

mouse and keyboard input• Menu-interactor, Move-Grow-Interactor, New-

Point-Interactor, Angle-Interactor, Text-Interactor, Trace-Interactor, Gesture-Interactor

• Benefits:– No programming experience to create

application-specific behaviors– Behavior is separate from the presentation


Iteration

• Purpose: To specify the presentation of variable amounts of data.

• Iteration construct called “part replication”– Designates one input data of a part to be

the index– Sounds similar to looping through a for loop

and outputting object data

• If index data changes, the display is reconstructed


Conditionality

• Purpose: To make presentations sensitive to the attributes of data to be displayed.

• Two conditional constructs:– Inclusion Condition: a formula to determine whether

to display a part or not.– Substitutions: when a template has a list of

alternatives to displaying template data; substitutions can form a hierarchy

• Conditions are not supported by Interface Builders, and are typically achieved through programming


Conclusions

• Benefits of the HUMANOID Interface Builder:– Increased “expressivity”, as designers can

specify more than just menus and dialogue boxes

– Ease of use • all aspects of the model are visible and

changeable• Example views are generated

– More support tools can be incorporated• The modeling language could utilize other tools

such as tools for task analysis

ics206: spring 2003model-based user interfaces model-based interfaces ics206: spring 2003 baolinh le...

Documents

interface builders

interface layeruims

interface styles

separate interface code

definition of interface

application developers

separating dialog control

dialog of flow control