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.

Planes, trains and automobiles…

This week I’m heading to Lincoln, Nebraska for Digital Humanities 2013 (abstracts) (where I’m also doing a half-day workshop on ‘Designing successful digital humanities crowdsourcing projects‘ and attending my first meeting as a member of the ACH Executive Council).

After DH2013, I’m gradually making my way east by Amtrak and Greyhound, ending up at One Week, One Tool (‘a digital humanities barn raising’!). I’ll be in Chicago from Sunday afternoon (July 21) until late 22nd, arriving in Cleveland on the 23rd and jumping on another bus to Pittsburgh for  July 24-27. If you’re going to be nearby and fancy a chat about crowdsourcing, museums or digital history, or have a suggestion for sights I should see, let me know! You can get a sense of my interests at the never-properly updated Upcoming talks and travel and My PhD research.

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