How did 'play' shape the design and experience of creating Serendip-o-matic?

Here are my notes from the Digital Humanities 2014 paper on 'Play as Process and Product' I did with Brian Croxall, Scott Kleinman and Amy Papaelias based on the work of the 2013 One Week One Tool team.

Scott has blogged his notes about the first part of our talk, Brian's notes are posted as '“If hippos be the Dude of Love…”: Serendip-o-matic at Digital Humanities 2014' and you'll see Amy's work adding serendip-o-magic design to our slides throughout our three posts.

I'm Mia, I was dev/design team lead on Serendipomatic, and I'll be talking about how play shaped both what you see on the front end and the process of making it.

How did play shape the process?

The playful interface was a purposeful act of user advocacy – we pushed against the academic habit of telling, not showing, which you see in some form here. We wanted to entice people to try Serendipomatic as soon as they saw it, so the page text, graphic design, 1 – 2 – 3 step instructions you see at the top of the front page were all designed to illustrate the ethos of the product while showing you how to get started.

How can a project based around boring things like APIs and panic be playful? Technical decision-making is usually a long, painful process in which we juggle many complex criteria. But here we had to practice 'rapid trust' in people, in languages/frameworks, in APIs, and this turned out to be a very freeing experience compared to everyday work.
Serendip-o-matic_ Let Your Sources Surprise You.png
First, two definitions as background for our work…

Just in case anyone here isn't familiar with APIs, APIs are a set of computational functions that machines use to talk to each other. Like the bank in Monopoly, they usually have quite specific functions, like taking requests and giving out information (or taking or giving money) in response to those requests. We used APIs from major cultural heritage repositories – we gave them specific questions like 'what objects do you have related to these keywords?' and they gave us back lists of related objects.
2013-08-01 10.14.45.jpg
The term 'UX' is another piece of jargon. It stands for 'user experience design', which is the combination of graphical, interface and interaction design aimed at making products both easy and enjoyable to use. Here you see the beginnings of the graphic design being applied (by team member Amy) to the underlying UX related to the 1-2-3 step explanation for Serendipomatic.

Feed.

serendipomatic_presentation p9.png
The 'feed' part of Serendipomatic parsed text given in the front page form into simple text 'tokens' and looked for recognisable entities like people, places or dates. There's nothing inherently playful in this except that we called the system that took in and transformed the text the 'magic moustache box', for reasons lost to time (and hysteria).

Whirl.

These terms were then mixed into database-style queries that we sent to different APIs. We focused on primary sources from museums, libraries, archives available through big cultural aggregators. Europeana and the Digital Public Library of America have similar APIs so we could get a long way quite quickly. We added Flickr Commons into the list because it has high-quality, interesting images and brought in more international content. [It also turns out this made it more useful for my own favourite use for Serendipomatic, finding slide or blog post images.] The results are then whirled up so there's a good mix of sources and types of results. This is the heart of the magic moustache.

Marvel.

User-focused design was key to making something complicated feel playful. Amy's designs and the Outreach team work was a huge part of it, but UX also encompasses micro-copy (all the tiny bits of text on the page), interactions (what happened when you did anything on the site), plus loading screens, error messages, user documentation.

We knew lots of people would be looking at whatever we made because of OWOT publicity; you don't get a second shot at this so it had to make sense at a glance to cut through social media noise. (This also meant testing it for mobiles and finding time to do accessibility testing – we wanted every single one of our users to have a chance to be playful.)


Without all this work on the graphic design – the look and feel that reflected the ethos of the product – the underlying playfulness would have been invisible. This user focus also meant removing internal references and in-jokes that could confuse people, so there are no references to the 'magic moustache machine'. Instead, 'Serendhippo' emerged as a character who guided the user through the site.

moustache.png But how does a magic moustache make a process playful?

magicmoustachediagram.jpgThe moustache was a visible signifier of play. It appeared in the first technical architecture diagram – a refusal to take our situation too seriously was embedded at the heart of the project. This sketch also shows the value of having a shared physical or visual reference – outlining the core technical structure gave people a shared sense of how different aspects of their work would contribute to the whole. After all, if there aren't any structure or rules, it isn't a game.

This playfulness meant that writing code (in a new language, under pressure) could then be about making the machine more magic, not about ticking off functions on a specification document. The framing of the week as a challenge and as a learning experience allowed a lack of knowledge or the need to learn new skills to be a challenge, rather than a barrier. My role was to provide just enough structure to let the development team concentrate on the task at hand.

In a way, I performed the role of old-fashioned games master, defining the technical constraints and boundaries much as someone would police the rules of a game. Previous experience with cultural heritage APIs meant I was able to make decisions quickly rather than letting indecision or doubt become a barrier to progress. Just as games often reduce complex situations to smaller, simpler versions, reducing the complexity of problems created a game-like environment.

UX matters


Ultimately, a focus on the end user experience drove all the decisions about the backend functionality, the graphic design and micro-copy and how the site responded to the user.

It's easy to forget that every pixel, line of code or text is there either through positive decisions or decisions not consciously taken. User experience design processes usually involve lots of conversation, questions, analysis, more questions, but at OWOT we didn't have that time, so the trust we placed in each other to make good decisions and in the playful vision for Serendipomatic created space for us to focus on creating a good user experience. The whole team worked hard to make sure every aspect of the design helps people on the site understand our vision so they can get with exploring and enjoying Serendipomatic.

Some possible real-life lessons I didn't include in the paper

One Week One Tool was an artificial environment, but here are some thoughts on lessons that could be applied to other projects:

  • Conversations trump specifications and showing trumps telling; use any means you can to make sure you're all talking about the same thing. Find ways to create a shared vision for your project, whether on mood boards, technical diagrams, user stories, imaginary product boxes. 
  • Find ways to remind yourself of the real users your product will delight and let empathy for them guide your decisions. It doesn't matter how much you love your content or project, you're only doing right by it if other people encounter it in ways that make sense to them so they can love it too (there's a lot of UXy work on 'on-boarding' out there to help with this). User-centred design means understanding where users are coming from, not designing based on popular opinion.you can use tools like customer journey maps to understand the whole cycle of people finding their way to and using your site (I guess I did this and various other UXy methods without articulating them at the time). 
  • Document decisions and take screenshots as you go so that you've got a history of your project – some of this can be done by archiving task lists and user stories. 
  • Having someone who really understands the types of audiences, tools and materials you're working with helps – if you can't get that on your team, find others to ask for feedback – they may be able to save you lots of time and pain.
  • Design and UX resources really do make a difference, and it's even better if those skills are available throughout the agile development process.

Clash of the models? Object-centred and object-driven approaches in online collections

While re-visiting the world of museum collections online for some writing on 'crowdsourcing as participation and engagement with cultural heritage', I came across a description of Bernard Herman's object-centred and object-driven models that could be useful for thinking about mental models designing better online collections sites.

(I often talk about mental models, so here's a widely quoted good definition, attributed to Susan Carey’s 1986 journal article, Cognitive science and science education:

'A mental model represents a person’s thought process for how something works (i.e., a person’s understanding of the surrounding world). Mental models are based on incomplete facts, past experiences, and even intuitive perceptions. They help shape actions and behavior, influence what people pay attention to in complicated situations, and define how people approach and solve problems.'

CATWALKModel House FaceTo illustrate a clash in models, when you read 'model' you might have thought of lots of different mental pictures of a 'model', including model buildings or catwork models, and they'd both be right and yet not quite what I meant:

And now, back to museums…)

To quote from the material culture site I was reading, which references Herman 1992 'The Stolen House', in an object-centred approach the object itself is the focus of study:

"Here, we need to pay attention to the specific physical attributes of the object. The ability to describe the object – to engage, that is, with a list of descriptive criteria – is at the forefront of this approach. A typical checklist of the kinds of questions we might ask about an object include: how, and with what materials, was the object made? what is its shape, size, texture, weight and colour? how might one describe its design, style and/or decorative status? when was it made, and for what purpose?"

In object-driven material culture:

"the focus shifts toward an emphasis on understanding how objects relate to the peoples and cultures that make and use them. In particular, ideas about contextualisation and function become all important. As we have already noted, what objects mean may change through time and space. As products of a particular time and place, objects can tell us a great deal about the societies that gave birth to them. That is, they often help to reflect, or speak to us, of the values and beliefs of those who created them. At the same time, it is also important to remember that objects are not simply ‘passive’ in this way, but that they can also take on a more ‘active’ role, helping to create meaning rather than simply reflect it."

It seems to me that the object-centred approach includes much of the information recorded in museum catalogues, while the object-driven approach is closer to an exhibition.  Online museum collections often re-use content from catalogues and therefore tend to be object-centred by default as catalogues generally don't contain the information necessary to explain how each object relates 'to the peoples and cultures that make and use them' required for an object-driven approach.  If that contextual information is available, the object might be sequestered off in an 'online exhibition' not discoverable from the main collections site.

A complicating factor is the intersection of Herman's approaches with questions about the ways audiences think about objects in museums and other memory institutions (as raised in Rockets, Lockets and Sprockets – towards audience models about collections?).  The object-centred approach seems more easily applicable to individual objects but the object-driven approach possibly works better for classes of objects.  I'm still not sure how different audiences think about the differences between individual objects and classes of objects, so it's even harder to know which approach works best in different contexts, let alone how you would determine which model best suits a visitor when their interaction is online and therefore mostly contextless.  (If you know of research on this, I'd love to hear about it!)

I'd asked on twitter: 'Can mixed models make online collections confusing?'  John Coburn suggested that modes of enquiry online might be different, and that the object-driven attributes might be less important.  This was a useful point, not least because it helped me crystallise one reason I find the de-materialisation of objects online disconcerting – attributes like size, weight, texture, etc, all help me relate to and understand objects.  Or as Janet E Davis said, 'I automatically try to 'translate' into the original medium in my head'.   John answered with another question: 'So do we present objects via resonant ideas/themes/wider narrative, rather than jpg+title being "end points"?', which personally seems like a good goal for online collections, but I'm not the audience.

So my overall question remains: is there a potential mismatch between the object-driven approach that exhibitions have trained museum audiences to expect and the object-centred approach they encounter in museum collections online?  And if so, what should be done about it?

What do you mean by 'wireframe'?

This post on 'The future of wireframes?' chimed a few bells, not only because I'm revising for a Requirements Engineering exam but because I've been in the start-up phase for projects of all sizes lately and have been thinking hard about the best way to understand and communicate requirements. In doing so, I've realised that 'wireframes' has become one of those terms that mean different things to different people – and that of course, it's an entirely new term to people who haven't worked on a design phase of a digital project before. This summed up past and current definitions neatly:

For many years the primary role of wireframes was to specify software. We now use wireframes to investigate and explore how people will interact with a site. Using a ‘just enough’ approach, we often create a series of simple interactive prototypes to try out a variety of approaches to solving a problem. These prototypes can be made in HTML or they can be as simple as a series of Keynote slide for someone to click through.

This is a very different approach to wireframing. Rather than simply documenting where a link goes, the goal is to model and start experiencing what moving around a site feels like as quickly as possible. The prototype can then be tested and the results used to iteratively improve the end solution.

Of course, sites still need to be specified, but wireframes aren’t always the right tool for doing this.

Here's a list of wireframe and prototype tools – do you have any favourites?

A rare post from me – I've been completely caught up in work and my MSc for the past few months. Normal service will be resumed soon – I've still got to report on UKMW09 and a trip to Oslo to give a lecture on social media and museums, libraries and archives.

Useful background on usability testing

I came across www.usability.gov while looking for some background information on usability testing to send colleagues I'm planning some user evaluation with. It looks like a really useful resource for all stages of a project from planning to deployment.

Their guidelines are available to download in PDF form, either as entire book or specific chapters.