Modelling the User Interface

  • 2,971 views
Uploaded on

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,971
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
0
Comments
0
Likes
7

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Modelling the User Interface Pedro J. Molina, PhD. Software Engineer Capgemini Spain | Valencia pjmolina@gmail.com http://pjmolina.com/metalevel
  • 2. Contents UI: Art or Science? Domains Modelling UIs The Abstractions of an UI Code Generation for UIs 2
  • 3. 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
  • 4. DomainsTypes of User Interfaces 4
  • 5. Command Line Interface Source: Matrix, 1999: Trinity hacking the Electric Power Plant with nmap. 5
  • 6. Games: joystick, motion 6
  • 7. WIMPs 7
  • 8. Touch UIs
  • 9. Desktop 10
  • 10. Web 11
  • 11. MobileOK. Today, the world is going Mobile.But in what platform should we invest in? 12
  • 12. Future UIs: Internet TV is comming 13
  • 13. Others Aural Interfaces 3D Users Interfaces Motion Based Interfaces And more to come… 14
  • 14. Future UIs: Internet Fridge? 15
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 22. Modelling the UI 23
  • 23. Dimensions of UI design Problem  SolutionDetail   Absract Source: [Trætteberg2004] 24
  • 24. Some UI Models  Tasks models  Dialogue/Interactions models  Navigation models  Presentation models  Component models  Dynamic models  Presentation logic models 25
  • 25. Some UI Models 26
  • 26. But also… Wireframes Sketches Mockups 27
  • 27. But also… Wireframes Sketches Use cases Mockups 28
  • 28. Wireframe Samples 29
  • 29. Navigation Maps 30
  • 30. Task Model Samples 31
  • 31. Presentation Models 32
  • 32. Design tools Paper SW drawing tools  Illustrator, FreeHand  Visio, Word, Excel Specific Sketching Tools  Balsamiq, Axure, Protoshare 33
  • 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
  • 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
  • 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
  • 36. Some useful Concepts Interaction Object [Vanderdonck&Bodart93]  AIO vs CIO Interaction Units Navigation UI Patterns 37
  • 37. Some Abstractions Service IU Instance IU Population IU Master/Detail IU Wizard IU 38
  • 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
  • 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
  • 40. Service Interaction Unit Represents an IU for a service.  Gathers input arguments and launches the service. Class Service 41
  • 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
  • 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
  • 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
  • 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
  • 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
  • 46. Just-UI / DiagrammingJust UI / VISIO Prototyping stencil 47
  • 47. Layered Approach UII_Invoice NUIMD_InvoiceAndLines Invoice A Invoice detail Lines UIP_InvoiceLines N A/Z LInes A 48
  • 48. Just-UI / Diagramming 49
  • 49. Just-UI / Diagramming 50
  • 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
  • 51. More info about: CUIPIndex ofConceptual User Interface Patternsavailable on-line at: http://pjmolina.com/cuip 52
  • 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
  • 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
  • 54. Platform constraints Physical Size Screen resolution Interaction Style Storage Computational Power Connectivity 55
  • 55. Aesthetics vs Functionality  Progressive enhancement  Unobtrusive Javascript Sample: www.datatables.net 56
  • 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
  • 57. UI CG approaches DB  Default UI  Code 58
  • 58. UI CG approaches Models  Default UI  code 59
  • 59. Demo: Essential & Io 60
  • 60. UI CG approaches Models  Default UI  code 61
  • 61. UI CG approaches Reverse engineering 62
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 69. 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
  • 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
  • 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
  • 72. Let’s do it! 73
  • 73. Thank you!Questions? @pmolinam