1. User Interface Toolkits Professor: Tapan Parikh (parikh@berkeley.edu)parikh@berkeley.edu TA: Eun Kyoung Choe (eunky@ischool.berkeley.edu)eunky@ischool.berkeley.edu Lecture #11 - March 6th, 2008 213: User Interface Design and Development

2. Today’s Outline 1)Model-View-Controller (MVC) 2)Widgets 3)UI Toolkits 4)Internationalization

3. Model-View- Controller (MVC)

4. 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)

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

6. 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

7. Example: A Text Field Adapted from Rob Miller Text display Mutable string Keystroke handler ControllerView Model change events get text edit text Screen Keyboard

8. Example: Web Browser Adapted from Rob Miller Page view Document Model (DOM) Hyperlink handler ControllerView Model change events get nodes load page Screen Mouse

9. Observer Pattern Used to decouple model from views (can support multiple simultaneous views of one model) Adapted from Rob Miller Model View A View B stock market data graph table query update query

10. Observer Pattern Adapted from Rob Miller Model Observer modify update gets return register interface Model { void register(Observer) void unregister(Observer) Object get() void modify() } interface Observer { void update(Event) }

11. 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

12. Widgets

13. 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 objects Adapted from Rob Miller

14. Kinds of Widgets Text boxes Buttons Scrollbars Menubars Containers Etc…

15. Widgets for 1-of-N Choices Adapted from Rob Miller Radio buttons Drop-down menu Single-selection listbox Toggle buttons

16. Widgets for Boolean Choices Adapted from Rob Miller Checkbox Toggle button

17. Widgets for K-of-N Choices Adapted from Rob Miller N checkboxes Multiple-selection listbox Two listboxes

18. Widgets for Commands Adapted from Rob Miller Menubar Toolbar Context menu (right-click) Push button Hyperlinkwww.ischool.berkeley.edu

19. Widgets for Organizing Content Adapted from Rob Miller Tabbed Pane Scrolled Pane Split Pane Listbox + Pane

20. Widgets for Dialogs Adapted from Rob Miller Dialog Box (Modal or Modeless) Sidebar

21. 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

22. View Hierarchy: Output Drawing –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

23. 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

24. 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

25. 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 Dos Adapted from Rob Miller

26. 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

27. Toolkit Examples Adapted from Rob Miller Win32Java SwingHTML componentswindowsJComponentselements strokesGDIGraphics pixelsbitmapsImage inputmessageslistenersJavascript window proc event handlers widgetsbutton, menu,JButton, JMenu,, textbox, …JTextField, …, …

28. Cross-Platform Toolkits: Swing Adapted from Rob Miller Windows Java AWT Motif XLib Java Swing OS X

29. Cross-Platform Toolkits: HTML Adapted from Rob Miller MS Windows Firefox GTK+ XLib HTML Mac OS IESafari

30. 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

31. 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”

32. Internationalization (i18n)

33. Internationalization Adapted from Rob Miller

34. 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

35. 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

36. Challenges of i18n Colors –Does white represent a wedding or a funeral? Icons Adapted from Rob Miller

37. 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 layout Adapted from Rob Miller

38. 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