OneWeek|OneTool: An Experiment in Interdisciplinary, Rapid, Open Source Software Development
An Experiment in Interdisciplinary, Rapid,
Open Source Software Development
Center for History and New Media, George Mason
The National Endowment for the Humanities,
Office of Digital Humanities
2. What it is
• “Digital Humanities Barn-Raising”
• 12 “digital humanists”
• 6 days in “isolation”
3. How it worked: Learning & planning
• Sunday night
Overview + Get-to-Know-You
• Monday morning
Source Software Development,
• Monday afternoon
• Tuesday morning
Team + Twitter voting, teams formed
(Development, Outreach, UX)
= 2 days
5. Guiding Principles: Center for History
& New Media
• Build something that will be used
• Keep tool simple & focused
• Outreach and marketing are important for building user &
• Make decisions and move on (“Leadership is momentum-
making,” Tom Scheinfeldt.)
Jeremy Dan Sheila Tom Sharon Trevor
6. Team Outreach Approach/Reflections
• Illustrate a compelling story for potential
users/developers-why should they care?
• Create buzz where users are
• Divide & conquer/Trust
• Outreach doesn’t stop at release
Guru/ WP Site
Effie Doug Zach Jana
7. Team UX Approach/Reflections
•ID’d real-world use case scenarios and built use cases
•Evaluated similar projects.
•The diversity of backgrounds in the OWOT crew was a benefit
•2 days in, Jason & Scott moved to the dev team to pitch in on
some UI/AJAX development. Kathie worked iteratively with the
dev team to build wireframes and UI documentation.
Kathie Jason Scott
8. Team Dev. Approach
• Forced parallel development
• Constant communication and trust
• Good-enough prototyping
• Decide and go
• Design software around technical strengths as well
as our hypothetical users’ needs
Patrick MJ Patrick R.
11. What worked
• Bringing together a group of do-ers
• Ratio of doing vs. planning
• Quick timeframe kept egos out
• Diversity of skills on one team
• Living & working together
• Common goal
12. What didn’t work
• More doing!
• More cross-learning
• Post-release, we have our
• Not enough time for UX
• Continue to develop tool – Recent 0.5
alpha release (10/2010)
• Continue dissemination of software
with online outreach and conferences
• Apply for more grants
14. How is it different than our environment?
• Ratio of Planning vs. Doing is flipped
• Minimal risk-taking
• We stay in our roles
15. One Week | One Tool http://oneweekonetool.org/
Center for History & New Media http://chnm.gmu.edu/
Effie Kapsalis firstname.lastname@example.org / @digitaleffie
Skills and effort no one member of the community alone could possess. Internet entrepreneurs have likewise joined forces for crash “startup” or “blitz weekends” that bring diverse groups of developers, designers, marketers, and financiers together to launch a new technology company in the span of just two days.
They were also relatively diverse in terms of gender (4 women, 8 men), seniority (ranging from a recently graduated college student to a tenured faculty member), and disciplinary backgrounds (designers, developers, scholars, project managers, outreach specialists, and other non-technical participants)
Photo credit: Barn raising in South Dakota in 1910, Central Pacific Railroad Photographic History Museum http://www.latinamericanstudies.org/immigrant-laborers.htm
From Tom, “Jeremy offered a practical introduction to software development best practices and tools. Trevor described the range of outreach strategies we have employed on projects like Zotero, Omeka, and the National History Education Clearinghouse. Dan provided the view from 30,000 feet with thoughts on the state of the art and near future of digital humanities software development. I kicked things off on Sunday with a brief introduction to CHNM and our tool building philosophy.”
VOTING: Well over 50 outside observers recorded their preferences. Taking this outside feedback into account, the group conducted two rounds of voting of its own, making a final consensus decision by mid-afternoon on Tuesday.
Blog to Book
Multimedia collections presentations
That’s twice as much time doing as planning.
From Brett Bobley, “What made this institute so compelling was the format. Rather than a more typical series of lectures, CHNM went with a “learn by doing” format.” They funded something where they had no idea what the outcome would be.
Check-ins: report progress, next steps, make any changes needed
“At CHNM we judge our tools by one key metric above all others: use. Successful tools are tools that are used,” Tom Scheinfeldt
“Building a user community is the first prerequisite to building a successful open source software project,” Tom Scheinfeldt
“Related to building a user community is building an open source developer community…a developer community needs open communication channels—an active IRC channel and listserv, for example—,” Tom Scheinfeldt
Jeremy Boggs, Creative Lead
Sheila Brennan, Associate Director of Public Projects
Dan Cohen, Director
Sharon Leon, Director of Public Projects
Trevor Owens, community lead for the Zotero
Tom Scheinfeldt, Managing Director
Effie Kapsalis, Head of Web & New Media, Smithsonian Institution Archives
Douglas Knox, Director of publication and digital initiatives, Newberry Library
Zachary McClune, Recent graduate in Modern Culture & Media at Brown University
Jana Remy, Director of Instructional Technology at Chapman University
Scripted compelling story
Named it and claimed it
Designed/Developed logo, swag, website
Gathered potential users & developers for post-release
Outreach (Press, social media, etc)
Illustrate the compelling story (who are the users, how people will find what you’re building useful, what are all the ways they could use it)
Find where your users are, what’s important to them, and encourage them to contribute
Build presences in all these spaces and interact
Create homebase to point users to all the resources and places to interact
Slow leak information about tool with photos, videos, behind-the scenes action, etc.
Outreach is ongoing Continue to monitor, guide people to user forums, announce changes, point out members of the community.
Kathy Gossett- Assistant Professor of Writing, Rhetoric & New Media at Old Dominion University
Jason Casden - Digital Technologies Development Librarian at NCSU Libraries
Scott Hanrath - Web Services Manager at the University of Kansas Libraries
It’s nice to have a little evidence. Now that we had some pretty consistent data affirming (but occasionally contradicting) the project assumptions, we had some rapid and productive discussions with the dev team, led by Julie.
(3 or 4 interviews and reviews of similar products in a day and half, followed by UX team getting absorbed into the dev team to do coding and UI documentation; this is very much in keeping with the forced parallel work going on with the dev team
Julie Meloni - Postdoctoral fellow in Information Management at the Electronic Textual Cultures Lab at University of Victoria
Steve Ramsey - Associate Professor English and a Fellow at the Center for Digital Research in the Humanities at the University of Nebraska-Lincoln
Boone Gorges - Lead Developer behind the CUNY Academic Commons, PhD candidate in Philosophy
Patrick MJ - Former medievalist, now doing digital academic stuff at University of Mary Washington
Patrick Rashleigh - Faculty Technology Liaison for the Humanities" at Wheaton College
Forced parallel development – different people working on different parts of the software at the same time, often without being able to test the connections. Related: this kind of parallel development necessitated a special kind of constant communication and trust, so we could be sure that the pieces of the dev puzzle would fit when we finally went to put them together. * Good-enough prototyping – With a radically tightened development timeline, we were forced to get parts of the software working and then move on without indulging our natural perfectionism by tweaking and refactoring. * Designing software around our technical strengths as well as our hypothetical users’ needs – The compressed nature of the initial development meant that we needed to build the spec sheet around the things that the members of our dev team could actually do rather than the features we wanted a perfect product to have. Patrick MJ was a metadata bad ass, I knew WordPress, PR knew XSLT, etc – all of which drove us to make certain decisions about how the software should look.
Another thing on the dev side . . .
Every project I've ever worked on has involved a series of spirited debates about technical matters. OWOT was no different. But because of the time constraints, every debate had to end with a decision (and end relatively quickly). So you might lose an argument or win one, but you couldn't spend all day arguing the point, and in the end, everyone had to pick one and say, "Okay, let's just do it." I've been on some projects where such debates became interminable -- always shelved for the next meeting, because no one really wanted to make a decision (even with an designated manager).
The OWOT model was liberating. "X? No, Y! No, Z. Okay, X. Let's go." I see no reason why it shouldn't be the spirit that animates the (often necessary) debates that happen on ordinary projects with less onerous time constraints.
Open source WP plugin for transforming online content into books (eBook& print)
Established an open code repository, a ticketing and bug tracking system, and a set of open source community development channels; and mounted an outreach and marketing campaign that consisted of an original name, logo, and website, as well as promotional bookmarks and stickers, a CafePress storefront, a formal press release, a media contact sheet, a set of public use cases, an FAQ page, and other end-user support channels.
Press (Atlantic Monthly, Chronicle of Higher Education, BBC, Read/Write/Web, etc)
eBook, PDF, TEI, HTML
CUNY Commons: http://news.commons.gc.cuny.edu/2010/08/03/one-week-one-tool-the-reveal/
The Atlantic: http://www.theatlantic.com/science/archive/2010/08/academics-build-blog-to-ebook-publishing-tool-in-one-week/60852/
Chronicle Wired Campus: http://chronicle.com/blogPost/Digital-Humanists-Unveil-New/25966/
BookNet Canada Blog: http://booknetcanada.ca/index.php?option=com_wordpress&p=1787&Itemid=319
BBC Tech Brief: http://www.bbc.co.uk/blogs/seealso/2010/08/tech_brief_61.html
KU Libraries: http://www.news.ku.edu/2010/august/10/hanrath.shtml
From Tom Scheinfeldt, “As it turns out, we have ended up with something even more interesting because of that diversity of skills. “
Also from Tom – “Most participants responded that they learned about collaboration, leadership, and team building. Doug Knox pointed to the "self-taught lessons in group dynamics for a team of pragmatic collaborative autodidacts" he took from One Week | One Tool. As one participant responded, those lessons included "the kind of flexibility, trust, humility, and perseverance that is necessary to take on a relatively big project in a short period of time." In a post titled "Unexpected leadership," Boone Gorges echoed these lessons, writing "leadership doesn’t work without humility and trust." Effie Kapsalis described that same lesson plainly on the Smithsonian 2.0 blog: "Trust. Period."
UX was perhaps the most difficult of the three team areas to fit into the OWOT model
Some of the limitations of trying to do UX work in one week were more than offset by the immediate feedback we received by pushing out our project quickly and to a wide audience
We can’t do anything if it doesn’t have a clear outcome from the beginning.