For a while we, at Jumping Rivers, have offered a Dashboard Health Check (DHC) largely focused around backend features and other facets the end-user doesn’t see: things like version control, documentation and deployment. However, the DHC also included a few checks related to user experience and accessibility. While we’ve always believed these are useful additions, we would like to offer more in-depth guidance to our clients on how they can make their applications more user-friendly. To facilitate this, we are now introducing the Frontend Dashboard Health Check (FDHC). What could an FDHC help me with? So what kind of advice can you get from us from a Frontend Dashboard Healthcheck, you might wonder. Here are just a few of the possibilities: Tools like Shiny and Dash make it relatively quick and easy to build data dashboards. These can often start out as a fixed single page of data and, over time, morph into something much more complex and interactive with multiple views. Such applications can be incredibly powerful, but with great power comes great responsibility complexity. For a dashboard to be successful, users need to understand how to use it effectively to answer their questions. This can mean discovering and/or learning many features from basic navigation between views to how to interrogate the data contained within using techniques like search, filter, sort, partition, drill-down and summarise. We can suggest places where users may get stuck or confused, and suggest means of amelioration. A successful, production-ready, dashboard also needs to be robust. At minimum that means resilient to unexpected user input and to its own (perhaps temporary) inability to provide the output its supposed to (if a server is down, for example). An app that just hangs when something goes wrong is going to confuse and frustrate users and can lead to wasted time and even loss of work. We can show you where your app may fall over so that you can take action to prevent it. These days we consume pages from the world wide web using all manner of devices. Does your app work on 4k and 5k monitors? More importantly, at the other end of the scale, there is now usually the expectation that things should work on mobile and other touchscreen devices. We can show you at which dimensions your app layout may become difficult or impossible to use and where users using specific input methods - e.g. mouse, touch, keyboard - may have difficulties. What deliverables would I get from an FDHC? The principle deliverable from an FDHC is a detailed spreadsheet indicating what issues we’ve found and where they can be found (or how to reproduce them). Wherever practical we will also include annotated screenshots (or occasionally recordings) giving a visual outline of a problem (see below). We will also strive to suggest possible remedies. An example of annotated screenshots highlighting an issue with the page layout for certain width-ranges for an old version of our own Litmus Dashboard application. An example of an annotated screenshot highlighting an issue with input labelling for an old version of our own Litmus Dashboard application. What about the old DHC? We will continue to offer a separate, report-based, health check for data dashboards. This “Backend Dashboard Health Check” (BDHC) will cover things like version control, documentation, deployment as before. We are, of course, more than happy to run a BDHC and an FDHC on the same application. How do I find out more? Please get in touch via this contact form or drop us an email at hello@jumpingrivers.com. For updates and revisions to this article, see the original post

R-bloggers

Jumping Rivers introduces a Frontend Dashboard Health Check (FDHC) service to help teams evaluate the user-friendliness of their data dashboards. The service covers three main areas: usability and discoverability of features in complex dashboards built with tools like Shiny or Dash, robustness and error handling, and responsive design across devices and input methods. Deliverables include a detailed spreadsheet of issues with annotated screenshots and suggested remedies. A separate Backend Dashboard Health Check (BDHC) covering version control, documentation, and deployment continues to be offered alongside the new FDHC.

Is Your Dashboard User Friendly?

What deliverables would I get from an FDHC?