UX – Open Objects

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.

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.

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.

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.

But how does a magic moustache make a process playful?

The 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.'

To 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?

Reflections on teaching Neatline

I've called this post 'Reflections on teaching Neatline' but I could also have called it 'when new digital humanists meet new software'. Or perhaps even 'growing pains in the digital humanities?'.

A few months ago, Anouk Lang at the University of Strathclyde asked me to lead a workshop on Neatline, software from the Scholar's Lab that plots 'archives, objects, and concepts in space and time'. It's a really exciting project, designed especially for humanists – the interfaces and processes are designed to express complexity and nuance through handcrafted exhibits that link historical materials, maps and timelines.

The workshop was on Thursday, and looking at the evaluation forms, most people found it useful but a few really struggled and teaching it was also slightly tough going. I've been thinking a lot about the possible reasons for that and I'm sharing them both as a request for others to share their experiences in similar circumstances and also in the hope that they'll help others.

The basic outline of the workshop was an intros round (who I am, who they are and what they want to learn); information on what Neatline is and what it can do; time to explore Neatline and explore what the software can and can't do (e.g. login, follow the steps at neatline.org/plugins/neatline to create an item based on a series of correspondence Anouk had been working on, deciding whether you want to transcribe or describe the letter, tweaking its appearance or linking it to other items); and a short period for reflection and discussion (e.g. 'What kinds of interpretive decisions did you find yourself making? What delighted you? What frustrated you?') to finish. If you're curious, you can follow along with my slides and notes or try out the Neatline sandbox site.

The first half was fine but some people really struggled with the hands-on section. Some of it was to do with the software itself – as a workshop, it was a brilliant usability test of the admin interfaces of the software for audiences outside the original set of users. Neatline was only launched in July this year and isn't even in version 2 yet so it's entirely understandable that it appears to have a few functional or UX bugs. The documentation isn't integrated into the interface yet (and sometimes lacks information that is probably part of the shared tacit knowledge of people working on the project) but they have a very comprehensive page about working with Neatline items. Overall, the process of handcrafting timelines and maps for a Neatline exhibit is still closer to 'first, catch your rabbit' than making a batch of ready-mix cupcakes. Neatline is also designed for a particular view of the world, and as it's built on top of other software (Omeka) with another very particular view of the world (and hello, Dublin Core), there's a strong underlying mental model that informs the processes for creating content that is foreign to many of its potential users, including some at the workshop.

But it was also partly because I set the bar too high for the exercises and didn't provide enough structure for some of the group. If I'd designed it so they created a simple Neatline item by closely following detailed instructions (as I have done for other, more consciously tech-for-beginners workshops), at least everyone would have achieved a nice quick win and have something they could admire on the screen. From there some could have tried customising the appearance of their items in small ways, and the more adventurous could have tried a few of the potential ways to present the sample correspondence they were working with to explore the effects of their digitisation decisions. An even more pragmatic but potentially divisive solution might have been to start with the background and demonstration as I did, but then do the hands-on activity with a smaller group of people who were up for exploring uncharted waters. On a purely practical level, I also should have uploaded the images of the letters used in the exercise to my own host so that they didn't have to faff with Dropbox and Omeka records to get an online version of the image to use in Neatline.

And finally it was also because the group had really mixed ICT skills. Most were fine (bar the occasional bug), but some were not. It's always hard teaching technical subjects when participants have varying levels of skill and aptitude, but when does it go beyond aptitude into your attitude about being pushed out of your comfort zone? I'd warned everyone at the start that it was new software, but if you haven't experienced beta software before I guess you don't have the context for understanding what that actually means.

I should make it clear here that I think the participants' achievements outshine any shortcomings – Neatline is a great tool for people working with messy humanities data who want to go beyond plonking markers on Google Maps, and I think everyone got that, and most people enjoyed the chance to play with Neatline.

But more generally, I also wonder if it has to do with changing demographics in the digital humanities – increasingly, not everyone interested in DH is an early, or even a late adopter, and someone interested in DH for the funding possibilities and cool factor might not naturally enjoy unstructured exploration of new software, or be intrigued by trying out different combinations of content and functionality just 'to see what happens'.

Practically, more information for people thinking of attending would be useful – 'if you know x already, you'll be fine; if you know y already, you'll be bored' would be useful in future. Describing an event as 'if you like trying new software, this is for you' would probably help, but it looks like the digital humanities might also now be attracting people who don't particularly like working things out as they go along – are they to be excluded? If using software like this is the onboarding experience for people new to the digital humanities, they're not getting the best first impression, but how do you balance the need for fast-moving innovative work-in-progress to be a bit hacky and untidy around the edges with the desires of a wider group of digital humanities-curious scholars? Is it ok to say 'here be dragons, enter at your own risk'?

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.