Fog Creek Software
Discussion Board

Database program UI question

I am currently working on a program whereby a number of my database tables have a one-to-many-to-many relationship, i.e., Customer is a one-to-many to Location, and Location is a one-to-many to Orders. My UI is presently built around an OutLook Bar (Sidebar) component with main items such as Customers, Orders, Employees, Vendors, etc. whereby clicking on an item provides the user with a particular view to work with Customers, Orders, Employee information, etc. While similar demos (dealing with Customers and Orders) have their bill-to and ship-to fields in the Customer table, the difference in my particular case resides in the fact that a Customer may have one or more service Locations as opposed to one whereby a particular location may serve as a billing and/or service location. Hence, a table separate from the Customer table, namely Location, addresses this need. My task then becomes one of creating a UI (with the Sidebar paradigm) that easily and intuitively lends itself to adding Location/s for each Customer in the database. As I realize there are many ways to accomplish this task (though not all equal), I am presently at a crossroads as to the best way to go about it (while Joel's book does an excellent job in providing guidelines as to what and what not to do when developing a UI, the implementation appears to be easier said than done) For example, I could add 'Location' to the sidebar to provide the user with a view to add or edit location/s for each customer in the database. However, I could also provide an icon in the Customer view to accomplish the same task or do both. The task is further compounded by the fact that each Location in turn has an equipment list generic to a particular Location (derives from the Equipment table) or Location is a one-to-many to Equipment. The point is, aside from my wanting a cleaner UI that provides more realestate by simply doing away with the usual clutter and unnecessary icons so commonly seen, I also want to do away with unnecessary form nesting whereby one has to drill down or click several times or more to get to a particular form or view. All told, any comments, suggestions, or general feedback regarding UI paradigms or methodology (preferably using the Outlook bar) from any of you who happen to develop or work on database program's dealing with one-to-many-to-many relationships, such as the one referred to herein, are most appreciated.

Marty Potokar
Friday, June 7, 2002

Very Similar to the problem I face at work.

The answer I would say is to take a step back and determine how your users are going to actually want to use the system.  A little bit of use case analysis can go a long way to simlifying the UI.

All the ting someone would want to modify quickly should be at their finger tips.  Things wanted less frequently can be further away.  THings like locations don't get changed very often, but the assignement of items to locations probably does.  It probably doesn't make sens to have a conoical list of equipment that gets modified separate from the locations, unless you are mostly modfying a few big-ticket items.

Friday, June 7, 2002

Again, ask the users. 

As Joel points out, you really want to find a metaphor that your user will be familiar with. 

For example, a common solution is to have the Bill to and ship to addresses on a single form, with a check box next to the billing address that says 'Same as shipping.'  Amazon, for example, use this.

This approach is popular because this is how it has been handled on paper invoices for years.  People find it familiar.

From an implementation point of view this causes problems because the structure of the forms do not reflect the structure of the tables.  However, it is usually best to develop systems for the users convenience.

Ged Byrne
Monday, June 10, 2002

*  Recent Topics

*  Fog Creek Home