Me and my colleagues from CERN are working on a new reporting tool to satisfy various administration needs of our organization. And trust me, as the largest particle physics laboratory in the world with over 15,000 people working here and a yearly budget over 1,000,000,000 CHF our admin departments are quite demanding.
It is obvious that to manage an organization of this scale we need tools that not only provide a clear overview of data but also offer a way to play with it. Since a lot of our admin data can be put to the best use when presented in a table view, we decided to give a chance to DataTables for jQuery. Long story short: that was very good decision!
However, soon after, we learnt that good is not good enough – this is what you get for working with an overzealous UX designer (yeap Bas, this one is about you!). There was no other way but to start improving the vanilla version of DataTables and I think we ended up creating a very interesting “monster”.
Here is how our DataTables looks like:
Now let’s take a closer look into some interesting details.
Looking for more space
A very common problem of nowadays websites is that they too often resemble a jumble of random elements. In other words, they are cluttered. Take into consideration a standard website: header with logo, side bar with menu, footer, huge badass looking search bar and some extra navigation on the side because why not. Sounds familiar? Exactly, 2/3* of the web looks like this. Now think about all the space these things occupy. Quite a lot, no? This is all fine as it allows users to quickly move between different parts of website and provides all sort of useful side information. However, sometimes as a user you want to forget about all of these and just focus on the data itself.
Full screen mode
The first and the foremost way to display more of useful information is to provide a full screen mode. In this mode all extra elements will be removed to make extra space for important content.
After switching to the full screen mode there are 28 lines visible instead of 23 (21% increase!).
Font size, margins and paddings
Another way to gain more space is to decrease font size, margins and paddings depending on a size of the canvas on which the page is rendered. This reduction is performed both whenever the website shrinks horizontally or vertically.
This allows us to show more information on smaller screens without giving up more lucid look on larger screens. Of course the same is applied for full screen mode both: turned on and off.
Trimming long columns
This time maybe less about looking for extra space but rather about avoiding taking too much space. We have a number of reports with columns that contain an extensive amount of text. Instead of having the text wrapped into many lines or making it expand the column to a ridiculous length, we trim it. At the same time, we leave a possibility to see its whole content if needed.
This works as well in case there is more than one trimmed cell in a row.
In-place filter bar
What is the most likely thing people will do when put in front of a big chunk of data? They will most probably try to filter it in order to extract the exact information they are looking for. When our users are searching for a specific data we want to both:
- give them the best hints on what kind of data they might expect in a certain column,
- provide a solution that would be placed as close to the data as possible.
To achieve the latter we decided to place filter elements in the same column as data they are linked to. That way, before user actually starts playing with the filter itself, they see what kind of data is stored in the column. This should give them better idea about the purpose of the column and as well give a steer on what to expect from filter object.
To achieve the former we have a set of different filter elements to work with different types of data. They might be all working in different ways but their main purpose is the same: guide users to find what they need without breaking a sweat.
One of the filter objects we have created is a list filter. A great feature of this object is that when linked to a column in a database it automatically creates a list of available values to choose from with no need of extra work from developers.
For columns with a large number of options an additional search bar is also displayed – who likes scrolling anyway, right?
Numeric range filter
We also have a simple number range filter with a slider.
Well, this guy was a lot “fun”. We came quite a long way trying to figure out what would be the best date picker. We have started with complex ones (like those where you see the whole calendar), but already during our first user tests we noticed that they were not intuitive enough – they were rather quite annoying really. We gave it few goes but ultimately decided for a simpler solution.
We accept two ways of filling in dates. Either through separate dropdowns for days, months and years or by typing the date inside an input.
Notice Earliest date and Latest date labels, based on source data the component itself will set its range/limits (of course these can be changed through API).
There is a way to select all records since a particular day…
… or until a particular day.
As much as we appreciate people who follow the official CERN date format we cannot ignore the fact that most of our users are probably not even aware that this standard exists (what a surprise, right?). To be on the safe side we decided to accept 36 different formats.
Organization unit filter
This is the first of our two CERN-trimmed filters. This element is used to select an organizational unit. To understand better what we consider a unit at CERN, you have to know that CERN is divided by: sectors, departments, groups and sections. All units follow one of the following patterns for naming:
Where A is name of a department, B is a name of a group and C is a name of a section. I will first try to find a BE department (careful, next image is static).
Since user might be looking for a group or section from that department you can see those on the list as well. However since the list is quite long, at the very top of it, under label Suggestions, we will see two special records. To get into Suggestions list one of the parts of unit’s name has to be an exact match to what user typed. Notice that user typed BE and the values suggested are BE (which is a department) and EP-ESE-BE (for which there is a section called BE).
Without the Suggestions element, EP-ESE-BE section would be at the very bottom of the list. But let’s stop for a second and think what is a more likely scenario when a user types these two letters: BE. Are they looking for a EP-ESE-BE section or one of the sections under a BE department (like BE-ICS-CSE)? Most likely it is the first case.
Finally, this element allows to select more than one unit at a time.
The Person filter is a second of our CERN-trimmed filters. This one’s responsibility is to search through CERN’s personnel. One can search using name/surname:
Using an unit in which that person works:
Using a combination of name and unit:
Using a person ID:
Applied filters bar
We believe that it is very intuitive to have a filter element and data in the same column, however… we noticed that are few drawback as well:
- when user removes a column with an applied filter from the report – the filter is still applied but there is no remark about that fact in the interface,
- likewise if a column with an applied filter is moved outside of the visible area users can easily forget that about that filter,
- there is no central place where users could overview / remove all applied filters.
To fix above problems we decided to add a filter bar (Applied filters bar) above the data. All applied filters are also visible in this bar and as well can be removed from there.
If more than one filter is applied, additional link is displayed, allowing to remove all filters in one go:
If a multiselect filter is used, users can remove individual criteria:
In the next episode
There are quite a few features that I have not had a chance to mention yet, but I will make up for it in the next post, e.g.:
- custom column selector,
- column context menu,
- collapsible columns,
- customisable totals and subtotals,
- possibility to save/reuse filters,
- sticky header.
What you have seen here is just a part of reporting platform we are creating for our users. I say we, as we are a team of seven people:
- Jan Janke (Project Manager),
- Bas Wallet (UX Designer),
- Rafael Sousa Hervés (Developer),
- Roberto Campensato (Developer),
- Rostislav Titov (Developer),
- Benjamin Wolff (Developer),
- and me (Developer).
Following dataset was used for DEMO: https://www.kaggle.com/mylesoneill/game-of-thrones
* I totally made up this number.