Tuesday September 19, 2017 - 10:00 AM Pacific Time
Recording of the Meeting:
UI Mockups with Gary
- Main goal to see the direction that is being proposed
- Not the items on the correct track and the items that are not in the right direction
Page 1: Dashboard is a one page look at the most relevant activity
- Yellow boarder is not going to present in real life
- Page you go to when you hit the drop down
- Similar to Hyku
- Collections area is currently AdminSets
- Collections Most recently updated
- Dashboard level attributes: Last updated, works& files count
- added a pagination
- Pinned collections
- where would you pin them?
- on the dashboard
- show or edit page for the collection
- Added links for date range, visibility and resource types into the graphic
Page 2: Dashboard view with works instead of collections
- most recently created vs most recently views
Page 3: Dashboard with Both Collections and Works
uses a lot of vertical space
Page 5: Reports - Get at the details
- Expand the menu item to include reports for collections, works, files, visitors(users?)
- Visitors/Users (actual registered users)
- layout would be the same for all the reports
- Distinct perspective will be tabs to subdivide the pages more
- Area at the top allows for report configuration
- Date range - Default start date repo initialization, end date: current date
- Filter based the object type that you are reporting on
- Display - Summary Table, graph, monthly totals
- Generate the report
- Export - CSV and or PDF
- Customize sub titles based on the configuration
- Each tab could have different sort filter and display options
Reports are likely to have pagination
Reports are visitors to the system or users?
- Do we want to show both visitors and users
- Visitor download and looks
- User deposits
How will this display work for non administrators?
- side bar has fewer options, but there would still be a report option so you can create reports on things you manage.
- group created a collection to share group data you would be interested in knowing about collection downloads and popular works.
- There would still be a dashboard view as a regular user
Next steps for Gary:
- Does the structure make sense?
- if so there is a firm direction
- For collections, works, and files what are the distinct reports wanted? What is feasible with the data we have
- Would work on it iteratively
- Will come to the calls on Tuesday
Drum up support for working on the analytics development effort at samvera connect. Want to start working on it in January 2018
Counter Update - Go with the minimum requirements to be counter compliant. Need to be consistent with how counter defines them. Counter is a standard used by vendors, which is outside of the open source OA comment experience. Allows us to compare the content with computers and bench marking repositories against other institution repositories. IRIS use project - benchmarking across UK repositories. You can install a tool (how does that work in Hyrax). One option would be to build in creating counter reports, but that was out of scope. Ensure the data can be counter compliant. Added definitions to the doc for counter reports. People can then aggregate the data out for counter at a future date.
- Why is there no OAI PMH compliance? Not part of this working group but others in the samvera community are looking at it.
Works & Collections only have page views
Files have works and downloads
Work level stats we report the views and the downloads for all child works and files
We are not certain about how the aggregation should work for views on a hierarchical work. The current definition is that you take the sum of all the views on works and files in the work
For collection we do not roll up the data to the collection. The views of the collection do not contain views of the works.
- People are interested as the collection as an object
- How many people have come to the digital exhibit
May want the aggregated information on all the things in the collection
Collections aggregate only child views from child collections
Downloads include all items, so only showing views for the collection may be counter intuitive
No one on the call has the use case for nested collection so we are uncertain how the collections in collections get aggregated.
Do not include the work counts in the collection counts since the works can be included in many collections.
Document how aggregation is happening and make that available to the user
Allow for either configuration or making it modifiable for the users.