Your SlideShare is downloading. ×
0
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The case for an agile and user driven approach to digital preservation development (Or why user driven hackathons kick ass)

130

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
130
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The case for an agile and user drivenapproach to digital preservationdevelopment(Or why user driven hackathons kick ass)Paul WheatleySPRUCE Project ManagerUniversity of LeedsTwitter: @prwheatleyhttp://openplanetsfoundation.org/blogs/paul
  • 2. What I’m going to talk about...All about SPRUCE Mashups:http://bit.ly/spruce-mashupusers/practitioners/problem ownersdevelopers/techs/hackers/solution providersImage:DimaYagnyuk,fromTheNounProject
  • 3. What’s the problem with developing DP tools?Rants and examples, just in case you don’t believe me:http://openplanetsfoundation.org/blogs/paul• Great solution to thewrong problem• Even with a good result,no users = no feedback,no bug reports: tool dies• Reinventing the wheel,getting nowhere• And lots more...Without strong user focus, awareness and communications...
  • 4. Putting the user in the driving seat• working with specific,concrete user challenges• actual user data• make the user own theproblem• separate problem ownerand solution provider roles• engage with problem ownerat *each* iteration ofdevelopmentImage:P.J.Onori,fromTheNounProject
  • 5. Sharing and communications• Capture and *share* therequirements/challenges/use cases.–Eg. Datasets, Issues, Solutions,http://bit.ly/spruce-results• Publicise intention to pursue aparticular approach, to validate it• Share the data–Eg. OPF Format Corpus on Githubhttps://github.com/openplanets/format-corpus• Make results easy for others to pickup and reuse: atomic tools,packaging, simple interface...
  • 6. Example: Broken JP2s and Jpylyzer• More information:–http://openplanetsfoundation.org/software/jpylyzer• Also see page on JP2 preservation risks:–http://wiki.opf-labs.org/display/TR/JP2Before and after:Broken JP2exampleJpylyzer waswritten by@bitsgalore of the@scapeproject
  • 7. Blatant plug...OPF Mashup, Disk images, emulation and forensicsChapel Hill, North Carolina, 3rd - 5th June 2013More information and registration:http://bit.ly/dft-ch
  • 8. Mashup Manifesto (SPRUCE)• Make it practitioner/user led– Solve concrete problems• Re-use, dont re-invent the wheel– Most problems have already been solved, although often not by this community– Re-use existing code where possible• Keep it small, keep it simple– Functional preservation tools should be atomic– Modularise in the face of growing requirements– Ensure results can be exploited and integrated with other orchestration/repositoryplatforms• Make it easy to use, build on, re-purpose and ultimately, maintain– Share your source– Automate your build– Package for easy install• Share outputs, exchange knowledge, learn from each other– Write up dev and user experiences and share them– Publish data about usage– Shout about it, blog it, tweet it, and add it to tool/service registry (or three)• Adapted from: the SPRUCE Mashup Manifesto

×