Perpetual Beta Final
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Perpetual Beta Final



UCSF Library Medical Library Association meeting presentation, May 2008.

UCSF Library Medical Library Association meeting presentation, May 2008.



Total Views
Views on SlideShare
Embed Views



1 Embed 1 1


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 06/07/09

Perpetual Beta Final Presentation Transcript

  • 1. 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
  • 2. 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.
    • A less loaded term is “iterative design”
  • 3. Iterative Design: Decision Continuum May 2008 Iterative Design Potential: Decision Continuum Low High Interdependent services with other libraries (ILL) Established policies at own library (Loan periods) New services (wiki server for the campus)
  • 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
    May 2008