When Users Becom Collaborators: Towards Continuous and Context-Aware User Input


Published on

Current requirements engineering practices for gathering user input are characterized by a number of communication gaps between users and engineers which might lead to wrong requirements. The problem situations and context which underlie user input are either gathered back in time, or submitted with wrong a level of details. We think that making user input a first order concern of both software processes and software systems harbours many innovation opportunities. We propose and discuss a continuous and context-aware approach for communicating user input to engineering teams and other users, by a) instrumenting the problem domain, b) proactively recommending to share feedback and c) annotating graphical interfaces.

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • fast development cycles/reduce time-to implementation There are many studies, proving that the biggest problems in software projects lie in the requirement analysis, the first stage of every software project. The interviewed experts in the study of the Standish Group have the opinion that insufficient requirements are the biggest problem and that the involvement of customer and user is very important. This study was performed again in the last years and the results didn’t changed significantly.
  • "Perpetual beta" "Perpetual beta" "Perpetual beta" "Perpetual beta" "Perpetual beta" "Agile development" "Agile development" "Agile development" "User innovation" "User innovation" Prototyping Prototyping Prototyping Feedback Feedback Feedback Feedback Feedback Feedback Feedback "Continuous improvement" "Continuous improvement" "Continuous improvement" "End-user development" "End-user development" "End-user development" "End-user development" "Usability Engineering" "Usability Engineering" "User Experience" "Participatory Design" "Participatory Design" "Participatory Design" "User-Centered Design" Mockup Continuous process improvement Continuous process improvement Continuous process improvementv
  • lead users adjust by themselves
  • Horizontal (user/dev) and vertical (iterations) gaps + user2user gap * Gap ** Actual distribution ** Media switches when sending requests (vs. feedback channels) ** Community interaction ** Difficult to monitor heterogeneous comm. streams
  • * back-feedback: ** customized release notes ** root updates in need
  • * Visual annotations: important, but only snapshot tools
  • * Proactive assistnce: ** Rate MR ** Extend help info ** Get recommendation for workaround
  • When Users Becom Collaborators: Towards Continuous and Context-Aware User Input

    1. 1. When Users Become Collaborators: Towards Continuous and Context-Aware User Input Walid Maalej (TU München) Hans-Jörg Happel , Asarnusch Rashid (FZI Karlsruhe) OOPSLA Onward! Orlando, FL, October 29 th , 2009
    2. 2. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    3. 3. <ul><li>Reasons for project failure </li></ul><ul><li>Incomplete Requirements </li></ul><ul><li>No customer requirements </li></ul><ul><li>Lack of resources </li></ul><ul><li>Unrealistic expectations </li></ul><ul><li>Uncontrolled changes of </li></ul><ul><li>requirements </li></ul>User involvement is critical for the success of software development projects 13% 12% 11% 10% 9% Reasons for project success Customer/User involvement Ex. Management support Clear Statement of requirements Proper planning Realistic expectations 16% 14% 13% 10% 8% [Standish Group 2003, recent studies with similar results]
    4. 4. Various concepts to address end users in software development
    5. 5. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    6. 6. Various types of user input ? Perpetual Beta Legacy Documents Usage Data Implicit Explicit Pull Push Issue and Bug Report Enhancement Request Feature Request Workshop Interview, Survey Clarification Request Field Observation Lead Users (Not used in SE) Communication Feedback
    7. 7. Various realizations of user input
    8. 8. Mysterious stack traces
    9. 9. Bug reports from within a program
    10. 10. Application usage data
    11. 11. Discussions in user communities
    12. 12. Various realizations of user input …but most applications still do not consider feedback at all…
    13. 13. Problems of the status quo <ul><li>Gaps through fragmented streams of user interaction – feedback cross-cuts proceses </li></ul><ul><li>User input difficult to understand </li></ul><ul><li>No frameworks for systematic integration into application </li></ul>How can we make user Input as a first-order concern in both processes and architectures? For Engineers For Users <ul><li>User input is usually… </li></ul><ul><li>Tedious to provide (e.g. writing detailed context information) </li></ul><ul><ul><li>Incomplete or imprecise </li></ul></ul><ul><ul><li>Focussed on one particular step (e.g. bug reporting) </li></ul></ul><ul><ul><li>Uni-directional and singular </li></ul></ul>
    14. 14. Streams of interaction Requirements Engineers Users Realization Provision Deployment Problem Usage Evolution Fix Question Support
    15. 15. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    16. 16. A Continuous Feedback Model Prospective Observation Assisted Feedback Improvement D ecision Back- Feedback Systematic Analysis Application User Engineering Team Development Infrastructure Community Sharing
    17. 17. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    18. 18. Technical building blocks Visual Annotation Recommend end user to share their experience with engineering teams end other end users Observation & Context Elicitation Allow user to annotate and „paint“ on the GUI in the work context Proactive Assistance Detect user intention and problem situations through observation of user and application Making user input a 1 st order concern
    19. 19. TeamWeaver Context Framework problem problem Execution Ontology Interaction Ontoloy Feedback Reporting Interface OS sensors User Profile Elicitation Problem events update trigger A pplication sensors Execution Env. sensors A dditional feedback interact Session- ization Context Observer http://www.teamweaver.org
    20. 20. Visual Annotation with OpenProposal End user application http://www.openproposal.de OpenProposal plus Username, Application, Version, Date, etc. Issue Tracker
    21. 21. Inverse Search to recommend users to share their experience <ul><li>Conventional recommendation systems: </li></ul><ul><ul><li>Match interests of users against a given set of information </li></ul></ul><ul><ul><li>Push information to the user </li></ul></ul><ul><li>Users providing information are not part of this model although they are potential sources for additional information </li></ul><ul><li>Recommendation using inverse search: </li></ul><ul><ul><li>Matches the private/local information of users (information providers) against a given set of needs </li></ul></ul><ul><ul><li>Identify information (e.g. experiences and interactions) worth sharing </li></ul></ul>Experiences Needs 3. iSearch 4. Share 1. Query 2. Results Engineer / User Information Seeker User Information Provider
    22. 22. Outline Motivation A Benchmarking A New Approach Technical Enablers Next Steps
    23. 23. Conclusion <ul><li>Feasability </li></ul><ul><ul><li>Technical building blocks are there </li></ul></ul><ul><ul><li>Further technologies to enable tighter collaboration between users and developers emerge (e.g. Microblogging) </li></ul></ul><ul><ul><li>Communication and transparency in Open Source projects </li></ul></ul><ul><ul><li>Several services on the web decide on realization options based on implicit feedback </li></ul></ul><ul><ul><li>Users are motivated by feedback </li></ul></ul><ul><li>Challenges </li></ul><ul><ul><li>Privacy </li></ul></ul><ul><ul><li>Development culture </li></ul></ul><ul><ul><li>Non-intrusiveness </li></ul></ul><ul><ul><li>Context-similarity </li></ul></ul>
    24. 24. Summary <ul><li>Results </li></ul><ul><ul><li>Comparing different types of user input </li></ul></ul><ul><ul><li>Identification of technology and process enablers for feedback-driven development </li></ul></ul><ul><li>User input deserves to become a first order concern in development processes and architectures </li></ul><ul><ul><li>How can users become prosumers instead of mere consumers of applications? </li></ul></ul><ul><ul><li>How to give engineering teams more continuous, direct and rich input for development? </li></ul></ul><ul><li>Tools </li></ul><ul><ul><li>www.teamweaver.org </li></ul></ul><ul><ul><li>www.openproposal.de </li></ul></ul>
    25. 25. References <ul><li>Walid Maalej and Hans-Joerg Happel: A Lightweight Approach for Knowledge Sharing in Distributed Software Teams. In Proceeedings of the 7th International Conference on Practical Aspects of Knowledge Management (PAKM2008). </li></ul><ul><li>Happel, H.-J. and Maalej, W.: Potentials and Challenges of Recommendation Systems for Software Development. In Proceedings of the International Workshop on Recommendation Systems for Software Engineering (RSSE 2008). </li></ul><ul><li>Rashid, A., Wiesenberger, J., Meder, D. Baumann , J.: Bringing Developers and Users closer together: The OpenProposal story. In: Multikonferenz Wirtschaftsinformatik 2008 (MKWI 2008), 26.2. - 28.2.2008, München. </li></ul><ul><li>Standish Group: The 2003 CHAOS Chronicles report. </li></ul><ul><li>Walid Maalej: Task-First or Context-First? Tool Integration Revisited. In: 24th IEEE/ACM International conference on Automated Software Engineering (ASE 2009) Auckland, New Zealand. 16th-20th November 2009. </li></ul>