Tag Archives: One Week | One Tool

Help fund a round of Anthologize development

In 2010, I was on the team that built Anthologize, a WordPress plugin for turning your WP content into ebooks. (For more on the project, check out my previous posts on Anthologize.) People continue to be interested in using Anthologize. Just the other day, for example, the nice folks at Profhacker published a post on using Anthologize to build a printable syllabus. When I saw that blog post come through my Twitter stream, my first thought was “Oh boy, here comes another round of bug reports that the team doesn’t have time to address”. Somewhat in jest, I tweeted the following:

I got quite a bit more interest than I expected. In addition to a couple direct inquiries from individuals and organizations, CHNM – where Anthologize was originally prototyped – offered to match, dollar for dollar, any donations to the cause (up to a maximum of $5,000).

So now I’ve got to put my money (or your money!) where my mouth is. I’ve started an Indiegogo campaign where you can pledge any amount to support a round (or more) of development time for Anthologize. Check it out for full details: http://www.indiegogo.com/anthologize. The campaign runs through October 10, and development will start in November.

Please spread the word!

Dude ranchin’ at THATCamp

This year I attended my third THATCamp (at CHNM, anyway – I’ve been to a few others around the country). The first time I went, in 2009, I’d just started working with Matt Gold on the CUNY Academic Commons. I didn’t know many people in the digital humanities community. I was a graduate student in philosophy, accustomed to conferences that were philosophy-ish and graduate-student-esque. THATCamp stood in stark contrast to this background, and as a result was very new and exciting. An event where academics would get together to talk about things that were actually interesting, independently motivated, and new – the very idea of it! I couldn’t help but feel intoxicated by it all.

Fast forward two years. I’m no longer a graduate student. I’m no longer a full-time employee of a university. I’m no longer a stranger to digital humanities and the DH community. And I’m no longer a n00b. Unsurprisingly, this perspective changes the way I experience THATCamp.

For one thing, the “more hack, less yak” theme which prevails at THATCamp does not have revelatory ring it once had. I build stuff for a living. All I ever do is hack. As a result, I actually look forward to the occasional yak. I recognize that the “less yak” mantra arises out of frustration about the futility of “mere” talk, and represents a railing against the tendency of academic activity to consist of little more than such talk. In this sense, I should probably be grateful that I’m no longer in a career where I feel trapped under a pile of words. And, in fact, I do feel pretty happy about it, especially after all these years. But my recent career changes do mean that I don’t get the same gee-whiz-I’m-so-excited-we’re-actually-doing-something rush out of THATCamp that many others (justifiably) do.

On a related note, I’m less excited about geekery these days than I was before I was a professional geek. (I’m being intentionally narrow in my use of the word ‘geek’ to mean ‘someone who codes’. The word isn’t particularly important; swap it out for ‘coder’ if you want.) THATCamp can be like a dude ranch. The city slickers come to the country for the weekend, ride a horse, throw a lasso, eat some beans-n-bacon, and say “Gee, isn’t the country life great?” What the dudes don’t realize is that being a rancher means doing stuff like shoveling a lot of cow shit. In the same way, coming to THATCamp and learning a bit about Greasemonkey scripts or the Google Maps API or WordPress themes can be a rush – after all, those things are all really cool. But it’s also a kind of cartoonish picture of what it’s like to write code all day long, which is really more about shoveling the cow shit of bug tickets than about whizbang jQuery effects and singing campfire tunes.

Of course, I’m under no illusion that THATCamp sessions are meant to be introductions to the Real Cowboy Life, and I’m certain that the attendees of such sessions aren’t under any such illusions either. And I should be clear that I don’t want to be a spoilsport. For the most part, I think it’s genuinely good for people to learn how to write code (where writing code should be understood as standing in for a whole bunch of related phenomena). For one thing, it’s undoubtably good for people to engage critically with the tools that mediate so much of our lives. Moreover, people like Patrick Murray-John have been making some interesting, if tentative, arguments for the ways in which the modes of thinking exemplified by coding might interesect with, and augment, the modes typified by traditional academic work. Plus, learning to code is just plain fun. So it’s great that people who wouldn’t otherwise have the chance to learn something about code have THATCamp as an outlet. I’m just no longer one of those people, I guess.

I also would probably enjoy THATCamp more if I broke outside of my own comfort zone. During this year’s event, I skipped a couple sessions to write Anthologize code with a few members of the One Week | One Tool gang. It was a blast, and a great way to spend time with some friends who are otherwise scattered throughout the country. Yet, I might have gotten more out of the event if I’d attended more sessions, especially sessions whose subjects were a bit outside of my normal area of specialization. But at an event like THATCamp Prime, which has the usual round-up of DH A-listers talking about tried-and-true topics, it becomes increasingly difficult to find those truly new conversations.

I don’t really mean these observations to be wholesale critiques of the THATCamp setup. Many of the reactions that I saw to this year’s event – blog posts, tweets, personal conversations, and the excited looks on people’s faces – suggested that the newcomers felt the same sense of giddiness that characterized my own first THATCamp experience. But I do think it’s interesting how my giddiness (or lack thereof) is so hugely shaped by changes in my own standing over the years. Maybe next year I’ll make more of a concentrated effort to carve out a spot at THATCamp for folks with my particular set of interests and strengths.

Introducing Anthologize, a new WordPress plugin

The moment has arrived!



The product of One Week | One Tool, a one week digital humanities tool barn raising hosted by CHNM and sponsored by the NEH Office of Digital Humanities, is Anthologize. Anthologize is a WordPress plugin that lets you collect and curate content, organize and edit it into a form that works for you, and publish it in one of a number of ebook formats.

As I said in my last post, I was the lead developer for Anthologize. This stemmed from the fact that, for reasons of market penetration and ease of use, we’d chosen WordPress as a platform, and I was “the WordPress guy”. As such, I was the natural person to oversee the various parts of the development process, and to make sure that they fit together in a neat WordPress plugin package. It was an incredible and humbling experience to work with a group of developers who were, to a person, more talented and experienced than I am.

Anthologize PDF output

Anthologize PDF output

Today, the plugin is shipping with four different formats for exporting: PDF, ePub, RTF, and a modified version of TEI that leaves most content in HTML form. None of these export processes are perfect. Some require that certain libraries be installed on your server; some do not offer the kind of layout flexibility that we like; some are not great at text encoding; etc. This release is truly an alpha, a proof-of-concept. The goal is to show not only what a group of devoted individuals can conceive and develop in six short days, but also to provide the framework for further development in the world of independent authorship, publishing, and distribution.

As such, the plugin is designed, and will continue to be developed, with an eye toward maximum flexibility and modularity. Content can be created in WordPress or pulled in by RSS feeds, providing for greater choice of authoring platform. Export formats are generated by translators that work not with native WordPress data, but with an intermediary layer structured with TEI metadata markup. That means that you don’t have to know anything about WordPress to build a new export translator for yourself – you only have to know some PHP and XSLT. And we’re working on expanding Anthologize’s action and filter hooks to allow for true pluggability in the manner of WordPress itself.

I’m hoping that Anthologize will be a useful tool that draws development interest from folks who might not otherwise be interested in WordPress or web development, especially those who are working in the academic, cultural heritage, and digital humanities worlds. Get involved by checking out our Github repository at http://github.com/chnm/anthologize, our development list at http://groups.google.com/group/anthologize-dev, or stop in and chat with the dev team at #oneweek or #anthologize-dev on freenode.


Anthologize allows you to collect, organize, edit, and export your WordPress content into a book.



Anthologize is populated with the content of your blog – the posts and pages that you’ve written in WordPress. You can also use Anthologize’s content importer to get content from RSS feeds. Once you’ve got your content, organize it into Parts or Chapters using the slick drag-and-drop interface. Merge, append, rearrange, rewrite, and when you’re ready, hit the export button. Anthologize currently supports a number of popular e-book formats for export, including PDF, ePub, RTF, and a modified version of TEI.

The plugin was originally developed as part of the One Week | One Tool project. I am the lead developer, but the team is really 15-18 members strong.

For more information, see the plugin homepage at anthologize.org.


  1. Upload the bp-external-activity directory to your WP plugins folder and activate
  2. Visit Dashboard > Anthologize > New Project to get started

Anthologize has been downloaded 20,844 times.

Version history

0.4-alpha – August 10, 2010
Better PHP error handling for increased export reliability
Better character encoding in output formats
Better image handling in PHP export
Required compression libraries for ePub are now bundled with Anthologize
Project organizer screen improvements: Anthologize remembers your last used filter when you return to the page; a bug related to item ordering was fixed; “Are you sure?” message added to the Delete Project button; better handling of item names with colons and other characters
Export screen improvements: project metadata (such as copyright information) is saved; selecting projects from the dropdown automatically pulls in saved metadata
Namespaced WordPress post type names to ensure compatibility with other plugins
Anthologize content is now set to ‘draft’ by default, keeping it out of WordPress searches and reducing conflict with plugins hooking to publish_post
Frontmatter added to PDF export
Improved TEI output
0.3-alpha – August 3, 2010
Initial release

Unexpected leadership: preliminary thoughts on One Week | One Tool

One Week | One Tool just finished, and it proved to be among the most challenging and most rewarding weeks of my professional life. I have a feeling that I’ll need a few go-rounds to really decompress – if for no other reason than that the tool we produced isn’t being announced until Tuesday, so I can’t talk details – but I thought it’d be worthwhile to jot down some thoughts while they’re still fresh.

There’s much to blog about regarding my experience at One Week, much of which I’ll be able to divulge more fully after the veil of secrecy has been officially lifted. (Yikes! So secretive.) One of the things I can talk about now is the workflow of the team over the course of the week, something Jana has already discussed nicely in her blog.

Whiteboard spoilers!

Whiteboard spoilers!

We arrived at CHNM with no idea what we were going to build over the course of the week. Monday was spent getting to know each other, hearing from the CHNMers about they develop and sustain open source software, and brainstorming ideas for our own project. By the end of the day Tuesday, the project had been decided and teams had been divided up. I didn’t sleep very well that night, both from excitement and from nerves: the tool we’d decided to build would rely on a set of technologies that would make me the de facto lead programmer.

And therein lies the first remarkable thing about the event. By many objective accounts – breadth and depth of knowledge and experience – I was, at best, the fifth or sixth most talented developer in the group. (Not trying to be overly humble here: one look at the One Week “People” page and you can see that the deck was stacked with incredible talent, folks with whom I’m happy to be in even the same ballpark.) Differently-focused projects require different kinds of talent, and it so happened that this very focused project required just the sort of skills that I possess. So the first lesson I take away from One Week is that leadership doesn’t necessarily follow, or require, the greatest technical skill or experience. It might be that the notion of “best leader” reduces to “best leader right now”, which is to say that “best” is highly relative to particular needs and circumstances. It’s a realization that highlights how leadership roles are not (or maybe should not) be merit badges gifted to those who have “earned” them, but instead are necessary aspects of a structure – like the One Week crew – aiming to acheive an independent goal.

My second One Week lesson is closely related to the first: leadership doesn’t work without humility and trust. The way we built our tool was like digging the Chunnel: developers at home with one part of the tool’s functionality (like the British on British soil!) tunnelled toward developers who were digging from the other direction. I was in charge of making sure that the several tunnels met in the middle to make for a navigable whole. But, as you’d expect, there’s no way that one person (even one as dashing and wonderful as I am) could really know what was happening in all parts of the project at the same time. There were simply too many technical details to keep track of. Making sure that the tunnel got built, and our code got merged, meant putting a good deal of trust in the diggers, and accepting – even embracing – those moments when their work was beyond my ability to understand technically.

All this is to say nothing of the equally crucial folks who were not writing code, but we doing what we called “user experience” and “outreach”. In those cases even more trust was required: the dev team trusts the outreach team not to write checks that the code can’t cash; the UX team trusts the dev team to remain true to the needs of the end user; and so forth. Here too, in a less technical but no less accurate way, we were digging a tunnel from opposite directions. The outreach and UX teams were developing an increasingly detailed vision of what the tool needed to do, and the dev team was cranking out code that would fulfill that vision. There was a magical moment when, on Thursday afternoon, Jason and Scott from the UX team – coders by trade who had found themselves in a non-coding position in our particular development project – merged in a totally organic way with the dev team to flesh out some of the UX that they’d been conceptualizing for the previous two days. That too demonstrated a kind of trust between One Weekers, where team boundaries were mutable when circumstances required it, and no one blinked an eye when two more people started committing code to the repo.

Much more to come, I’m sure.