Final Reflections from One Week One Tool: The Blur of Days 4-5

Posted on

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.

Click the icon to try it out!

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 on day 1, day 2, and day 3, 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:

Learning take-away #1: It’s all about building trust, ASAP
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.

Recommendation #1: 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.

Learning take-away #2: Failure always needs to be an option
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.

Recommendation #2: 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.

Learning take-away #3: The tools to create our tool
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.

Recommendation #3: 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.

Learning take-away #4: Encourage code curiosity
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.

Recommendation #4: 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 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.

Learning take-away #5: Keep it fun
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.

Metaphorical learning moments at One Week One Tool, Day 3

Posted on
Exasperated team member Amrys Williams, OWOT Day 3, by Brian Croxall

My short post on a lesson learned yesterday at One Week One Tool, the half-crazed can-we-build-it digital humanities camp at the Center for History and New Media. If you lock a bunch of very talented scholars, designers, librarians, and programmers into a room and ask them to come up with catchy names for an innovative software product (and half or more have advanced degrees in literary studies), then you are very likely to spend about five hours considering over 120 nominations. Also, you may devote considerable time to contemplating metaphorical conflicts between titles, taglines, and iconography such as: Do garden seeds experience Gestalt insights? Would a homey American potluck dinner make sense with British-style sorcery? Can a martini also be a bikini? Do mustaches look better on hippos or ostriches? (I’m not making this up, and would link to my online notes if this wasn’t a top-secret project. Wait for the big launch on Friday.) Moreover, if the name-game brainstorming session runs long enough (without participants strangling one another), you’ll eventually discover the magical 121st name that brings joy to everyone’s faces (but only if the domain names are still available). Finally, when the process draws to a close and everyone congratulates one another on our so-called collective brilliance, it’s slightly embarrassing to realize that the 121st title was simply a clever variation of the 1st one at the top of the list, which had been staring us in the face for the past five hours. Sigh. . .

My Peggy Olson learning moment at One Week One Tool, Day 2

Posted on
Peggy Olson from "Mad Men" (via WikiMedia)

Tuesday was the second day of One Week One Tool, the Can-We-Build-It? digital humanities workshop hosted by the Center for History and New Media and funded by NEH. If you haven’t already done so, read two wonderful posts on the idea winnowing and early tool design stages by lead developer Mia Ridge and co-project manager Brian Croxall, for a broader overview of what happened, at least, the parts we can tell you before Friday’s big unveil. This post tells a more personal story about my “Peggy Olson” learning moment. After our finally compromised on one of the 11 nominated tool concepts, we divided into work teams and the outreach group (Amrys Williams, Ray Palin, and me) were assigned the task of scripting a one-paragraph pitch for that-thing-we’re-building-before-anyone-really-knows-what-we’re-doing. You know, that kind of amorphous writing assignment that digital humanities faculty types assign to their students. Due to the unavoidable chaos of our five-day design and production schedule, time slipped away to the point that we had about only 9 minutes to draft something to share at the larger group meeting. We didn’t have a name for the tool yet, nor did anyone really know exactly how it would work, so writing a rich description, technical or otherwise, wasn’t possible. Instead, our pitch focused on how people would feel when using our tool and the emotional joys it would bring to their lives. In other words, watching five seasons worth of Mad Men, the television series on the 1960s advertising industry, finally paid off.

During our presentation to the group, Tom Scheinfeldt quipped on Twitter:

But standing nervously in front of this very talented group of coders, making our team’s pitch while wearing my t-shirt and shorts, felt nothing like the cool and confident Don Draper. Instead, I was Peggy Olson in season 2, stepping into this unfamiliar role of copywriter, somewhat unsure of what’s expected, not quite confident, and generally mesmerized by the mysterious process of collaboratively designing complex software in a very short period of time. That’s what the learning experience felt like for me yesterday. While I can’t share details about our product with you now (Don would kill me!), stay tuned for the next episode.

PS: One of my favorite photos this week shows the design/development team working late in a hotel room, after they were kicked out of the bar for ordering a pizza from an outside establishment. I’m the elder half of a father-and-son duo here at One Week One Tool, and it feels absolutely wonderful to watch my kid working with the other coders.

The One Week One Tool design/development team working late (Brian Croxall)

Learning Moments at One Week One Tool 2013, Day 1

Posted on

This week I’m one of twelve participants at One Week One Tool, a National Endowment for the Humanities summer institute hosted by the Center for History and New Media, where we have five days to discuss, design, and build a software tool for the digital humanities. Last night we publicly released a list of possible tools we’re considering and asked for votes and commentary. You also can follow our progress (and roadblocks) via Twitter #owot.

Since our fearless leader, Tom Scheinfeldt, reminds us that what matters most is the learning process, not the technology project we’re scrambling to build, I’ll try posting short reflections on selected learning moments that stand out in my mind. (But definitely check out how other participants chronicle their experience, such as teammates Brian Croxall and Amanda Visconti.) As an educational historian, I teach my Trinity College students about John Dewey’s project-based social learning philosophy and try to practice elements of it in my introductory urban education class (with participant-observer placements in Hartford public school classrooms) and my Cities Suburbs & Schools seminar (through team research projects with community partners). What makes this week different is that I’m one of the regular learners — not the instructional leader — and digital tool creation is outside my comfort zone, as most participants have more coding and design experience than me. While I can hack my way around some WordPress PHP and Google Maps JavaScript, most of what I’ve do is simply modifying open-source code that other people have already written. Creating a new tool from the ground-up is an entirely new — and somewhat frightening — experience for me. Two moments that have stood out for me, so far:

Learning point #1: From open brainstorming to more focused thinking
While this may seem like a small point to some, I learned a great deal about how groups can make progress on brainstorming ideas. At the beginning of our Monday afternoon session, we launched into a free-for-all discussion to generate possible tools on the white board, in somewhat random fashion, as shown below.

The first general brainstorming whiteboard at One Week One Tool 2013 (by Brian Croxall)

To move our discussion one step further, our group followed Tom’s advice to focus on who we are building for and why. With participant Meghan Frazer leading us, we started filling out a grid with these categories — tool, audience, and need — by refining the content from the first whiteboard, as shown below.

Filtering brainstormed ideas by tool, audience, and need at One Week One Tool, 2013

Learning point #2: From group idea talk to collaborative text
Anyone who has worked with me knows that I favor making discussions more concrete by helping the group to capture its thinking in writing. For #owot 2013, we created a Google Document and restricted the link to our group, then expanded descriptions from the tool idea grid. The collaborative document also allowed individuals to refine the text while the larger group continued to discuss topics, while generating a semi-permanent archive of our thinking process. Most important, all of us worked together to craft the wording that we released when we requested public feedback for our tool nominations (see link, but voting has closed).