User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
My team is building a Material Design table component. The Material Design guidelines on data tables state:
Row hover (Desktop)
Display a background in a table row if a user hovers over any part of that row.
It is worth noting that our data tables don't have checkboxes or other selection controls on them. They're read only.
Does this make sense for a non-interactive data table? Would users expect to be able to highlight rows on hover? Does it help with readability?
Yes. Just yes.
Though I do UX work, I am speaking as a user on this one. As a user, I very much want you to help me easily follow a row of data from end to end. I want to easily be able to see what lines up and what goes with what.
It is too easy for me to look at a column on one side of a row, then to look at what I think is the opposite side of the same row but which is actually the row above or below it. I do this accidentally all the time on interfaces which do not help me. I end up physically tracing across with my finger on the monitor to help me ensure I'm looking at the same row end to end. That is slow, frustrating, and error prone. Please help me.
As for some of the sub-questions:
Does this make sense for a non-interactive data table?
a. Yes! I do use this feature to assist me even in read-only tables.
Would users expect to be able to highlight rows on hover?
a. I do not expect it, per se, since lots of interfaces (unfortunately) do not do it. But I hope for it and am annoyed when there is no such assistance.
b. If you meant "Would users expect to be able to select..." (or otherwise be actionable): possibly. Some users might wonder if that means they are clickable, but they will quickly realize they are not. If some users think the row is actionable and accidentally waste a few seconds and a few clicks, that annoyance is overshadowed by table readability annoyances.
Does it help with readability?
c. Yes! Very much. Just as someone commented, I often select a row-heading in Excel even if I have no intention of editing that row; I do it to help with readability for that row.
Another option for readability: @Tulains Córdova suggested the alternating colors approach. That is also a good idea, except that the pictures provided showed colors that contrasted too much. Best of both worlds: Use very low contrasting, alternating colors (white and a very light grey, for example), and use a higher contrasting highlight color for the single mouse-over row.
Have you also considered striped rows (zebra stripes) if you think users need to read carefully? It sounds like they won't perform any selection or operations.
One aspect of zebra stripes is that they clearly show separate rows without the user interacting with the table.
Relying on hover states might indicate potential interactivity with the data (and selection or operations), which in your case is not the intention.
There's an article (a bit older now) on A List Apart:
Zebra Striping: More Data for the Case
She has a rigorous study (even testing types of striping to see if it improves legibility), and in the end she states:
if you are designing an application or website that contains data tables, don’t let personal preference, habit, or the (untested) status quo drive your design decisions—go out there and get some user data.
Material Design is amazing (I use it constantly), but it can't account for every need or scenario (they even state it's a guideline). Test and find out what works for your own users.
No, alternate row colors instead.
Alternating row colors (usually white and light green) to make it easier to read lines in wide reports have been used way before computer displays.
If that table had alternating colors to beging with, there would be no need for highliting the row when hovering over it.
Above: Green bar continuous paper
Above: Alternating row colors in a computer report
Above: Less constrast is easier on the eyes though
Sometimes the itch for adding animated bells and whistles causes us to move away from simple, traditional and time-tested usability solutions.
Besides, highlighting on hover can convey the false hint that the row is clickable or actionable.
Highlighting on hover can convey the false hint that the row is clickable or actionable = fair, although a pointer cursor vs. normal cursor can emphasise this distinction.
Highlighting doesn't necessarily imply interactivity, they also help the user maintain his horizontal line. Tables which are particularly dense or sparse on one or both axes can make it difficult to stay on one line.
Material design guidelines already recommend enough whitespace to avoid being too dense, but don't necessarily prevent sparseness from becoming problematic.
However, hover states are problematic because of their relationship to pointer devices, which can create accessibility issues. They are also problematic on mobile. Inca is also right to point out that if there is an interactive element within a highlighted region, the expectation may be that the highlight implies said interaction -- in your example, the checkbox.
So if you think that strong visual separation is a necessary feature, consider a static alternative - e.g., the zebra striping Mike M suggests.
I'd only use it where it actually helps: If it's hard to visually keep track of what's happening without it. Otherwise it seems to add unnecessary visual complexity.
In a very large table, it does help track rows visually. I've found that, as long as this is justified, it is worth the initial step of "user possibly wants to click, finds out they can't" (reddish row has mouse pointer over it, sorry for all the blurring):
I find it to be less visually noisy than even/odd row coloring when there's a lot of information being presented:
The obvious downside to the highlighting, of course, is it doesn't do much good on pointerless devices (the pages above are very much intended for desktop use).
In your case, though, the highlighting doesn't seem functionally necessary imo.
As for sticking to material design guidelines, that's really up to you. I'm not a big fan of strict material design myself, way too much guessing and memorizing what icons mean because of its inexplicable quest to rid the world of text, and a bit heavy on whitespace. You can be somewhat flexible, the material design police won't bust your door down (yet), as long as your UI stays clear and sane.
It does help with readability, especially if the table is wide, but in the example you give, I think people will expect such a hover-effect to indicate the checkbox will be marked.
This can be a valid action, if marking the checkbox will be something that needs to be done a lot, or it can be too much if checking the box is very rare, other actions (like selecting text for copy-paste) are more common, or the action that will be taken is destructive. (Then it's better to have the checking only on the actual checkbox.)
It's also worth considering how much the users will need the individual rows and the information across the table. If they are generally scanning the whole list for a reference and the details on the right are nice but generally not important, a hover-effect will more likely disrupt than help, and require people to move the mouse out of their way to have an unobstructed view.
So, definitely test with your actual users and get their feedback if it's important. Only they can tell how important readability of a single row really is and how hovering or not affects it.
To give some other options: you can also consider changing the border color on the rules on hover, especially the bottom border, or change text color, or have gradients on the row above and below. (Be careful with changing font weight or border-widths, as that may lead to reflow and movement.)
