If you have a table where each row can be selected, and you are only allowed to select one row at a time, and selecting a row causes a drill-down table to appear to the side, how would you render the "selectable" table?

For the tables, would you rather:

  1. Use separate pages

  2. Use a nested > nested grid pattern

  3. Use a modal window at some point

  4. other...?

For the action of selecting, would you rather:

  1. Use an input button that reads "Select"? (particularly awful in my view)
  2. Use a text only link that reads "Select"?

  3. Use a text link that reads "Select" along with a small icon (16px x 16px)?

  4. Use an icon only?

  5. Use radio buttons?

  6. Use only the row itself; i.e., make the entire row clickable, with no "extras"?

After reading the accepted answer at: When to use icons vs. icons with text vs. just text links?, I'm leaning a bit towards the combination of text with an icon.

And when you can't just select a row by clicking on it...

Then to further complicate the issue: what if you cannot make your entire row selectable, because you will have multiple actions possible: Select, Edit, Update, Cancel, Remove, and the like?


Here's a mock-up of the interface as it was originally sent to me, and which I have no intention of using! It used an ASP.NET gridview, which is out-of-the-box ugly.

ugly interface

This screenshot doesn't quite do the issue justice, the tables will have more fields and have more rows than I'm able to display here in this small space. The original developer's intention was to try to fit everything into one screen so you wouldn't have to go back-and-forth between pages, but once more fields are added, there's no way it can work they way it was originally made.

Update 2 Here are some examples of icons only in a table.

Google Analytics

google analytics

Weightshift - design for AIGA cms - http://weightshift.com/work/aiga-cms-design

weightshift aiga cms

And here's an example that while you might consider best-practice because text is included, the table becomes cluttered and ugly, and the column size jumps around because of the varying text length. Some have tried to make the text links the same size, no matter what you click as you update the table, and that just serves to further de-emphasize the actual data. - http://msdn.microsoft.com/en-us/magazine/cc163933.aspx

asp.net gridview

  • Could you provide a screenshot or mockup of your table for clarity?
    – Rahul
    Commented May 18, 2011 at 15:42
  • It would help to know the purpose of the table. Is it for finding information, is it for editing information or something else. I think UI can have significant differences depending on the purpose.
    – Denzo
    Commented May 19, 2011 at 0:51
  • @Rahul - trimmed down mockup now added.
    – mg1075
    Commented May 19, 2011 at 23:17

3 Answers 3


If you are wedded to master-detail with detail on the right...

Try to Avoid Mono-Select for Tables

I much prefer trying to find ways to make mono-select tables multi-select and then using checkboxes. I prefer it as I find it (a) clearer and (b) because when the user does want to do 'the same thing' to a number of instances it is so much more efficient.

Use Conventional Item-Selected Highlighting

If I had to do mono-select, I'd do it by the usual convention of highlighting the selected row:


With master-detail it is vital to make it clear that the details belong to the row, hence the repeated name and visual tie in the mock-up.

Detail alongside a table often ends up looking and being crowded. You can get away with it if, and I am guessing this is so in your case, there are just one or two columns and the detail is amenable to a tall rather than a wide format.

Reducing number of Action Buttons

It is good to try to cut down the number of buttons that only make sense if there is a current selection. Ideally a button's title makes total sense on its own without other context. So...

You don't need a button for 'Select', since clicking on the row and up and down arrow does that for you. You don't need a button for 'Edit' since you can edit in place - possibly in-place in the detail panel. You don't absolutely have to have buttons for row 'Update' and row 'Cancel'. One way to avoid that pair is to put an OK button in bottom right of the detail panel. Another is to have icons with tooltips for Undo/Redo.

Undo/Redo still means two 'buttons' but it's a simpler to understand interface. Replacing Update/Cancel isn't about reducing number of buttons, it's about getting away from more per-row functionality.

So - thanks to this reduction in number of buttons that apply to a selection, I've only given you two buttons for per-row actions in the mock-up. If they are navigation actions you might be able to dispense with buttons entirely by using hyperlinks in the detail pane.


Now that you've shared a screenshot with more info, the fact you've got two levels of master-detail is driving you towards a tree layout for the first two levels. Losing the truly awful Select buttons gives you a little more space, so it wouldn't be too crowded. Looks to me like it is moving to an explorer-like interface, tree on the left, detail list on the right.


If there are secondary actions or information related to the row, you could either follow a tree pattern and have that information open up below the row with a state arrow icon to indicate and toggle the open/closed state.

Or, make the primary title of the row click-able but have the drill down go onto a second page, not on the same page.

My preference is usually to break up information into multiple pages with good hierarchy navigation rather than cramming multiple levels of info onto one screen.

  • Pretty much what I was going to post. :)
    – Rahul
    Commented May 18, 2011 at 15:43

I absolutely agree with @James about the highlighting and the action buttons. You can a) reduce them the way he suggested, b) make them into a toolbar/menu, located outside the table and operating on whatever row is selected, c) turn them into icons and place them on one of the sides of the table, d)only show them on the selected row.

In terms of layout: If this table is used for more than isolated updates once in a while, if the user actually works with it, then I wouldn't break it up to different pages, the back-and-forth navigation would be very frustrating. You basically have 3 levels of hierarchy, with the first two being mostly navigation, and the third one has the data.

I find that the outlook 3-pane structure works very well:

enter image description here

You can arrange panes 2&3 either side-by-side, as shown, or one on top of the other in case you need the width more then the height.

Depending on the app, another possible layout could be this:

enter image description here

(here, too, the bottom level could be on the side just as well).

  • The 3 pane structure and other vertical layout examples do look nice (slideshare.net/chaocai/standard-screen-patterns), although they seem contingent upon certain panes having a very small number of table columns.
    – mg1075
    Commented May 20, 2011 at 15:11
  • @mg1075 If you go for the side-by-side layout, then yes - but as I mentioned, you can make the 2nd and 3rd panes horizontal (it's possible in Outlook too). BTW, excellent link, thanks! Commented May 20, 2011 at 15:41

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.