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

Can you capture visitors with a steampunk arm?

Credits: Science Museum

This may be familiar to you if you've worked on a museum website: an object will capture the imagination of someone who starts to spread the link around, there's a flurry of tweets and tumblrs and links (that hopefully you'll notice in time because you've previously set up alerts for keywords or URLs on various media), others like it too and it starts to go viral and 50,000 people look at that one page in a day, 20,000 the next, furious discussions break out on social media and other sites... then they're gone, onto the next random link on someone else's site.  It's hugely exciting, but it can also feel like a missed opportunity to show these visitors other cool things you have in your collection, to address some of the issues raised and to give them more information about the object.

There are three key aspects to riding these waves of interest: the ability to spot content that's suddenly getting a lot of hits; the ability to respond with interesting, relevant content while the link is still hot (i.e. within anything from a couple of hours to a couple of days); and the ability to put that relevant content on the page where fly-by-night visitors will see it.

For many museums, caught between a templated CMS and layers of sign-off for new content , it's not as easy as it sounds.  When the Science Museum's 'steampunk artificial arm' started circulating on twitter and then made boingboing, I was able to work with curators to get a post on the collections blog about it the next day, but then there was no way of adding that link to the Brought to Life page that was all most people saw.

In his post on “The Guardian’s Facebook app”, Martin Belam discusses how their Facebook app has helped archived content live again:

Someone shares an old article with their friends, some of their friends either already use or install the app, and the viral effect begins to take hold. ... We’ve got over 1.3 million articles live on the website, so that is a lot of content to be discovered, and the app means that suddenly any page, languishing unloved in our database, can become a new landing page. When an article becomes popular in the app, we sometimes package it with content. Because we know the attention has come at a specific time from a specific place, we can add related links that are appropriate to the audience rather than to the original content. ...when you’ve got the audience there, you need to optimise for them

As a content company with great technical and user experience teams, the Guardian is better placed to put together existing content around a viral article, but still, I'm curious: are any museums currently managing to respond to sudden waves of interest in random objects?  And if so, how?

Notes from 'Building a bilingual CMS' at MCG's Spring Conference

These are my notes from Chris Owen's presentation, 'Building a bilingual CMS' (for the National Museum of Wales) at the MCG Spring meeting. Chris' slides for 'Building a bilingual CMS' are online. There's some background to my notes about the conference in a previous post. Any of my comments are in [square brackets] below.

Why did they build (not buy) a CMS?
Immediate need for content updating, integration of existing databases.
Their initial needs were simple - small group of content authors, workflow and security weren't so important.
Aims: simplicity, easy platform for development, extensible, ease of use for content authors, workflow tailored to a bilingual site, English and Welsh kept together so easier to maintain.

It's used on main website, intranet, SCAN (an educational website), Oriel I (more on that later in a later talk), gallery touch-screens and CMS admin.

The website includes usual museum-y stuff like visitor pages, events and exhibitions, corporate and education information, Rhagor (their collections area - more on that later too) and blogs.

How did they build it?
[In rough order] They built the admin web application; created CMS with simple data structures, added security and workflow to admin, added login features to CMS, integrated admin site and CMS, migrated more complex data structures, added lots of new features.

They developed with future uses in mind but also just got on with it.

Issues around bilingual design:
Do you treat languages equally? Do you use language-selection splash screens or different domain names?
Try to localise URLs (e.g. use aliases for directories and pages so /events/ and /[the Welsh word for events]/ do the same [appropriate] thing and Welsh doesn't seem like an afterthought). Place the language switch in a consistent location; consider workflow for translation, entering content, etc.

Use two-character language codes (en/cy), organise your naming conventions for files and for database fields so Welsh isn't extra (e.g. collections.en.html and the equivalent .cy.html); don't embed localised strings in code. [It's all really nicely done in XML, as they demonstrated later.]

Coding tip: pull out the right lang at the start in SQL query; this minimises bugs and the need to refer to language later.

It's built on XML, as they have lots of databases and didn't want to centralise/merge them together; this means they can just add news ones as needed.

Slide 16 shows the features; it compares pretty well to bigger open-source projects out there. It has friendly URLs, less chance of broken links, built in AJAX features and they've integrated user authentication, groups so there's one login for whole website for users. The site has user comments (with approval) and uses reCaptcha. There's also a slide on the admin features later - all very impressive.

They've used OO design. Slide 18 shows the architecture.

Content blocks are PHP objects - the bits that go together that make the page. Localised. Because links are by ID they don't break when pages are moved. They're also using mootools.

The future: they want to have more user-centric features; work with the [Welsh project] People's Collection and other collaborations; APIs with other sites for web 2.ish things; more use of metadata features; they will make it open source if people think it's useful.

They would really open it up, via something like sourceforge, but would take lead.

[Overall it's a really impressive bit of work, sensibly designed and well implemented. Between that and the Indianapolis Museum of Art I've seen some really nice IT web tools in museums lately. Well done them!]