I’ve just carried out some usability testing on the prototypes and thought it might be an interesting point to reflect and consider what we’ve been trying to achieve.

My main inspiration for the interface for the project came from Mitchell Whitelaw’s recent work on generous interfaces for cultural collections. In short the ideas are primarily to present content to the user up-front, not to hide it behind search boxes or esoteric lists of links; and to combine some elements of data visualisation into the presentation of content. In some ways the former element isn’t so original–e-commerce sites have been doing this kind of thing for a long time now, although it’s been rarer in the area of online digital cultural collections. The latter is particularly interesting however–check out Mitchell’s TEDx talk for an introduction to some of his work to see ways in which the use of data viz techniques might present ideas for research paths, e.g. by highlighting commonly occurring words and their relationships with other words in online archival collections.

I was keen to use this principal, partly because I personally find search/text interfaces rather dry and also because the project is based around a digitised collection of slides–the Roman stonecarving collection of the sculptor Peter Rockwell. The collection is visually very interesting, from photographs of entire Roman monuments down to more detailed views showing textures and evidence of particular carving techniques. It seemed a shame to hide these behind traditional “stingy” faceted browse and search tools. I wanted to present selections of these up front to users to encourage engagement with the collection and serendipity (whilst of course still preserving the ability for more advanced filtering of images).

Although we haven’t gone too far down the data viz route yet, by presenting selections of content up-front to users (e.g in a randomly selected group of images on the main “Explore” page and in groupings of related images on more detailed pages) I hope we may be encouraging greater exploration of the collection.

I carried out typical task-based, think aloud usability testing on the site which was of course useful and has provided us with plenty of feedback for the next design iteration. However I’ve often wondered about how this kind of testing can really answer the questions we may have about how engaging this kind of interface is. After all, the idea of generous interfaces could go beyond the usable more into the realm of emotional design, something which is more difficult to evaluate. It’s a question I asked Mitchell himself in an email a while back and was interested to learn he’d also been thinking of suitable methodological approaches to testing. In this reply he stated,

“…with a mixture of different modes – eg web analytics, ethnographic style observation, interviews with domain experts and lay users, as well as “real world” impact and influence, etc., we could build up an impression of how these systems work.”

Maybe you could call it selective data gathering and it’s certainly anecdotal, but I was pleased to hear some of the testers in our usability tests being pleased with some of the results they were seeing on screen, even if it was by way of just a “that’s really cool” type comment. Also, in the post-testing feedback questionnaire asking participants about their favourite aspect of the site there were favourable comments about the selection of images. I don’t have any answers to how we can rigorously evaluate these types of interfaces but I suspect it will mainly need to be qualitative and done most likely via some kind of contextual enquiry, observing how users create their own navigation paths, and possibly the kind of language they use in response to what they’re presented.

Matt Cottam started things off discussing Tellart’s work on the Chrome Web Lab at the Science Museum. It was interesting to hear about the process and thinking behind this, having visited the exhibition in December; the driving idea was to connect web audiences to physical objects. One of the nice touches from the exhibition I thought was the individual “lab tag” you were issued at the start of the exhibition. You can scan this with your computer’s web cam when you get back home and see everything you created. Here’s my go on the “Universal Orchestra”.

Joe Parry of Cambridge Intelligence spoke on network analysis–primarily from the viewpoint of analysing criminal networks, although the methodology suits any kind of network, from social networks to computer networks. He demoed a visualisation using the KeyLines Javascript library which I’ve made a mental note to check out for a couple of projects I’m working on.

It was great to hear from Phil Gyford about the Samuel Pepys’ diary project which came to an end at the end of December last year, having started back in 2003 in the form of a blog entry per diary entry. It was kind of interesting to reflect that when he started blogs were pretty new–and in the pre-Wordpress era seemed to involve rather horrific coding. Anyway, working as I currently do in the area of the digital humanities, it was particularly interesting to compare the kind of work I get involved with with this more spontaneous, enthusiast and community driven project.

Lloyd Shepherd spoke on digital note taking–the text of his talk is on his blog and definitely worth a look. The gist of the talk is that, although digital note taking is great for capturing information it’s not so great for understanding it. He made the point that “real” notebooks (e.g. Moleskines) have started to become more popular–they offer a more personalised experience and are less homogenous than their electronic counterparts.

I enjoyed Will Stahl-Timmins‘ talk on information graphics and visualisation for science–partly as I’m part-way through a course on data visualisation and also it’s interesting to think about how these can tools can be successfully used in academia where there can be some understandable reluctance to embrace them. Will’s involved in some interesting research looking at the use of information graphics in science communication and spoke about the randomised tests being carried out examining how effectively people retain information communicated in text and graphic forms. Initial results show that people retain graphically-communicated information for longer. “Impact” is an important consideration for any academic project and is considered when being scored in the REF, so Will’s research is definitely worth keeping an eye on for those of us operating within academia.

Another take on data visualisation was presented by Stephanie Posavec. Stephanie considers herself (amongst other things) a “data illustrator”–not focussing on the analytical aspect of data visualisation but thinking about how it can be used to communicate data more emotionally or subjectively. She spoke about the 94 Elements project where she’s using a logical design system to create icons for each of the 94 naturally occurring elements in the periodic table.

I have to admit I didn’t engage that much with the next two talks–maybe my brain was a bit full for the time being, maybe they were too beyond my current interests or maybe it was a post-lunch lull. Not to criticise the speakers of course, this was down to my attention span. The talks would certainly worth checking out if they’re your thing: we had Justin McGuirk on activist architects in Latin America and Beeker Northam on, umm, something else (my apologies).

The last two talks reenergised me–Cait O’Riordan spoke about the BBC’s wonderful  interactive coverage of the 2012 Olympics which was a massive success. The stats on usage were pretty impressive–I can’t remember what they were but I think they can be summarised as “lots”.  One of the interesting observations for me that came out was about user behaviour on the mobile app and mobile website: although they were primarily the same (the app being mainly a wrapper around the mobile website), they were used in very different ways. Users engaged far more with and took more time exploring the mobile app, whilst most traffic to the mobile website was from search engines and involved quick in-out visits to obtain the required information.

For me the most interesting presentation came last–Ben Terrett spoke on the Government Digital Service’s rationalisation of government websites into one main site: www.gov.uk. I’m always inspired and impressed by “user first” projects–particularly if your user base is diverse as the one served by government websites. Ben spoke of some of the motivations of the project coming from the heritage of British information design–think particularly of the tube map and the design of motorway signs–both of which have been emulated in other countries.

Margaret Calvert, one of the road sign designers has become a mentor to the project–and a new screen-optimised version of her font, New Transport is being used to typeset the new website. The team tested various fonts before settling on this one which was particularly effective in terms of legibility, maybe not surprising considering how rigorously tested the original font was–after all it had to be read at 70mph in all weather conditions. For me this goes to show that divisions between graphic design, information design and user experience design can be artificial: typography can have just as significant impact on usability and understanding as many of the other factors we emphasise as interaction designers.

Of course I have to mention the venue too–I’d never been to St. Bride and it was great to have an opportunity to explore both the library and the workshops where you can take courses in printing–I’ve got my eye on a couple already.

Anyway, a great day and I’ve got lots of think about and links to follow up. I’ll be sure to go back next year.

Obviously it’s pretty impossible to meaningfully cover any aspect of user experience in this amount of time so I went for the broadest possible approach: some definitions of the many terms that are bandied about in our profession, a discussion of user-centred design and an overview of key design principles.

The main “take-away” here is that user-centred design needs to be thought of as an embedded process and mindset for any software development and not an optional add-on.  I also wanted to stress that it’s not hard to start incorporating UCD–even with limited resources you can start giving a voice to your users.

Where to start?

I’ve been reading a fair number of books on the subject, including Luke W.’s Mobile First and the Sitpoint’s catchily-named Build Mobile Website and Apps for Smart Devices. However when I’d got beyond the initial sketching and wireframing stages I found myself at a bit of a loss as how to proceed until I decided there was no point worrying about the “app” side of things, I could just prototype in HTML and view via the browser.

No problem. However, after a day and a half of building some basic HTML screens I found myself bogged down with things such as icon size and resolution for the iPhone’s retina screen (I have an iPhone so am concentrating on designing for this, at least in the first instance). The work I’d done just wasn’t looking very convincing. I needed to up my game a bit if I was going to get anything done by the end of the week which led me to me to my next discovery…

Use a framework

Although I’d heard of various frameworks I’d more of less discounted them due to the fact they seemed like overkill and I’d have to spend a bunch of time getting up to speed with them before I could create anything. However I was at the stage where I thought they were worth another look. I looked at Sencha Touch for about five minutes before I went cross-eyed and then settled on jQuery Mobile which seemed much more lightweight.

Although jQuery Mobile does that jQuery UI thing of inserting a whole bunch of extra markup and styles into your code it does at least give you a load of common design patterns and interaction styles. Also, let’s face it when you’re prototyping it’s best not to get too hung up on final design but boil things down to key interactions and navigation flows.

Mobile design is not web design

Sounds almost too obvious to state but the reason I do is it’s interesting how much you really have to change your mindset when you approach a mobile app. This is not web design, it’s not even responsive design. Throw everything out and start from scratch. User flow and navigation become more important than ever. Just working out where the navigation should go in different contexts can be pretty challenging (hint: not just at the top and the left).

Get others involved

I’m lucky enough to know some talented developers who are keen at giving this whole thing a go too, which is handy given that about four days in I’d felt I’d gone as far as I could. Although I toyed with the idea of setting up some basic database I realised that this would soon make me quite angry and not a nice person to be around so I decided to drop a couple of friends an email.

Talking to someone else really helps put things in perspective as well as providing some practical advice about how to move forward.

Next steps

So, the next steps are really to get back to basics: firm up the storyboards which can be quite illuminating in showing you the screens you’ll need (hint: a lot more than you probably initially thought). Once this is done, pass these on to others to take a look at and put a big black marker through anything that’s going to take too much time and set priorities. Then, some short, concentrated sprints to create some basic prototypes we can actually show people and see if it’s something they’d actually use.

So, overall this has been a worthwhile exercise, even if what I’ve learned is I know less about this area than I thought!

I’ve found a couple of newish tools particularly useful for creating moodboards: Pinterest and probably more so, Gimmebar. Whilst these don’t do anything essentially different from some other tools I’ve used like Zootool or Evernote I particularly like the way they present your saved artefacts and their minimal interfaces seem–to me anyway–to be well suited to quickly grabbing and dumping stuff.

Pinterest

At the moment you need to have an invite to join Pinterest but it’s not too difficult to get one: I requested one via the website and received one the next day. Once you have an account you can invite friends along too. The idea behind Pinterest is you create boards which you can pin things to–either images you’ve found on the Web or you can “repin” from other people’s boards.

I found some interesting examples of other people’s moodboards by searching Pinterest which I was able to pin to one of my own boards.

As the concept of boards underlies the whole app it would seem a natural tool for creating moodboards. However I’ve had some problems with performance: it’s a been a little slow at times which has made it a little frustrating to use. But maybe those are just teething issues.

Gimmebar

Gimmebar allows you to create collections, similar to Pinterest’s boards and allows you save various kinds of artefacts: images, videos, full web pages and status updates.

The main advantage of Gimmebar for me is collections can be private or public–so you can create a “private stash” of stuff you’ve found without having to share it by default with the outside world. This gives it more of a notebook feel to me so I don’t feel so self-conscious about creating some kind of finished product. Also, the ability to save a complete web page from header to footer rather than just a predefined or viewport size is a really useful feature.

Like Pinterest, Gimmebar uses that “jQuery Masonry” style of tiling to present results which means it’s easy to browse the stuff you’ve saved and get more of a sense of the overall feel of your collection–making it easier to take editorial decisions on what fits and what doesn’t. I prefer this to say, Zootool’s approach to presenting same-size thumbnails (although as a visual bookmarking tool I think Zootool’s great).

You could share this as your moodboard–either by publishing it or sharing it as a collaborative space with other Gimmebar users, although I like to add a little more editorial control by downloading the images and using them in a Photoshop comp. Here’s one I made earlier:

There you go–pretty straightforward. What do you use?

The lack of network connectivity fitted in quite nicely with themes of two of the presentations. Robbie Manson‘s “The Mindful Designer” encouraged us to step away from our tools, think better and make the most of the teams we work in; think “positive disruptions” rather than the negative ones like the constant interrupting communication flow of Tweets, emails and RSS.

Denise Jacobs delved deeper into this, explaining via a story the different mental states we experience. As someone who’s been interested in the benefits of meditation for the past year or so  it was pretty cool to see them being discussed (or at least alluded to) in a mainstream design conference. The brain’s “alpha” states are associated with increased learning, greater creativity and flow. Simply closing your eyes will start the process of entering this state. Playfulness triggers the right side of the brain; gamma states are associated with insights– these can be triggered by laughter. So, according to Denise: to get your creative groove back, breathe, play, laugh. Sounds alright to me.

The conference kicked off with Dan Mall asking us to explain what we do. This set the tone for the rest of the day, getting us to think about exactly what design is: “adding form to a shapeless idea”, mending what’s broken (Naomi Atkinson), making interesting and exciting stuff–after, ahem, loosening the f up  (Travis Schmeisser), making things better (Trent Walton), eliciting emotion, inducing action and affecting change (Cameron Koczon) or getting from A to B (Frank Chimero).

If any common themes did emerge I think they could basically be summarised as:

• just make stuff–you don’t need a startup and you don’t need to make anything perfect (and let’s face it there’s nothing like a bout of IE7 CSS fixes to kill the excitement of an idea);
• give back–as designers we’re in a privileged position to get involved and help out our local communities, education or health service (although they were some murmurings of this veering dangerously towards “Big Society” territory).
• teams are good–make the most of the people around you, whether this is your co-workers or the design community.
• Now is a good time for design and design-led startups.

So, turn off the Twitter feed for a moment and think: what do you do?

[Featured image credit: NACONF2012 by Paul Robert Lloyd on Flickr].

With this in mind I thought it was time to move away from nailed-down desktop-favouring fixed width grid designs and venture into the slightly scarier world of responsive fluid grids. As I always learn better by doing than by just reading I decided to create a example website and go through the whole process from planning to coding, which I’ll share here in case you’re interested (of course you are!).

There’s quite a lot to this whole fluid grid business so I’ve broken up this post in to two sections: first we’ll consider how we might approach a responsive design conceptually and at the visual design stage; in the second part we’ll look at turning the design into HTML/CSS to see it in action.

Some definitions first…

I’m going to be concentrating on fluid grids in these posts rather than responsive design per se. So, what is a fluid grid? Well, let’s think about what we mean by grid first. Wikipedia defines the typographic grid as,

a two-dimensional structure made up of a series of intersecting vertical and horizontal axes used to structure content.

Sounds reasonable to me. In print (or fixed width web design terms) these intersecting axes combine to produce modules or units of a predictable fixed size with which to construct your layout and give it consistency and rhythm. When we go fluid the units–I’m going to use this term rather than “modules” to avoid confusion down the line–will still structure the content consistently and predictably but their size and positioning will change depending on the available size of the rendering device’s display.

We should be clear than fluid grids are not in themselves responsive web design. Responsive design is a combination of a number of elements, fluid grids being one, the others being the use of fluid images / media and the use of media queries to load in CSS depending on screen size.

Designing for responsive, er, design

You could use fluid grids in an old-fasioned fluid design where the grid units resize according to screen size, but in a true responsive layout it’s likely your grid will reflow when the screen size changes. For instance, a 16 unit wide grid may be fine on a desktop or laptop browser but an 8 unit wide grid may be more suited to a tablet (or a desktop browser at a smaller size) and a 4 unit grid to a mobile screen. Of course it’s not just a case of halving the amount of grid units on a screen and moving the remaining content on to the next line: it takes more thinking than this to ensure your desired content hierarchy is reflected at different resolutions. One of the reasons that true responsive design is pretty demanding; but that’s good, right?

Introducing our sample site

The site I’m going to be using is a real site for a project I’m currently working on for a basic HTML/CSS framework simple enough for designers to do rapid prototyping with but powerful enough to use for proper site builds. SPIL (simple powerful interface library) is written in HTML5 and uses OOCSS concepts to make code easy to get to grips with and maintain. But, more of that later. SPIL is due to be released under an open source (BSD) licence and will have its own website containing information about the project, a download link, documentation and a gallery of projects built with SPIL. Nothing too complex.

This is our Photoshop comp showing what the user will see on a desktop-size screen: a 16 unit grid taking up 960 pixels of screen width.

Before we launch off into fluid grid land we need to make some decisions about the kind of devices and screen resolutions we’re going to support and our audience. Well, luckily we can bypass a lot of the user research you might normally do at this stage as we know the users most interested in this are going to be designers and front-end developers. So we want to ensure we cater for our highly tech-savvy audience and make sure our site looks good on desktop, tablet and mobile.

Let’s consider the contexts in which people might be looking at our site. Again we’re going to make some assumptions here based on our own knowledge and experience. If you want to download a framework and play around with it, chances are you’re going to be on a desktop or laptop. However as we know that the web world will be all-abuzz about SPIL (yes, I know, just pretend ok?) let’s imagine (try hard now) that people will be sharing it with others at conferences and meetups. So our design should reflow to display clearly and usefully at the kind of resolutions we’d find on tablets and mobiles.

We’ll call our target layout sizes “desktop”, “tablet” and “mobile” but of course this is a little misleading as a desktop browser is capable of displaying all of them depending on its viewport size; likewise a tablet browser could also be resized to show the lower size.

Content hierarchy

Before we can make any design decisions we should think about our content hierarchy and what will be important to different users.

Let’s look at our comp again. We’ve got four rows with 3-4 groupings of information on our main “desktop” layout. Let’s categorise them below (leaving aside the header and footer).

Row “A” (About):
1. What is SPIL?
2. How does SPIL work?
3. Download button
4. News

Row “B” (Documentation):
1. Code example one
2. Code example two
3. Full list of tutorials

Row “C” (Examples carousel)
1. Screenshot one
2. Screenshot two
3. Screenshot three

Row “D”
1. Credits
2. Licence
3. We love (links to other sites)

“Tablet” resolution

As we’ve got less screen real estate on a tablet we need to think about structuring our content accordingly: we still want the most important information most prominent. We’re going to use a 8 unit wide grid for our tablet design, half the amount we’re using for the desktop.

Arguably the download button is not so useful for tablet users as they won’t be working with the framework in that environment. However, remember that this resolution is also available for desktop users and we don’t want to assume that tablet users definitely won’t want to download the files. So we’ll want the first row to display our initial row “A” information about SPIL but will move the “download” and “news” section to the row below thus:

A1  A2
A3  A4

We’ll handle the “documentation” section in a similar way:

B1  B2
B3

Our initial row “C” is a carousel of three images. We’ll make this smaller for our tablet design, just showing two of the images at any one time:

C1  C2

Our initial row “D” can be reflowed thus:

D1  D2
D3

Our mobile design

We need to think more carefully about our mobile design: we’ve obviously got even less space than for the tablet design so we want to be cautious about what we show.

We’ll be working with a 4 unit-wide grid for our mobile design. We’ll reflow our initial row “A” information accordingly:

A1
A2
A3
A4

For our initial row “B” information we’ll do some editing. We don’t want our page to appear too cluttered on a small screen so let’s dispense with the “teaser” code examples and just list out our tutorials:

B3

In terms of example websites we could decide to edit these out entirely or just display one image:

C1

For our initial row “D” information we’ll just stack these on top of each other but for the sake of a more concise page we’ll leave off the links to other sites.

D1
D2

So, would you bother creating Photoshop visuals for these design as it’s tripling the amount of work you need to do? I guess it would depend on the size and scope of your project and the client you were working for. But in our case we’ll just use our sketches to inform how our layout and content will reflow at lower screen sizes but will do all the work in-browser.

So, so far we’ve thought about what a fluid grid is and how it relates to the area of responsive design. We’ve also thought about our site’s content hierarchy and how we would want to present this at different screen sizes. With all this considered and documented it’s time to move on to the only place we can see responsiveness in action: the browser. But that’s for next time!

Firstly–a disclaimer. These are entirely personal and largely anecdotal observations–I haven’t exactly undertaken widespread research on the topic so there’s bound to be work which I’m ignorant of. Ok…

Understanding the domain

What is digital humanities (DH)? I imagine you’ll get a different answer depending on who you ask but a good starting point might be the Wikipedia entry:

The digital humanities is an area of research, teaching, and creation concerned with the intersection of computing and the disciplines of the humanities.

In practical terms DH projects usually involve the creation of scholarly digital publications, more often than not now delivered via the Web. This has often equated to digitised texts, manuscripts or other source material of use to a small, specialised audience of researchers. However, this is not necessarily the only application of the technology in the field–some projects, whilst retaining scholarly rigour in their production may have a far wider user base, both in terms of their creation and consumption.

For instance the Great War Archive project undertaken at Oxford University, and its sister project in Germany run by Europeana created a crowd-sourced digital collection of memorabilia, documents and ephemera from the First World War. A diverse range of participants were able to contribute objects to the resource, either by uploading digital images via a website or by attending sessions in which people could bring their collections in for examination and digitisation. Some were also able to make connections and construct their own stories from the data.

I’ll admit a personal preference for the more “participatory” end of the digital humanities–simply as I’m excited by the potential of the Web to involve and, hopefully enthuse a wide range of people. However, whatever the type of resource being created, as all good designers know it will only be truly successful if designed for the needs of its users, whether they are a narrow selection of specialists or a much wider audience of non-specialists.

Approaches to user experience design in the digital humanities

Whilst I can’t speak for every project, I imagine it wouldn’t be massively unfair to say there is some reluctance to adopt wholesale user-centred design techniques in all DH projects–for a number of reasons, including some you might encounter in other fields: it requires time, effort and money to be done properly and sometimes funding and deadlines are tight.

However I think there are other reasons too. Culturally DH projects have been led by a particular research agenda rather than the desire to produce a “product” for a set of users. For this reason projects can often be rather vague in their precise aims at the outset, so resources may be the result of collaborative research between the technologists and non-technologists rather than built to a pre-set specification.

Related to this, academic staff involved in the projects may have a strong idea of how they want to present their findings–after all, it is their area of specialisation and they may not see the value of involving others; or they may simply make an assumption that others will use the resource in the same way they do–a common pitfall for the creator of any software.

There may also be a question of expertise–digital humanists themselves may not have the relevant knowledge of human computer interaction and interface design simply because they are highly skilled specialists in other areas (e.g. mark-up languages or text analysis). As DH projects are largely led by technologists it can be difficult to sell them on the value of design–which they may see as simply making something look pretty.

So, why bother?

All resources are (or you would certainly hope be) created for a purpose, and by association have a group of potential users. Understanding this from the outset and designing a resource appropriately can surely greatly enhance the impact and amount of use it receives (of course if your target is “future scholars” then it might be a little more difficult!).

It’s also worth thinking of a digital resource as being more than data. Data is generally stored in formats (e.g. XML or databases) that can be reused or even divorced from its presentation layer and archived. I see resources as a combination of this data, tools to interrogate and make sense of it and interfaces which allow users interact with the data–something which necessitates the involvement of the people who will be using them in the first instance; otherwise resources run the risk of being unused, unusable or simply esoteric experiments which soon disappear from view.

Current work

While it seems to me user-centred design is a relative newcomer to DH, things are certainly happening. Although focus groups and last-minute usability testing have certainly been used in the past, more robust approaches to user experience appear to be gaining more ground within the discipline: one indicator being more academic articles appearing on the subject.

Also, as I noted in an earlier post there is some very innovative participatory work going on in what might be considered DH’s more democratic/populist sister discipline: digital museums. Museum users are being encouraged to interact with institutions and their collections in more and more creative ways. In order to do this user-centred design processes are being adopted enthusiastically; something DH will no doubt learn from, especially as it adopts similar techniques to build resources (see for instance the Ancient Lives crowd-sourcing project to transcribe papyrii).

The Ghosts of Gone Birds is a project to “raise a creative army for conservation” — highlighting extinct species of birds and raising awareness of current conservation issues — via exhibitions and events. All of the proceeds go towards the work of Birdlife International.

I went along to a night of poetry and music at Rich Mix London (featuring amongst others the damn fine experimental folkies Walking with Ghosts) and also got to the exhibition just round the corner, at the Rochelle School in Shoreditch. This ran over a couple of floors and featured installations and paintings from a number of artists, including Ralph Steadman.

There were various notices around in the exhibition positively encouraging the taking and sharing of photos — a nice touch I thought.

The presentations covered a wide range of topics relating to digital museums, from planning a realistic digital strategy to refining your metadata but those I found of particular interest related to engaging and involving users in building and using digital resources, a topic I’ve been finding myself more and more interested in of late–addressing those nagging questions about exactly why and for whom we in the digital cultural heritage and humanities sectors are building these resources in the first place.

Museums and galleries arguably have a head start when it comes to involving users in projects: direct access to them as visitors to their institutions. This is something that the Social Interpretation project at the Imperial War Museum (IWM) is making the most of: a project to record visitors’ interpretations of exhibits, bringing them the same ability to share and discuss found on the social web to the museum space, via in-museum devices, the web and mobile apps.

This project is putting the user at the centre of the design process, both directly via testing of prototypes and observation of user behaviour in the galleries.  Interestingly, it’s also been run entirely according to an agile methodology–not just the development but the design and management, so I’m really looking forward to hearing more about this.

Another participatory IWM project being developed is Lives of the Great War–a crowdsourced project to create stories of those who served and died in the First World War. This is being done principally by enabling access to the various appropriate information sources distributed across the Web, some of which are behind paywalls, via a single access point. The plan is to archive the resource permanently and also to release the data under a “CCO” licence (the most permissive Creative Commons licence); making the data available for reuse in a number of contexts.

The Outside In project, run by the Pallant House Gallery is a slightly different participatory project–providing a space for artists traditionally unable to engage with the artistic mainstream due to disability or social circumstance to display their work. The interface for doing this was developed iteratively, including in workshops with the artists themselves. The next stage is a mobile app–not for the sake of developing one but because interaction via a mobile device involves fewer cognitive steps, e.g. the need to understand concepts such as file structures when uploading content from your computer’s file storage. With a mobile app, the device which records the art work can also be used to upload it directly.

I was fortunate enough to be elected to the committee of the conference’s organising body, the Museums Computer Group–something I’m very excited about. The levels of innovation and creativity in the sector are very impressive and I’m looking forward to learning and sharing more with all involved.