2019-01-22 Meeting notes

• As of now, there are no further updates to this from my end.
• The general idea (to recap), is to compile all Hyrax design assets. Combine, organize, and store existing wireframes and mockups from Hyrax Github issues.
  • Hyrax Working Group efforts surfaced the potential utility of doing this - best way to facilitate reference material for producing new components in a consistent way?
  • Adam got some pre-work done as the Hyrax WG was concluding.
  • Much existing documentation is buried / scattered in a few different places.
• Next step would be to identify Hyrax screens which do not have a design asset, and create one.
  • Adam will continue to shape potential deliverables - potential summer timeline for work.
• Dave - use cases for repositories might be worth noting (DAMs versus digital library, etc.)

• The general idea is break down the generic UI/UX label in Hyrax, and group into more specific labels (view / functionality / etc)
• Slated for summer 2019.
• Spearheaded by Oregon State University

  • Steve Van Tuyl - Hyrax Product Owner (Oregon State University)

  • Sarah Imholt - Metadata Technician (Oregon State University)

• Details here: https://goo.gl/KFo2om
• If anyone is interested in working on this, following the action, contributing, or has ideas, feel free to reach out.

Here's what I'd like to happen, if possible. As more and more dev teams in the community start exploring independent front end applications and components, there exists some structure or path for collaborative work.

Ideas:

• Create a component library repository under Samvera / Samvera Labs which houses generic UI components available to anyone who'd like to use them.
• Out of this component library, say perhaps an independent front end application is created, which may one day replace what Hyrax currently uses as a front end.

How?

• It'd probably make sense (provide there is interest), in some type of community decision to run with a particular JS component library/framework. So everyone could be on the same page.
• Similar to how Ruby/Rails is the back end choice for Samvera apps instead of Java or Node, maybe we could all decide in 2019 to develop in Vue instead of React or Angular?
• This doesn't have to be a hard and fast rule which dictates all future development for people, but just a general, "community preferred" path? Does this make sense?

Why?

• For example Northwestern has been building out front end applications in React/Redux the past year. We're going to start building out an independent front end to handle ingestion of works/collections. Should we continue with React? Someone else is probably doing the same thing we are (or will be soon). It'd be great to share the work. Here's a React app built on top of works ingested via Hyrax:
  • http://dc.library.northwestern.edu/
• Avalon Media System is starting to build out components on top of Hyrax via the Webpacker gem. The project has also contracted work from Universal Viewer devs in the UK in React/Redux. Should we continue on the React route, or switch to Vue if others prefer it and we're building on Hyrax?
• In Avalon we've built a few existing React/Redux standalone apps we're importing into our projects. It's been expressed that if some of the work was in Vue.js, it could be shared? That'd be great Here's the open repository Avalon stuff:
  
  • https://github.com/avalonmediasystem/structured-metadata-editor-react
  • https://github.com/avalonmediasystem/react-iiif-media-player

• We may want to do an update roundtable at future meetings.
• Seek UX related demos?