exclusive select in a table: radio button, rowclick, text only, text and icon, or icon?

Question

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?

---

Update

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.

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

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

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

Answer 1

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.

Edit

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.

Answer 2

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.

Answer 3

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:

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:

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