Monday, 12 November 2012

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


  1. Teaching a DH tool workshop is sometimes a very tough gig, for all of those reasons you state. Even so, I think you can say this is new, enter at your own risk.

    After years of teaching Omeka workshops, we have learned a few tricks--such as working with an Omeka site pre-populated with different types of items that attendees can log in and use if they don't have their own site at the time of the workshop.

    We also have tried to distinguish different types of workshops by using different terminology, which sometimes helps. An introduction or a demo has very little building, and often the audience wants to listen and talk. Playdates have lots of building but with different types of users (content building in admin versus a developer modifying a plugin), and Advanced workshops use the time to build a new plugin or theme from scratch.

    We try to offer some guidelines ahead of time to alert potential attendees of what type of skills might be needed for the workshop to be beneficial, but in the end all are invited to come.

    For example,
    End Users without technical knowledge who might be adding collections and building online exhibitions with those collections.

    Developers who are comfortable working in open source software such as WordPress who want to learn about the API to build plugins, hack themes.

    I've found at academic conferences, more recently, that even when I'm giving a workshop, we rarely get beyond adding an item. More and more attendees aren't even bringing a laptop to work along with me. And that is because even though Omeka has been around for awhile, it is new to those coming. They need to discuss what Omeka is, what it does, how it can be used to build certain kinds of sites, et al, and are less concerned with working along and talking.

    And that sometimes means that I as an instructor feel less satisfied with what I've been able to teach within that time. But, usually I get a lot of positive feedback because people leave with a greater understanding of what Omeka is even if they didn't build anything. And that is something too!

  2. Mia,

    Thanks so much for doing the workshop - and for all of the thoughtful feedback! We're in the middle of a big round of new development on Neatline in preparation for a new release of the software that will go along with the public launch of Omeka 2.0, and we're really keen to get this kind of information about how the software interacts with users outside of the Scholars' Lab orbit.

    I think the workshop hit on a couple issues that are definitely growth areas for Neatline. First, we're in the process of completely rewriting the documentation for the next release. What we have now is sort of like programming API documentation - good for specific questions about specific features, not so good for high-level questions about how the pieces fit together. We're planning to produce a series of 15-20 short, step-by-step "workflow narratives" that provide instructions for accomplishing specific tasks ("Create an exhibit," "Import Omeka items," "Create a Neatline Record," etc). We're also planning to write a longer document, almost like a mini "book," that will cover the entire lifecycle of a project - installing Omeka / Neatline, georeferencing maps, running GeoServer, creating an exhibit, etc.

    From a development standpoint, we're putting a huge amount of focus right now on improving the performance, reliability, and usability of the editing interface. We're currently in the process of moving it over to a better JavaScript application architecture that will make the whole thing faster, more testable, and generally sleeker from a user's perspective. We're also simplifying wherever possible - Neatline v1.0 was written with a couple of specific projects in mind, and now we're in the process of editing the feature set down a bit to make the whole experience more immediately intuitive.

    As for the challenge of managing different levels of experience: I think you're hitting on what may be _the_ central challenge of building and and presenting this kind of software. I actually wrote a blog post earlier this year called "Neatline and the Framework Challenge" that actually gets at the same issue, although from a somewhat different starting point (

    As I see it, there's something of a tension between the _power_ and _accessibility_ in designing frameworks like Neatline. If you expose lots of options, allow for complex content modeling, and generally leave off the training wheels, advanced users can build wildly creative, unique stuff (eg., ArcMap) - but many users who don't have the time or desire to invest in learning the tool won't be able to create much of anything at all. Or the tool can be simple enough that everyone can succeed in building something - but everyone's output will look largely the same (eg., Google Mapmaker).

    The first version of Neatline tries to split that difference. Going forward, we're moving the GUI interface more in the direction of simplicity, while at the same time architecting the codebase so that it's really easy for developers to implement custom solutions for specific projects with complex needs.

    Thanks again,
    David McClure

  3. Sheila, to reiterate my tweet at the time, thank you so much for your comment, it's been really helpful. Frustratingly I do things like your guidelines when I am consciously teaching a heavily technical subject, but it's clearly something I should think about for teaching any emerging DH tool.

    And David, thank you all so much for being so responsive to my comments in the lead-up to the workshop and the responses from participants. I'm really excited about the potential of Neatline and it sounds like the changes you're making will lead to a much more mature product. Let me know if you'd like any help testing it out!

    Cheers, Mia