Academia, Books, Collaboration, Conferences and Workshops, Programming, Unconferences

Thoughts on One Week | One Tool

Well that just happened. It’s hard to believe that last Sunday twelve scholars and software developers were arriving at the brand-new Mason Inn on our campus and now have created and launched a tool, Anthologize, that created a frenzy on social and mass media.

If you haven’t already done so, you should first read the many excellent reports from those who participated in One Week | One Tool (and watched it from afar). One Week | One Tool was an intense institute sponsored by the National Endowment for the Humanities that strove to convey the Center for History and New Media‘s knowledge about building useful scholarly software. As the name suggests, the participants had to conceive, build, and disseminate their own tool in just one week. To the participants’ tired voices I add a few thoughts from the aftermath.

Less Talk, More Grok

One Week director (and Center for History and New Media managing director) Tom Scheinfeldt and I grew up listening to WAAF in Boston, which had the motto (generally yelled, with reverb) “Less Talk, More Rock!” (This being Boston, it was actually more like “Rahwk!”) For THATCamp I spun that call-to-action into “Less Talk, More Grok!” since it seemed to me that the core of THATCamp is its antagonism toward the deadening lectures and panels of normal academic conferences and its attempt to maximize knowledge transfer with nonhierarchical, highly participatory, hands-on work. THATCamp is exhausting and exhilarating because everyone is engaged and has something to bring to the table.

Not to over-philosophize or over-idealize THATCamp, but for academic doubters I do think the unconference is making an argument about understanding that should be familiar to many humanists: the importance of “tacit knowledge.” For instance, in my field, the history of science, scholars have come to realize in the last few decades that not all of science consists of cerebral equations and concepts that can be taught in a textbook; often science involves techniques and experiential lessons that must be acquired in a hands-on way from someone already capable in that realm.

This is also true for the digital humanities. I joked with emissaries from the National Endowment for the Humanities, which took a huge risk in funding One Week, that our proposal to them was like Jerry Seinfeld’s and George Costanza’s pitch to NBC for a “show about nothing.” I’m sure it was hard for reviewers of our proposal to see its slightly sketchy syllabus. (“You don’t know what will be built ahead of time?!”) But this is the way in which the digital humanities is close to the lab sciences. There can of course be theory and discussion, but there will also have to be a lot of doing if you want to impart full knowledge of the subject. Many times during the week I saw participants and CHNMers convey things to each other—everything from little shortcuts to substantive lessons—that wouldn’t have occurred to us ahead of time, without the team being engaged in actually building something.

MTV Cops

The low point of One Week was undoubtedly my ham-fisted attempt at something of a keynote while the power was out on campus, killing the lights, the internet, and (most seriously) the air conditioning. Following “Less Talk, More Grok,” I never should have done it. But one story I told at the beginning did seem to have modest continuing impact over the week (if frequently as the source of jokes).

Hollywood is famous for great (and laughable) idea pitches—which is why that Seinfeld episode was amusing—but none is perhaps better than Brandon Tartikoff’s brilliantly concise pitch for Miami Vice: “MTV cops.” I’m a firm believer that it’s important to be able to explain a digital tool with something close to the precision of “MTV cops” if you want a significant number of people to use it. Some might object that we academics are smart folks, capable of understanding sophisticated, multivalent tools, but people are busy, and with digital tools there are so many clamoring for attention and each entails a huge commitment (often putting your scholarship into an entirely new system). Scholars, like everyone else, are thus enormously resistant to tools that are hard to grasp. (Case in point: Google Wave.)

I loved the 24 hours of One Week from Monday afternoon to Tuesday afternoon where the group brainstormed potential tools to build and then narrowed them down to “MTV Cops” soundbites. Of course the tools were going to be more complex than these reductionistic soundbites, but those soundbites gave the process some focus and clarity. It also allowed us to ask Twitter followers to vote on general areas of interest (e.g., “Better timelines”) to gauge the market. We tweeted “Blog->Book” for idea #1, which is what became Anthologize.

And what were most of the headlines on launch day? Some variant on the crystal-clear ReadWriteWeb headline: “Scholars Build Blog-to-eBook Tool in One Week.”

Speed Doesn’t Kill

We’ve gotten occasional flak at the Center for History and New Media for some recent efforts that seem more carnival than Ivory Tower, because they seem to throw out the academic emphasis on considered deliberation. (However, it should be noted that we also do many multi-year, sweat-and-tears, time-consuming projects like the National History Education Clearinghouse, putting online the first fifteen years of American history, and creating software used by millions of people.)

But the experience of events like One Week makes me question whether the academic default to deliberation is truly wise. One Weekers could have sat around for a week, a month, a year, and still I suspect that the tool they decided to build was the best choice, with the greatest potential impact. As programmers in the real world know, it’s much better to have partial, working code than to plan everything out in advance. Just by launching Anthologize in alpha and generating all that excitement, the team opened up tremendous reserves of good will, creativity, and problem-solving from users and outside developers. I saw at least ten great new use cases for Anthologize on Twitter in the first day. How are you supposed to come up with those ideas from internal deliberation or extensive planning?

There was also something special about the 24/7 focus the group achieved. The notion that they had to have a tool in one week (crazy on the face of it) demanded that the participants think about that tool all of the time (even in their sleep, evidently). I’ll bet there was the equivalent of several months worth of thought that went on during One Week, and the time limit meant that participants didn’t have the luxury of overthinking certain choices that were, at the end of the day, either not that important or equally good options. Eric Johnson, observing One Week on Twitter, called this the power of intense “singular worlds” to get things done. Paul Graham has similarly noted the importance of environments that keep one idea foremost in your mind.

There are probably many other areas where focus, limits, and, yes, speed might help us in academia. Dissertations, for instance, often unhealthily drag on as doctoral students unwisely aim for perfection, or feel they have to write 300 pages even though their breakthrough thesis is contained in a single chapter. I wonder if a targeted writing blitz like the successful National Novel Writing Month might be ported to the academy.

Start Small, Dream Big

As dissertations become books through a process of polish and further thought, so should digital tools iterate toward perfection from humble beginnings. I’ve written in this space about the Center for History and New Media’s love of Voltaire’s dictum that “the perfect is the enemy of the good [enough],” and we communicated to One Week attendees that it was fine to start with a tool that was doable in a week. The only caveat was that tool should be conceived with such modularity and flexibility that it could grow into something very powerful. The Anthologize launch reminds me of what I said in this space about Zotero on its launch: it was modest, but it had ambition. It was conceived not just as a reference manager but as an extensible platform for research. The few early negative comments about Anthologize similarly misinterpreted it myopically as a PDF-formatter for blogs. Sure, it will do that, as can other services. But like Zotero (and Omeka) Anthologize is a platform that can be broadly extended and repurposed. Most people thankfully got that—it sparked the imagination of many, even though it’s currently just a rough-around-the-edges alpha.

Congrats again to the whole One Week team. Go get some rest.

Standard
Podcasts, Programming

Digital Campus #25 – Get With the Program

We were incredibly lucky to get two of the most sophisticated programming gurus in the humanities, Bill Turkel and Steve Ramsey, on the podcast this week. Bill and Steve are both committed to teaching other humanities scholars how to get started with programming, and they provide a number of terrific points and insights into the process in our feature story. If you’ve ever wanted to pick up programming or know someone who does, it’s definitely worth a listen (or worth passing on the link). We also take a look at the launch of Google App Engine, which raises questions about outsourcing, and myLOC.gov, which raises questions about whether digital collections should have their own personalization tools. [Subscribe to this podcast.]

Standard
Facebook, Programming

The First Principle of Writing Academic Facebook Applications

If you really must line the pockets of Mark Zuckerberg by writing a Facebook application, be sure the application takes advantage of the nature of Facebook. First and foremost, it’s a social networking site, so your application should have some social aspect to it. Many academic Facebook applications are merely search boxes or other non-social search and information services transposed to Facebook (e.g., JSTOR Search or the countless library search widgets). Study Groups, on the other hand, gets it right by emphasizing the networking and collaboration possible within Facebook.

Standard
Books, History, Open Access, Programming

MacEachern and Turkel, The Programming Historian

Bill Turkel, the always creative mind behind Digital History Hacks (logrolling disclosure: Bill is a friend of CHNM, a collaborator on various fronts, and was the thought-provoking guest on Digital Campus #9; still, he deserves the compliments), and his colleague at the University of Western Ontario, Alan MacEachern, are planning to write a book entitled The Programming Historian. Better yet, the book will be open access and hosted on the Network in Canadian History & Environment (NiCHE) site. Bill’s summary of the book on his blog sounds terrific. Can’t wait to read it and use it in my classes.

Standard
Academia, Blogs, Programming

Creating a Blog from Scratch, Part 6: One Year Later

Well, it’s been over a year since I started this blog with a mix of trepidation, ambivalence, and faint praise for the genre—not exactly promising stuff—and so it’s with a mixture of relief and a smidgen of smug self-satisfaction that I’m writing this post. I’m extremely glad that I started this blog last fall and have kept it going. (Evidently the half-life of blogs is about three months, so an active year-old blog is, I suppose, some kind of accomplishment in our attention-deficit age.) I thought it would be a good idea (and several correspondents have prodded me in this direction) to return to my series of posts about starting this blog, “Creating a Blog from Scratch.” (For latecomers, this blog is not powered by Blogger, TypePad, or WordPress, but rather by my own feeble concoction of programming and design.) Over the next few posts I’ll be revisiting some of the decisions I made, highlighting some good things that have happened and some regrets. And at the end of the series I’ll be introducing some adjustments to my blog that I hope will make it better. But first, in something of a sequel to my call to my colleagues to join me in this endeavor, “Professors, Start Your Blogs,” some of the triumphs and tribulations I’ve encountered over the last year.

As the five-part series on creating this blog detailed, I took the masochistic step of writing my own blog software (that’s probably a little too generous; it’s really just a set of simple PHP scripts with a MySQL database) because I wanted to learn about how blogs were put together and see if I agreed with all of the assumptions that went into the genre. That learning experience was helpful (and judging by the email still I get about the series others have found it helpful), but I think I have paid a price in some ways. I will readily admit I’m jealous of other bloggers with their fancy professional blogging software with all of the bells and whistles. Worse, much of the blogosphere is driven by the big mainstream software packages like Blogger, TypePad, and WordPress; having your own blog software means you can’t take advantage of cutting-edge features, like new forms of searching or linking between blogs. But I’m also able to tweak the blog format more readily because I wrote every line of the code that powers this blog.

As I wrote in “Welcome to My Blog,” and as regular readers of this blog know well, I’m not a frequent poster. Sometimes I lament this fact when I see blogs I respect maintain a frantic pace. I’ve written a little over 60 posts (barely better than one per week, although with the Zotero crunch this fall the delays between posts has grown). Many times I’ve felt I had something to post to the blog but just didn’t get around to writing it up. I’m sure other bloggers know that feeling of missed opportunity, which is of course a little silly considering that we’re doing this for free, in our spare time, in most cases without a gun to our heads. But you do begin to feel a responsibility to your audience, and there’s no one to pawn that responsibility off on—you’re simultaneously the head writer, editor, and publisher.

On the other hand, I just did a quick database query and was astonished to discover I’ve written almost 40,000 words in this space (about 160 pages, double-spaced) in the last twelve months. Most posts were around 500-1000 words, with the longest post (Professors, Start Your Blogs) at close to 2000 words. Had you told me that I would write the equivalent of half a book in this space last fall, a) I wouldn’t have believed it, and b) I probably wouldn’t have started this blog.

One of the reasons bloggers feel pressure to post, as I’ve discovered over the last year, is that it’s fairly simple to quantify your audience, often in excruciating detail. As of this writing this blog is ranked 34,181 out of 55 million blogs tracked by Technorati. (This sounds pretty good—the top 1/100th of a percent of all blogs!—until you realize that there are millions of abandoned and spam blogs, and that like most Internet statistics, the rankings are effectively logarithmic rather than linear. That is, the blog that is ranked 34th is probably a thousand times more prominent than mine; on the other hand, this blog is approximately a thousand times more prominent than the poor blogger at 34,000,000.) Because of that kind of quantification, temptations abound for courting popularity in a way that goes against your (or at least my) blog’s mission. I’ve undoubtedly done some posts that were a little unnecessary and gratuitously attention-seeking. For instance, the most-read post over the last year covered the fingers that have crept into Google’s book scanning project, which of course in its silliness got a lot of play on the popular social news site Digg.com and led to thousands of visitors on the day I posted it and an instant tripling of subscribers to this blog’s feed. But I’m proud to say that my subsequent more serious posts immediately alienated the segment of Digg who are overly fond of exclamation points and my numbers quickly returned to a more modest—but I hope better targeted— audience.

Surely the happiest and most unexpected outcome of creating this blog has been the way that it has gotten me in touch with dozens of people whom I probably would not have met otherwise. I meet other professional historians all the time, but the blog has introduced me to brilliant and energetic people in libraries, museums, and archives, literary studies, computer science, people within and outside of academia. Given the balkanization of the academy and its distance from “the real world” I have no idea how I would have met these fascinating people otherwise, or profited from their comments and suggestions. I have never been to a conference where someone has come up to me out of the blue and said, “Hi Dan, I’m so-and-so and I wanted to introduce myself because I loved the article you wrote for such-and-such journal.” Yet I regularly have readers of this blog approach me out of the blue, and in turn I seek out others at meetings merely because of their blogs. These experiences have made me feel that blogging has the potential to revitalize academia by creating more frequent interactions between those in a field and, perhaps more important, between those in different fields. So: thanks for reading the blog and for getting in touch!

Next up in the anniversary edition of “Creating a Blog from Scratch”: it’s taken me a year, but I finally weigh in on tagging.

Part 7: Tags, What Are They Good For?

Standard
Programming, Web Design

Using AJAX Wisely

Since its name was coined on February 18, 2005, AJAX (for Asynchronous JavaScript and XML) has been a much-discussed new web technology. For those not involved in web production, essentially AJAX is a method for dynamically changing parts of a web page without reloading the entire thing; like other dynamic technologies such as Flash, it makes the web browser seem more like a desktop application than a passive window for reading documents. Unlike Flash, however, AJAX applications have generally focused less on interactive graphics (and the often cartoony elements that are now associated with Flash) and more on advanced presentation of text and data, making it attractive to those in academia, libraries, and museums. It’s easy to imagine, for instance, an AJAX-based online library catalog that would allow for an easy refinement of a book search (reordering or adding new possibilities) without a new query submission for each iteration. Despite such promise, or perhaps because of the natural lag between commercial and noncommercial implementations of web technologies, AJAX has not been widely used in academia. That’s fine. Unlike the dot-coms, we should first be asking: What are appropriate uses for AJAX?

As with all technologies, it’s important that AJAX be used in a way that advances the pedagogical, archival, or analytical goals of a project, and with a recognition of its advantages and disadvantages. Such sober assessment is often difficult, however, in the face of hype. Let me put one prick in the AJAX bubble, though, which can help us orient the technology properly: AJAX often scrubs away useful URLs—the critical web addresses students, teachers, and scholars rely on to find and cite web pages and digital objects. For some, the ability to reference documents accurately over time is less of a concern compared to functionality and fancy design—but the lack of URLs for specific “documents” (in the broad sense of the word) on some AJAX sites make it troubling for academic use. Brewster Kahle, the founder of the Internet Archive, surmised that his archive may hold the blog of a future president; if she’s using some of the latest AJAX-based websites, we historians will have a very hard time finding her early thoughts because they won’t have a fixed (and indexable) address.

If not implemented carefully, AJAX (like Flash) could end up like the lamentable 1990s web technology “frames,” which could, for instance, hide the exact address of a scanned medieval folio in a window distinct from the site’s navigation, as in the Koninklijke Bibliotheek’s Medieval Illuminated Manuscripts site—watch how the URL at the top of your browser never changes as you click on different folios, frustrating anyone who wants to reference a specific page. Accurate citations are a core requirement for academic work. We need to be able to reference URLs that aren’t simply a constantly changing, fluid environment.

At the Center for History and New Media, our fantastic web developers Jim Safley and Nate Agrin have implemented AJAX in the right way, I believe, for our Hurricane Digital Memory Bank. In prior projects that gathered recollections and digital objects like photographs for future researchers, such as the September 11 Digital Archive, we worried about making the contribution form too long. We wanted as many people as possible to contribute, but we also knew that itchy web surfers are often put off by multi-page forms to fill out.

Jim and Nate solved this tension brilliantly by making the contribution form for the Hurricane Digital Memory Bank dynamic using AJAX. The form is relatively short but certain sections can change or expand to accept different kinds of objects, text, or geographical information depending on the interactions of the user with the form and accompanying map. It is simultaneously rich and unimposing. When you click on a link that says “Provide More Information” a new section of the form extends beyond the original.

Once a contribution has been accepted, however, it’s assigned a useful, permanent web address that can be referenced easily. Each digital object in the archive, from video to audio to text, has its own unique identifier, which is made explicit at the bottom of the window for that object (e.g., “Cite as: Object #139, Hurricane Digital Memory Bank: Preserving the Stories of Katrina, Rita, and Wilma, 17 November 2005, <http://www.hurricanearchive.org/details.php?id=139>”).

AJAX will likely have a place in academic digital projects—just a more narrow place than out on the wild web.

Standard