We are designing a datatable view for scientistic users. They get this table after they input a bunch of filters and press search. The table is already quite big - 13 columns. However we know that often our users want to know more detailed information about each of rows. Each item(row) has quite a lot of additional information. As this is a research tool, our users want to find some interesting items from this table, and sometimes they just want to glance over table quickly and check detailed information of interesting items, or go one-by-one item and view detailed information for each of them. Also we know that our users might want to copy some text in that datatable in order to e.g. search that term on the internet. Also some rows are links to external websites with additional information.

So what we came up with:

  • Detailed information about an item is quite heavy information to squeeze in popup's on hovering some columns, so we decided to go for master detail pattern.

  • We could put the detailed view of each item just below the table, however we have content on the page above the table, so it might be not so easy for users to keep everything aligned nicely in the screen. Therefore we decided to show detailed view on the side of table, while minimizing the table on demand.

So there are two modes basically:

Mode 1 - Full table mode:

Master view

Mode 2 - Minimized table+detailed information mode:

Detail view

  1. Mode 1. Full table mode, where users can go over items basic information. Clicking on e.g. Name1 will open 1st item in Mode 2. Clicking Value4 of first item will also open 1st item in Mode 2, however it will also open a 2nd subtab "Info2" in the detailed view, instead of default subtab "Info1".

  2. Mode 2. Minimized table+detailed information mode, activated clicking on the name cell of an item. Here users can see detailed information about an item. And there is an easy way to go back to detailed view (blue arrowed control). Minimized table provides some way for them to distinguish the items and go quickly over them one by one. To switch to another item, use click on Value 2 (alternative name to Name1 that makes sense in that context)

The problem we have is that only name + 2 other columns of the datatable that are opening the detailed information about an item. However it can be possible that users want to switch often between mode 1 and 2, so we are not sure it's very natural/fast way to do via clicking on some links inside rows.

We can't make the whole row clickable, because then it will be hard for our users to copy values from the table. Also we want both minimized and full tables work in the same way, therefore we would also need to have same kind of mechanism for switching items in detailed view. Clicking on a particular cell in the minimized table to change the item might be agains expectation of users regarding how master-detail view should work.

Somebody asked a similar question Is it worth making an exception to a single-click master/detail pattern? however in our case some cells have links to external websites and we don't think so far right click is a good way to go.

What would be most natural solution here?

Any input is welcomed!

Cheers, Max


Solution we ended up with

In the end we have ended up with the following solution:

  • We still use togglable detail pane with all the content about row in several tabs in it. Michael proposed to split content into pieces and show only part of information in the detail view, e.g. only information about Value4 when user clicks on it. The problem was that the object had quite some more information chapters (tabs) than were represented in the row in master view (basically some of the tabs in the detail view would have no link in the master view).
  • We open the relevant tab in the detail pane, depending on if user clicks on e.g. Value4 or Value5. However because our users want to quickly compare e.g. Value4 details between different rows, we keep the previous tab opened in the detail view, when user clicks on Name links. We think this should be quickly discoverable.
  • We indicate the difference between internal/external links by showing different icons next to links on hovering the link.
  • We highlight the whole row in the master view when opening the detail view, so user clearly sees what she is viewing.
  • We left the toggle control (blue error) about quite bulky as it is in the wireframe, so make it faster to switch (easier to click) between the modes.
  • We show detail view on the right-hand side, as this is more natural position for details (thanks Michael!)
  • We do not have an extra toggle for table view - since most of the times the user always want to see the table (e.g. for fast switching between the items to view in detail view)

Problems left to address

  • The detail view is quite bulky - it might be that user does not need most of the time all the information at once. Main requirement was that the user can quickly browse/compare different information between the items. Another possible solution to this would be to take an advice of Michael and show only relevant information to the link that was clicked. Then to view the whole information about the object we could add a link in each detail view View the whole object data, which would display all the tabs with the information about object in a different page/modal window.
  • It is not obvious to user that clicking on Name would allow to quickly iterate over objects and comparing the previously opened tab in detail view between the objects

I will keep this question open for a while in hope to get some hints to the remaining problems


Just wanted to get back and share out insights after testing this with our users. Most of advices from Michael turned out working well in practice. However some things we observed/still assume:

  • We have kept the multi-tab detail pain as in Mode 2 - Minimized table+detailed information mode: mockup, since all of the parts of that complicated object rows are related and somehow interconnected (the parts to which e.g. Name, Value4, Value5, etc. links would lead). It would confuse users that different links show different parts of the object, and user does not seem connection between them (which switching tabs would show).
  • Pure links are confusing our users. They don't see that the whole row "contains" detailed information about the row, and they see links on the rows are something that would not show details/summary. about the whole item. Now we see best approach to have the whole row clickable (which will drop user to the default tab of the detail view), and specific in-row links just lead to the particular tabs of that detail view (as a shortcut). External links are show with a icon that gives a needed hint.
  • Specially-styled toggle button as in the wireframe seems to be well received by our users
  • There is indeed problem with the space - its hard to fit both part of master view together with content of the subtabs. Minimizing master view with a toggle would be a great solution to that.

1 Answer 1


How to switch from Mode 1 to Mode 2?


I think clicking a link to open and populate the detail pane could be okay. Users can click a link to open the detail, then click any other link (for the same or different row) to change the content of the detail pane. Certainly is fast and easy. Personally, I’d expect the detail content to appear to the right of the table, rather than left (consistent with a left-to-right top-to-bottom hierarchical flow that master-details usually have), but maybe you have your reasons.

You seem to be concerned that users are expecting links to navigate to another page rather than open something in the same page. That may be true, but users are going to see the detail content appear (it takes most of the window), so, while it may not be expected, users will quickly figure out what happened. They’re not going to wonder why the “link isn’t working.” I think a link is probably okay in your case since you’re changing almost all the content on the page. In a sense, the link navigates to a new page that happens to share a little content with the previous page for context.

It may be a good idea to visually distinguish links that populate the detail pane from links that go to an external site so users can form correct expectations. Unfortunately there is no standard for it (it’s long overdue) nor is there a naturally intuitive imagery, so your users are going to have to pick it from experiencing you site. It sounds like your users will be relatively intensive users, so it’ll happen. I suggest icons (google for ideas). I’d recommend against color coding.

Toggle Buttons

The main alternative to a link is some sort of state control, such as toggle button. This would be a small button beside each Name2, Value2, etc. with a compact label (maybe a left-pointing arrow?) to indicate it provides detail. Depressing it (only one in the whole table can be depressed at a time) displays the appropriate detail content. This is sort of like using a list box (another state control) to select what goes in a detail, which you note that you can’t do. Toggle buttons have the advantage of telling the user what’s in the detail pane when the user is looking that the table, which sometimes is easier than reading the detail pane title.

However, I’m concerned about doing this in your case because the button is embedded in the columns of a table. It might look like it represents an attribute “set” for a row item (e.g., the item “has” Value2 but not Value3). Also, since the page opens with all toggle buttons un-depressed, they might be mistaken for command buttons that alters the data (most do), making users reluctant to click.

Object Control

Another alternative to links is an object control. In effect, what you have are multiple objects (sub-items, each represented by a single summary/identity field) imbedded in a row that represents a superordinate object/item. However, I think object controls only make sense if you’re also going to exploit their other capabilities (e.g., ability to differentiate copying Value 2 as an entire object from just copying its summary/identity field value). Otherwise, all you have is a toggle button that has a column-specific icon for a label.

Right Click and Related

You are correct that right-clicking and double-clicking aren't good for this. These are expert shortcuts with poor discoverability and more effort than a single-click. They also introduce inconsistencies of their own. Functionality this frequent and important should be by a visible single-click method.

How to switch from Mode 2 to Mode 1?

This may have been obvious to you (you just didn’t bother to show it in the mockup), but you can provide a single-click control to “close” the detail pane in order to switch from Mode 2 to Mode 1. An “X” button in the corner of the detail pane may be sufficiently intuitive, noticeable, while minimizing space consumption. I actually recommend both the master and detail pane be hide-able via a toggle buttons.

Save space

It seems like some of your concern is related to the space availability. Here’ a couple things to give you more real estate to play with:

  1. Only show the Name1 details when the user clicks Name1. Show no tabs when Name1 is in the detail. Instead, if users want Tab2, they click Value2 (or whatever) in the table. Users still have one-click access to swap information into the detail pane, but now your detail pane is half the size. It may also reduce confusion about whether clicking Tab2 is really the same as clicking Value2 (sometimes providing multiple navigation paths ends of causing more confusion than it’s worth).

  2. Put the search controls in a popup or separate page. If users generally do a search then work intensively on the result, it may be worth it to force a little extra navigation to re-search in order to have more space available for the tasks that dominate the users’ work. You should include some indication of the search criteria above the table in case users forget what they’re looking at, but that will generally take less space than full-blown editable controls (although see Alan Cooper’s About Face for a remarkably compact way to present editable search/filter criteria).

  • Thanks for a great answer Michael! I have learned a lot actually from it. I have just described in the edited question, the solution we have ended up with. I will keep the question open for some time in hope to get hints for remaining problems. Commented Sep 9, 2016 at 10:02
  • we have tested our design decisions, and you might be interested to check our outcomes in the updated answer. Thanks again for help! Commented Apr 3, 2017 at 6:37

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.