OneWeek|OneTool: An Experiment in Interdisciplinary, Rapid, Open Source Software Development
•Télécharger en tant que PPTX, PDF•
1 j'aime•1,119 vues
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à OneWeek|OneTool: An Experiment in Interdisciplinary, Rapid, Open Source Software Development
Similaire à OneWeek|OneTool: An Experiment in Interdisciplinary, Rapid, Open Source Software Development (20)
Plus de Effie Kapsalis
Plus de Effie Kapsalis (14)
Dernier
Dernier (20)
OneWeek|OneTool: An Experiment in Interdisciplinary, Rapid, Open Source Software Development
- 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 digitaleffie@gmail.com Twitter: @digitaleffie
- 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 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. How it worked: Doing/Testing/Refining/Launching Tuesday afternoon - Saturday afternoon = 4 days Work in teams with BRIEF morning/ evening check-ins
- 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. 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. 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. 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. PLAY VIDEO
- 10. Results • 6,000 downloads since Aug. 3, 2010 • Active user & dev. forums • Press • We learned a ton.
- 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 day-jobs • Not enough time for UX
- 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. 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/ Anthologize http://anthologize.org Center for History & New Media http://chnm.gmu.edu/ Twitter #Anthologize Effie Kapsalis digitaleffie@gmail.com / @digitaleffie
Notes de l'éditeur
- 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. 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 CHNM PARTICIPANTS 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: http://www.neh.gov/ODH/ODHUpdate/tabid/108/EntryId/140/Report-from-ODH-Institute-One-Week-One-Tool.aspx 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/ Musematic: http://musematic.net/2010/08/03/anthologize/ Read-Write-Web: http://www.readwriteweb.com/archives/scholars_build_blog-to-ebook_tool_in_one_week.php 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 Snarkmarket: http://snarkmarket.com/2010/5979 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.