Treating Users as CoDevelopers: One Library's Experience with Perpetual Beta
15
Perpetual Beta: Treating Users As Co-Developers Marcus Banks, Sadie Honey, and Julia Kochi UC San Francisco Library and CKM Medical Library Association Annual Meeting, Chicago May 2008
-
Upload
mab992 -
Category
Health & Medicine
-
view
716 -
download
0
description
UCSF Library Medical Library Association meeting presentation, May 2008.
Transcript of Treating Users as CoDevelopers: One Library's Experience with Perpetual Beta
Perpetual Beta: Treating Users As Co-DevelopersMarcus Banks, Sadie Honey, and Julia KochiUC San Francisco Library and CKM Medical Library Association Annual Meeting, ChicagoMay 2008
What Is Perpetual Beta?
“The open source dictum, ‘release early and release often’ in fact has morphed into an even more radical position, ‘the perpetual beta,’ in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis.”
Tim O'Reilly. What Is Web 2.0., Page 4. End of the Software Release Cycle. http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=4
A less loaded term is “iterative design”
May 2008 3
Iterative Design: Decision Continuum
Iterative Design Potential: Decision Continuum
Low HighInterdependent services with other libraries (ILL)
Established policies at own library (Loan periods)
New services (wiki server for the campus)
May 2008 4
Three Projects, One Concept
Federated / Metasearch Question Tracking System User Toolbars
All released before they were perfect Plan is/was to iterate to improve the product Lessons we have learned along the way…
May 2008 5
Federated / Metasearch
May 2008 6
Question Tracking System
May 2008 7
User Toolbars
May 2008 8
Three Projects, One Concept
Lessons we have learned along the way…
May 2008 9
Set Expectations
Be clear (to yourself as well) that this is an experiment
Be clear about whose problem you are attempting to solve Those impacted by the change may not be
the beneficiaries Define success (and failure) Be clear that you will significantly change
course, or abandon a project altogether if warranted
May 2008 10
Question Authority
Most people don’t look at an interface and see the ways that it can be improved
You have to train your users (including staff members) to constructively criticize the product
You have to train yourself to hear and respond appropriately to the criticism
May 2008 11
Be Realistic
Establish a realistic pace for change—to yourself and users
Be aware of staff views re: rate of change Exhausting if constant; need times of stasis
Limited resources mean a slower rate of change
May 2008 12
Get Feedback
Determine how you will get feedback before the project begins
It will not come without effort “Watch” usage
Are you able to track user statistics?
May 2008 13
Consider Interdependencies
Cascade effect in which one change can affect many other services Handle with care
Rate of iteration will be slower with interdependent projects
May 2008 14
Pull the Plug
Be willing to accept a project isn’t worth continuing
Letting something drag on indefinitely is demoralizing
Define success and/or failure at the beginning of the project
Be aware that staff may feel like they have “failed” if a project gets cut
May 2008 15
Rinse, Repeat
Hold a post-mortem, or “after party” Reviewing what went wrong is not a personal
criticism There is a lot to learn from a “failed” project
Hard but essential step Try and try again
Act on what you’ve learned
