Master / Edit / Detail / Edit

Question

I am implementing a (Windows/WPF) dialog, which displays a list (companies), the details of the selected item (company name) and some items for that selected item (employees). Since I only need a maximum of three data fields for each item I would like to keep it in one dialog instead of spreading it out to multiple dialogs. Right now I am stuck with the design in the image but somehow it feels unintuitive/wrong and I cannot see, where the problem is.

On the bottom of the dialog there are Save/Cancel buttons and the table with the employees is meant to allow inline-editing.

Any idea is welcome.

Answer 1

As you've done in the annotations on your mockup, it is important to make clear how the pieces of information relate to each other.

That is to say, "Company Details" are contained within one entry on the "Companies" list. The "Employees" list is a subset of "Company Details".

I would do the following:

• Label the list of companies as "Companies".
• Label the company details section as "Company Details - Selected Company Name". (This way a user sees the name change to reflect the company that is selected in the list.)
• Visibly set off the company details section. For example, contain it in a 1px border, or separate the two sections.
• Make the company details section invisible whenever a company is not selected.
• Label the list of employees as "Employees".

Answer 2

Two Tables, and Nothing More

Sounds like you’ve identified the specific problem and solution yourself in your response to Taylor L’s advice. The problem is an inconsistent UI, with a separate edit section for the Companies table while having in-line editing for the Employees table. The solution is to provide in-line editing in the Companies table and eliminate the editing area. This makes the UI consistent, fastest and simplest to use, and puts the available real estate to best use. It would be very similar to the master-detail windows commonly seen for file managers, with a list (or tree) of folders on the left, and a list of folder contents on the right, so you should be able to make it familiar to your users (although window managers tend to have relatively limited in-line editing ability).

I don’t understand why you “just did not want to use the ugly Master-Detail with two tables.” (To me, "master-detail" refers to any hierarchical multi-pane layout where one pane provides additional information related to the current object in another. That additional information could be a list of components, such as employees of the current company. It does not necessarily mean a separate editing region for objects in a table or list). A two-pane master-detail layout seems like the right solution. As for ugliness, maybe that’s more an issue with graphic design than page layout, and you need to a skilled designer to work it, perhaps taking inspiration from other more attractive multi-table master-detail windows, like file managers through the ages.

Primary Window, not a Dialog

Other than that, good labeling, as Taylor L suggested, is helpful.

Also, instead of Save and Cancel buttons, consider Save, Undo, and Close toolbar/menubar controls, along with other basic commands (e.g., Cut, Copy, Paste, Insert, Delete). The difference is that neither Save nor Undo closes the window and that Undo reverts one change to one field at a time, instead of discarding all edits the user made (to do the latter, the user closes the window without saving). A large window with so much data to edit shouldn’t be a dialog, but a primary window, allowing users to incrementally save (and revert) their work, and providing users a full set of tools for sophisticated editing that will likely be necessary. If the window were a dialog, then one slip of the mouse on the Cancel button could vaporize a half hour of work.