UI design/flow question

[Ronald S. Cook]

We're designing a Windows application. On a given form (let's say edit
customer), there would be a list of all the (let's say cars) that the
customer owns. We want the user to be able to click on a car (likely
hyperlinked) and go to the car form and view/edit all those details.

What's the best "flow" for this? Should we prompt the user that they've
made changes to the customer form and they must save or cancel before going
to the car form? Should we have any sort of "back" button to get back to
the customer form after viewing/editing the car form?

I'm just looking for general best/most common practices.

Thanks for any input,
Ron

[rowe_newsgroups]

Re: UI design/flow question

On Feb 27, 8:02 pm, "Ronald S. Cook" <r...@westinis. comwrote:

We're designing a Windows application. On a given form (let's say edit
customer), there would be a list of all the (let's say cars) that the
customer owns. We want the user to be able to click on a car (likely
hyperlinked) and go to the car form and view/edit all those details.
>
What's the best "flow" for this? Should we prompt the user that they've
made changes to the customer form and they must save or cancel before going
to the car form? Should we have any sort of "back" button to get back to
the customer form after viewing/editing the car form?
>
I'm just looking for general best/most common practices.
>
Thanks for any input,
Ron

How often will the user be switching between the customer and cars
screens? I ask because users hate being prompted all the time.

Also is this a web app or a desktop app?

Finally, if a desktop app is it a MDI, SDI or multiple SDI?

Thanks,

Seth Rowe

[Ronald S. Cook]

Re: UI design/flow question

Desktop app, SDI. Actually, we're using one shell form with "forms" as
actually user controls that we'll load into a panel on the shell form.

We definitely don't want to allow many forms to be open at a time,
especially if changes have been made in any but no update button yet
clicked.

We're dealing with very unsophisticated users for the most part.

Thanks,
Ron


"rowe_newsgroup s" <rowe_email@yah oo.comwrote in message
news:1172629962 .392183.191530@ v33g2000cwv.goo glegroups.com.. .

On Feb 27, 8:02 pm, "Ronald S. Cook" <r...@westinis. comwrote:

>We're designing a Windows application. On a given form (let's say edit
>customer), there would be a list of all the (let's say cars) that the
>customer owns. We want the user to be able to click on a car (likely
>hyperlinked) and go to the car form and view/edit all those details.
>>
>What's the best "flow" for this? Should we prompt the user that they've
>made changes to the customer form and they must save or cancel before
>going
>to the car form? Should we have any sort of "back" button to get back to
>the customer form after viewing/editing the car form?
>>
>I'm just looking for general best/most common practices.
>>
>Thanks for any input,
>Ron

>
>
How often will the user be switching between the customer and cars
screens? I ask because users hate being prompted all the time.
>
Also is this a web app or a desktop app?
>
Finally, if a desktop app is it a MDI, SDI or multiple SDI?
>
Thanks,
>
Seth Rowe
>

[Tom Leylan]

Re: UI design/flow question

Hi Ron: There are a couple of possibilities and issues to be considered.

From the sounds of it if there is no "Back" button (and if it is a WinForms
app I'd hesitate to add such a button) and if the user is in "edit mode"
when the form is displayed then there isn't too much the user can do to
close out that form except to select "Save" or "Cancel" is there? If there
is a significant amount of information you might add an "Apply" button to
apply changes (so far) without closing the form.

That way you don't actually display a message box unless you wanted to add a
warning that their changes would be lost when they edited something and then
pressed "Cancel".

Tom


"Ronald S. Cook" <rcook@westinis .comwrote...

Desktop app, SDI. Actually, we're using one shell form with "forms" as
actually user controls that we'll load into a panel on the shell form.
>
We definitely don't want to allow many forms to be open at a time,
especially if changes have been made in any but no update button yet
clicked.
>
We're dealing with very unsophisticated users for the most part.
>
Thanks,
Ron
>
>
"rowe_newsgroup s" <rowe_email@yah oo.comwrote in message
news:1172629962 .392183.191530@ v33g2000cwv.goo glegroups.com.. .

>On Feb 27, 8:02 pm, "Ronald S. Cook" <r...@westinis. comwrote:

>>We're designing a Windows application. On a given form (let's say edit
>>customer), there would be a list of all the (let's say cars) that the
>>customer owns. We want the user to be able to click on a car (likely
>>hyperlinked ) and go to the car form and view/edit all those details.
>>>
>>What's the best "flow" for this? Should we prompt the user that they've
>>made changes to the customer form and they must save or cancel before
>>going
>>to the car form? Should we have any sort of "back" button to get back
>>to
>>the customer form after viewing/editing the car form?
>>>
>>I'm just looking for general best/most common practices.
>>>
>>Thanks for any input,
>>Ron

>>
>>
>How often will the user be switching between the customer and cars
>screens? I ask because users hate being prompted all the time.
>>
>Also is this a web app or a desktop app?
>>
>Finally, if a desktop app is it a MDI, SDI or multiple SDI?
>>
>Thanks,
>>
>Seth Rowe
>>

>
>

[Cor Ligthert [MVP]]

Re: UI design/flow question

Ronald,

In my eyes a very simple problem. Almost every control is clickable (I
thought even all).
You can show a lot of immage boxes with cars, you can show textboxes with
names whatever.

In the click event of the one which is clicked, you open a showdialog form
with all the information of the client, he can only do one thing then, look
at the form and close it.

You can dynamicly build that page with controls.

http://www.vb-tips.com/dbpages.aspx?ID=e7510e67-92f3-49f6-b902-03abce36aa60

Cor

"Ronald S. Cook" <rcook@westinis .comschreef in bericht
news:eTMyHUuWHH A.4880@TK2MSFTN GP05.phx.gbl...

Desktop app, SDI. Actually, we're using one shell form with "forms" as
actually user controls that we'll load into a panel on the shell form.
>
We definitely don't want to allow many forms to be open at a time,
especially if changes have been made in any but no update button yet
clicked.
>
We're dealing with very unsophisticated users for the most part.
>
Thanks,
Ron
>
>
"rowe_newsgroup s" <rowe_email@yah oo.comwrote in message
news:1172629962 .392183.191530@ v33g2000cwv.goo glegroups.com.. .

>On Feb 27, 8:02 pm, "Ronald S. Cook" <r...@westinis. comwrote:

>>We're designing a Windows application. On a given form (let's say edit
>>customer), there would be a list of all the (let's say cars) that the
>>customer owns. We want the user to be able to click on a car (likely
>>hyperlinked ) and go to the car form and view/edit all those details.
>>>
>>What's the best "flow" for this? Should we prompt the user that they've
>>made changes to the customer form and they must save or cancel before
>>going
>>to the car form? Should we have any sort of "back" button to get back
>>to
>>the customer form after viewing/editing the car form?
>>>
>>I'm just looking for general best/most common practices.
>>>
>>Thanks for any input,
>>Ron

>>
>>
>How often will the user be switching between the customer and cars
>screens? I ask because users hate being prompted all the time.
>>
>Also is this a web app or a desktop app?
>>
>Finally, if a desktop app is it a MDI, SDI or multiple SDI?
>>
>Thanks,
>>
>Seth Rowe
>>

>
>