Believe me, there was intent to blog about One Week | One Tool each day, but the last two blurred together in my mind. As we approached the public launch finale of our software development marathon, every spare brain cell in my possession (a small, finite set) needed to focus on getting me through Friday. So here’s a Sunday morning reflection on learning moments of the week, with a couple of recommendations for our fine host (the Roy Rosenzweig Center for History and New Media), our funder (the National Endowment for the Humanities, Office of Digital Humanities), and anyone else who may consider organizing a similar event in the future.
For those just tuning in, our tale began with twelve librarians, scholars, and students who came together at CHNM to design, build, and launch a digital tool in a 5-day work week. (If you’re counting days, it meant going from “Hi, my name is. . .” on Sunday evening to “Hello world, here’s what we built. . .” on Friday afternoon.) We brainstormed eleven possible tool ideas on Monday, invited public feedback via an online survey that evening, then spent most of Tuesday voting, discussing, and voting several times again to reach a compromise by mid-afternoon. After dividing into smaller work teams (7 on design & development, 3 on outreach, and 2 project managers to keep us all connected), we hunkered down from Tuesday to Friday afternoon to build what eventually became known as Serendip-o-matic. Feed in your sources — an article, song lyrics, or a bibliography — and let our “serendipity machine” do the work of making unexpected connections with major research collections, such as the Digital Public Library of America, Europeana, and Flickr Commons.
My role was to lead the outreach team on crafting stories and supplementary text (press releases, user documentation, the launch broadcast script) to explain our tool to broader audiences and integrate this message with the software products as they were being created by the designers and coders. While I had energy to blog about what I was learning (see prior posts), the latter half of the week was just a blur in my mind, so here’s a three-minute video montage to show you what it felt like from my point of view, followed by some take-away messages and recommendations:
Our lead developer Mia Ridge nailed this idea in her late-night blog post (and continually amazed me with her ability to think simultaneously at the micro and macro levels about our project):
an intense process like this isn’t just about rapid prototyping — it’s also about rapid trust. When there’s too much to do and barely any time for communication, let alone checking someone else’s work, you just to rely on others to get the bits they’re doing right and rely on goodwill to guide the conversation.
This quote meant so much to me that I wrote it into a draft of our Friday press release, and when handing it over to other team members, I trusted that they’d do whatever they thought was best. (Fortunately, this one stayed, not like the other great quotes they cut!) Remember, most our group of twelve began the week as strangers to one another. For example, I had met Brian Croxall, who became our project co-manager, at two prior conferences and was familiar enough to conclude that he was crazy (the good kind). Also, I’ve had the privilege of knowing nineteen-year-old Eli Rose, a Python coder on the development team, for the past nineteen years (as he’s the younger half of our father-son duo). But I didn’t know much about anyone else other than what I had read in online bios and twitter feeds. Even Tom Scheinfeldt, our CHNM leader for this project, stated that he only knew 3 of the 12 when selecting the final candidates.
| If you’ve ever experienced the stress of making fast decisions for a five-day concept-to-launch software development window, there’s quite a bit of fuel that could spark social conflicts. Some of us (me included) have, um, well, let’s just say “intense” personalities and a strong sense that there’s a “right way to do things” most of the time. But this was a dream team without the drama. The past decade of reality TV on major networks has warped our sense of how people work together. If PBS launched a reality show, it could be titled, “One Week | One Tool” (has that soap opera appeal to it), but our positive interactions would probably receive low ratings. |
While there’s no way to magically sprinkle “trust” into a group (please do NOT attempt to build “Trust-o-matic”), future workshop participants would benefit from reading prior members’ reflections on trust-building, to reinforce the importance of the process over the product. What surprised me about One Week | One Tool was that the 2013 participants were not encouraged to read what our counterparts had experienced in 2010, though some of us found links and shared them during the week. Of course, the experiences of any two groups will never be the same. Yet as humanists we need ways to retain and reflect on these stories of the experience, which have more enduring value than the technologies we build. Members of our 2013 team actively tweeted at #owot and/or blogged on personal or group sites. Although our week has ended, we are *thinking* about ways to incorporate these links and tweets into the bottom of our “About” page of our tool, *as soon as we get our act together*. Also, CHNM would be wise to archive posts & tweets on their site to make them easier to find for future readers. And who knows, maybe some future OWOT team will finally build that network analysis tool we talked about, to figure out which half of us voted for it versus those who voted against.
We hit lots of road blocks during our One Week adventure. Some were head-on collisions, and others nearly stalled us out. While several of our teammates tweeted heavily during the week, we all agreed not to announce the project until we launched, so important details and context were not revealed (until others write their “tell-all” posts). Our first challenge arose near the end of day 1, when some skeptics in the group (like me) questioned our decision invite public feedback tool nominations via the IdeaScale site, since we discovered (too late into the process) that it required a login and didn’t display as we had wished on mobile devices. But a bigger problem arose halfway through day 2, when our group wrestled with too many good ideas, then split down the middle (6 versus 6) on whether to build one tool or the other. The graciousness of the group got us through that struggle, but we hit another obstacle on day 3 that could not be solved with kindness: what should we call this thing when, after five hours, no one can come up with a name that excites any of us? These are only three types of problems we faced, and there were many others.
The CHNM staff has years of experience in dealing with these obstacles, and I suppose it was painful for them to watch us stumble through the process. Some seemed to have difficulty letting our group wander down these dead end paths, and out of frustration, were tempted to jump in and tell us what to do. But as participants, we learned so much from our failures, which have to be a real, possible outcome for us and our project. This tension is very familiar to me, as an educator who’s organized several student projects and had difficulty finding the line about holding back too long versus getting too involved. Additionally, all of those tweets we sent about the “big launch” coming on Friday probably pumped up the pressure on our hosts, since failure would reflect poorly on the Center and have longer-lasting effects for the organization than individual participants.
Future OWOT organizers should take a page from CHNM staff, some of the most patient people I’ve met in this field, who listened carefully to long discussions and began their sentences with thoughtful phrasing, such as “Here’s an observation. . .” and “What I’m hearing you say is. . . ” All of us leaned in to listen when our guides spoke this way, since we valued their experience, and it did not come across as an ultimatum from high above. And if that doesn’t work, then perhaps set up a clock with a clear process, something like, “If the group cannot decide by 3pm, then the decision falls to two project co-managers.” In other words, if you find yourself saying, “the process matters more than the product,” then don’t just talk the talk, but walk the walk. . . even if it involves us jumping off a plank.
How on earth did anyone do collaborative work like this without these three magic ingredients: rolling whiteboards, Google Documents, and GitHub? I’ve never been a fan of whiteboards because of their typical fixed position at the front of a classroom, where the usually a dominant leader wields the marker and occupies the space. But CHNM changed my thinking by filling our workspace with many whiteboards on wheels, which makes more group members more likely to step up and scribble their thoughts, then wheel them down the hall to share for a larger group meeting. Also, as mentioned in my day 1 post, I’m also a big fan of using whiteboards and collaborative Google Documents in tandem with one another.
While everyone in our group actively used whiteboards and the Google Document, that wasn’t true for GitHub, the other essential tool for making our tool. I’ve just begun to learn GitHub basics over the past year, and when I need to explain it to non-coders, I usually say something like “it’s the Google Docs for creating code,” though of course it’s more complicated than that. Still, OWOT is an ideal place for people who aren’t already familiar with this tool to learn how it works, to help everyone participate more in the code creation process, even if all you’re doing (like me) is writing user documentation. From the OWOT 2010 interim report I understand that CHNM staff were trying to spend less time “teaching us” during the first days of the workshop. But our 2013 team could have worked better together if all of us had a basic familiarity with how to navigate and make commits to our Serendip-o-matic code repository on GitHub, especially since all of us had editing privileges for the code. One way to teach this would have been for CHNM staff to create a simple 20-minute hands-on session with a practice repository on day 1, and pair up more and less experienced users to revise some text files. Another option would have been for CHNM staff to hold an optional “drop in and learn about GitHub” on Tuesday evening. A third option would have been for our hosts to speak to the group this way: “Here’s an observation: the development team is starting to use GitHub, and not everyone in the group knows how it works. What do you think about that?” As it turns out, we did some informal teaching about GitHub among ourselves, but a bit too late in the process. Since it’s an essential tool for creating our tool (like Google Docs), perhaps make it a larger priority.
On the morning of day 5, someone tweeted that they liked watching #owot, but couldn’t imagine participating due to the lack of coding skills. I tweeted back that what matters is being “code curious,” a phrase I’ve picked up from Patrick Murray-John at CHNM. Some of us on the 2013 team had relatively little coding experience. For example, I do not identify as a coder, but I am curious enough to read through code to try to grasp the basic concepts and occasionally make tweaks to try out, especially on test sites where I can’t break anything. I do not recall writing an entire page of code from scratch, at least not since high school. But I am curious about how this stuff works, and occasionally copy and paste some WordPress plugin pages or Google Maps or CSS style sheets and jiggle around stuff inside to make it work a different way. And I usually have no real idea what I’m doing, yet it’s one good way to learn.
When advertising future workshops like this, CHNM and other organizations would be wise to clearly message what kinds of skills are expected, or better, to encourage people who are “code curious” to step over the line and explore. If it would be helpful for participants to try out key tools ahead of time (a GitHub tutorial, for instance, or maybe something like CodeAcademy), then tell that to applicants during the recruiting stage. Also, after the launch, think about ways that the more experienced coders could show & tell the less experienced ones what the code actually does. While driving away from CHNM, I had the benefit of riding with my son, Eli, and asking him questions as he drove north on the NJ turnpike back to his current apartment in Brooklyn. (My end of the conversation went like “What does this manage.py file do?” and “Where exactly are the APIs in the code?” and “What did you tell me to type into the command line again?” followed by occasional fatherly statements like “Don’t miss our exit!”).
One extra point on this theme (since I’m too lazy to create a separate recommendation): clearly tell applicants how much the stipend is worth (it turned out to be $1,000, plus travel/meal expenses), because that figure really matters to many people who would be ideal team members.
This week I laughed much more often than I usually do at work, and that’s a healthy lesson to incorporate into my teaching and research projects. That feeling emerged from our wonderful group and was expressed in our approach to design. Here’s another favorite quote that had to be cut from the final press release due to length, but I love it too much to let it go, so will conclude with it here:
In designing Serendip-o-matic, the team sought to create a tool that would be both useful and fun. To capture this whimsical quality, the project’s lead graphic designer, Amy Papaelias, imagined this 21st-century digital tool in the style of a 1950s Rube Goldberg machine. “The visual identity is inspired by that moment when a friend recommends an amazing book, or a librarian points to a source you never considered,” she imagined. “That’s the feeling we’re trying to replicate with Serendip-o-matic.”
Hmmm. . . I wonder what will happen if I copy the whole blog post and paste it into Serendip-o-matic? Be curious. Find the unexpected. Try it out.