Fog Creek Software
Discussion Board

Question Pertaining TO UI

Wanted to get some thoughts on a database UI that keeps track of Customers and Orders. Is it common practice to generate Customer Orders from one view or form as opposed to two? For example, it only makes sense to have one form or view that allows adding new customers as well as editing existing customer records with regard to changes in address, phone number and the like. Whereas another view or form would be provided to create new as well as edit existing orders for customers already in the database. However, the problem arises when a new customer (not in the database) phones in to place an order. If the person taking the call is working with orders, he/she would first have to enter the new customer using the Customer form/view and then proceed to the Orders form/view to create an order for this new customer which approach seems somewhat lame. This said, is it considered better practice to allow adding a new customer on the fly from the Orders form/view or do I allow an order to be created from the the Customer form/view in cases such as this one? Any thoughts or comments as to the most common or best way to accomplish this task in a database program are most appreciated.

Marty Potokar
Wednesday, April 3, 2002


I have had this problem myself.
I kept the forms seperate and added a button to both forms
that invoked the other. So if you are on the order form and the customer is new, then you press the add customer button. the customer form then displays in the "add customer" mode with whatever was entered in the Order form for the customer already filled in on the customer form.

The users liked this as they could approach the task from the Order or the Customer.

James Ladd
Thursday, April 4, 2002


Do you have enough screen real-estate to put both the orders form and the customers form together in one interface?  If it is a common scenario for a new customer to phone up and also want to place an order then it would be nice to build an interface that supports both tasks side-by-side. 

For common tasks/scenarios, a good golden rule is to reduce unnecessary interaction - don't make the user go elsewhere if something is done frequently.

A HCI expert would normally begin to analyse this problem by looking at the most common user scenarios that your program will support - functions for common scenarios would (if possible) be built into the main interface, without the need for additional pop-up windows, etc.

There is no correct answer - you just need to put yourself in the user's shoes.  Is switching between forms going to happen a lot? Is this likely to bug the hell out of the user after a while?

I hope your programme goes well,

Thursday, April 4, 2002


I don't know enough about your system to make a totally concrete suggestion, but it would seem that you'd want something along the lines of a modal dialog box over the orders view to enter the customer information before you enter the order. That way, visually, you'd be in a "sub-context" of the orders view. It would certainly "flow" better since you'd be working within the context of the orders view. This is assuming that your user has access to a keyboard of course ... :-)

Of course, since this sounds like a POS app, a lot of rules can be broken to make something like this work. More rules will be broken if you're using a touchscreen :-)


James Wann
Thursday, April 4, 2002

To build on sherlock's suggestion from above, try to combine both forms into one.

In the customer ID section, include a field for customer ID. If a value is entered into this field, when the user tabs to the next field, the system finds that customer id number and populates all of the other fields (name, address, etc).

You can include a button on this section of the form that updates the user's information with any changes made manually.

If no number is entered into the customer ID field, the name, address, etc. can be manually entered into their fields. When the form is submitted, if there is no customer ID number in the field, a new customer account is created and the customer ID is given to the customer at the end of the transaction.

If you need a different way of identifying customers (than by customer ID), you can do the same type of thing with a phone number or email address or whatever.

I think the best idea in this situation is to let the system do some work in the background to prevent the user from having to navigate between separate forms.

Benji Smith
Thursday, April 4, 2002

For an ECommerce syste, you want to get the absolute minimum amount of info to register the person.  Since you are taking the calls over the phone, I would assume that Phone NUmber is acceptable.  Other commonly used IDs are Zipcode and name.

"Hello, thanks for Calling X.  May I have your name please"

"Joe Snuffy"  Person enters in Joe Snuffy.  System checks for a match.  No Match?  Start a new record.  Mr. Snuffy may have called before and used a different name (Joeseph or Joey)  So If at anypoint you have enough info to Merge this record with an old record you use it.

"Yeah, I'm calling about this Gizmo I purchased.  I need an AC Adpter for it."

"Do you have a Warreny number, Sir?"

"Yeahs its ABC12345"  Bingo,, No You can say that Joe Snuffy is an Alias for Snuffy, Joespeh R.

What I'm doing here is called Use Case analysis.  I got the Term from UML, but it actually predates it by a lot.  I think they Jacobson's big contribution to the UML system.  Before you design UI, do some simple analysis of the following things:

Who is going to use the system.  Include the different type of peopl that are going to be calling up. 

How are these people going to be using the system.  What are the steps they are going to go through.

It sounds like you are thinking from an operators perspective.  In this case, the most important thing is for them to be able to get to the info quickly.  Usablility is focused on speed of operation as opposed to speed of learning.  Minimize scrolling.  Put more stuff on a page since people will quickly learng where to find it. 

Good Luck,

Friday, April 5, 2002

*  Recent Topics

*  Fog Creek Home