Page Comparison

...

Meeting Notes

Dashboard

• FOLIO Dashboard slides

• Slide 2: Why a dashboard?  ERM SIG – data driven workflows – specific information relevant at a specific time - need for personalized information

• Slide 3: dashboard version 1 introduced in Juniper release to display key information at a glance - personalizable –> your dashboard is linked to your login to FOLIO

  • Focused on ERM first – but designed for other areas of FOLIO as well - It's designed to be able to display information from any module as long as that module kind of knows how to talk to the dashboard. The dashboard knows how to talk to that module and get the information and display it.

• Slide 4: Example use cases

  • Collected 30 use cases so far for ERM e.g. list of Agreements/Licenses approaching end date

  • Assign to particular FOLIO users – show me “my agreements”

  • Check status of synchronization with external KB

• Slide 5: Dashboard look and terminology

  • Dashboard as a canvas as blank screen to add or remove widgets 

  • Examples: Agreements expiring less 30 days, my active agreements, unsuccessful jobs

  • Tables within the widgets can be configured – Agreements / Licenses different end dates

  • Repeat of the same widget e.g. 30 days and 60 days and 90 days is possible

• Slide 6: Dashboard look and terminology

  • Ideas of different types of widgets maybe a pie chart – but the examples so far are those with tables

• Andrea (chat): If the data is more than would show in the widget can it link to a fuller display

  • Idea to display brief information, each agreement line in the table is a link and can be reviewed in the full Agreement

• Demonstration

  • Actions button --> new widget

  • enter name
  • choose definition - what type of widget - 3 in the moment – Agreements, Agreement Jobs, Licenses
  • Example: Agreements expiring within the next 30 days

  • What criteria --> Filter end date: today or relative date or fixed date

  • Results - how many rows (default 10 rows)
  • Choose which columns and save and close

  • Menu "…" → edit a widget: e.g. extra column

  • Cannot change the type of widget after it was saved

  • Layout of dashboard depends on screen size/width of screen

  • Actions button – can change the order of the widget of the display

  • Joanne (chat): Owen, can you delete a widget?

    • Yes, menu "…" --> delete – not deleting the data, but the view/display in the dashboard

  • Andrea (chat): Can widgets be shared?

    • At the moment no, but two possible approaches for the future 

    • Supporting copy a widget - could allow other users to copy this – copy and then make changes – as a shortcut for creating – not changing the "original" widget

    • a set of widgets for a team – in future there could be multiple dashboard e.g. extra tab or switch to team dashboard – with permissions for a user to change it – single version of those widgets

    • Those are ideas – not started work on those

• Ethan: Dashboard technical background: One backend module and two frontend pieces

  • Backend module: mod-service-interaction listens to other apps

  • Coupling between our back-end and any back-end that want to use this should be fairly minimal

  • Not hardcoded dependencies – platform for others modules to push data and information

  • 3 main level: widget type, widget definition, widget instance

  • Widget type = big JSON schema – e.g. simple search widget

  • Widget definition = what your module will send – e.g. you can filter or sort by

  • Widget instance = user chooses between the options of the definition

  • Frontend: two pieces the dashboard and registry

  • Registry – code that can take information from other frontend modules 

  • Goal is that developer look at JSON schema and write JSON and maybe add a couple of registry entries

  • Maura: How much time to set up a dashboard for another app?

  • Owen: time consuming telling the widgets how to get data, once you have this – different version is not difficult

• use cases

  • Thomas (chat): first thing that popped into my head was the new actual cost fine/fees workflow.. having a widget that shows new fines that need to be addressed.

  • Thomas: It doesn't actually add a fine to the patron's account. it's a separate UI that you go into that identifies all the items that have just been marked as lost - does require staff attention. having a widget that identified these items

  • Andrea: expired holds – this holds still expired - when we pull all the holds that have expired from the hold shelf sometimes you miss a couple

    • Courses reserves: sometime items are on order, when you put them on course reserves - show me what the status of these items are that are still on order that are also in the reserves.

    • same for recalled items that are going on reserves

• slide Slide 8: Next steps

  • Just ideas - Balance widgets for budgets or status widget (that something has succeeded or failed) or graphical widgets

  • Are there other ideas of widgets types? 

  • Andrea (chat): Can widgets pull data from more than one app?

  • currently we're focusing on single calls use cases, challenge: widgets are complex enough to be useful, but simple enough to not become a replacement for the application itself, as it were.

  • trying to avoid adding functionality that could be in the application itself

  • Considering possible performance issues

  • purpose of the dashboard as a kind of way of displaying data as opposed to doing kind of additional calculation or logic based on that data.

  • Let us know about your use cases

  • Andrea: bar chart that showed you lost items, recalled items, claims return - bar chart that shows you what areas need attention 

  • both display the summary and link to the full detail information

• Please add use cases here: Dashboard Use Cases