I wanted to take a moment to reflect on where DH Box started and how far we’ve come. We introduced our project in early February:

What is DH Box?

Not much, so far. But we intend it to be a portable, customized linux environment for Digital Humanities learners that can rely on incredibly inexpensive technology. All you really need is a computer that runs Linux (and a monitor and keyboard, of course!) — but the platform that excites us most is the Raspberry Pi, a tiny computer that sells for just $35. Imagine a collection of DH tools, pre-installed and configured, and a set of texts for users to interrogate — all on a portable and inexpensive device.

That’s a quote from our first blog post — and it illustrates the most drastic change to our project. DH Box’s founder, Stephen Zweibel, had originally envisioned DH Box as being scripts that, when run, installed common DH applications (think Omeka, MALLET, NLTK) onto the user’s system; additionally, DH Box could be shipped as its suite of tools pre-installed on the light and portable Raspberry Pi computer.

As DH Box developed, it took a shift in platform, moving away from the issue of dealing with the idiosyncrasies of each individual’s system, to hosting instances of a virtual computer that any user could launch.

This was a vast and visible shift. But, despite not being as drastic, many other project elements developed in the journey from DH Box’s inception to its official launch.

Team Communication

Our first step was figuring out how to communicate with each other.

We needed a space to organize our materials and our tasks. We chose Google Drive as a central document repository, given each of us uses Gmail. To manage tasks, we initially chose Asana – but eventually went with GitHub’s Issues utility, given we were already using GitHub to host our code.

Project Documentation

Documentation became an increasingly important aspect of our project as the platform became solidified.

One aspect of DH Box that we all consider important is its potential for lowering barriers to engagement with DH tools – part of lowering that barrier involves making a tool like DH Box, with a fairly technical back-end, comprehensible to all users through clear documentation.

Project Publicity

DH Box started making its work visible with this very blog – then developed a Twitter account (a popular gathering place for those interested in DH) and a website.

Our Outreach coordinator, Cailean, thought carefully about what information would be presented on all of these mediums throughout the project. Additionally, a number of presentations were done on DH Box to introduce it to potential user communities.

User Testing

Once DH Box had enough of an interface – online documentation, a website for users, etc. – it was time to see how uninitiated users would react to it and where they might get stuck.

This aspect of the project was critical — not only did it lead to important iterations and additions to our website and documentation, but solidified us narrowing our focus for our launch to academic communities.

And More

These were large topics that DH Box had to approach during its development up to the time it launched. It was a large undertaking for a team of graduate students, requiring devoted developers, an outreach coordinator, and a project manager — as well as advisers.

We leave this summary of our process for DH-ers working on projects such as ours as an idea of what might be required to undertake it. But, DH Box’s story isn’t over. Keep following along for insight into how a project such as DH Box is sustained after launch!

Our team did a presentation on DH Box for the Academic Center for Excellence in Research and Teaching at Hunter College. It was exciting to show our project to faculty who may want to use it in classroom teaching and research. The audience included math professors, English professors, sociology professors, librarians, IT specialists, and adaptive technology specialists. We got a great range of questions. Some were very specific: “Can I upload a csv file with the information for all 25 students in my class or do I need to add a new user for each one?” Great idea – we’ll see what we can do! Some questions were more general such as “What tools do you plan to add in the future?” We will be adding more tools as the project develops, but we need to limit our selection to web based or command line tools that are open source.

Everyone was very interested in how using a virtual server can improve access to technology for students. Our team is excited about a new project at the University of Mary Washington called A Domain of One’s Own The project will provide all incoming freshmen with their own domain names and Web space. Students will have the freedom to create subdomains, install any LAMP-compatible software, setup databases and email addresses, and carve out their own space on the web that they own and control.

DH Box brings a powerful virtual computer to anyone with a web connection. Students do not need to own the most recent laptop computer or to attend a school with a big budget computer lab.  We are very exited about how our project may grow in the future to offer even more!

The results of our first round of user experience testing gave our team some great insights, and a fresh perspective on the project. We learned that perhaps one of our biggest challenges is effectively conveying the concept of the project in a readily digestible way.

We discovered that users can easily get the impression that DH Box is essentially a website, when in fact it’s much more than that (it’s a computer!). It’s understandable that this virtual computer could be confused for a website since DH Box’s primary navigation happens through your web browser. A distinct IP address is assigned to each DH Box instance at the time of launch. DH Box users navigate to applications (Mallet, Omeka, etc.) through specific ports designated for each tool. The “port” is just a unique numeric identifier appended to the end of your DH Box IP address. This same protocol for assigning unique identifiers is the basis of the internet; there’s an IP address behind every website.

We as a team are now reexamining how to explain the system of navigation, along with all of the fantastic stuff a virtual computer can offer so that users will be ready to push DH Box to the limit.

This is, in part, due to the fact that I did not begin with a particular plan. Though we had a well-defined goal for DH Box, I knew that there were myriad ways to reach it. So I experimented with different methods of cloud deployment and server provisioning, that is, different ways of creating each new instance of DH Box and automatically installing all of the necessary software on it.

I started with a BASH script designed to run on the first boot of each new DH Box instance. This worked well enough, but didn’t offer much in the way of sophisticated automation or transparency for debugging. I then tried some of the more well-known server deployment/provisioning tools, like Puppet and Salt. Puppet I found less straightforward than I’d hoped, partially because it requires modules to be written in a homespun variety of Ruby, which I’m not super comfortable with. Salt did more of what I wanted, but I was still reading its documentation when I became distracted by yet another tool, Ansible.

Ansible turned out to be just what I needed: It is written in Python, a language I have more familiarity with, and it allows me to monitor each deployment of a new DH Box in real time. Using Ansible, I’ve been able to create a whole automation workflow in one language, and, even better, I can easily see if and at exactly which point a deployment fails. This is crucial to efficient problem solving and future updates for DH Box, as its installation process necessarily involves many separate moving parts.

With these details of DH Box’s technical framework determined, it’s possible to create a more concrete “blueprint”, and I’m now working with our project planner, Gioia, to incorporate much more specific technical milestones into our overall plan. Going forward, I hope to keep everyone up-to-date and communicate some of what I learn along the way, without getting us too bogged-down in technical minutiae.

What the DH Box Team has been tackling this week is striking a balance between providing a robust tool that is useful for the intended audience and whose maintenance is not insurmountable for its administrators.

To recap — the platform chosen for delivering the DH Box environment, ready with DH tools installed, is a web server image provided through Amazon’s AMI (Amazon Machine Image) appliance. This will deliver, in essence, an identical copy of a tool-laden operating system to any user’s system.

Choosing this platform offered important benefits — for example, freedom from having to address issues caused by tools being installed to users’ personal systems. However, it also introduced tension: to deploy images hosted by Amazon, one needs to use an Amazon account. Would we have users create their own Amazon Web Services (AWS) accounts that require credit card information (though launching the Image is a free service) or would we maintain an account that instances would be launched from and figure out how the DH Box team would handle potential related charges?

Many questions entered into this equation: Would our intended users be open to providing credit card information? Who might this alienate? Or, if we managed the AWS account with many instances running, would we incur charges we’re not prepared to deal with? What would be the time-period allotted to users for running the instances?

DH Box has had to think through how different deployment options (e.g. requiring users to have their own AWS accounts) might affect how DH Box will be adopted by intended users. And this — the tension between providing a service that is maintainable, sustainable, and at-once useful to the intended audience — is something any project like DH Box might face.

User experience testing and documentation will be very important over the next few weeks. We need to be sure that people who are not already familiar with the command line, cloud computing, and DH tool installation will find DH Box easy and convenient to use. Documentation (aka the “user manual”) will be the key to helping users make the most of DH Box. We have decided to use Read the Docs  to host our documentation. Read the Docs allows us to host documentation files on our website and update our documentation when pushing to the GitHub repository that hosts our website – this means updating our online documentation is as simple as updating text on our website! One great benefit of using a utility like Read the Docs is our documentation will be easily maintainable, will be forkable by contributors, will be available online, and will be searchable.

As some may know, DH Box will be available on a pre-installed, pre-configured Debian cloud server. To achieve this, we are using Amazon Web Services. For those who aren’t initiated, AWS is a vast cloud computing infrastructure (with internet servers throughout the world) that offers services very similar to what a physical computer would. But AWS brings unrivaled scale, flexibility, and economy (pay as you go pricing).

DH Box’s Intro to Cloud Computing

Dennis Tenen led the DH Box team through its first group workshop on setting up a virtual web server image, a.k.a. an “EC2 Instance.” The virtual web server contains an Amazon Machine Image (think of it as an identical copy) of an operating system. DH Box will be freely available for users to launch their own instance of ours. This solution saves users the trouble of downloading and installing tools to their own computers.

What do users need to access DH Box in the Cloud?

It will be pretty simple- users must sign up for a free AWS account. And we’re making use of AWS’ CloudFormation (templates that deploy services rapidly) utility to automate many of the steps required to launch a new AMI instance. We also have custom scripts to automate the launch of DH Box files and software once users copy our server image. We’re really excited about being introduced to this powerful service, and even more encouraged that our configuration templates will allow DH Box users to dive swiftly into DH inquiry.

This is just the beginning- we’re focusing heavily on providing thorough documentation so that DH Box users will have everything they need to get up and running. Stay tuned!

Special thanks to Prof. Dennis Tenen for his amazing Intro to Cloud Computing Workshop.

I’ll be using these slides to give a short talk about DH Box to faculty this Tuesday at Hunter College. It looks like we’ll be making quite a few presentations like this one, because as it turns out, building a community is one of the key factors determining success for DH Box. We will need the help of an invested community to:

• Determine which tools should be included
• Identify new platforms to target
• Contribute to documentation
• Spread awareness about DH Box

and it seems clear that in-person meetings and discussions are the best way for us to create interest in our work. That’s not to discount social media approaches at all; they allow for broad outreach we couldn’t manage otherwise. But in-person conversation allows us to demonstrate and discuss DH Box in greater depth, thus solidifying each potential user’s understanding and their relationship with us and our project.

A couple weeks ago we were surprised and delighted to find that another team had come up with the idea for a portable tool that could help users quickly get going with DH applications. And this week we found that Professor Tenen and colleagues had also discussed how to tackle such a project and had come up with yet a different solution! In discussing that solution, we found it matched our aim of providing an ease of quickly setting up an environment for new users and made us change our focus for both implementation and outreach.

We’ll keep a description of Professor Tenen’s proposed approach for a later post, but say that using his method circumvents big issues we would have encountered with our original proposal — what if users don’t have one of the operating systems that a DH Box install script was written for? Moreover, what if an addition works for one operating system but not others (a painful lesson Steve learned this week!)? What if unaccustomed users have issues with the install scripts? Or with the command line? This will save us a lot of user issues in the long run. We were happy to hear we wouldn’t have to give up our Raspberry Pi pursuits — Professor Tenen was also excited about the potential of the hyper portable/affordable Raspberry PI platform, suggesting a DH Box ‘lite’ version to be later produced.

So, we will be abandoning the install script approach and with it the need for a robust way to deal with different operating system issues. Our main issues will now be:

1. Creating meticulous documentation to get unaccustomed users up-and-running
2. Maintenance of new releases of the DH tools in DH Box
3. Building of a community invested in suggesting improvements for DH Box and helping with maintenance

Professor Tenen suggested starting with GitHub for organizing pending tasks (as GitHub “Issues”) into Milestones, recording documentation on a GitHub Wiki, and inviting users to enter requests through new Issues.

Not only did Professor Tenen’s suggestions prove invaluable, but forming a relationship with him did as well — he offered to continue meeting with the DH Box team weekly, to present a workshop at CUNY on the technologies he suggested for us, and to help start our documentation based off his own.

The DH Box team is very excited to dive into our new implementation strategy and to work through how maintenance and community building will be executed.

A huge shoutout and special thank you to Professor Dennis Tenen!

Our scope has been narrowing down as we refine our concept of DH Box. We are thinking more about who will use DH Box and thinking about the best way to make it a valuable toolkit for introductory students in digital humanities classes.

Pedagogy is a key part of the digital humanities at the CUNY Graduate Center and the Praxis Network. Our focus for the first phase of development will be text analysis and topic modeling including key tools such as Mallet, Natural Language Toolkit (NLTK), and the Stanford Named Entity Recognizer. We are going to build an interactive textbook using IPython Notebook. The textbook will be bundled with the DH Box install scripts and it will help orient students with the tools through interactive code execution. We have also thought more about our platform and what would be most useful for our users. We are going to make DH Box available for download not only for Raspberry Pi but also for Linux, Mac, and hopefully Windows.

As we have narrowed down our scope, we are also discovering a much wider range of connections to the DH community. Our professor, Matt Gold, has put us in touch with his colleague Dennis Tenen. GC Digital Fellow  Micki Kaufman suggested we check out Ian Milligan’s work and we’ve found amazing stuff in Big Digital History: Exploring Big Data through a Historian’s Macroscope, a co-written manuscript by Shawn Graham, Ian Milligan, and Scott Weingart. My library colleague Roxanne Shirazi, who edits the dh+lib blog, suggested we check out an idea for a project called DH creator stick which George Williams proposed at THATCamp Piedmont 2012 (see also a blog post by Mark Sample).

We’re amazed by the range of rich ideas we are beginning to discover. We hope to reach out to the DH community and ask for advice and feedback as DH Box takes shape.