• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Modelling the User Interface

Modelling the User Interface



Introduction to the User Interface domain for business applications, a pattern based approach to model the UI and code generation techniques to make it possible. ...

Introduction to the User Interface domain for business applications, a pattern based approach to model the UI and code generation techniques to make it possible.

Session for Code Generation 2011



Total Views
Views on SlideShare
Embed Views



9 Embeds 298

http://pjmolina.com 284
http://startnewday85.blogspot.com 3
http://www.linkedin.com 3
https://www.facebook.com 3
http://www.slideshare.net 1
http://twitter.com 1 1
http://paper.li 1
https://twimg0-a.akamaihd.net 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Modelling the User Interface Modelling the User Interface Presentation Transcript

    • Modelling the User Interface Pedro J. Molina, PhD. Software Engineer Capgemini Spain | Valencia pjmolina@gmail.com http://pjmolina.com/metalevel
    • Contents UI: Art or Science? Domains Modelling UIs The Abstractions of an UI Code Generation for UIs 2
    • UI. Art or Science?Science ArtDeterministic Evidence-based Open-Ended Art Science Focus look & feel architecture Method intuition investigation Validation subjective testing, metrics Source: http://www.teehanlax.com/blog/2010/01/20/the-art-science-of-evidence-based-design 3
    • DomainsTypes of User Interfaces 4
    • Command Line Interface Source: Matrix, 1999: Trinity hacking the Electric Power Plant with nmap. 5
    • Games: joystick, motion 6
    • WIMPs 7
    • Touch UIs
    • Desktop 10
    • Web 11
    • MobileOK. Today, the world is going Mobile.But in what platform should we invest in? 12
    • Future UIs: Internet TV is comming 13
    • Others Aural Interfaces 3D Users Interfaces Motion Based Interfaces And more to come… 14
    • Future UIs: Internet Fridge? 15
    • Focus on: Business Information Systems Works mainly with business data Stored in a persistence layer Offers CRUD operations Workflows Expedient/Request management Transactions Reporting Business Intelligence Multichannel: desktop, web, mobile But soon also: TV and fridge, remember!! 16
    • Typical Features in Information Systems UIs  Coherent  Standardization  Common set of tools for developers  Less learning time for users  Corporate Style Guide  Designs, colors, fonts, etc. are predefined  Usability / Accessibility compliance  To be certified by a 3rd party 17
    • What makes a UI a good UI? Clear Concise Familiar Responsive (feedback)  Easy of use Consistent Attractive (design and aesthetics) Efficient Forgiving (Undo choices) 18
    • Novak’s rule“ Automatic Programming is defined as the synthesis of a program from an specification. If automatic programming is to be useful, the specification must be smaller and easier to write than the program would be if written in a conventional programming language.” G.S. Novak. 19
    • So, is UI Modelable? Generable? Can we apply Separation of Concerns?  Common part vs variable part  Design guides vs functionality of the UI Can we do it better than the traditional form?  Novak’s rule will be the unappealable judge  Let’s try! 20
    • Main Benefits to Model (& Generate)the UI Fast prototyping  Quality (error free) Fast Time to Market  Consistency / Homogeneity Multi-channel UIs  Style-guide Technology independence  Accessibility Assurance  Business surviving the  Formal validation, usability Technology validation 21
    • The Tech Tale & UI Technology Trends ?To be continued … more chapters of the tech war to come. BTW: That is why I love Technology Independence in MDD. Always ready to throw away my technology stack for a another one. 22
    • Modelling the UI 23
    • Dimensions of UI design Problem  SolutionDetail   Absract Source: [Trætteberg2004] 24
    • Some UI Models  Tasks models  Dialogue/Interactions models  Navigation models  Presentation models  Component models  Dynamic models  Presentation logic models 25
    • Some UI Models 26
    • But also… Wireframes Sketches Mockups 27
    • But also… Wireframes Sketches Use cases Mockups 28
    • Wireframe Samples 29
    • Navigation Maps 30
    • Task Model Samples 31
    • Presentation Models 32
    • Design tools Paper SW drawing tools  Illustrator, FreeHand  Visio, Word, Excel Specific Sketching Tools  Balsamiq, Axure, Protoshare 33
    • Standarization inniatives Red Whale Inc. XIML Forum Harmonia Inc. UIML ongoing standardization on OASIS UsiXML UCL, Jean Vanderdonckt Mozilla XUL Microsoft XAML WebRatio on standardizing WebML via OMGBut... Is it too early? Are UIs too broad in domain? 34
    • The Quest for the right level of abstraction Entry Page <<Login>> Do we need to specify the behavior of a login page one over again? Definitely, not interested in working at this level of detail. Login is a well known UI Pattern. Use is as a commodity, as a COTS. 35
    • Patterns to the rescue Patterns in Software  identify recurring problems  in a given domain  provide well known solutions  and criteria to  when to apply the pattern  and when not to Language patterns 36
    • Some useful Concepts Interaction Object [Vanderdonck&Bodart93]  AIO vs CIO Interaction Units Navigation UI Patterns 37
    • Some Abstractions Service IU Instance IU Population IU Master/Detail IU Wizard IU 38
    • Hierarchical Action Tree (HAT) A task oriented tree providing the user access to the system.  Intermediate nodes: grouping labels  Leaf nodes: links to interaction units Store View Purchases Purchase article Purchase to supplier Pending orders Sales Sell article New order Pending orders Store ... 39
    • Interaction Unit It is an abstraction of a window, a scenario where user interacts with the system  Based on: AIO & Presentation Unit  Extended with behaviour semantics Interaction Unit Name Alias Help message ... 40
    • Service Interaction Unit Represents an IU for a service.  Gathers input arguments and launches the service. Class Service 41
    • Instance Interaction Unit Abstracts object presentation.  Composed of:  Display Set  Actions  Navigation What to see? < Code What to do? Country.Name Class Name < Customer_Edit Surname Customer_Delete Address.Street Country_Nationalize > Display Set ... < Actions Currency Explore data > Navigation Country Invoices Receipts Payments > 42
    • Population Interaction Unit  Represents a set of objects  Composed of:  Filters  Order Criteria  Display Set  Actions  Navigation What to see? How to search? < Code Country.Name What to do? Class Name Filters < Customer_Edit Surname Order Criteria Customer_Delete Address.Street > <date ASCcode DES Display Sets Country_Nationalize < Actions ... Currency Country Explore data > Navegation > Invoices Receipts Payments > How to sort? 43
    • Master/Detail Interaction Unit Represents a composed pattern with head-details semantics.  Composed of:  A Master Component  One or many Detail Components Customer Master Current Invoices Due Payments Detail 1 Detail 2 Invoices Payments 44
    • Just-UI / Diagramming Population_Class2 MasterDetail1 ServiceNewInstance1 Alias2 Alias3 Alias4 Alias1 (a) Instance IU (b) Population IU (c) Master/Detail IU (d) Service IU (e) Navigational Link Graphical primitives in Just-UI. 45
    • Just-UI / Diagramming S_Rent MD_Contract-Vehicle Rent Vehicle Current Contract-Vehicle S_Return Return Vehicle S_Change_AddressP_Vehicle P_OldContracts I_User Change Address Vehicle Fleet Old Contracts S_Delete_User User Delete User S_Create_Fare Create Fare S_Change_Fare I_Fare Change Fare Fare S_Delete_Fare Delete FareExample of graphical language for UI specification. 46
    • Just-UI / DiagrammingJust UI / VISIO Prototyping stencil 47
    • Layered Approach UII_Invoice NUIMD_InvoiceAndLines Invoice A Invoice detail Lines UIP_InvoiceLines N A/Z LInes A 48
    • Just-UI / Diagramming 49
    • Just-UI / Diagramming 50
    • A B IntroductionA uses B Service IU Defined Selection Argument Grouping Conceptual Status Recovery User Interface Dependency Patterns Supplementary Info. Instance IU Display SetHAT Actions Navigation Population IU Filter Order Criteria Level 1 (1) Level 2 (4) Master IU Master/Detail IU Level 3 (11) Detail IU 51Level 1 Level 2 Level 3
    • More info about: CUIPIndex ofConceptual User Interface Patternsavailable on-line at: http://pjmolina.com/cuip 52
    • Mappings: AIO  CIO Desktop Hierarchical Action Tree Menu Interaction Unit Form Action Button Navigation Button Display Set  An object Labels  Many objects Grid Defined Selection Combo-boxes ... 53
    • Mappings: AIO  CIO Web / HTML Hierarchical Action Tree Dynamic Menu Interaction Unit HTML page Action <A> Link Navigation <A> Link Display Set  An object HTML Labels  Many objects <Table> Defined Selection <Option> ... 54
    • Platform constraints Physical Size Screen resolution Interaction Style Storage Computational Power Connectivity 55
    • Aesthetics vs Functionality  Progressive enhancement  Unobtrusive Javascript Sample: www.datatables.net 56
    • Code Generation for UIs AIO to CIO mapping driven by:  Direct (expert hardcoded it)  Heuristics  Designer choices Important to keep coherent Interaction Styles 57
    • UI CG approaches DB  Default UI  Code 58
    • UI CG approaches Models  Default UI  code 59
    • Demo: Essential & Io 60
    • UI CG approaches Models  Default UI  code 61
    • UI CG approaches Reverse engineering 62
    • Guideline compliance Windows / Mac / X11 Guidelines Usability / Accessibility Guidelines US Section 508 / Accessibility W3C WAI / AAA Recommendations  Conformance Level A  Priority 1. must  Conformance Level Double-A  Priority 2. should  Conformance Level Triple-A  Priority 3. may 63
    • Guideline compliance Put as much as possible standardisation inside the common part.  Implement such common part using the guideline criterion to be compliant with.  Usually guidelines also include best practices in the domain  study them deeply before starting the design of the output Now the code generator produces compliant software by design. In some contexts the product must be certified to be compliant  If you can proof the compliance of your code generator output, you will get the certification for all the output produced by the generator. 64
    • High vs Low level UI modellingUI ModellingHigh level Spec. Low level Spec.Pros: Pros:  near to the problem domain  adapted to the target device  more general  very preciseCons: Cons:  difficult to implement  device dependent  rigid automatic implementations  difficult to be re-targeted to another device 65
    • Modelling & Code Gen. Technologies Diagramming tools  Eclipse GMF  Eclipse Graphiti  MS DSL Tools  MetaEdit+  Obeo Designer Textual Domain Specific Languages  Xtext  Grammars & Parsers: ANTLR Templates  Strict separation of model, transformation & presentation (template)  output grammars  StringTemplate And many more... 66
    • Balance: flexibility vs Homogeneity Parameterisation  Reduces common parts  Increases family size  Increases complexityImmutable Variability Sample: Background color Sample: fixed to #34FF23 Background color can be specified Standardisation  Increases common parts  Reduces family size  Simplifies the system 67
    • User Interface Code Generation Key concept  AIO  Abstract Interface Object (technology independent)  CIO  Concrete Interface Object (platform dependent)  Mappings between them Architectures  MVC  Model View Controller  Direct data-binding 68
    • User Interface Code Generation AIO CIO AIO  CIO Selection Concept Desktop Web View Form HTML Page  Based on platform mapping List of objects Grid Table  Based on data type  Based on usability rules  Based on UI designer choice 6
    • User Interface Code Generation Automatic Layout Generation  There is not silver bullet  Choices depend on  However, you can find good heuristics to solve  Domain 80% of cases  Device physical constrains  Column alignment, multicolumn, grid, liquid layout, etc. 70
    • Creativity vs Automation. Where to put the division line? Artist & GUI designers  Programmers  Skills:  Skills:  Creativity  Analytic thinking  Design aesthetics  Abstraction  Usability  Tools:  Tools:  IDEs, compilers, debuggers,  Dreamweaver, Illustrator, Freehand, profilers. Expression Blend  They have different skills sets, tools & languages  It is difficult to find people with both skills  Languages oriented to split concerns: HTML, Javascript vs CSS and Images  Team work is needed to • Improve communication • Clear separation of concerns (SoC) & responsibilities • Degrees of freedom 71
    • Summing up UI is (not?) different to other computer science concerns UI coherence needed: UI componentization helps UI can be generated (50-90%) * (your mileage can vary) MDD needs better tool support to be mainstream Tools are improving in the latest years But we can do it better So ... 72
    • Let’s do it! 73
    • Thank you!Questions? @pmolinam