Master-Detail GUI in .net [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.

---

This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.

开发者_Go百科

Closed 8 years ago.

Improve this question

This type of UIs are frequently displayed in various web-Sites and .net books.

Are these types of User-Interfaces acceptable and/or popular in commercial and/or customized Business Software?

Please note

(1) the use of Binding Navigator, and

(2) the placement of Master-grid, Detail-grid and Input Area in the same form.

To me a search facility is always needed no matter how trivial the UI is, which is not available here. And of course I don't find any relevance of using a Binding Navigator in any UI that deals with huge data.

---

Missing search was the first thing I noticed too.

So I think you need an advanced search for the main grid, as well as filter and sort options for columns.

With regards to the master-detail, it may be more intuitive to have the ability to select (double click/enter) from the main grid and that would bring up the details for the order to edit, as well as a similar grid with order details.

The reason that is more intuitive is because the user is dealing with a separate window each time - allowing them to deal with the task in hand, without being bashed over the head with a cluttered main window with everything crammed in.

---

May be it is not a perfect interface for web but it is nice, for example, for some ERP forms, where changing between forms is a waste of time when you really don't need it.

For example, when you are registering orders you won't need to change between forms, you are doing same work over and over in the same window and this save you time (more time if you can do this work only with the keyboard).

So, defining an apropiate interface is always related for the use it is suposed to.

---

In this example, I would put the orders-grid on one dialog, and the order detail view on another. I would then move the first/previous/next/last buttons to the detail dialog, enabling the user to move from one order to the next, without going back to the grid.

I would also copy the new/delete buttons to the detail dialog. Again, enabling the user to delete the current order or create a new one (in the same window or a new one).

Also I would add print buttons to both overview and detail. Business software users love to print stuff. :)

Putting everything on one dialog should only be done, if there isn't much information and a detail dialog feels like an overkill.

---

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.