Page Comparison

...

The data displayed by a dashboard widget isn’t likely just a single query, but can possibly contain data from a group of queries with results that contain human-legible strings associated with unique id’s (UUID’s). For the results to render in a human-legible way, each of the associated queries must finish execution. For example, items in the /users query contain a field for patron_group , which contains a UUID that’s associated with an item from results procured from the /group endpoint. https://s3.amazonaws.com/foliodocs/api/mod-users/r/users.html#users_get Registered components can be created to make their own requests - this currently happens in the licenses widget: https://github.com/folio-org/stripes-erm-components/blob/master/lib/InternalContactsArrayDisplay/InternalContactsArrayDisplay.js

The next major requirement for rendering is describing how the values should be represented in a useful way. Is the value to be rendered as a link? Where in the data does the label for the link or the href come from? If these questions are not fulfilled, the user will be likely presented by generic, meaningless representation such as [object Object] or possibly long UUID’s where meaningful data should be.

...

The App Interaction SIG compiled a list of use-cases for the dashboard in 2022. Dashboard Use Cases The lengthy list of cases mostly shortcuts to displaying data that might otherwise be cumbersome to obtain through standard search UI. To summarize, challenging queries like users with recently updated permissions, or patrons with fees/fines, lost or overdue items above a specified amount. Users with patron groups that are soon to expire.

Next steps for any team that wants to create/display a widget on Dashboard app

1. Review the use cases and prioritize/fulfill any backend capabilities with those features. If the backend can’t already resolve a particular query, the dashboard won’t be able to provide an option for it!

2. Design and implement a widget form that might conform to a number of use cases, given adequate information from associated meta-information about the data.

   1. Can use the currently supported query language KIWT

   2. OR create a new widget that supports CQL

3. Expose the proper meta-information from backend modules (dashboard interface)

4. Expose UI display resources through the frontend registry.

The

...

questions

1. How can these current implementations be improved?

2. How easily could the Dashboard app leverage FQM and/or the Lists app?

3. Are there better ways aside from polling an interface to obtain meta-information about data sources

4. Could the front-end provide rendering methods in a way that would depend less on the monolithic bundle in the current state of FOLIO platforms? In a way that didn’t require all of the provided presentation code to be present at the time some centralized event is triggered?

5. Could query-building be shaped in a way that leverages recently run queries in the system? Would that be useful?

6. How receptive would the users be for a query builder that got their hands a bit dirtier with the raw data, allowing them deeper display customization and query control?

The future

The ideal solution for a dashboard system is a feature that will be capable of gracefully sitting atop a potentially changing, modular platform and have a ‘sit and forget’ agnosticism to change, fulfilled by existing work that’s achieved as part of the standard process for developing FOLIO modules, frontend and backend.

...