jacob adams topic paper department of computer science southern illinois university edwardsville

46
Model-Driven Techniques for User Interface Generation Jacob Adams Topic Paper Department of Computer Science Southern Illinois University Edwardsville

Upload: gracie-burbey

Post on 15-Dec-2015

214 views

Category:

Documents


2 download

TRANSCRIPT

  • Slide 1

Jacob Adams Topic Paper Department of Computer Science Southern Illinois University Edwardsville Slide 2 Wikipedia- software development methodology which focuses on creating models, or abstractions, more close to some particular domain concepts rather than computing (or algorithmic) concepts Slide 3 Benefits Model is typically more declarative Model is typically described in terms related to the problem domain Required less technical knowledge to create Slide 4 Same benefits as regular model-driven development Creating user interfaces (UIs), is still a largely manual process Creating UIs for several different platforms can lead to redundant work Slide 5 Basler Electric 2005-2008 Many products had hundreds of screens Needed similar user interfaces for both desktop and embedded applications Developed multiplatform, database- driven screen generator Slide 6 Evaluate techniques for model-driven UI generation from a software engineering standpoint. Important Criteria Extensibility Maintainability Efficiency Simplicity Slide 7 Slide 8 Alan Heirich -1987 Use declarative commands to describe system: 1) Token command describe type of data to be entered 2) Descriptive phrases 3) Actions that can be executed 4) Acceptance tests-performs validation logic Slide 9 Can also define dependencies between fields UI elements are limited to a small set of widgets (textbox, selection, button, menu, dialog box) Can also create command line version of the application Slide 10 Allows an application to be developed in an evolutionary fashion Provides quick prototypes Slide 11 Originally requires a task model Slide 12 Task model is turned into a dialog graph Slide 13 Dialog graph is used to create abstract UI (AUI) AUI is defined in XUL AUI is originally just placeholder widgets Placeholders are replaced by real widgets Slide 14 Making updates Changes must be propagated back through task model, dialog graph and AUI Slide 15 Gajos and Weld Requires 3 Models Interface specification constraints (e.g. type, widget used) places on user interface elements Device model information and constraints for the particular device that the UI will be generated for User model information, such as usage patterns about the intended user of the application Slide 16 After the data is collected, a pruning algorithm is performed to find the rendering of the UI the reduces the expected effort required to use the user interface UI generation and rendering is performed at runtime and is performed dynamically. Slide 17 User Interface Generated for Mouse/Pointer-Based Input Slide 18 User Interface Generated for Touch-Based Input Slide 19 Different User Interfaces Generated Based on Different Usage Patterns Slide 20 Gajos, Weld, and Wobbrock Used to generate effort estimations used by SUPPLE Asks user to choose between renderings Slide 21 Gajos, Weld, and Wobbrock Another method of determining effort estimate for SUPPLE Measures users motor abilities In experiment with 11 participant with motor impairments Users were 26% faster Made 73% fewer errors Slide 22 http://www.youtube.com/watch?v=B63w hNtp4qc&feature=player_embedded http://www.youtube.com/watch?v=B63w hNtp4qc&feature=player_embedded Slide 23 Requires context model, task tree, domain model, abstract user interface, and dialog models Provides a tool to generate layout statement from these models. Layout statements can define containment, order, orientation and size Slide 24 Slide 25 Containment Order Orientation Size Statement are given a scope (screen, set of elements, entire application) Models and statements are evaluated at runtime Slide 26 Fully automated process of generating UI from model Requires discourse model Screens and state machine are created from discourse model Discourse model contains set of actions Common types request, informing, question, answer, etc. Slide 27 ATLAS transformation language converts actions and other information into an AUI Model2Code transformation language converts AUI into concrete UI (CUI) Widgets are selected based on type of information to be input or displayed Slide 28 Requires domain model (relational database) Wizard style tool Select list or datasheet style UI Select data source Select data source for lookup widgets Choose which widgets update data Choose relative position of widgets Make optional modifications to sizes Slide 29 Widgets are generated based on their type Widgets are sized based on their longest possible value Tool can create both desktop and mobile UIs Slide 30 Stirewalt and Rugaber Requires Presentation model information presented to user Application model information and functions available to UI Dialog model interactions between user and application, relationships to other models Automatically creates UI from these models Slide 31 An agent is created to handle each model Creates event to act as connection points Contain information about actions and callbacks Specified in generic, model independent way UI is generated if models and connections are valid. Created two proof of concept applications Simple print and save widget Air traffic controller application Slide 32 Also generated UI completely from the models Requires Static structural task model (SSTM) hierarchy of tasks and what they are supposed to do. Dynamic structural task model (DSTM) sequencing and synchronization of tasks in SSTM Slide 33 Operational model converts task models into component objects Contain state machine built from actions and hierarchy defined in SSTM and transitions defined in DSTM Component objects are aggregated into larger objects. Translated into information need for concrete UI: user models, local interface models, abstract interface models, and interface implementation models Slide 34 Slide 35 Some techniques required only one model, others required several The detail involved in the models also varied significantly There are tradeoffs between having a simpler or more complex model Slide 36 Simple models Easier to develop models Detailed Models Easier to develop the rest of the application Information is more declarative Possible to require more work that traditional development techniques Slide 37 No outside steps required Requires detailed model or application may become rigid and/or have poor quality May be difficult or impossible to model UI entirely Manual changes Allows more flexibility and customization Can make updates difficult Slide 38 Maintainability is a primary aspect of software engineering System needs to be flexible to change over time Automatic UI generation allows for quicker changes Making updates in multiple places defeats purpose of the using a model Slide 39 Applications with automatic generation are often tightly coupled to their models Can cause problems if model cannot handle future changed Can also make getting rid of model difficult Tradeoff: tightly coupled vs. harder to update Slide 40 Can help reduce dependencies on model Helps decouple generation process from concrete UI specifics Allows easier changes of UI widgets Provides easier creation of UI for different environments, including different form factors Slide 41 Some approaches (Stocq and Vanderdonckt, User Interface Generator) produce UIs for a few platforms Others, such as SUPPLE, support creation on an unlimited number of platforms Several even allow different input mechanisms (keyboard, mouse, touch) Increasingly important with rise of mobile computing Slide 42 User may want different UIs for different platforms Allowing customizations to UI can help solve this problem Using sample usage patterns can also address this problem Slide 43 Contains information such as frequency and order of actions performed by a user. Can make using application much more efficient. Requires more work. Can be generated dynamically and at runtime. Slide 44 Allows UI to change over time, which recompilation Can change with user as usage requirements change Can not easily be performed if manual steps are required Can be confusing to have dramatic changes to the UI Gajos, Weld, and Wobbrock showed that using a hybrid approach can be a good comprimise Slide 45 Less manual involvement of the developer Provide richer interfaces Make more improvements from software engineering perspective Slide 46 Considerable research has already been done. However, UI generation is still a relatively new and expanding field There is still significant improvements that can be made.