User Interface Toolkits

Professor: Tapan Parikh (parikh@berkeley.edu)TA: Eun Kyoung Choe (eunky@ischool.berkeley.edu)

Lecture #11 - March 6th, 2008

213: User Interface Design and Development

Today’s Outline

1) Model-View-Controller (MVC)

2) Widgets

3) UI Toolkits

4) Internationalization

Model-View-Controller (MVC)

Model-View-Controller (MVC)

Architecture for developing programs with modular, reusable components

Originally conceived in Smalltalk-80, immortalized in Design Patterns

Allows separation of application state (model) from application display (view) and application logic (controller)

Source: Krasner and Pope, “A Description of the Model-View-Controller User Interface Paradigm in Smalltalk-80”

Model-View-Controller (MVC)Model

– Maintains application data– Provides methods to access and modify data– Notifies observers when data changes

View– Maintains application display– Updates view by listening to and querying model– Can have multiple views for the same model

Controller– Handles user input– Mediates between view and model– Manages lifecycle of other objects– Views and controllers can be reusable across applications

Example: A Text Field

Adapted from Rob Miller

Text display

Mutable string

Keystroke handler

Controller View

Model

change events

get text

edit text

ScreenKeyboard

Example: Web Browser

Adapted from Rob Miller

Page view

Document Model (DOM)

Hyperlink handler

Controller View

Model

change events

get nodes

load page

ScreenMouse

Observer Pattern

Used to decouple model from views (can support multiple simultaneous views of one model)

Adapted from Rob Miller

Model

View A

View Bstock market data

graph

table

query

update

update

query

Observer Pattern

Adapted from Rob Miller

Model Observer

modify

update

gets

return

registerinterface Model { void register(Observer) void unregister(Observer) Object get() void modify()}

interface Observer { void update(Event)}

View-Controller

In practice, it is often difficult to separate the view and the controller– Output is closely tied to Input– View needs to update itself based on

controller state (currently depressed button, currently selected text, etc.)

MVC has largely been superseded by MV - Model-View

Reusable GUI components providing both input and output (also called components, or widgets)

Adapted from Rob Miller

Widgets

Widgets

Reusable user interface components– Also called components, controls,

interactors, etc.– Handle both input and output

Includes a view, a controller, and possibly a model– Embedded model - data included in

widget; needs to be copied in and out– Linked model - data stored in model

object, which provides interface for accessing and editing

– Allows binding of widgets to data objectsAdapted from Rob Miller

Kinds of Widgets

Text boxes

Buttons

Scrollbars

Menubars

Containers

Etc…

Widgets for 1-of-N Choices

Adapted from Rob Miller

Radio buttons

Drop-down menu

Single-selectionlistbox

Toggle buttons

Widgets for Boolean Choices

Adapted from Rob Miller

Checkbox

Toggle button

Widgets for K-of-N Choices

Adapted from Rob Miller

N checkboxes

Multiple-selectionlistbox

Two listboxes

Widgets for Commands

Adapted from Rob Miller

Menubar

Toolbar

Context menu (right-click)

Push button

Hyperlink www.ischool.berkeley.edu

Widgets for Organizing Content

Adapted from Rob Miller

Tabbed Pane

Scrolled Pane

Split Pane

Listbox + Pane

Widgets for Dialogs

Adapted from Rob Miller

Dialog Box(Modal or Modeless)

Sidebar

View Hierarchy

Views can be arranged into hierarchies of containers and components– Containers: Window, Frame, Panel, etc.– Components / Widgets: Canvas, Text Box, Button,

etc.– Containers are also components / widgets

This hierarchy is used to delegate handling of input, output and layout

Adapted from Rob Miller

View Hierarchy: OutputDrawing

– Draw requests are passed top-down through the hierarchy

Clipping– Parent container prevents its child components from drawing

outside its extent

Z-order– Children are (usually) drawn on top of parents– Child order dictates drawing order between siblings

Coordinate system– Every container has its own coordinate system – Child positions are expressed in terms of parent coordinates

Adapted from Rob Miller

View Hierarchy: Input

Raw input events (key presses, mouse movements, mouse clicks) are sent to lowest component

Event propagates up the hierarchy until some component handles it

One component in the hierarchy has the focus (which it can choose to delegate to its ancestors)

Adapted from Rob Miller

View Hierarchy: Layout

Children can be automatically positioned and sized relative to their parents and siblings– Allows window-resizing– Can handle internationalization and

platform differences (window size, font size, etc.)

– Reduces requirement for programmer to manage sizing and positioning (usually requires fiddling to achieve graphic design requirements)

Adapted from Rob Miller

Pros and Cons of Widgets

Pros– Reduce development effort - designing,

coding, testing, maintaining, etc.– Maintain consistency across platforms and/or

applications

Cons– Constrains designer’s thinking– Encourages form and menu-based styles as

opposed to more direct manipulation

Further Reading – Jeff Johnson, GUI Bloopers 2.0: Common

User Interface Design Don'ts and DosAdapted from Rob Miller

User Interface Toolkits

Software architecture:– Usually MV, or MVC

Output:– View hierarchy– Stroke drawing– Pixel-level access

Input:– Event handling

Widgets:– Buttons, menus, containers, etc.

Adapted from Rob Miller

Toolkit Examples

Adapted from Rob Miller

Win32 Java Swing HTMLcomponents windows JComponents elements

strokes GDI Graphics <canvas>

pixels bitmaps Image <img>

input messages listeners Javascript window proc event handlers

widgets button, menu, JButton, JMenu, <button>,textbox, … JTextField, … <input>, …

Cross-Platform Toolkits: Swing

Adapted from Rob Miller

Windows

Java AWT

Motif

XLib

Java Swing

OS X

Cross-Platform Toolkits: HTML

Adapted from Rob Miller

MS Windows

Firefox

GTK+

XLib

HTML

Mac OS

IE Safari

Cross-Platform Toolkits

AWT, HTML– Use native widgets, but only those common to all

platforms– Consistent look-and-feel with native applications,

because they use the same underlying code – Sometimes misses some widgets

Swing, Amulet:– Reimplement all widgets– Not constrained by least common denominator– Provides consistent look-and-feel across platforms

SWT:– Use native widgets where possible– Reimplement missing widgets

Adapted from Rob Miller

Themes for Successful Toolkits

Address the Important Parts of the UI

Provide a Low Threshold and a High Ceiling

Make it Easy to do the Right Thing, and Hard to Do the Wrong Thing

Make the Behavior of Your Toolkit Predictable

Make Sure the Target of your Toolkit is Stable and Well-defined

Source: Myers, Hudson and Pausch “Past, Present and Future of User Interface Software Tools”

Internationalization(i18n)

Internationalization

Adapted from Rob Miller

Challenges of i18n

Translations– Have to translate every visible word in the

application– Requires specialists who are not only fluent in

the language, but are aware of local culture, conventions and standards

Right-to-left languages (arabic, hebrew, etc.)– Affects drawing, screen layout, icon shapes

Adapted from Rob Miller

Challenges of i18n

Encodings– Can vary across (and even within) languages– Fonts and input methods both need to support

specific kinds of encodings

Sorting (collation)– Uppercase / lowercase, accents, different letters - all

affect sorting in different languages

Numbers– 172,350.55 (US), 172.350,55 (Germany)– 1,72,350.55 (India)

Dates– 3/6/8 (US) vs. 6/3/8 (everywhere else)

Adapted from Rob Miller

Challenges of i18n

Colors– Does white represent a wedding or a funeral?

Icons

Adapted from Rob Miller

Toolkit Support for i18n

Message files– Separates messages from source code – “OK” vs. gettext(“OK”)– Human translators generate a message file

for each supported locale

Skins– Separates images, icons, presentation rules

from source code

Formatting support– Numbers, dates, currency

Bidirectional layoutAdapted from Rob Miller

For Next Time

Interactive Prototype / Final Project Proposals are Due on Tuesday

Review the slides and the readings on Heuristic Evaluation

Each of you will be asked to perform one heuristic evaluation

Each of your projects will be evaluated 2-3 times