Easiest/most idiot-proof UI for database?

[Pieter Linden]

Hi,
I have been asked to fix a database that deals with Customers and
Sales/Repairs that they request. The company is a clock shop, and the
users are NOT very technically savvy. In a nutshell, the process goes
like this:
1. Customer comes to shop.
2. Staff person looks user up by phone number, and finds all the
client's records
3. If the customer is dropping off a new item, the staff person
duplicates the record (I think) and adds the "Invoice" information.
4. As the repair is changes status, it is updated in the database.
5. Once the repair is complete and the customer comes to pick the
piece up, the invoice is printed and the customer takes both the items
repaired and the invoice.

There are a zillion ways of doing this, I know. I was thinking of
presenting the user with an interface where he could:
1. Find a customer (by Phone number).
2. Show the open and closed invoices on two separate(?) subforms. - or
just put a dropdown to do the filtering.
3. Include a button on the subform to allow the viewing/opening of the
Invoice report based on the clicked job. (One invoice per job - "house
rules".)

is this a reasonable approach or am I off my rocker? There's no need
to keep any "location history" for a client. Just the current
name/address/phone number is fine.

Any ideas on which is the best way to go with this, or would I have to
just build it and test it out on the users? Keep in mind, these users
are serious technical neophytes...

Thanks,

Pieter

[Tom van Stiphout]

On 14 Jan 2004 16:15:49 -0800, pi********@hotmail.com (Pieter Linden)
wrote:

Do your client a favor, and insert a prototyping phase in your
development lifecycle. Whip up some ideas - not necessarily in
Access, and run them by your client to gauge their reaction.

-Tom.

Hi,
I have been asked to fix a database that deals with Customers and
Sales/Repairs that they request. The company is a clock shop, and the
users are NOT very technically savvy. In a nutshell, the process goes
like this:
1. Customer comes to shop.
2. Staff person looks user up by phone number, and finds all the
client's records
3. If the customer is dropping off a new item, the staff person
duplicates the record (I think) and adds the "Invoice" information.
4. As the repair is changes status, it is updated in the database.
5. Once the repair is complete and the customer comes to pick the
piece up, the invoice is printed and the customer takes both the items
repaired and the invoice.

There are a zillion ways of doing this, I know. I was thinking of
presenting the user with an interface where he could:
1. Find a customer (by Phone number).
2. Show the open and closed invoices on two separate(?) subforms. - or
just put a dropdown to do the filtering.
3. Include a button on the subform to allow the viewing/opening of the
Invoice report based on the clicked job. (One invoice per job - "house
rules".)

is this a reasonable approach or am I off my rocker? There's no need
to keep any "location history" for a client. Just the current
name/address/phone number is fine.

Any ideas on which is the best way to go with this, or would I have to
just build it and test it out on the users? Keep in mind, these users
are serious technical neophytes...

Thanks,

Pieter