I have a table containing users like so:


download bmml source – Wireframes created with Balsamiq Mockups

In the system, users can associate multiple emails with their account. When the user mouses over a row, the row expands downwards to show all the emails registered. This is done with the CSS :hover selector:


download bmml source

As can be seen, this creates a pretty jarring effect and pushes the pagination widget and all content below it downwards. In addition, if ther user has moused over the last row, and wishes to click on one of the pagination buttons, she will try and aim for them, but once she mouses off the table row, the row contracts and the pagination widget shifts up, making her miss the buttons.

Are there anyways to improve the user experience for this? Is there a pattern I could use? I would like to make it as easy as possible for the user to show additional emails for a given user in the system.

3 Answers 3


Consider replacing the Hover effect with a "see N more..." link, which would expand the list of email addresses (pattern: Progressive Disclosure). This also has the benefit of indicating to the user which rows can be expanded, rather than having to hover over each one. You could provide a small [x] or [^] icon to allow the user to condense the cell back to its default state.

Depending on your space constraints and the frequency of multiple email entries, you might also want to consider always showing the first 2 entries as a better indicator of having more than one email address.

  • 3
    Or possibly use a simple [...] button like GMail does now. Mouseovers which alter layout are really distracting if you are simply moving the mouse from A to B and happen to cross an active element. Apr 29, 2012 at 9:24

You are already using the pattern of progressive disclosure, but it seems that refinement of the the trigger (to better interpret intent) and the display (to put the user in control of interface changes) is needed.


Hover is being widely abandoned as:

  • It is unavailable to touch device users. If your users will never need to access the interface from a touch device, then it may be fine... but, why not be future-friendly?
  • Hover without intent is not able to be discerned from hover with intent. Users passing over a hover target will trigger the view, even if it was not their intent.


  1. Use a tap(click) trigger on "view all" or similar text. By binding to the click event, you can be fairly certain that there was intention to trigger the view.

  2. If you would like to keep the hover, move from a css:hover trigger to a JavaScript hover that has a slight delay so that mouse-pass-overs will not trigger the view. jQuery Hover Intent Plugin or similar should work well.


For display, you could stay with inline expansion or move to a modal display that will not affect the flow of the table.

  • For inline expansion, if you went with a click trigger - you could also have a click trigger for closing the information so that it would not slam shut at inopportune times (when they are about to paginate)

I'd recommend a modal solution that does not disturb the flow of your datatable. See mockup.


or a less intrusive "pop-over" modeless style (thanks @kalms)


download bmml source – Wireframes created with Balsamiq Mockups

  • That was very helpful :) Unfortunately, I can't accept 2 answers, so I gave you a +1 :)
    – F21
    Apr 30, 2012 at 9:18

I agree with deprecating hover-based behaviors. Not only are they touch device unfriendly, but also, when badly coded, can be really annoying even on desktop devices (e.g. lack of debounce on the triggers, or wholesale trigger without excluding checkbox cells)

The suggested click-based View All option seems more robust and explicit, however it also can be a nightmare for those who need to see detail most of the time.

In order to address this scenario I would consider a toggle setting labeled Show detailed view, as a checkbox placed above the table, and make that setting persistent through local storage or a cookie. This way, a person who uses this application heavily, willing to see details 90% of the time, will have a better experience not having to constantly click in individual cells.

The only downside of this solution is when the expanded data is heavy - then the backend performance could be a concern.

This toggle would probably need to be supported with some additional UI logic. The View All links would probably have to be hidden/disabled when the toggle were set to show detail.

Another idea for a trigger would be to support double-click/tap-and-hold. This patter is becoming even more common.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.