Author Archives: Cailean Cooney

DH Box Development and Testing

We’ve made big strides developing the front end interface to launch a new DH Box, and the Welcome page/menu that acts as the DH Box ‘home base’. We received extremely helpful feedback from some generous volunteer user experience testers at City Tech, and valuable advice from Chris Stein, Director of User Experience for the CUNY Academic Commons.

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.

DH Box: Making a place in the Cloud

The DH Box team has made exciting strides over the past week!

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 it’s 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.

DH Box: Tackling Project Scope

We have this great Digital Humanities project idea, but what happens between now and launch time?

With an idea like DH Box (a customized linux OS with preinstalled DH Tools and the flexibility to operate on a computer as cheap and portable as the Raspberry Pi) there are a number of directions we could take, and will certainly consider for further iterations of DH Box beyond the Spring term (this blog currently documents the experiences of a project team enrolled in a graduate course in Digital Humanities Praxis at the Graduate Center, CUNY).

In order to refine the scope of our tool, we asked ourselves some questions:

  • What approach will we take around educating users about coding, the infrastructure around the DH Box software, hardware, and operating system?
  • Which DH Tools should we include? See Alan Liu’s curated list for more info on the scope of DH tools out there
  • What user(s) are we building this for?

The success of our project hinges on our ability to carefully model the scope of the tool by shaping the answers to these questions . . . all by May 12th (public launch date)!

Educational Value

Beyond providing a collection of accessible DH Tools, we want DH Box to help bridge knowledge gaps by delivering a strong educational component. We’d like for instance, undergraduate English students to gain exposure and develop proficiency in Digital Humanities inquiry through the kind of guidance and practical experience DH Box will offer. To that end, we will begin an interactive textbook to provide instruction about the specific tools included in this first iteration of DH Box. We are most inspired by the Learn Code the Hard Way interactive textbook series by Zed Shaw.

Tools

We are gearing this version of DH Box to bring Topic Modeling and Text Analysis to Humanities students!

We began by considering the most popular DH Tools out there and quickly realized it made a lot of sense to whittle the list down for this current project phase. We’ve made choices based on optimal software performance with the Raspberry Pi. We also want to provide DH Tools that haven’t yet had the level of proliferation like some of the more popular content management systems such as WordPress.

Users

Undergraduate Humanities students currently have little familiarity with terms like tokenization, sentiment analysis, etc., and how these components of text analysis can open expansive modes of textual inquiry. As part of its mission, DH Box will work to make these methods accessible to a broad audience!

Stay tuned for exciting updates on implementing the install scripts, using IPython Notebook, and more!

 

Questions? Comments? Tweet us!

Catching Lightning in a Bottle

It’s interesting to reflect on the discussion channels pouring out of Tom Scheinfeldt’s presentation about One Week | One Tool. It seems we’re contending with how to infuse the energy and spontaneity characterized by some of the One Week | One Tool ethos into our yet to be, semester long projects next Spring. The attraction I, and certainly others see in a short term, intensive program like One Week | One Tool is exactly the phenomenon Tom Scheinfeldt remarked upon- this freedom within constraints, this ability for the clear (just the right kind of spooked) mind to shepherd in powerful concentration and creativity.

We make very fuzzy visualizations about what next semester’s project might really look like or turn into- and we’ve had plenty of time to let our imaginations run rampant without the ability to put any of this energy into doing the project itself. And I think this speaks directly to another of Scheinfeldt’s points- stress creeps in when we don’t know what’s expected of us. We haven’t gotten there yet, so we certainly aren’t able to grasp the expectations.

One Week | One Tool aims to catch lightning in a bottle by giving willing attendees the opportunity to collaborate and produce results under extreme pressure. How can we leverage that ‘camp’ like energy and combine it with more traditional project timelines for the better of our projects?

Perhaps we can start with an approach similar to how Scheinfeldt described this summer’s One Week | One Tool participants’ working process. First, a rapid brainstorming session, followed by a few rounds of viability and assessment discussions. Projects would be conceived in a short amount of time, and there would be an emphasis on developing and testing the tool quickly. I think it’s crucial to be really strategic and cognizant, yet make haste on the design and development side of things as often the concept and reality can get conflated and cause distortion- really putting a wrench in the project’s momentum. We could then take the results to our constituents: the end users and ‘funders.’ This would give us more of an opportunity to interface with crucial stakeholders beyond project participants, and hopefully enable reworking phase(s) in order to work out some kinks.

 

Defining DH: An Exercise

1st Definition: A discipline that functions to study, promote, and create digital technology and tools to advance scholarship, knowledge, and literacy among humanities disciplines.

2nd Definition: A field/movement that leverages digital technology to promote knowledge and exploration in the humanities.

When our class grappled with the definition of DH, one issue captured my attention in particular- will Digital Humanities become obsolete once the “Digital” component fully saturates the academy? If DH loses its luster on the way to commonplace, who’s to say a midlife crisis/senioritis moment won’t destroy the thing altogether? The intransigence, exclusivity, bureaucracy, etc. which often plagues the establishment could conceivably take the wind out of DH’s sails, too…right? As I imagine this doomsday scenario, I find myself asking another set of questions: What attracted me to DH? What do I want from DH? What do I want to contribute to DH?

The answers that come to mind have formulated my take on why DH has the potential to stick around for a while. I like DH for its flexibility and adaptability, its collaboration and interdisciplinarity, its versioning and experimentation, its hands on approach, and its scholarly approach. There is inherent dualism in much of DH and I believe there will never be a shortage of demand to improve the interconnectedness between mind and matter.

I expect DH will have quite a few growing pains, but I do believe there’s no reason why the foundations of DH can’t serve the next iteration well. First “Humanities Computing,” now “Digital Humanities” …what’s next?