Académique Documents
Professionnel Documents
Culture Documents
05 - Software Tools
Lecture 05 - Overview
UIs should be: reliable, standard, safe, inexpensive, effective widely acceptable and be build on a predictable schedule Software tools help to achieve this! UI Architect needs:
Simple and quick methods of sketching UIs Precise methods for working out details with the client, for coordinating with team-members and for telling the developers what to do UI specification methods Software tools to support design and software engineering Evaluation and critiquing tools Desktop Web, Mobile, Universal Usability and Customization UI building tools need to be adapted for these changes
Trends:
Specification Methods
Specification Methods
Grammars
Test if a string adheres to a specified set of rules Use (examples):
Specification of textual commands or expressions that a program should understand Verification of validity of user input (e.g., via forms)
Example of a grammar for UI purposes: Multiparty Grammar Extension of BNF that labels non-terminals with the party of an interaction that produces the string Pros: formal, hence can be verified by computer programs (completeness and correctness) Cons: difficult to follow, complicated, less suitable for 2-Dim interaction styles (e.g., forms, DM, etc.)
Specification Methods
Menu-selection and dialog-box trees
Show the stakeholders of a project a complete and detailed coverage of the system Show high-level relationships and low-level details Help in discovering inconsistencies, check for completeness, redundancies and ambiguity Due to the intention of avoiding clutter such trees are incomplete, are restricted to a static view and do not show the entire structure of possible user actions Problem: (A) In some aspects of UI design a precise specification of every possible action is required or (B) In cases of non-menu systems there might be a need to express the set of possible states and allowed transitions Solution: Use Transition Diagrams
Specification Methods
Transition Diagrams
Typical TD Set of nodes (system states), links between nodes (transitions), labels Many specialized TDs are available with specific notations for specific application domains (e.g., word-processing, ecommerce) Pros: can be effective for following flow or action and keeping track of the current state and options of the UI/System, can also be verified (e.g., reachability, deadends, etc.) Cons: Too complex with growing system complexity (too many states and possible transitions), confusing when many nodes need a link to help, back, quit, etc., in their basic form poor representation of concurrency and synchronization Alternative: State-Charts
Specification Methods
State Charts Grouping feature (nesting) allows for factoring repeated transitions out Offer extensions for concurrency, synchronization, external interrupt events and user actions Offer extensions with dataflow and constraint specifications May be extended with embedded screen prints to show the visual state of a graphical widget BSP: UML state-chart diagram
Interface-Building Tools
Interface-Building Tools
Benefits of high-level software tools in the context of HCI
1. User interface independence
(A) Separate interface design from internals, (B) enable multiple user interface strategies and multiple platform support, (C) establish role of UI architect, (D) enforce standards
2.
3. 4.
Rapid Prototyping
(A) Try out new ideas very early, (B) test, revise, test, revise,..., (C) engage end-users, managers and customers
Software Support
(A) Increase productivity, (B) offer constraint and consistency checks, (C) facilitate team approach, (D) ease maintenance
Interface-Building Tools
Interface Mockup Tools Main purpose: Create quick sketches during early design to explore multiple alternatives, facilitate communication Very important also in the pre-contract phase Examples: Slideshows, Macromedia Director, Flash, Dreamweaver, MS Visio, JBuilder, VB, etc. Depending on the approach/tool: Either show simple slides of screens or provide complete prototypes where users can select, navigate, click, scroll, etc. Note: Prototypes are naturally limited
Interface-Building Tools
Software-engineering tools Main Purpose: Build the final product In earlier days, general purpose languages (e.g., Java, C++) were used to build UIs from scratch Today, this is supported through software tools, APIs and Frameworks, etc. A classification of UI building tools:
Layer 1: Windowing Toolkit Layer 2: GUI Toolkit Layer 3: Application Framework/Specialized Languages Layer 4: Application Level
General Trend:
Lack of modifiability led to building architectures that separate the UI from the application logic (e.g., MVC-Pattern), also supports cross platform development
Interface-Building Tools
Windowing-system layer no widgets available, need to draw manually, no event support encapsulated in objects Low-level work required Especially useful/important for new platforms or if resources are expensive/limited Build the basis for higher-level layers Pros: Performance, very flexible Cons: Requires extensive programming, long learning time, offers little support for interactive tools, no visualization tools
Interface-Building Tools
GUI-toolkit layer provides software libraries and widgets (e.g., frames, dialog boxes, scrollbars) including event encapsulation as building blocks Pros: Abstraction, shorter development times, great flexibility, often based on general-purpose languages (makes it easier to combine UI with application logic) Cons: Possibly high learning times, building and maintenance time is still high, no support for consistency, experienced programmer needed Example for Toolkits: ILOG Views, Gtk, Qt, Java (AWT, Swing, SWT), .Net GUI toolkit)
Interface-Building Tools
Application framework and specialized language layer
Application Framework
Software architecture specifically designed for building GUIs Idea: Many UI-based programs have a similar structure, capture structure, translate it to classes, objects and methods, which can then be extended/reused Commonly uses widgets from the GUI Toolkit layer Based on convenient visual programming, simple scripting languages, or general purpose languages Less support for non-graphical part of the application Example: Cocoa, MFC, Macromedia Director
Specialized Languages
Languages specifically designed for building UIs Can also be used for rapid prototyping Example: Tcl, java script in combination with HTML
Interface-Building Tools
Application layer Interface Generators, also called: Model-Based Systems or UI Management Systems Visual tools, that allow for most parts of an application to be built with one tool and without coding Only available for a small class of applications (e.g., DB front-ends) or research prototypes
Interface-Building Tools
Selecting the right tool Obviously higher-level tools are more efficient, however, they are the most restricting as well Finding the right tool is a tradeoff between 6 criteria:
Which part of the application do you need to build using the tool? How long can learning time be / or are experts available? How long can the building time be? Do you accept a methodology being imposed or rather advised? Is communication with other subsystems required? Do you need to consider extensibility and modularity?
The End
Questions?