Introducing Binder: A Web-based, Open Source Digital Preservation Management Application
•Download as PPTX, PDF•
2 likes•1,387 views
Binder is a new digital preservation management application developed by Artefactual Systems in conjunction with the Museum of Modern Art (MoMA). This new system aims to facilitate digital collections care, management, and preservation for time-based media and born-digital artworks and is built from integrating functionality of both Archivematica and AtoM.
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (20)
Similar to Introducing Binder: A Web-based, Open Source Digital Preservation Management Application
Similar to Introducing Binder: A Web-based, Open Source Digital Preservation Management Application (20)
More from Artefactual Systems - AtoM
More from Artefactual Systems - AtoM (20)
Recently uploaded
Recently uploaded (20)
Introducing Binder: A Web-based, Open Source Digital Preservation Management Application
- 1. BinderIntroducing a new, open-source Digital Repository Management Application Dan Gillean
- 2. Binder aims to support standards-based digital repository management by providing users with a single place to view administrative, technical, descriptive, and preservation metadata related to objects in a repository and the relationships between them. This in turn gives repository managers the information they need to craft appropriate preservation policies and implement decisions for long-term care.
- 5. BACKGROUND TMS archivematicaSTORAGE DAM MANAGER RELATIONSHIPS DEPENDENCIES SEARCH / BROWSE REPORTING ANALYTICS FIXITY MONITORING
- 9. Jesús García Crespo Lead Developer David Juhasz Project Manager Dan Gillean Domain analysis; Design Mike Cantelon Developer Misty De Meo Developer José Raddaoui Marín Developer Heather Anderson Developer Binder Team
- 10. 2013 2014 ANALYSIS PROTOTYPING DEVELOPMENT SITE VISIT USABILITY STUDY TECHNICAL ADVISOR’S MTG USABILITY STUDY DEVELOPMENT TIMELINE
- 11. From use cases… To UX flowcharts
- 12. From UX flowcharts… To wireframes
- 14. REUSING AtoM Binder • Authentication / Authorization • Taxonomies • Search capabilities • Archivematica integration • Archival descriptions • Authority records • Functions • Archival institutions • Advanced search • Accessions • Physical storage • etc • Authentication / Authorization • Taxonomies • Search capabilities • Archivematica integration • AIPs • Dashboard • Context browser • Artwork records • Supporting technology records • Reports • Fixity checks • etc
- 15. Graphic by Ben Nadel
- 17. CONTEXTBROWSER
- 18. CONTEXTBROWSER
- 19. ARTWORKRECORD
- 20. ARTWORKRECORD
- 23. DASHBOARD
- 24. DASHBOARD
- 25. ARTWORKBROWSE
- 26. AIPBROWSE
- 27. REPORTS
- 28. CURRENT STATUS • Code available: https://github.com/artefactual/binder • Initial docs up: http://binder.readthedocs.org • Includes API docs; intro to project so far • MoMA promotional vid: https://youtu.be/TelwvLkt-84 • User Forum: https://groups.google.com/forum/#!forum/binder- repository • Looking for development partners!
- 29. CURRENT STATUS • Upgrade to ES 1.3+ throughout application • Create a way to upload from Archivematica without using TMS …but there’s still work to do…
Editor's Notes
- Artefactual is a small open source web development company of about 16 people Our main projects are AtoM, a web-based application for standards-based archival arrangement, description, and acess; and Archivematica, a web-based digital preservation system. We’ve had 7 members of our team focused on development of the DRMC, with participation from other team members at various points. David Juhasz has acted as Project Manager throughout this project, While Jesus Garcia Crespo is our Systems Architect and Lead Developer I have been responsible for Domain Analysis and User Interface design Mike Cantelon has done both Front and back end development throughout the project Misty De Meo has built our fixity checker app, and worked on Archivematica integration and development Jose Raddaoui Marin has developed much of the Elasticsearch architecture and REST endpoints Heather has done a lot of the front-end work in Angular
- This slide depicts an example of how the process followed from phase one to phase two. The image in the top right depicts one of the use cases that MoMA had outlined as a requirement for DRMC functionality – in essence, a conservator searches for a work, finds it and navigates to it, and then browses the files contained within an associated AIP. The first thing we did was to take these text-based use cases, and transform them into workflows – shown in the bottom left-hand corner. This helped us to understand the use case visually, and to be able to determine for each task what steps the user would take, and what corresponding actions would be performed by the application. Based on these, we could then determine how many wireframes we felt would be necessary to illustrate the interface as each action took place. The top images in the middle and on the right show two examples of the wireframes produced from this workflow – the first depicts a sample of the search results, while the image on the right shows an example of the digital object browser used to explore files contained within an AIP. Below are images of the application as it was a month ago – mid development. Many elements have been developed almost exactly as they were in the original wireframes, while other elements have changed based on the flexibility of the agile model – testing, feedback, evolution. We felt that this combination of approaches – that is, a long and well-considered planning phase, combined with an agile and flexible development methodology – has given us a strong base from which to work, while still retaining the ability for us to adapt and account for new ideas.
- This slide depicts an example of how the process followed from phase one to phase two. The image in the top right depicts one of the use cases that MoMA had outlined as a requirement for DRMC functionality – in essence, a conservator searches for a work, finds it and navigates to it, and then browses the files contained within an associated AIP. The first thing we did was to take these text-based use cases, and transform them into workflows – shown in the bottom left-hand corner. This helped us to understand the use case visually, and to be able to determine for each task what steps the user would take, and what corresponding actions would be performed by the application. Based on these, we could then determine how many wireframes we felt would be necessary to illustrate the interface as each action took place. The top images in the middle and on the right show two examples of the wireframes produced from this workflow – the first depicts a sample of the search results, while the image on the right shows an example of the digital object browser used to explore files contained within an AIP. Below are images of the application as it was a month ago – mid development. Many elements have been developed almost exactly as they were in the original wireframes, while other elements have changed based on the flexibility of the agile model – testing, feedback, evolution. We felt that this combination of approaches – that is, a long and well-considered planning phase, combined with an agile and flexible development methodology – has given us a strong base from which to work, while still retaining the ability for us to adapt and account for new ideas.
- This slide depicts an example of how the process followed from phase one to phase two. The image in the top right depicts one of the use cases that MoMA had outlined as a requirement for DRMC functionality – in essence, a conservator searches for a work, finds it and navigates to it, and then browses the files contained within an associated AIP. The first thing we did was to take these text-based use cases, and transform them into workflows – shown in the bottom left-hand corner. This helped us to understand the use case visually, and to be able to determine for each task what steps the user would take, and what corresponding actions would be performed by the application. Based on these, we could then determine how many wireframes we felt would be necessary to illustrate the interface as each action took place. The top images in the middle and on the right show two examples of the wireframes produced from this workflow – the first depicts a sample of the search results, while the image on the right shows an example of the digital object browser used to explore files contained within an AIP. Below are images of the application as it was a month ago – mid development. Many elements have been developed almost exactly as they were in the original wireframes, while other elements have changed based on the flexibility of the agile model – testing, feedback, evolution. We felt that this combination of approaches – that is, a long and well-considered planning phase, combined with an agile and flexible development methodology – has given us a strong base from which to work, while still retaining the ability for us to adapt and account for new ideas.