5 thoughts on “Reflections on teaching Neatline”

  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 (http://www.scholarslab.org/geospatial-and-temporal/neatline-and-the-framework-challenge/)

    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

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.