Friday, April 11, 2008

Who do I build for?

Over at ClioWeb, Jeremy Boggs is starting a promising series of posts on the development process for digital humanites process. He's splitting the process up into five steps, which may happen at the same time, but still follow a rough sort of order. Step one, obviously, is "Figure out what exactly you’re building."

But is that really the first step? I'm finding that what I build is dependent on who I'm building for. Having launched an alpha version of the product and shaken out many of the bugs in the base functionality, I'm going to have to make some tough decisions about what I concentrate my time on next. These all revolve around who I'm developing the product for:

My Family: Remember that I developed the transcription software to help accomplish a specific goal: transcribe Julia Brumfield's diaries to share with family members. The features I should concentrate on for this audience are:
  • Finish porting my father's 1992 transcription of the 1918 diary to FromThePage
  • Fix zoom.
  • Improve the collaborative tools for discussing the works and figuring out which pages need review.
  • Build out the printing feature, so that the diaries can be shared with people who have limited computer access.
THATCamp attendees: Probably the best feedback I'll be able to receive on the analytical tools like subject graphs will come from THATCamp. This means that any analytical features I'd like to demo need to be presentable by the middle of May.

Institutional Users: This blog has drawn interest from a couple of people looking for software for their institutions to use. For the past month, I've corresponded extensively with John Rumm, editor of the Digital Buffalo Bill Project, based at McCracken Research Library, at the Buffalo Bill Historical Center. Though our conversations are continuing, it seems like the main features his project would need are:
  • Full support for manuscript transcription tags used to describe normalization, different hands, corrections/revisions to the text, illegible text and other descriptors used in low-level transcription work. (More on this in a separate post)
  • Integration with other systems the project may be using, like Omeka, Pachyderm, MediaWiki, and such.
My Volunteers: A few of the people who've been trying out the software have expressed interest in using it to host their own projects. More than any other audience, their needs would push FromThePage towards my vision of unlocking the filing cabinets in family archivists' basements and making these handwritten sources accessible online. We're in the very early stages of this, so I don't yet know what requirements will arise.

The problem is that there's very little overlap between the features these groups need. I will likely concentrate on family and volunteers, while doing the basics for THATCamp. I realize that's not a very tight focus, but it's much clearer to me now than it was last week.


Anonymous said...

How much work would it take to get it into a state where other people can extend it according to their needs?

Ben W. Brumfield said...

Most of the work would be organizational.

1. Choose the appropriate license that serves my needs (probably some sort of non-commercial use Open Source -- need to pay a lawyer on this)

2. Figure out how to run an open source project -- this is something I've never even contributed to before, and I'm sure plenty of pitfalls exist I haven't thought about.

3. Carve out the time to orchestrate updates to the core system and (more importantly) provide support to developers.

Technical work:

1. Extract dead code that introduces unnecessary dependencies. My decision last Fall to use the restful_comments plugin broght with it a host of dependent packages, none of which are in use.

2. Create a "phone home" system -- based on Matt Mullenweg's much-repeated advice, it's important to be able to navigate the ecosystem of FromThePage instances.

3. Do whatever infrastructural things are necessesary -- like move to RubyForge or Git or somesuch.

4. Do whatever technical things are needed to support a system of plugins: in a scenario where multiple instances of FromThePage are running with different customizations, I imagine that some of these (e.g. TEI-WYSIWYG) would be shared between different instances. This would require both plugin architecture in the FromThePage software, and a plugin directory akin to #2.


I do think that a distributed, open-source system is almost certainly the way to satisfy these competing user groups. Unless somebody funds me, having myself as the sole, part-time developer doesn't scale at all.


If you're interested in a more informal, more immediate arrangement, send me a note with your thoughts.