digital humanities – Page 2

So we made a thing. Announcing Serendip-o-matic at One Week, One Tool

So we made a thing. And (we think) it's kinda cool! Announcing Serendip-o-matic http://t.co/mQsHLqf4oX #OWOT
— Mia (@mia_out) August 2, 2013

Source code at GitHub Serendipomatic – go add your API so people can find your stuff! Check out the site at serendipomatic.org.

Update: and already we've had feedback that people love the experience and have found it useful – it's so amazing to hear this, thank you all! We know it's far from perfect, but since the aim was to make something people would use, it's great to know we've managed that:

Congratulations @mia_out and the team of #OWOT for http://t.co/cNbCbEKlUf Already try it & got new sources about a Portuguese King. GREAT!!!
— Daniel Alves (@DanielAlvesFCSH) August 2, 2013

Update from Saturday morning – so this happened overnight:

Cool, Serendipmatic cloned and local dev version up and running in about 15 mins. Now to see about adding Trove to the mix. #owot
— Tim Sherratt (@wragge) August 3, 2013

And then this:

Just pushed out an update to http://t.co/uM13iWLISU — now includes Trove content! #owot
— RebeccaSuttonKoeser (@suttonkoeser) August 3, 2013

From the press release: One Week | One Tool Team Launches Serendip-o-matic

After five days and nights of intense collaboration, the One Week | One Tool digital humanities team has unveiled its web application: Serendip-o-matic <http://serendipomatic.org>. Unlike conventional search tools, this “serendipity engine” takes in any text, such as an article, song lyrics, or a bibliography. It then extracts key terms, delivering similar results from the vast online collections of the Digital Public Library of America, Europeana, and Flickr Commons. Because Serendip-o-matic asks sources to speak for themselves, users can step back and discover connections they never knew existed. The team worked to re-create that moment when a friend recommends an amazing book, or a librarian suggests a new source. It’s not search, it’s serendipity.

Serendip-o-matic works for many different users. Students looking for inspiration can use one source as a springboard to a variety of others. Scholars can pump in their bibliographies to help enliven their current research or to get ideas for a new project. Bloggers can find open access images to illustrate their posts. Librarians and museum professionals can discover a wide range of items from other institutions and build bridges that make their collections more accessible. In addition, millions of users of RRCHNM’s Zotero can easily run their personal libraries through Serendip-o-matic.
Serendip-o-matic is easy to use and freely available to the public. Software developers may expand and improve the open-source code, available on GitHub. The One Week | One Tool team has also prepared ways for additional archives, libraries, and museums to make their collections available to Serendip-o-matic.

Highs and lows, day four of OWOT

If you'd asked me at 6pm, I would have said I'd have been way too tired to blog later, but it also felt like a shame to break my streak at this point. Today was hard work and really tiring – lots to do, lots of finicky tech issues to deal with, some tricky moments to work through – but particularly after regrouping back at the hotel, the dev/design team powered through some of the issues we'd butted heads against earlier and got some great work done. Tomorrow will undoubtedly be stressful and I'll probably triage tasks like mad but I think we'll have something good to show you.

As I left the hotel this morning I realised an intense process like this isn't just about rapid prototyping – it's also about rapid trust. When there's too much to do and barely any time for communication, let alone checking someone else's work, you just have to rely on others to get the bits they're doing right and rely on goodwill to guide the conversation if you need to tweak things a bit. It can be tricky when you're working out where everyone's sense of boundaries between different areas are as you go, but being able to trust people in that way is a brilliant feeling. At the end of a long day, I've realised it's also very much about deciding which issues you're willing to spend time finessing and when you're happy to hand over to others or aim for a first draft that's good enough to go out with the intention to tweak if it you ever get time. I'd asked in the past whether a museum's obsession with polish hinders innovation so I can really appreciate how freeing it can be to work in an environment where to get a product that works, let alone something really good, out in the time available is a major achievement.

Anyway, enough talking. Amrys has posted about today already, and I expect that Jack or Brian probably will too, so I'm going to hand over to some tweets and images to give you a sense of my day. (I've barely had any time to talk to or get to know the Outreach team so ironically reading their posts has been a lovely way to check in with how they're doing.)

Our GitHub repository punch card report tells the whole story of this week – from nothing to huge levels of activity on the app code

I keep looking at the #OWOT commits and clapping my hands excitedly. I am a great. big. dork.
— Mia (@mia_out) August 1, 2013

OH at #owot 'I just had to get the hippo out of my system' (More seriously, so exciting to see the design work that's coming out!)
— Mia (@mia_out) August 1, 2013

OH at #OWOT 'I'm not sure JK Rowling approves of me'. Also, an earlier unrelated small round of applause. Progress is being made.
— Mia (@mia_out) August 1, 2013

#OWOT #owotleaks it turns out our mysterious thing works quite well with song lyrics.
— Mia (@mia_out) August 1, 2013

Halfway through. Day three of OWOT.

Crikey. Day three. Where do I start?

We've made great progress on our mysterious tool. And it has a name! Some cool design motifs are flowing from that, which in turn means we can really push the user experience design issues over the next day and a half (though we've already been making lots of design decisions on the hoof so we can keep dev moving). The Outreach team have also been doing some great communications work, including a Press Release and have lots more in the pipeline. The Dev/Design team did a demo of our work for the Outreach team before dinner – there are lots of little things but the general framework of the tool works as it should – it's amazing how far we've come since lunchtime yesterday. We still need to do a full deployment (server issues, blah blah), and I'll feel a lot better when we've got that process working and then running smoothly, so that we can keep deploying as we finish major features up to a few hours before launch rather than doing it at the end in a mad panic. I don't know how people managed code before source control – not only does Github manage versions for it, it makes pulling in code from different people so much easier.

There's lots to tackle on many different fronts, and it may still end up in a mad rush at the end, but right now, the Dev/Design team is humming along. I've been so impressed with the way people have coped with some pretty intense requirements for working with unfamiliar languages or frameworks, and with high levels of uncertainty in a chaotic environment. I'm trying to keep track of things in Github (with Meghan and Brian as brilliant 'got my back' PMs) and keep the key current tasks on a whiteboard so that people know exactly what they need to be getting done at any time. Now that the Outreach team have worked through the key descriptive texts, name and tagline we'll need to coordinate content production – particularly documentation, microcopy to guide people through the process – really closely, which will probably get tricky as time is short and our tasks are many, but given the people gathered together for OWOT, I have faith that we'll make it work.

Things I have learnt today: despite two years working on a PhD in digital humanities/digital history, I still have a brain full of technical stuff – it's a relief to realise it hasn't atrophied through lack of use. I've also realised how much the work I've done designing workshops and teaching since starting my PhD have fed into how I work with teams, though it's hard right now to quantify exactly *how*. Finally, it's re-affirmed just how much I like making things – but also that it's important to make those things in the company of people who are scholarly (or at least thoughtful) about subjects beyond tech and inter-disciplinary, and ideally to make things that engage the public as well as researchers. As the end of my PhD approaches, it's been really useful to step back into this world for a week, and I'll definitely draw on it when figuring out what to do after the PhD. If someone could just start a CHNM in the UK, I'd be very happy.

I still can't tell you what we're making, but I *can* tell you that one of these photos in this post contains a clue (and they all definitely have nothing to do with mild lightheadedness at the end of a long day).

And so it begins: day two of OWOT

Day two of One Week, One Tool. We know what we're making, but we're not yet revealing exactly what it is. (Is that mean? It's partly a way of us keeping things simple so we can focus on work.) Yesterday (see Working out what we're doing: day one of One Week, One Tool) already feels like weeks ago, and even this morning feels like a long time ago. I can see that my posts are going to get less articulate as the week goes on, assuming I keep posting. I'm not sure how much value this will have, but I suppose it's a record of how fast you can move in the right circumstances…

We spent the morning winnowing the ideas we'd put up for feedback on overnight down from c12 to 4, then 3, then 2, then… It's really hard killing your darlings, and it's also difficult choosing between ideas that sound equally challenging or fun or worthy. There was a moment when we literally wiped ideas that had been ruled out from the whiteboard, and it felt oddly momentous. In the end, the two final choices both felt like approaches to the same thing – perhaps because we'd talked about them for so long that they started to merge (consciously or not) or because they both fell into a sweet spot of being accessible to a wide audience and had something to do with discovering new things about your research (which was the last thing I tweeted before we made our decision and decided to keep things in-house for a while). Finally, eventually, we had enough of a critical mass behind one idea to call it the winner.

Personally, our decision only started to feel real as we walked back from lunch – our task was about to get real. It's daunting but exciting. Once back in the room, we discussed the chosen idea a bit more and I got a bit UX/analysty and sketched stuff on a whiteboard. I'm always a bit obsessed with sketching as a way to make sure everyone has a more concrete picture (or shared mental model) of what the group is talking about, and for me it also served as a quick test of the technical viability of the idea. CHNM's Tom Scheinfeldt then had the unenviable task of corralling/coaxing/guiding us into project management, dev/design and outreach teams. Meghan Frazer and Brian Croxall are project managing, I'm dev/design team lead, with Scott Kleinman, Rebecca Sutton Koeser, Amy Papaelias, Eli Rose, Amanda Visconti and Scott Williams (and in the hours since then I have discovered that they all rock and bring great skills to the mix), and Jack Dougherty is leading the outreach team of Ray Palin and Amrys Williams in their tasks of marketing, community development, project outreach, grant writing, documentation. Amrys and Ray are also acting as user advocates and they've all contributed user stories to help us clarify our goals. Lots of people will be floating between teams, chipping in where needed and helping manage communication between teams.

The Dev/Design team began with a skills audit so that we could figure out who could do what on the front- and back-end, which in turn fed into our platform decision (basically PHP or Python, Python won), then a quick list of initial tasks that would act as further reality checks on the tool and our platform choice. The team is generally working in pairs on parallel tasks so that we're always moving forward on the three main functional areas of the tool and to make merging updates on github simpler. We're also using existing JavaScript libraries and CSS grids to make the design process faster. I then popped over to the Outreach team to check in with the descriptions and potential user stories they were discussing. Meghan and Brian got everyone back together at the end of the day, and the dev/design team had a chance to feed back on the outreach team's work (which also provided a very ad hoc form of requirements elicitation but it started some important conversations that further shaped the tool). Then it was back over to the hotel lobby where we planned to have a dev/design team meeting before dinner, but when two of our team were kidnapped by a shuttle driver (well, sorta) we ended up working through some of the tasks for tomorrow. We're going to have agile-style stand-up meetings twice a day, with the aim to give people enough time to get stuck into tasks while still keeping an eye on progress with a forum to help deal with any barriers or issues. Some ideas will inevitably fall by the wayside, but because the OWOT project is designed to run over a year, we can put ideas on a wishlist for future funded development, leave as hooks for other developers to expand on, or revisit once we're back home. In hack day mode I tend to plan so that there's enough working code that you have something to launch, then go back and expand features in the code and polish the UX with any time left. Is this the right approach here? Time will tell.

#owot dev team is hard at work. #fb pic.twitter.com/Zj5PW0Kj2a
— Brian Croxall (@briancroxall) July 31, 2013

Working out what we're doing: day one of One Week, One Tool

Hard at work in The Well

I'm sitting in a hotel next to the George Mason University's Fairfax campus with a bunch of people I (mostly) met last night trying to work out what tool we'll spend the rest of the week building. We're all here for One Week, One Tool, a 'digital humanities barn raising' and our aim is to launch a tool for a community of scholarly users by Friday evening. The wider results should be some lessons about rapidly developing scholarly tools, particularly building audience-focused tools, and hopefully a bunch of new friendships and conversations, and in the future, a community of users and other developers who might contribute code. I'm particularly excited about trying to build a 'minimum viable product' in a week, because it's so unlike working in a museum. If we can keep the scope creep in check, we should be able to build for the most lightweight possible interaction that will let people use our tool while allowing room for the tool to grow according to uses.

We met up last night for introductions and started talking about our week. I'm blogging now in part so that we can look back and remember what it was like before we got stuck into building something – if you don't capture the moment, it's hard to retrieve. The areas of uncertainty will reduce each day, and based on my experience at hack days and longer projects, it's often hard to remember how uncertain things were at the start.

Are key paradoxes of #owot a) how we find a common end user, b) a common need we can meet and c) a common code language/framework?
— Mia (@mia_out) July 29, 2013

Meghan herding cats to get potential ideas summarised

Today we heard from CHNM team members Sharon Leon on project management, Sheila Brennan on project outreach and Patrick Murray-John on coding and then got stuck into the process of trying to figure out what on earth we'll build this week. I don't know how others felt but by lunchtime I felt super impatient to get started because it felt like our conversations about how to build the imaginary thing would be more fruitful when we had something concrete-ish to discuss. (I think I'm also used to hack days, which are actually usually weekends, where you've got much less time to try and build something.) We spent the afternoon discussing possible ideas, refining them, bouncing up and down between detail, finding our way through different types of jargon, swapping between problem spaces and generally finding our way through the thicket of possibilities to some things we would realistically want to make in the time. We went from a splodge of ideas on a whiteboard to more structured 'tool, audience, need' lines based on agile user stories, then went over them again to summarise them so they'd make sense to people viewing them on ideascale.

#owotleaks #owot – we're building a tool that converts whiteboard brainstorming notes into fully developed applications
— Jack Dougherty (@DoughertyJack) July 29, 2013

So now it's over to you (briefly). We're working out what we should build this week, and in addition to your votes, we’d love you to comment on two specific things:

How would a suggested tool change your work?
Do you know of similar tools (we don’t want to replicate existing work)?

So go have a look at the candidate ideas at http://oneweekonetool.ideascale.com and let us know what you think. It's less about voting than it is about providing more context for ideas you like, and we'll put all the ideas through a reality check based on whether it has identifiable potential users and whether we can build it in a few days. We'll be heading out to lunch tomorrow (Viriginia time) with a decision, so it's a really short window for feedback: 10am American EST. (If it's any consolation, it's a super-short window for us building it too.)

Update Tuesday morning: two other participants have written posts, so go check them out! Amanda Visconti's Digital Projects from Start to Finish: DH Mentorship from One Week One Tool (OWOT), Brian Croxall's Day 1 of OWOT: Check Your Ego at the Door and Jack Dougherty's Learning Moments at One Week One Tool 2013, Day 1.

DHOxSS: 'From broadcast to collaboration: the challenges of public engagement in museums'

I'm just back from giving at a lightning talk for the Cultural Connections strand of the Digital.Humanities@Oxford Summer School 2013, and since the projector wasn't working to show my examples during my talk I thought I'd share my notes (below) and some quick highlights from the other presentations.

Mark Doffman said that it's important that academic work challenges and provokes, but make sure you get headlines for the right reasons, but not e.g. on how much the project costs. He concluded that impact is about provocation, not just getting people to say your work is wonderful.

Gurinder Punn of the university's Isis Innovation made the point that intellectual property and expertise can be transferred into businesses by consulting through your department or personally. (And it's not just for senior academics – one of the training sessions offered to PhD students at the Open University is 'commercialising your research').

Giles Bergel @ChapBookPro spoke on the Broadside Ballads Online (blog), explaining that folksong scholarship is often outside academia – there's a lot of vernacular scholarship and all sorts of domain specialists including musicians. They've considered crowdsourcing but want to be in a position to take the contributions as seriously as any print accession. They also have an image-match demonstrator from Oxford's Visual Geometry Group which can be used to find similar images on different ballad sheets.

Christian von Goldbeck-Stier offered some reflections on working with conductors as part of his research on Wagner. And perfectly for a summer's day:

Christian quotes Wilde on beauty: "one of the great facts of the world, like sunlight, or springtime…" http://t.co/8qGE9tLdBZ #dhoxss
— Pip Willcox (@pipwillcox) July 11, 2013

My talk notes: 'From broadcast to collaboration: the challenges of public engagement in museums'

I’m interested in academic engagement from two sides – for the past decade or so I was a museum technologist; now I’m a PhD student in the Department of History at the Open University, where I’m investigating the issues around academic and ‘amateur’ historians and scholarly crowdsourcing.

As I’ve moved into academia, I’ve discovered there’s often a disconnect between academia and museum practice (to take an example I know well), and that their different ways of working can make connecting difficult, even before they try to actually collaborate. But it’s worth it because the reward is more relevant, cutting-edge research that directly benefits practitioners in the relevant fields and has greater potential impact.

I tend to focus on engagement through participation and crowdsourcing, but engagement can be as simple as blogging about your work in accessible terms: sharing the questions that drive your research, how you’ve come to some answers, and what that means for the world at large; or writing answers to common questions from the public alongside journal articles.

Plan it

For a long time, museums worked with two publics: visitors and volunteers. They’d ask visitors what they thought in ‘have your say’ interactives, but to be honest, they often didn’t listen to the answers. They’d also work with volunteers but sometimes they valued their productivity more than they valued their own kinds of knowledge. But things are more positive these days – you've already heard a lot about crowdsourcing as a key example of more productive engagement.

Public engagement works better when it’s incorporated into a project from the start. Museums are exploring co-curation – working with the public to design exhibitions. Museums are recognising that they can’t know everything about a subject, and figuring out how to access knowledge ‘out there’ in the rest of the world. In the Oramics project at the Science Museum (e.g. Oramics to Electronica or Engaging enthusiasts online), electronic musicians were invited to co-curate an exhibition to help interpret an early electronic instrument for the public.

There’s a model from 'Public Participation in Scientific Research' (or 'citizen science') I find useful in my work when thinking about how much agency the public has in a project, and it's also useful for planning engagement projects. Where can you benefit from questions or contributions from the public, and how much control are you willing to give up?

Contributory projects designed by scientists, with participants involved primarily in collecting samples and recording data; Collaborative projects in which the public is also involved in analyzing data, refining project design, and disseminating findings; Co-created projects are designed by scientists and members of the public working together, and at least some of the public participants are involved in all aspects of the work. (Source: Public Participation in Scientific Research: Defining the Field and Assessing Its Potential for Informal Science Education (full report, PDF, 3 MB))

Do it

Museums have learnt that engaging the public means getting out of their venues (and their comfort zones). One example is Wikipedians-in-Residence, including working with Wikipedians to share images, hold events and contribute to articles. (e.g. The British Museum and Me, A Wikipedian-in-Residence at the British Museum, The Children's Museum's Wikipedian in Residence).

It’s not always straightforward – museums don’t do ‘neutral’ points of view, which is a key goal for Wikipedia. Museums are object-centric, Wikipedia is knowledge-centric. Museums are used to individual scholarship and institutional credentials, Wikipedia is consensus-driven and your only credentials are your editing history and your references. Museums are slowly learning to share authority, to trust the values of other platforms. You need to invest time to learn what drives the other groups, how to talk with them and you have to be open to being challenged.

Mean it

Done right, engagement should be transformative for all sides. According to the National Co-ordinating Centre for Public Engagement, engagement ‘is by definition a two-way process, involving interaction and listening, with the goal of generating mutual benefit.’ Saying something is ‘open to the public’ is easy; making efforts to make sure that it’s intellectually and practically accessible takes more effort; active outreach is a step beyond open. It's not the same as marketing – it may use the same social media channels, but it's a conversation, not a broadcast. It’s hard to fake being truly engaged (and it's rude) so you have to mean it – doing it cynically doesn't help anyone.

Asking people to do work that helps your mission is a double win. For example, Brooklyn Museum's 'Freeze Tag' ask members of their community to help moderate tags entered by people elsewhere – they're trusting members of the community to clean up content for them.

Enjoy it

My final example is the National Library of Ireland on Flickr Commons, who do a great job of engaging people in Irish history, partly through their enthusiasm for the subject and partly through the effort they put into collating comments and updating their records, showing how much they value contributions.

Almost by definition, any collaboration around engagement will be with people who are interested in your work, and they’ll bring new perspectives to it. You might end up working with international peers, academics from different disciplines, practitioner groups, scholarly amateurs or kids from the school down the road. And it’s not all online – running events is a great way to generate real impact and helps start conversations with potential for future collaboration.

You might benefit too! Talking about your research sometimes reminds you why you were originally interested in it… It’s a way of looking back and seeing how far you’ve come. It’s also just plain rewarding seeing people benefit from your research, so it's worth doing well.

—
Thanks again to Pip Willcox for the invitation to speak, and to the other speakers for their fascinating perspectives. Participation and engagement lessons from cultural heritage and academia is a bit of a hot topic at the moment – there's more on it (including notes from a related paper I gave with Helen Weinstein) at Participatory Practices.

Notes from THATCamp Feminisms West #tcfw

I'm just back from ten days in the US where I attended two events, both closely related to digital history, feminist digital humanities and women's history (whether intellectual, science, education, etc related). I'm posting to mark the moment and to collect some links – I think I'm still digesting the many conversations and moments of insight.

THATCamp Feminisms West #tcfw

A THATCamp is a technology+humanities unconference, a format much loved in the digital humanities world. This one was conceived from a twitter conversation and organised by the wonderful Jacque Wernimont of Scripps College in Claremont, California for March 14-15. Two other THATCamp Feminisms were held simultaneously in the south and east. I was invited over to do a workshop, and thought 'data visualisation as a gateway to programming' would be useful – I prepared two exercises, one of which involved thinking about how to match visualisation types to the structure of the selected content in ManyEyes, while the other was more about learning about how code works by playing with a pre-coded (and heavily, chattily commented) working visualisation that used SIMILE's JavaScript libraries – 'view source' and save the file to your hard drive to get started. It was a good chance to talk about the issues that messy humanities data create for generic visualisation tools, the risks in the 'truthiness' of visualisations, the importance of thinking critically about algorithms and issues around primary sources and women's history, etc, with people who'd thought deeply about some of these issues and could make their own contributions to the workshop.

The day started with the #tooFEW Wikipedia editathon (storify of results), which gave everyone a chance to learn and try out something new before the THATCamp had even officially started. It was a nice way to ease into things and achieve something together before working out the THATCamp programme as a group.

Over the day and a half I went to sessions including Feminist digital pedagogy and Feminist Collaboration. After a week of further travel across the US and another conference, the sessions are blurring into one, but overall they were a great chance to think about what a feminist digital humanities might be like (see for example Transformative Digital Humanities projects or read Toward an Open Digital Humanities from an earlier THATCamp for things to move towards or be careful of), to ask questions like 'what would a feminist Digging into Data look like?', to ask 'does it matter if feminist projects are made with people who don't share their politics'? (Probably not, though academic work might be attractive to people who value work/life balance.) What's the right mix of openness and shared authority, how collaborative can a class be, and how can we help students fail safely in the cause of experimenting (especially when using public technologies like YouTube or Twitter)? It's important to remember that, as Alex Juhasz said, feminism is about process (or praxis), doing and making things, which in turn made me realise that one reason I value teaching coding is that it gives people DIY tools to make things that suit their own research needs and styles (see 'Why learning to code isn’t as important as learning to build something' but please also read Code: Craft and Culture and the comments below it). I also loved Alex's statement that she's 'less interested in feminism that starts from danger than feminism that starts from agency' and being fearless about taking up space.

The value of meeting in person was an underlying theme of the event, and eventually a conversation about Building a DH Regional Hub, and the difficulties in collaborating between institutions and organising in-person meetings with the huge geographic coverage of the Los Angeles area lead to the invention of Mindr: 'Grindr for travelling DHers – who's nearby and what do they want to chat about?', or as @laurenfklein described it, a 'geo-aware interface to DH Answers', an app that lets you know when someone with similar scholarly interests is nearby and might be up for a chat. I would *love* this to actually happen, and who knows, if someone is able to shepherd the enthusiasm for it, it might.

Beyond the value in the discussion, just being surrounded by people who were digitally savvy and were also aware of the effects of implicit biases and tech-as-a-meritocracy, the role of disciplinary gatekeepers, assumptions about gendered work, emotional labour and the pressure to be 'nice' as well as the peculiarities of academia was brilliant. It was also a bit intimidating at first as I don't feel hugely qualified to comment on feminist issues (it's a long time since I've been caught up on theory and 'feminism' online has probably made it sound scarier than it really is) unless conversation moved to 'women in tech' issues or I could contribute observations on my experience of academia and workplaces in the UK. Perhaps that's one reason I was encouraged by discussion about possible models of feminist scholarship and mentoring (including asking male allies for help) – I don't have to figure this out on my own. That said, as Anne Cong-Huyen said:

'At an event like this one, where we come together to address or at least share about gender and sexual equality in dh and the academy it leaves us to ask: Where does the burden of addressing that inequity fall? […] And how about those of us who are junior faculty, adjuncts, or graduate students (like myself) who have even less power within the academy?'

Or in Amanda Phillips' words:

In this way, THATCamp Feminisms felt a bit different than other THATCamps I’ve attended. The infectious enthusiasm of DH was tempered here by the political, professional, and market realities that disproportionately affect marginalized communities.

I think it's important that those realities are widely understood and shared, or some of the promise of the digital humanities will have failed to blossom. Creating space for those hard questions perhaps highlights how positive, supportive and constructive the environment at THATCamp Feminisms West was. I don't have a witty or concise conclusion, except to say that I met a bunch of amazing women and came away encouraged and inspired, and you should definitely go to a THATCamp Feminisms if you ever get a chance. Or run one yourself and see what happens. To quote Alex Juhasz again:

To me it is was less the DH, or even the digital, that made this conversation matter, but the feminist: because we shared values, the will and capacity to be critical as well as intellectual while being supportive and trying to distribute authority and voice around the room all the while working, quick.

Finding museum, digital humanities and public history projects and communities online

Every once in a while I see someone asking for sources on digital, participatory, social media projects around museums, public history, social history, etc but I don't always have a moment to reply. To make it easier to help people, here's a quick collection of good places to get started.

I think the best source for museums and digital/social media projects is the site and community around the Museums and the Web conference, including 'Best of the Web' nominations and awards (2012-1997) and conference proceedings: 2012, 2011, 2010-1987.

Other projects might be listed at the new Digital Humanities Awards (nominations closed on the 11th so presumably they'll publish the list of nominees soon) or the (US) National Council on Public History Awards. The Digital Humanities conferences also include some social history, public history and participatory projects e.g. DH2012, as did the first Digital Humanities Australasia conference and the MCG's UK Museums on the Web conference reports.

To start finding online communities, look for people tweeting with #dhist, #digitalhumanities, #lodlam, #drinkingaboutmuseums, #musetech (and variations) or join the Museums Computer Group or the Museum Computer Network lists (or check their archives).

I'd like to add a list of museum bloggers (whether they focus on social media, technology, education, exhibition design, audience research, etc) but don't know of any comprehensive, up-to-date lists (or delicious etc tags). (Though since I originally posted @gretchjenn pointed me to the new 'Meet a museum blogger' series and @alexandrematos told me about Cultural blogging in Europe which includes a map of the European cultural blogging scene.) Where do you look for museum bloggers?

This is only a start, so please chip in! Add any resources I'm missing in the comments below, or tweet @mia_out.

Keeping corridors clear of dragons (on agency and digital humanities tools)

A while ago I posted 'Reflections on teaching Neatline', which was really about growing pains in the digital humanities. I closed by asking '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 [for stable, easy-to-use software]? Is it ok to say 'here be dragons, enter at your own risk'?' Looking back, I started thinking about this in terms of museum technologists (in Museum technologists redux: it's not about us) but there I was largely thinking of audiences, and slightly less of colleagues within museums or academia. I'm still not sure if this is a blog post or just an extended comment on those post, but either way, this is an instance of posting-as-thinking.

Bethany Nowviskie has problematised and contextualised some of these issues in the digital humanities far more elegantly for an invited talk at the MLA 2013 conference. You should go read the whole thing at resistance in the materials, but I want to quickly highlight some of her points here.

She quotes William Morris: '…you can’t have art without resistance in the material. No! The very slowness with which the pen or the brush moves over the paper, or the graver goes through the wood, has its value. And it seems to me, too, that with a machine, one’s mind would be apt to be taken off the work at whiles by the machine sticking or what not' and discusses her realisation that:

"Morris’s final, throwaway complaint is not about that positive, inherent resistance—the friction that makes art—which we happily seek within the humanities material we practice upon. It’s about resistance unhealthily and inaccessibly located in a toolset. … precisely this kind of disenfranchising resistance is the one most felt by scholars and students new to the digital humanities. Evidence of friction in the means, rather than the materials, of digital humanities inquiry is everywhere evident."

And she includes an important call to action for digital humanities technologists: "we diminish our responsibility to address this frustration by naming it the inevitable “learning curve” of the digital humanities. Instead, we might confess that among the chief barriers to entry are poorly engineered and ineptly designed research tools and social systems". Her paper is also a call for a more nuanced understanding and greater empathy from tool-builders toward those who are disenfranchised by tools they didn't create and can't hack to fit their needs. It's too easy to forget that an application or toolset that looks like something I can happily pick up and play with to make it my own may well look as unfathomable and un-interrogable as the case of a mobile phone to someone else.

Digital humanities is no longer a cosy clubhouse, which can be uncomfortable for people who'd finally found an academic space where they felt at home. But DH is also causing discomfort for other scholars as it encroaches on the wider humanities, whether it's as a funding buzzword, as a generator of tools and theory, or as a mode of dialogue. This discomfort can only be exacerbated by the speed of change, but I suspect that fear of the unknown demands of DH methods or anxiety about the mental capabilities required are even more powerful*. (And some of it is no doubt a reaction to the looming sense of yet another thing to somehow find time to figure out.) As Sharon Leon points out in 'Digital Methods for Mid-Career Avoiders?', digital historians are generally 'at home with the sense of uncomfortableness and risk of learning new methods and approaches' and can cope with 'a feeling of being at sea while figuring out something completely new', while conversely 'this kind of discomfort is simply to overwhelming for historians who are defined by being the expert in their field, being the most knowledgable, being the person who critiques the shortfalls of the work of others'.

In reflecting on March 2012's Digital Humanities Australasia and the events and conversations I've been part of over the last year, it seems that we need ways of characterising the difference between scholars using digital methods and materials to increase their productivity (swapping card catalogues for online libraries, or type-writers for Word) without fundamentally interrogating their new working practices, and those who charge ahead, inventing tools and methods to meet their needs. It should go without saying that any characterisations should not unfairly or pejoratively label either group (and those in-between).

Going beyond the tricky 'on-boarding' moments I talked about in 'Reflections on teaching Neatline', digital humanities must consider the effect of personal agency in relation to technology, issues in wider society that affect access to 'hack' skills and what should be done to make the tools, or the means, of DH scholarship more accessible and transparent. Growing pains are one thing, and we can probably all sympathise with an awkward teenage phase, but as digital humanities matures as a field, it's time to accept our responsibility for the environment we're creating for other scholars. Dragons are fine in the far reaches of the map where the adventurous are expecting them, but they shouldn't be encountered in the office corridor by someone who only wanted to get some work done.

* Since posting this, I've read Stephen Ramsey's 'The Hot Thing', which expresses more anxieties about DH than I've glanced at here: 'Digital humanities is the hottest thing in the humanities. … So it is meet and good that we talk about this hot thing. But the question is this: Are you hot?'. But even here, do technologists and the like have an advantage? I'm used to (if not reconciled to) the idea that every few years I'll have to learn another programming language and new design paradigms just to keep up; but even I'm glad I don't have to keep up with the number of frameworks that front-end web developers have to, so perhaps not?

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