This post is also available in: Español (Spanish)
Hi again, design followers! Today’s article was requested by my colleague Nadine, who is often taking care of data treatment and presentation. The fact is that, despite how much design has evolved, there are still some elements we cannot get rid of as of yet: tablesbeing one of them.
I do admit I particularly dislike HTML tables, probably because I still remember when they were used for “designing” websites but more importantly because I’m still obligated to build email layouts using them. Eugh. However, I consent that tables(as a matrix of rows and columns) are the most universal solution to understand and show data.
Still, it is a solution born and forged for horizontal and relatively wide spaces (and I’m not just talking about screens, also paper sheets, books, etc.) From the moment we start to consume information from our mobile devices we realize that tables are not so simple or intuitive to adapt.
But fear not! We’re going to go through some ideas and fixes we can apply to have a design that supports a good user experience in a smaller visual context. Let’s start!
Our example material
The best way to test these ideas it to take a basic data table as example. In this case, we’ve chosen something neutral but juicy: a list of fruits and its nutritional values, taken from this website. We are going to transform this table into different versions for a mobile screen, applying a mix of proposals.
Solution 0 – From table to picture
As the title said, an option I read while I documenting myself for this article was turning our table into an image format. I add this as point zero because I don’t consider this as a real solution, and we’re not really going to apply it either, but it is worth mentioning all the same as a quick fix for very specific situations.
Let’s imagine that our project uses tables in a very anecdotal way. For instance, we are considering a hotel search and rating app, where each hotel has an image gallery and, in some cases, some hotels want to add a table with information about their buffer, restaurant or pool zone opening times. Creating a specific section with responsive and flexible data tables for this may be a bit of an overkill development and a waste of resources, since maybe not all hotels are going to share that information or/and the format of said data may be very different and not interesting to be indexed as a global level. So, a quick solution may be to pass said information to an image and include it in the gallery.
Another example: we have a project that uses very basic tables that the users may be interested in saving somewhere. Maybe they will want to check them out frequently or off-line, even sharing or printing them. For instance, the weekly timetable of a gym that is going to be kept the same for several months. If instead of using a conventional coded table we produce an image, the users can easily check that data, turn the phone around if they want to see it better, zoom in as they are used to do in their devices, and save and share it easily.
✅ Pros:
- It’s quick and easy to do (but not painless).
- The user has the data in a familiar image format, therefore…
- Easy to share, easy to print, easy to work with for the user.
❌Cons:
- We lose the data in the projectas that info is no longer legible in the application, nor editable or indexable. This is a huge blow for SEO.
- It’s not interactive and can’t get the information from a database directly.
- Updating the data is also harder as it may depend on another department creating and editing the image to be added.
- It can force the user to rotate the phone so, in other words, harm their experience.
- Reading texts as pixels is uncomfortable for the eyes, and if the image doesn’t have a good quality, it may even be impossible to read.
- Images weight more than code so the loading time is increased (again, bad for SEO and UX).
In general, the bad sides of this overshadow any kind of advantage. I would never support this approach except on the cases where creating a table would take much more time and resources than it is worth investing in it. However, having gone through this can drive us to a hybrid solution:
Code data table with a download option
I think an interesting point here is having the user wanting to save the dataand, in those cases, I recommend keeping a coded table while adding a download button that can provide a friendly version of the table in PDF format (light and lossless).
Idea 1 – Data simplification
Now we’re talking! The way a person uses a laptop or desktop pc is different from the usage of a mobile device. We have less time and less space to impact the users, therefore we must have priorities. Before proposing any important visual improvement we should be able to simplify: let’s present only the most important elements for the users, at least, on a first level. We can always give them access to further information in following screens. This proposal of simplifying the data is useful in all cases because we can apply it to any kind of data and contents.
Table synthesis is what Bloomberguses in its stock market section. As you can see, we go from 8 columns in desktop to 4 in mobile.
A piece of advice for data synthesis?
- Show only what the users really need to know. Exercise your empathy (or make user tests your app) and leave only what is going to be used the most at plain view and accessible.
- Get rid of useless data. Intermediate values or info that only has meanings in the bridge of investigation is not worth your users’ attention.
- Abbreviate when it’s possible and add sustitution images or icons.
- Erase the repetitions. Choose only a way to show the data that is redundant or similar.
- Find alternatives to certain dimensions. For instance, we don’t need the registry data if we have a sorting filter from most recent to less recent.
Applied to our example:
For our test data we’ve decided the most valuable data for the users is, apart from the fruit names, the proteins, calories and fiber info. We’ll add some images and some style changes to make the table more attractive and… tada!
✅ Pros:
- We help make the data query experience shorter, easier and more enjoyable.
- We quickly give the user the information we believe holds the most value.
- Visually we highlight what is crucial, without “noise”.
❌Cons:
- We must sacrifice part of the information, and not always all that is essential will fit in the width of a mobile screen.
- It is often not easy to elucidate which information is more important without prior testing.
- We are guiding the user experience around what we consider important, and our opinion may be biased.
2 – Horizontal scroll/slide with feedback
Even if we left it for third, this one is the most obvious solution. This fits for tables that are wide but not too tall. If the table doesn’t fit the width, we can just cut it and make the user scroll across the Y axis to see the rest of the data. This is the simplest solution. It is also the default behaviour of a website table if the content overflows the container, but that doesn’t make it responsive out of the box.
Something crucial if we are going to make users scroll is to adapt that to mobile language, making it obvious for them, Remember that in mobile apps and website the scrolls are invisible while the user is not interacting with them. Your users should be able to tell that the table has other elements easily, so invite them to scroll through them. How can we do this? A good way is to cut your table in pieces and slide though them, while using a navigation bar as feedback, fixed in the lower part of the screen.
Applied to our example:
The idea of simplifying to what fits is very nice, but we have deleted some dimensions that were perhaps important just because they did not fit in our screen width. Let’s try now to keep it simple but with enriched values. This time we are going to adapt the information to something useful: a top 3 of vitamins and minerals! Instead of comparing by quantities of these values, we are going to order them and show which three elements of these two categories are the most important in each fruit. And, in addition, we are going to put a mobile pagination system, so that the user knows where they are in the table.
✅ Pros:
- The visual experience is pleasant, summarized and allows user interactivity to learn more.
- The order of the information can be easily prioritized, putting the most valuable first and leaving the least obvious for the far end of the table.
❌Cons:
- The information the users are looking for may not be there at a first glance, forcing them to scroll/slide (and, if it is not evident, we may lose their interest).
- Poner el sistema de paginación de móvil puede no ser tan intuitivo si se trata de una web. El uso de librerías externas (como Slick -en nuestro ejemplo- o Bootstrap) hace la vida más fácil, aunque también aumenta el tiempo de carga.
- In cases where there is too much data, the users can get lost navigating through it, especially if they don’t keep track of the header or the first column. In those cases…
3 – Scroll with fixed elements or collapsable rows
To avoid the bad sides of the previous solution we have… fixed columns and collapsible rows! It’s as simple as it sounds.
For starters, fixing the columns allow us to keep the identifier of the element visible at all times, preventing the user from crossing lines without realizing it while reading the data. The same applies for the row header for tall lists.
On the other hand, stackable rows are useful to fold and unfold categories. In the fruit case it may not be very interesting, but imagine the data that we show in the rows is, for example, related to the specs of a mobile phone, grouped by subject (screen, camera, connectivity, etc.). Then it can be good to keep them visible, as the users scroll so that they do not lose sight of the category they are in. The best would be to add to those groups headers a “sticky” behaviour.
Applied to our example:
We’ve kept the idea of the previous table but, this time, fixing the first column and the header row, so they remain fixed and always visible.
✅ Pros:
- It’s simple and evident.
- The users don’t get lost in any axis while navigating. They’re always aware of what dimension they’re in.
❌Cons:
- It is valid for cells with short contents. If there were a lot of content, it would be quite tedious to read.
- It is not a good solution for tables with a big amount of data because it forces you to scroll too much.
- It makes it hard to have a clear overview, a global idea.
4 – From table to data cards
Let’s suppose that, despite everything, we still want to present all the information that we had in our initial table to our public. What we propose with this design is toconvert each element to a synthesized data card, accessible at a single glance. This is an especially useful solution when you have more columns than rows and you don’t have a huge amount of items in rows and/or you can benefit from other filtering options for your table (for example, a top filter bar or even a search box).
A very useful element for these cases is the collapsible data accordions. Thanks to them we can keep the cards with a nice size so they don’t use up too much on the screen, keeping it simple to navigate between items,
✅ Pros:
- We avoid the scroll inside a same element.
- We can apply this solution to great amounts of data without making sacrifices.
- We give the readers an overview of an element with all its values, with the option to display more details.
- It is a flexible way of presenting information, which gives us a lot of design options.
❌Cons:
- Column names are going to be repeated.
- It makes it harder to compare elements because it is an individual view.
- If we don’t have other ways to filter or there are too many elements, we overcomplicate the user experience as they would need to go through many elements until they can find the one they’re looking for.
- We still need to scroll in different directions to get all the desired data.
5 – Comparator
Following the major cons of the previous solution, we arrive at the comparator idea, which combines the best of different worlds. When we know that data in our app is going to be read mainly to compare different elements’ properties this is the best solution, but it will also involve a longer and more expensive development.
Here we go beyond creating a table ourselves, as we give the users the ability to choose what they want to put in it. We then need to think the design in two parts: one will show each product detail page, and another will includes a dynamic component where elements can be added (up to a reasonable limit) and deleted when convenient.
Let’s leave the fruits aside. To check this out in action I hardly recommend Kimovil, my favourite comparator website.
A note: we must be careful not to overload our comparators. Although in a desktop view we can have up to 5 or 6 elements at the same time, on mobile we should never show more than two elements, and make it easier for the user to move between them with a navigation system in slides or even with a drag & drop.
✅ Pros:
- Applies to sets of items with many fields and details, allowing a large amount of data.
- Works with any kind of data.
- Make it easy to compare items.
- It is very useful for e-commerce platforms or product qualifiers.
- Helps the user when making decisions and invites them to action.
❌Cons:
- It involves a longer and more expensive development.
- In mobile we are only going to see two elements at a time, so the comparisons are reduced to those two dimensions.
- The project is more complicated so it is a challenge in terms of design, coding and UX.
6 – Pick and choose
Finally, we can also empower the users by creating a table whose dimensions are dynamic and depend, for example, on a selector, a search filter or buttons that toggle the visibility of elements. In other words: we provide the user with the option to check and uncheck query dimensions in the table. For these situations, it is best to start with a basic table that has the main information and provide some way to show and hide additional dimensions in a user-friendly way.
If you think that your project can benefit from this system, the best option is to take a look at a library that can be of help. One of the most powerful is Data Tables, which is the one we have used for this example. It is based on the traditional table format. It is also very easy to implement in any kind of project.
* If the iframe version doesn’t behave correctly here, try navigating with the keyboard in the x axis or access this demo link from a mobile device.
✅ Pros:
- We can getthe best of the previous cases but without limiting the users ourselves.
- Data is not sacrificed, just left a second click away.
- We allow a data query aimed at the users’ preferences so that they cross the dimensions they want.
❌Cons:
- The responsibility of properly displaying the data falls on the users. If the design is not well thought out, the consultation may not give them what they want.
- It involves “learning” through trial and error, which may not go well with non-proactive users.
- A dynamic table is more complex on a technical level, so there are more things that can go wrong while developing/designing. If we depend on external libraries tor this we’ll be under the umbrella of their limitations.
- Both development and design take longer.
Reference: Application of the different solutions in a real case
Now that we have seen different ways to make our tables more UX-friendly, I invite you to take a look at Joe Winter’s redesign for a macro risk table. It is a wonderful real case, where some point’s we’ve previously seen are applied.
Summing up – final tips
We’ve seen quite a lot of options, but not all of them are going to be equally suitable depending on the case. What should we consider when choosing one solution or another?
- Kinds of data and dimensions of said data:
- Existence of data priority: there usually is, but there are cases in which it is much more evident that certain data is essential and certain other provides little added value. In those cases, you can ignore the latter or leave them hidden, in case users may want to search for them.
- Consultation of data: you must ask yourself and imagine how this data is going to be consulted: are users going to compare the values, are they going to check the data in whole, or perhaps it’s the evolution over time what proves most interesting?
- Rotating the phone should always be the last resort: let’s try to avoid this as much as possible. Remember that your public is using your web or application in a certain way. If you force them to change it, you’ve made a wrong design decision.
I hope this article was useful for you. If you want to see the messy magic behind the different fruit tables, here is a link to the demo repository that I have been using. And that will be all, folks!
If you apply any of the solutions here to your responsive redesign, I want to see it. I am always eager to see the transmutation of traditional tables in favour of more imaginative solutions. See you soon and take good care of yourselves!