Successfully reported this slideshow.

OneWeek|OneTool: An Experiment in Interdisciplinary, Rapid, Open Source Software Development



1 of 15
1 of 15

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

OneWeek|OneTool: An Experiment in Interdisciplinary, Rapid, Open Source Software Development

  1. 1. OneWeek|OneTool An Experiment in Interdisciplinary, Rapid, Open Source Software Development Sponsor/Organizer Center for History and New Media, George Mason University Funder The National Endowment for the Humanities, Office of Digital Humanities Effie Kapsalis Twitter: @digitaleffie
  2. 2. What it is • “Digital Humanities Barn-Raising” • 12 “digital humanists” • 6 days in “isolation”
  3. 3. How it worked: Learning & planning • Sunday night Overview + Get-to-Know-You • Monday morning Brief seminars(Outreach/Open Source Software Development, Digital Humanities) • Monday afternoon Brainstorming • Tuesday morning Team + Twitter voting, teams formed (Development, Outreach, UX) = 2 days
  4. 4. How it worked: Doing/Testing/Refining/Launching Tuesday afternoon - Saturday afternoon = 4 days Work in teams with BRIEF morning/ evening check-ins
  5. 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 & developer community • Make decisions and move on (“Leadership is momentum- making,” Tom Scheinfeldt.) Jeremy Dan Sheila Tom Sharon Trevor Creative Lead Director Director of Public Projects Community Lead Assoc. Dir. of Public Projects Managing Director
  6. 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 Project Mgt/ Copywriter/ Outreach/ Designer Copywriter/ Editor/ Grant Writer Design/Multi media Prod./ WP Site Builder Social Media Guru/ WP Site Builder/Writer Effie Doug Zach Jana
  7. 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 Project Mgt/ I.A I.A/ Java- Ajax Hijinx I.A/ Java- Ajax Hijinx
  8. 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 Metadata Badass Wordpress Guru XSLT Transfixor“Glue” Julie Steve Boone Patrick MJ Patrick R. pdf -Tamer
  9. 9. PLAY VIDEO
  10. 10. Results • 6,000 downloads since Aug. 3, 2010 • Active user & dev. forums • Press • We learned a ton.
  11. 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. 12. What didn’t work • More doing! • More cross-learning • Post-release, we have our day-jobs • Not enough time for UX
  13. 13. Future • 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. 14. How is it different than our environment? • Ratio of Planning vs. Doing is flipped • Minimal risk-taking • We stay in our roles
  15. 15. One Week | One Tool Anthologize Center for History & New Media Twitter #Anthologize Effie Kapsalis / @digitaleffie

Editor's Notes

  • 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
  • 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.

    CV Builder
    Blog to Book
    Timeline builder
    Geo-located collections
    Multimedia collections presentations
    PDF builder
  • 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

    From Boone:

    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.

    From Steve:

    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

    NEH Report:
    CUNY Commons:
    The Atlantic:
    Chronicle Wired Campus:
    BookNet Canada Blog:
    BBC Tech Brief:
    KU Libraries:

  • 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.
  • ×