Gesture-based information systems: from DesignOps to DevOps
•Download as PPTX, PDF•
1 like•296 views
Keynote address for the 29th International Conference on Information Systems Development ISD'2021 (Valencia, Spain, September 8-10, 2021). See https://isd2021.webs.upv.es/program.php#keynotes This talk promotes the Seven I': Implementation continuity Inclusion of end-users Interaction first Integration among stakeholders Iteration short Incremental progress Innovation openness
Report
Share
More Related Content
What's hot
What's hot (20)
Similar to Gesture-based information systems: from DesignOps to DevOps
Similar to Gesture-based information systems: from DesignOps to DevOps (20)
More from Jean Vanderdonckt
More from Jean Vanderdonckt (20)
Recently uploaded
Recently uploaded (20)
Gesture-based information systems: from DesignOps to DevOps
- 1. Gesture-based information systems: from DesignOps to DevOps Jean Vanderdonckt ISD’2021 (Online, September 8th, 2021)
- 2. 2 Summary 1. Goals and Some Definitions 2. Motivations 3. The Seven I’s: An Overview 4. First case study: gesture-based application 5. Second case study: collaborative real-time GUI dev 6. The Seven I’s: Examplification 7. Conclusion
- 3. Goals and Some Definitions • Overall goal: to reduce the time elapsed between a change request and its delivery while ensuring software quality • DevOps (initiated at DevOpsDays ‘09, Ghent, Belgium!) • “Makes up a model in which development, quality assurance, releasing, deployment, operation with infrastructure management, and maintenance are integrated and automated as much as possible” [Benni, 2019] • “A software development methodology, under which a tight coupling between operation teams and software developers takes place” [Kuusinen, 2018] • “A collaboration in the end-to-end delivery process of software products or services” [Diaz, 2019] • “Including end-users themselves” [Heistand, 2019]
- 4. Goals and Some Definitions • Overall goal: to reduce the time elapsed between a change request and its delivery while ensuring software quality • DesignOps • “They help grow and evolve design teams by operationalizing workflows, managing projects, budgets and hiring. But most importantly, they help improve the quality of the designs being produced by allowing designers to do what they do best: design.” [SuperSide, 2021] • “The orchestration and optimization of people, processes, and craft in order to amplify design's value and impact at scale” [Nielsen, 2021] • “refers to the practice of integrating the design team’s workflow into the company’s larger development context” [ProductPlan, 2021]
- 5. 46% 30% 28% 28% 24% 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% Reduce development costs Increasing technological complexity Need to increase revenue Increasing data requirements Move to hybrid and multicloud infrastructure Top Pressures to Improve Application Performance Monitoring Motivations • To reduce development costs, etc. Source: Aberdeen report, 2020
- 6. 75% 64% 63% 62% 55% 40% 38% 40% 46% 40% 0% 10% 20% 30% 40% 50% 60% 70% 80% Identify sources of delay in application response times in… Monitor end-user experience Real-time incident alerting Measure application response times Perform root-cause analysis on application issues Modern APM lead to better end-to-end application management With Without Motivations • Impact of an Application Performance Management Source: Aberdeen report, 2020
- 7. SDLC efficiency Prioritize software quality factors Quickly respond to end-users requests Guarantee that requests are properly addressed Time-to-market delivery Software quality Break the waterfall workflow Benefits from agile methods Participatory design Accommodate needs for change management Meet customer satisfaction Identify KPI to address Need to incorporate new aspects Organizational flexibility User eXpercience Measurability Capability to innovate Computer Science Management Sciences Overlapping Goals Means = Maximize, = Minimize
- 8. The Seven I’s 1. Implementation continuity 2. Inclusion of end-users 3. Interaction first 4. Integration among stakeholders 5. Iteration short, not fast 6. Incremental progress 7. Innovation openness
- 9. First case study: gesture-based application • Aims and goals: to collect gesture proposals from end-users based on designer suggestions, reach consensus, and transfer to development • Stakeholders: distributed in time and space Define Conduct Classify Measure Discuss Export Gesture Mapping Command COPY Log files on all steps! Source: Magrofuoco & Vanderdonckt, Gelicit: A Cloud Platform for Distributed Gesture Elicitation Studies, EICS 2020
- 10. Define
- 11. Define Conduct
- 13. Define Define Conduct Classify Measure
- 14. Define Define Conduct Classify Measure Discuss
- 15. Define Define Conduct Classify Measure Discuss Export
- 16. Second case study: collaborative real-time GUI dev • Aims and goals: to collaboratively design and develop a GUI for a web site • Stakeholders: distributed in time and space Source: Moldovan et al., OpenUIDL, A User Interface Description Language for Runtime Omni-Channel User Interfaces, EICS 2020 Initiate Customize Collaborate Measure Discuss Export See http://teleporthq.io
- 18. Initiate Customize Collaborate Measure See http://teleporthq.io
- 19. Initiate Customize Collaborate Measure See http://teleporthq.io Discuss Export
- 20. I1: Implementation continuity • Continuous integration (CI): early and continuous integration of coe, enable faster feedback cycles and reduced workload [Debroy, 2018] • Continuous Delivery (CDE): process in which new development is brought into production [Düllman, 2018] Poor examples • Separation between design and development • What I designed is what you have to develop (but not really!) • Throw-away prototypes
- 21. I1: Implementation continuity Poor example Source: https://www.smashingmagazine.com/2010/05/resurrecting-user-interface-prototypes-without-creating-zombies/
- 22. I1: Implementation continuity Poor example Source: https://www.smashingmagazine.com/2010/05/resurrecting-user-interface-prototypes-without-creating-zombies/
- 23. I1: Implementation continuity Poor example
- 24. I1: Implementation continuity Better example • Continuity between prototyping steps Generic design Specific design All stakeholders Development team User Interface mockups with comments UI design specifications UI Screen shots with call-outs on specific elements 1 2 3 UI flow document
- 25. I1: Implementation continuity Better example • Continuity between prototypes of different levels of fidelity Level of fidelity Low Check box Identification label Medium High Final
- 26. I1: Implementation continuity Better example • Continuity between prototypes of different levels of fidelity
- 27. I1: Implementation continuity Better example • Continuity between prototypes of different levels of fidelity
- 28. I2: Inclusion of end-users Poor example • Leave an interface builder in the hand of any end-user • Tables with dynamic data • Gantt chart • Direct manipulation of tasks Desired UI Obtained UI • Window with menu bar • Toolboar with icons • Static controls: list boxes, push buttons, • No navigation
- 29. I2: Inclusion of end-users Better example • Provide end-users with a prototyping tool that preserves continuity and ensure integration (I4) Source: Vanderdonckt & Grolaux, End-User Composition of Graphical User Interfaces by Composite Pattern, EICS ‘19
- 30. I2: Interaction first Poor examples Controller Functional core Presentation Global navigation Local navigation Presentational prototype first Controller Functional core Presentation Global navigation Local navigation Local navigation prototype first Controller Functional core Presentation Global navigation Local navigation Global navigation prototype first
- 31. I2: Interaction first Better example User interface Controller Functional core Complete Interactive application Horizontal prototype Vertical prototype User interface Controller Functional core Complete interactive application Diagonal prototype Scenario = script of particular fixed uses of the system; no deviation allowed
- 32. I2: Interaction first Better example: GAMBIT Try our app at http://qualihmgambit.appspot.com/ Sketching as a Service (Skaas) is a delivery model where the sketching activity is offered as a service for • Multiple stakeholders • Multiple platforms • Multiple environments • Multiple purposes
- 33. I2: Interaction first Better example: Step1 = define structure GAMBIT
- 34. I2: Interaction first Better example: Step2 = define behavior GAMBIT
- 35. I2: Interaction first Better example: Step3 = test in lab GAMBIT
- 36. I2: Interaction first Better example: Step3 = test in real GAMBIT
- 37. I4: Integration among stakeholders Better example: GAMBIT
- 38. I4: Integration among stakeholders Better example: GAMBIT
- 39. I5: Iteration short Better example: GAMBIT
- 40. I6: Incremental progress Some example: MUI
- 41. I7: Innovation openness Some example: MUI Acquisition Recognition Frontend Sensor interface Static recognizer MUI application Dynamic recognizer Segmenter Segmentation
- 42. Conclusion: The Seven I’s 1. Implementation continuity 2. Inclusion of end-users 3. Interaction first 4. Integration among stakeholders 5. Iteration short, not fast 6. Incremental progress 7. Innovation openness DesignOps DevOps 4 4 4 1 4 2 3 3 4 4 3 2 1 2 Importance
- 43. Thank you very much for your attention