User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 5 down vote accepted

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.

share|improve this answer
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. – Andrew Leach Apr 29 '12 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

share|improve this answer
That was very helpful :) Unfortunately, I can't accept 2 answers, so I gave you a +1 :) – F21 Apr 30 '12 at 9:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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