In my last post I spoke about the idea of web dashboards as customisable user interfaces. I gave a short example for the sake of explaining how it works – but it wasn’t very interesting. This post is a follow-up post, showing a more concrete example of where a dashboard interface works well.
Over the last few months, I’ve been spending a lot of my time working on a web project http://www.calllog.org. CallLog is a web archive and reporting tool for your call data. The relevant part here is reporting.
CallLog generates various reports and calculates various statistics by analysing the user’s call data. However, one user may want to see the last 5 people they called while another user may find this data useless and prefer to know how much they spent on calls last month. A dashboard is an effective solution for this problem as it allows any one user to choose exactly what they see and exactly what they don’t see. They also have the flexibility to modify this at any time.
After logging in, CallLog sends the user to their dashboard page:
In this example, 4 widgets have been added to the dashboard: my cost history, statistics of who I speak to most, a graphical overview of my data and my data totals.
In 1988 Bertrand Meyer described a software engineering principle now commonly known as OCP or the Open/Closed Principle.
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
OCP defines a design where new features of your solution don’t cause changes to existing working parts that have already been produced. Instead, new features gracefully extend the existing parts. While this principle is mostly relevant to actual code, it also makes a lot of sense when we think of user interfaces in the same way.
In the context of the user experience, there are various benefits when new features can be introduced without having to change what’s already there. Firstly, your users are familiar with the interface and will have an easier time understanding the new parts. But more importantly, from an implementation perspective, new parts can be produced and deployed with less friction and hence more quickly.
When your interface consists of a dashboard, a new feature can be added in complete isolation. The feature can be developed as a widget that handles its own data access, calculations and anything else it needs to do. When the feature is complete, it can simply be dropped into the dashboard and begin being used.
Furthermore, having a new feature be frictionless to add tends to cause the removal of that feature to be frictionless too. Why would you want to remove it anyway? Removal might be a maintenance task; you might be removing it so you can replace it with a newer version.
My point in all this is that dashboards [when designed in such a way] can be easy to work with in terms of extensibility and maintainability. I am now in a position with CallLog where I can continually create new widgets, deploy them quickly and with minimal pain and build a rich set of decoupled reporting tools. Oh, and they look cool too.