Towards an Agile approach to building application profiles
0 likes688 views
The document discusses taking an Agile approach to developing application profiles. It involves bringing potential users into the process early through techniques like prototyping and user testing. The goal is to iteratively develop application profiles based on evidence from user engagement to complement the Singapore Framework. By testing and receiving feedback early, costly mistakes can be avoided and user requirements can evolve with changing needs. Tools like MrVobi support collecting user input through activities like free listing, card sorting, and storyboarding to develop a shared understanding and iteratively refine domain models and functional requirements.
Towards an Agile approach to building application profiles
- 1. Towards an Agile approach to building application profiles Paul Walk (p.walk@ukoln.ac.uk) Emma Tonkin (e.tonkin@ukoln.ac.uk) UKOLN is supported by: www.ukoln.ac.uk A centre of expertise in digital information management 1
- 2. Objective • in general, our approach is to bring (potential) users into the process at the earliest opportunity, and to develop the application profile using Agile development techniques • we have taken some lessons from HCI and software engineering disciplines which give us the related techniques of: • prototyping • user (usability) testing • we aim to re-use or prototype tools and approaches which are easy and cheap to deploy • our aim is to complement the Singapore Framework 2
- 3. Why Agile? • we think that the Application Profiles we are involved in developing could benefit from an Agile approach • Agile emphasises: • close involvement of users, or potential users, at each stage of development • working solutions over comprehensive documentation • responding to changing requirements/ understanding • agile development aims to reduce risk of failure 3
- 4. Singapore Framework - scope • scope of our work • functional requirements (mandatory) ✔ • domain model (mandatory) ✔ • description Set Profile (mandatory) • usage guidelines (optional) ✔ • encoding syntax guidelines (optional) • we have concentrated on the the early processes, especially the functional requirements gathering and early modelling stages 4
- 5. Singapore Framework - scope 5
- 6. Singapore Framework - scope 5
- 8. Progress • beginning to demonstrate how: • decision making about functional requirements can be based on evidence from user-engagement • usability of domain models can be tested at early stages of development • user engagement can be both valuable and fun :-) 7
- 9. The pay-off • testing and checking early can keep development on- track - avoids expensive mistakes • application profiles can be re-tested later on, as functional requirements evolve with external developments • confidence that the application profile has passed some preliminary usability testing (evidence for this) • user-engagement! • user-engagement!! • user-engagement!!! • user-engagement!!!! 8
- 10. Objective – part 2 • Prerequisite for collaborative work: The ability to communicate effectively • Prerequisite to effective communication: Sharing – common ground, mutual understanding …Speaking the same language This is harder than it seems 9
- 11. Terms • Q. What’s in a domain? • A. Easiest way to find out – ask. • Free-listing is “a simple technique for gathering data about a specific domain or topic by asking people to list all the items they can think of that relate to the topic.” • Output: Quantitative, reusable list of ‘concepts and things’ 10
- 12. Example 11
- 13. Example 2 12
- 14. Free-listing - analysis • Very much like social tag analysis • Just a very large data collation exercise • Leading to a list of terms and term frequencies (synonym identification is also an issue, but tends to fall out in the next stage, so this analysis is an ongoing process) • Other data sources for this stage could include social tagging and machine analysis of a domain – general area of ontology creation and evaluation 13
- 15. Structures • Now that we have some idea of ‘things’ (could be entities, functions/methods, properties, classes…) • Users have something to ‘play’ with • Card sorting for classification is a well-known approach, which we use here • Principle: The important point is not that participants are in effect creating a taxonomy. It is that they are coming to a shared understanding of the ‘things’ involved in the domain, and how they see them as fitting together. 14
- 16. 15
- 17. Card sorting - analysis • It’s not a question of ‘right’ or ‘wrong’ • An opportunity to collect evidence and understand user viewpoints • Again, quantitative outputs available (eg. ‘card sorting diffs’ are possible) 15
- 18. Contexts of use • Now that we have a strawman prototype, we can proceed to ask and answer questions about it • Simple questions can check the intuitiveness of the sort • More complex questions can teach us more about how the prototype would fit into user-contributed workflows • 1. Collect workflows • 2. Storyboarding using the prototype to solve the workflow 16
- 19. Same Thing, But On The Web: MrVobi • A web-based tool supporting the stages described here • Simple, basic prototype • Ongoing development • Handles data collection and visualisation • Accessible MrVobi 17
- 20. Card Sorting on the big screen • Very visual interface • For use in collaborative workspaces • Supports touchscreen interfaces, etc • (but less accessible for visually impaired) • What’s in an interface? What difference does the use of different media make? Don’t know yet, but we’re investigating. video-> 18
- 21. 20
- 22. questions? 19