Board index » Visual Studio » UI design/flow question

UI design/flow question

Visual Studio122
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


-
 

Re:UI design/flow question

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

Quote
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



-

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_newsgroups" <rowe_email@yahoo.com>wrote in message

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

>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







-

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.com>wrote...

Quote
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_newsgroups" <rowe_email@yahoo.com>wrote in message

news:1172629962.392183.191530@v33g2000cwv.googlegroups.com...

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

>>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

>









-

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" rel="nofollow" target="_blank">www.vb-tips.com/dbpages.aspx=e7510e67-92f3-49f6-b902-03abce36aa60



Cor



"Ronald S. Cook" <rcook@westinis.com>schreef in bericht

Quote
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_newsgroups" <rowe_email@yahoo.com>wrote in message

news:1172629962.392183.191530@v33g2000cwv.googlegroups.com...

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

>>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

>









-