Date post: | 22-Dec-2015 |
Category: |
Documents |
View: | 222 times |
Download: | 3 times |
User Interface Toolkits
Professor: Tapan Parikh ([email protected])TA: Eun Kyoung Choe ([email protected])
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