We're creating a new version of an application that is based on a master-detail view of data. So basically there is a list of records at the top and detail information about selected record at the bottom.

Unfortunately there can be another list in the detailed view. A user is able to create/edit/delete or to use some other actions on records in both lists. So the current version of the app has two toolbars, one for each list. Here is a quick sketch of current app: quick sketch

We can't get rid of these "detail" lists, we have to keep the same functionality. We want to get rid of those two toolbars, because we find them confusing for a user. We have some ideas like inline controls or some toolbar that slides from one list to another depending on focus but nothing seems to be ideal solution.

Did anyone encounter such a problem?? Does anyone have any suggestions?

2 Answers 2


Distinguish Selected from Current

You need to separate content marked for action from content marked as the master record. That is, you need to functionally and visually distinguish selected content from the current record. The current record is the master record for the detail list. There is always exactly 1 current record for a given master list. Selected content is what the user has explicitly highlighted for action. It may be master record or a detail record. It may be multiple records in a list, assuming you support multiple selection (you should). It may not be a record at all, but a field in a record or a portion of a field (e.g., highlight text in a text box), assuming you support edit-in-place (you should). Maybe it’s even multiple fields. There may be nothing selected at all (e.g., when the user is typing in a text field).

No matter what is selected, how many are selected, or even if nothing is selected, there is still always exactly one current record per master list. There has to be –you are always showing the detail list, so you always have to show what it belongs to. This is why selected and current need to be functionally and visually separate, even though it represents an additional complication for your users. The selected record often is the current record, but it doesn't have to be.

The Menu Acts on the Selected

Not trivially, separating selected from current also solves your problem. You have one menu and it operates on the selected content (which is the definition of selected content). The current record is irrelevant. For example, the user can use the same Copy menu item to copy one or more master records, or one or more detail records, or one or more characters from a text box, and one or more fields. All that matters is what’s selected.

(BTW, for commands on the view of the list as a whole, e.g. filtering, I recommend you do have a separate menu for each list. This is because the menu items often also show the settings of the view, e.g., what is being filtered, and the user should be able to see these all the time).

UI for Current and Selected

Visually, you can indicate the selected content by highlighting (e.g., reverse-video or shading), and indicate the current record with a marker in the left margin.

enter image description here

You may also try including a dotted box around the current record, consistent with how the list boxes indicate the item with focus during keyboard use (especially if you do not have edit-in-place, in which case, the current record is the item with focus in the master list).

Functionally, the user sets the current record by clicking anywhere on a master record (e.g., clicking a checkbox in the record, or clicking in a text box to edit it). The master record is the record the user most recently clicked on in the master list. By default, it’s the first record in the list. If you do not have edit-in-place, the selected record(s) is/are the record(s) the user most recently click on from either list. If you have edit in place, you need to functionally distinguish selecting an entire record from setting focus or selecting within a record (e.g., to copy text from a text box). I recommend an “object control” in the left margin to handle actions on an entire record.

  • One menu for both lists sounds good. There is just one problem: there can be different actions for records in master and records in detail. In that case the menu will change - some actions will disappear, another actions will appear - when user changes selected records - as you said it can be record(s) from master or record(s) from detail. I'm afraid it can confuse the user.
    – andrle
    Aug 27, 2014 at 12:08
  • Normally, you disable, not hide, menu items that do not apply to the current selection (e.g., in Firefox, Cut, Paste, and Delete are enabled for selections in URL text box, but disabled for selections of the web page). This keeps the menu items in the same relative location to avoid confusion. Usually, users can understand why a menu item is enabled or disabled (e.g., you can't change a web page). In your case, with only two lists, you can make it clearer by appending the class of the applicable records to the menu item caption (e.g., "Audit Pass" not simply "Audit"). Aug 28, 2014 at 1:01

Do you have the need to have the master section constantly visible when editing/working with the details list? Think of progressive disclosure: first select item from master, then open/slide in a new page with the details, now with enough space to present the details in detail. So the master list would be only one step/click away (back) and you are able to make better use of screen space. It should bring in more clarification on the action buttons, because the buttons are only visible in the correct context. So nobody can confuse the "new" from the first row with the "new" from the details actions. (Think of scent of information, I'm looking for deletion, and the first thing which seems to me which brings me to my goal could be the very first occurance of this button).

Hope this helps

  • Unfortunately we have to keep the master section visible.
    – andrle
    Aug 27, 2014 at 11:44

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.