Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Information should be concise and easy to scan, at a glance, with minimum interaction needed. E.g. scrolling should be minimisedminimized
  • Content should be timely and up to date.
  • Where changes over time or since the last access are important they should be highlighted. 
  • Comparison of data/information should be possible and under the user's control. E.g. through side by side repositioning of widgets.
  • Space is at a premium on the dashboard. The display should be keep concise and clean. Irrelevant content such as unessential graphics should be omitted.
  • Common behavioral patterns and presentation styles should be applied throughout to ensure a consistent user experience. 

...

Widget presentation

...

and behavior

Widgets are cards containing information from FOLIO apps, which are added and managed by the individual user. The below example shows a widget called "Meine Konsortialteilnahmen (aktiv)" (my consortium participation (active))

...

The aim is to offer widgets displaying data from a variety of apps developed by different teams, but which apply a common set of design principles and patterns to help achieve a consistent user experience. Almost all of the presentational presentation and behavioural aspects behavioral aspects are baked into the widget type and will be automatically applied. 

...

The bare essential UI elements for all widgets are:

  1. A name summarising the summarizing the widget's purpose
  2. A body containing the key messages and data
  3. Options to “Edit” and to “Delete” the widget
  4. A timestamp showing when the content was last fetched
  5. An option to refresh the content

...

The widget card is a rectangular container with style attributes. The presentation and behaviour of behavior of the cards is common to all widgets. Style attributes such as alignment and margins, the positioning of elements, and interactive features are core and cannot be not altered.

...

Up to four cards will display on a single row, depending on screen width. Cards have a minimum width of 300px and will expand to fill the available column width. Card width is not responsive to content. If content does not fit within the available width a horizontal scrollbar will be introduced. Horizontal scrolling is not desirable from a usability and accessibility perspective and should be born in mind when designing a new widget definition. Where possible, content should resize to fit in the card and the user should be given the option to minimise or minimize or completely avoid horizontal scrolling when creating a widget instance. Taking a Simple Search widget instance as an example, the user is able to control which columns which are displayed in a table, and although this means that it is possible for the user to specify many columns (leading to horizontal scrolling), this is entirely under the user's control.

...

The main content of the widget is presented in the body. The information displayed in the body will depend on the widget type, widget definition and widget instance. Some widgets may support configuration options which control exactly what exactly what is displayed in the widget, while other widgets could be hardcoded hard-coded to support only specific content. For example, with the with the simple search widget, the widget definition states which columns are available to display, while the widget instance is used to control which columns are actually displayed in the particular instance - so for simple search the user is able to control what columns display in the widget instance via the Widget Edit option.

...

Errors relating to a widget should display in the widget body.

User has insufficient permissions

When the user has insufficient permissions to view content or use a feature a message will be displayed informing them of the specific issue.

Unable to find the dashboard canvas

When there is a problem retrieving a dashboard a message will be displayed on the canvas: "Error: unable to find the dashboard name. Insert action"

Unable to find a specific component

When there is a problem retrieving a component a message will be displayed in any widgets which use the component: "Error: unable to find the component name for type name. Insert action"Dashboard (name) cannot be found. Please check the URL." 

Unable to display any widget content

If a widget's content cannot be displayed, for example the user does not have the correct permissions, an error message should be displayed in the widget. As there are many reasons for this possible failure a general error message will be displayed together with a link to the full error log.

The error message will be displayed in the widget body using the Error "Message Banner" component. The message will be formed of two parts. The text to be displayed is "Content cannot be displayed". The second part is a link to "View error details", as shown in the example below.

Error banner in widget mockup.pngImage Added

The "View error details" link UX pattern should mirror that of the Error Boundary component. Selecting the link will open a new modal.

  • The modal header is "Error details".
  • The first paragraph of text introduces the error with the text "The following occurred," and then a brief description of the result of the error. For example "The following occurred, preventing the display of content in the widget:"
  • The error details are presented in full
  • An error heading is displayed
  • An option to "Copy" the error to the clipboard is presented

An example of the error modal displayed when the user has insufficient permissions to view the content of a widget is shown below.

Image Added


Unable to display specific content in a widget

When part of the content within a widget cannot be displayed, for example the content of an MCL cell, an error should be displayed in situ. The error message should be kept brief so as not to take up too much space, with a link to the full error details. 

The error message will use the Error "Message Banner" component. The text should summarize the error, for example "Data Error". The example below shows an example of a data error within table cells.

image-2021-05-24-14-06-48-641.pngImage Added

The "View error details" link UX pattern should mirror that of the Error Boundary component. Selecting the link will open a new modal.

  • The modal header is "Error details".
  • The first paragraph of text introduces the error with the text "The following occurred," and then a brief description of the result of the error. For example "The following occurred, preventing the display of content in the widget:"
  • The error details are presented in full
  • An error heading is displayed
  • An option to "Copy" the error to the clipboard is presented

Informative messages and confirmations

...