Cross-posted from the DH Box Blog: https://dhbox.commons.gc.cuny.edu/blog/2014/dh-box-takes-off
This is it: DH Box is officially launching. The Digital GC is presenting an evening of short talks from various CUNY Graduate Center digital initiatives today, May 12 — starting off with DH Box.
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.
Cross-posted from the DH Box Blog: https://dhbox.commons.gc.cuny.edu/blog/2014/deployment-options-dh-box
Once DH Box knew the platform it would adopt, it was simply a matter of figuring out the best way to utilize that platform. But was it so simple?
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.
Cross-posted from: http://harlankellaway.com/2014/03/17/online-documentation-platforms/ (March 17, 2014)
Documentation for technical projects — especially ones you envision having non-technical end users — is essential. This statement comes from various experiences, both as a user and a developer who has both produced documentation for such users and has taken over poorly-documented projects from other developers. Having good documentation cuts down on the endless issues that come with figuring out how to use a technical product, whether from the frontend or the backend.
The reason documentation is on my mind is that one of the current projects I’m doing development for, DH Box, is one targeted towards end users of the variety described above. Not only that, but one of the systems integral to the project is a notoriously opaque one: Amazon Web Services. Moreover, it’s a mission of mine in my personal work to explore how tech can be made more accessible to those who don’t deem themselves technically savvy (I consider the technical/non-technical social binary and contributing factors to be problematic — but I’ll save that exploration for a different post!).
This week, I explored some tools that could help maintain the online documentation for our DH Box project, with a few preferences in mind: documentation that is easily updatable, documentation that is browsable and searchable, documentation that is configurable (e.g. in how it looks).
Cross-posted from: http://harlankellaway.com/2014/03/02/online-branding-subtle-elements-to-help-web-impression/ (March 2, 2014)
I found myself in the midst of an interesting exchange a couple weeks ago — it was over whether Twitter handles should have underscores in them or not. The person questioning the underscores had been told to not use them period, but was unclear on why. It occurred to me that there are many subtle forms of online branding that folks who work on/with the Internet quite a bit eventually pick up, things that are obscure to more general users.
Here are a few examples of such online branding to think about when building an online presence.
Cross-posted from: http://harlankellaway.com/2014/02/20/web-development-beginners-tradeoffs-jekyll-wordpress/ (February 20, 2014)
I’ve used WordPress for years as the base for just about every site I’ve created. It had occurred to me occasionally that WordPress may not be the best choice in every website development case, whether big or small, simple or complex. But, honestly, the idea of creating a website that didn’t have a database behind it hadn’t even occurred to me. A website that is almost purely HTML? I had subconsciously equated this with broken links and scrolling banners. I had equated database-backing with words like easy, maintainable, modern, and extensible.
It’s a clear case of every problem looking like a nail when the only tool you have is a hammer. But what if your problem is a thumbtack? Or a staple? A hammer might work, but it’s most definitely overkill and can even limit your creativity in solving the problem of fastening paper to things.
In terms of website development, WordPress has been my hammer and it’s gotten the job done. But, I had the opportunity the past weeks to use a new tool — Jekyll.
Cross-posted from: https://dhbox.commons.gc.cuny.edu/blog/2014/dh-box-new-friend-new-platform
This week the DH Box team reconsidered their choice of platform, with the help of Dennis Tenen, a professor at Columbia University in the Digital Humanities and New Media Studies program (and former developer with Microsoft).
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.