Last week, EDM Director Darran Edmundson and Glenda Smith from the Museum of Australian Democracy at Old Parliament House (MoAD), spoke to attendees at the MuseumNext 2012 conference in Barcelona. Their talk, titled “Interactive Learning Trails: An RFID Success Story”, provided MuseumNext attendees with insight into the collaborative development of MoAD’s on-site interactive learning experience. The software behind this experience, originally launched in 2010, now forms the core of EDM’s flagship product, TRAIL.
TRAIL emerged from a very concrete mandate: Create a compelling digital replacement to the traditional paper worksheet-based approach to museum learning. Specific challenges issued to the design team included:
- Improve student engagement with the museum’s objects, images and stories
- For program delivery staff, be less ‘work’ than the pencil and paper approach (allow educators to focus on learning, not logistics)
- Allow educators to create and update activities without technical assistance (from EDM or MoAD IT staff)
- Provide students and teachers with a takeaway component reflecting the unique on-site experiences
- Appeal to different learning styles
- Coexist with public visitors sharing the same gallery space
In the talk, Darran and Glenda spoke to TRAIL’s iterative development. Traditionally museum software development follows the same model used in exhibit fabrication, one of thorough design, followed by client sign-off, and finally build to spec. This architectural model makes perfect sense in the physical realm. You couldn’t very well design and build a full-scale mockup of an exhibition, assess it, and then decide to start over. But software is different. Good software is modular and amenable to reuse. The benefits of quickly coding up a minimally-functional version of an interactive to test assumptions and gain important user feedback far outweigh any ‘throw-away’ costs involved. We used this approach extensively in TRAIL’s development, carrying out dozens of filmed tests along the way that the MoAD/EDM team reviewed during our bi-weekly ‘design direction’ meetings.
Iterative development embraces testing, using relatively-short repeated cycles of design, programming and testing to … well, iterate … towards the project goal. Of course, knowing what your goals are is critical, and, while the above challenges provide a high-level summary, they are far too general to be useful on a day-to-day assessment basis. Enter ‘User Stories’.
User Stories are short statements that describe a software system requirement. Each user story is limited to one or two sentences that fit on a small paper card. They are written by the client and represent one of the most significant means of influencing software development. Stories are written in plain English from the perspective of a stakeholder (Presenter/Docent, Teacher, Student, Public Visitor), have a context that sets the scene, an explanation of how the scenario plays out, and a reason for wanting it. Here’s an example:
Story 4: As a Presenter, when a group arrives late, I want to easily set the duration of the exhibition experience in order to ensure that the group leaves the exhibition on time.
This story is obviously borne out of experience. While a timed experience might work for the bulk of visitors, at MoAD some school groups show up late, and program length needs to adjust to take this into account. What can we notice about this specific story? First, there is no mention of implementation details. This is extremely important, as it allows the client (who is typically not technologically-savvy) to author software requirements as an equal. At MoAD, once stakeholders understood the format and value of User Stories, they literally poured in … and continued to do so throughout the development process. Second, the story can be tested. When the final system appears, we can check: does TRAIL fulfil Story #4? Third, the story has been given a priority by the client. The realities of time and budget mean that not all stories will be implemented – priorities ensured that EDM spent the bulk of its efforts solving problems that the client identified as important.
Iterative Development and User Stories are two examples of the agile-software approach that MoAD and EDM took on this project. Judging from MuseumNext audience positive feedback, we might just see more museum software projects using this development methodology in the near future.
Care to share your thoughts? Please contact us using the form below or send us an email.