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.
Very Similar to the problem I face at work.
Again, ask the users.
Fog Creek Home