Master-detail windows are acceptable, but not as popular as they should be, if by master-detail you mean any multi-frame or multi-pane window where the contents of “detail” panes are determined by the selected or active object in a “master” pane. Users in general are familiar with master-details since that is essentially what you have in Windows Explorer and many email clients, like Outlook.
Search and master-detail are not mutually exclusive, so there’s no reason to limit it to small data sets. The master pane itself may be (and usually are) a set of records meeting a filtering or querying criteria, rather than representing all the records in the database table. This may be done through instant-apply filtering or “facet” controls on the window, or a separate pane of fixed filtering criteria represented as “folders” (e.g., one may be an “inbox” of orders to process), or a separate search or query window or dialog (e.g., to show all orders for Customer VCTE).
If you are dealing with a regularly used app that supports multiple tasks, then it’s usually best to fit lots of stuff in one reasonably large window rather than have a bunch of little windows. Separate little windows:
Means more navigation, which takes more user time.
It’s easy for the user to get disoriented and “lose” windows, or forget how one window is related to others, resulting in confusion.
Some fields will have to be repeated on the windows to provide context, creating more total complexity than otherwise.
Usually in business software you have far too much in an app to fit in a single window, so the question becomes how to divide your content among several large windows. The rule is to put together things the users most often do together. You want to minimize the number of times the user switches among windows. Often the best way to accomplish this is with master-detail windows (using the search methods described above). Many tasks involving multiple objects/records of multiple classes/tables (e.g., study Customer VCTE order history to see how ordered products have changed over time; copy detail attributes from a past order to a new order), and master-detail windows allow the user to complete them without window navigation. Master-detail windows also allow the user to switch easy back and forth between tasks involving different classes, improving UI flexibility.
Compare this with UI where there is one window for both the search criteria and the list of search results, and a separate detail window for an object in the results list. This is common in web-based business apps, but is often an indication of poor UI or business process design. If you have a search-results window with a separate detail window, there are three possibilities:
The users are expected to work on multiple objects in the results list. However, if that were the case, the results list should be on a separate window with detail (as a master-detail) so the users don’t have to navigate back and forth between the search-results window and the detail window.
The users are expected to scan the results list for one object then work on that object in the detail window. However, if that were the case, then you need to improve your search/querying feature so the user can get to the object directly from the search criteria and skip the scan through a bunch of irrelevant results.
The users are expected to perform repeated searches, scanning the results list, then tweaking the search criteria to get the results they want. However, rarely is the users’ job to search. Search is something to do to get to the objects the users need in order to then do their job. If your users are spending a lot of time futzing in search, then again you should provide better search abilities so the user can get to the object(s) they need quickly to actually get some work done.
More at http://www.zuschlogin.com/?p=31.
