One Week | One Tool, the digital humanities barn-raising, is wrapping up; we released the tool we built in less than a week (Tuesday afternoon through Friday afternoon, to be exact), Serendip-o-matic. Head on over to the site to check it out and let your sources surprise you--I recommend trying both the option to take your Zotero library for a spin, and also submitting some beloved text like song lyrics or a book chapter. You might even try an interesting Wikipedia article and discover some new branches of information to explore!

Screenshot of http://serendip-o-matic.com/ The front page of the tool we created, serendip-o-matic.com.

Site visitors are already tweeting screenshots of their results, and some have even advanced their research with their first visit:

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

We're all exhausted and full of new knowledge and very happy with our work. Before he head out to a celebratory dinner not at The Well (the hotel bar where we had to grab most of our meals this week), I'm capturing a few notes on the experience.

Photo of OWOT dev team members working hotel room. Coding in a hotel room after we got kicked out of the hotel restaurant for eating pizza delivered from outside. Photo by team member Brian Croxall?

Project Ideas, Criteria, and Projects vs. Tools

Producing a working tool was an awesome experience, but Monday and Tuesday's debates before we decided on our project was also a useful experience. We talked about the gaps in our digital experience and what tools might fill them, and developed very high-level pseudocode-type explanations for how the ten or so ideas that made it to public voting would work--work we hope to capture and submit to the developing DiRT DH tool wishlist.

Criteria for choosing the tool included

work our skills allowed (no mobile apps meant nixing the oral history recording idea),
accessibility,
text-centrism (could we work with images or audio?),
scope (could we deploy the tool in a few days?),
would the tool actually be used? (what people say they want can be different from what they'd actually use; sometimes creating a tool creates or reveals a need),
an interface that allowed users to quickly try the tool without reading too much textual documentation,
ease of explanation for marketing purposes

Update: immediately below are photos from the process of choosing which tool we'd build.

Photo of whiteboard during One Week One Tool planning and dev work. (CC0 Amanda Visconti)

Another take-away from earlier in the week was the difference between brainstorming projects and tools: often we generated ideas that involved generating or creating structures for content, such as an archive for audio descriptions of visual art for blind museum-goers, or a place to list DH dream-tool ideas so that bored DH coders could get inspiration for work that would serve the community. I realized that often my ideas for DH creations are projects and not tools, or at least somewhere in a gray area in-between, with the code work closely tied to the generation of inclusion of specific topic (Infinite Ulysses, for example). This might have something to do with my skillset, which is weighted toward interface development and design, but it reminded me it might be interesting to create a DH object that can be applied to multiple research areas.

Coding Schedule

A quick glance at graphs of our code commits to the Github repository over the week shows a predictable trend (and some Friday 3am coding!):

Hippos, Mustaches, and J.K Rowling

As commit messages started to shoot out quicker and closer to the deadline, clarity decreased. We ended up making a lot of small commits to make sure everyone was working with the same code.

We used a photo of J.K. Rowling as a filler for results without images; combined with an error causing the filler image to peep up behind other photos, it produced a frightening effect: