Introduction Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame [email protected] @jeremyfriesen github.com/jeremyf ndlib.github.io Presentation at http://goo.gl/4g44F4
Sipity is a patron-oriented deposit interface into CurateND. At least that is what it started out as... Sipity is an evolving modular workflow tool for Notre Dame’s library; And I hope others. What is Sipity?
But What Does Sipity Do? Sipity guides a group of collaborators: depositors, approvers, catalogers, etc., through the preparatory steps of depositing a work wortem PCDM work.
Regardless of planning, our shared understanding of the workflow kept drifting The Workflow “planning poker warm up” https://www.flickr.com/photos/fsse-info
As it drifted I had to keep updating the ● working prototype ● documentation I hate updating “what is happening” documentation Because I see the code as the authority on what is happening The Workflow “I said “I'm busy!”” https://www.flickr.com/photos/stitch
The Workflow “Fortune Telling Wax Robot Gypsy Grandma 4296” https://www.flickr.com/photos/93779577 No matter how hard our team tried, our understanding of what is needed for the workflow kept changing overtime. We needed to reduce the impact of those changes on our development process.
The Workflow The workflow’s state machine – states, actions, guards, and permissions – are defined by several database entries. The diagram on the right is the state machine for our ETDs: $ rails runner scripts/processing_to_dot.rb > etd-workflow.dot $ open etd-workflow.dot
The Workflow What happens for a given action is still defined within the code: ● Required fields ● Related data should be updated/changed ● Who receives what notification ‡ ‡ This is moving to the database
Users, Groups, Collaborators “Many mani” https://www.flickr.com/photos/roberto_ferrari Collaboration of Different Units ● Individuals ● Groups ● Non-university individuals All at differing degrees of participation And at differing times
Users, Groups, Collaborators No matter how hard our team tried, our understanding of what is needed for user permissions kept changing overtime. We needed to reduce the impact of those changes on our development process.
Users, Groups, Collaborators “Actor” https://www.flickr.com/photos/[email protected] Enter stage left, the processing actor: A proxy for something that can participate in the workflow process of Sipity.
Users, Groups, Collaborators “Boundary” https://www.flickr.com/photos/batiks In creating the processing actor, Sipity exposes a narrow interface to allow us to introduce our own: ● User management system ● Group management system ● User’s that act on behalf of someone And swap in an upcoming new system
The Design “Actor” https://www.flickr.com/photos/[email protected] No matter how hard our team tried, our understanding of what is needed keeps changing overtime. We need to reduce the impact of those changes on our development process.
The Design “NYC - Queens - LIC: 5 Pointz - You're Entering a World of Pain” https://www.flickr.com/photos/wallyg We spent time looking at the pain points of our previous projects and collaborations. And I’d like to show you some of our reflections.
The Design “Painful Stab Wounds Heal My Soul, I Beg for Mercy” https://www.flickr.com/photos/thirtyfootscrew Conjecture: That which is painful to test is painful to change. Therefore, reduce the pain in testing.
We can dive deeper into the code if you are inclined? Or answer questions? Further Down the Rabbit Hole “Has he gone yet?” https://www.flickr.com/photos/jm999uk
Thank You Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame [email protected] @jeremyfriesen github.com/jeremyf ndlib.github.io This presentation available at http://goo.gl/4g44F4
jeremyf
sbtechnight
mapbox_jp
foursue
tsubakimoto_s
iwashi86
tatematsu_san
tarao
takufujii
shpigford
pedronauck
bluesmoon
hatefulcrawdad
holman
sachag
jrom
kastner
mojombo
marcelosomers
myddelton
geeforr