Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.
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
responsibilitycomplexity. 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.
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.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.