menus vs. switchboards

[JasonL]

Hey all,
Just a very generalized question/opinion. IMO one of the most annoying and
over-used UI designs is the maximized forms and switchboards with big, ugly
command buttons. To perform any useful operation, the user must navigate
from the "main" switchboard, to the next, to the next to finally get to the
form they want. Then to do perform another task, close the form and navigate
back up the chain of switchboards and down another. It's as though DOS had
gotten a 3D look with customizable colors.
I prefer to use a MDI form as my main form with menus to navigate, even if
the MDI form only acts as a 'container' for several different forms.
However, I've heard it argued (even here) that an MDI form should only be
used for 'truly MDI' applications like a souped-up Notepad or Excel. But IMO
if I have only one instance of a customer info form and only one instance of
an invoice form, to me that is still multiple-documents.
I only bring this up because I'm taking over a Point of Sale project. The
original authors used the switchboard model and it drives me nuts. I'm
supposed to do a new version to add functionality and fix many bugs. I'd
like to tackle the UI at the same time.
Any other thoughts or opinions?
-Jason

[Raymond R Cassick]

I think that most people are correct in saying that a MDI application is
best left for those style apps that require multiple DOCUMENTS to be open at
a time.

Now, with that said, I also feel that some peoples view of using the MDI
capabilities of that design model are quite limited. They ONLY see a MDI
design that allows you to open multiple documents at a time, each one being
in their own window, and they don't really see that this design is easily
(and with great simplicity) used to create an application that has to
quickly change screens.

I have used this many times in the past with great success. Create a MDI
parent form with your menu bars and tool bars, then create all your
secondary screens as MDI child windows, with NO title bar, and maximize them
as they load. This gives you a single screen application that can use forms
as it's various screens, but does not have the look of a standard MDI
application.

To me, this sure beats trying to dynamically change a main screen at
runtime.



"JasonL" <jasonl@wirelesszone.com> wrote in message
news:39465a36$1@news.devx.com...
> Hey all,
> Just a very generalized question/opinion. IMO one of the most annoying and
> over-used UI designs is the maximized forms and switchboards with big,
ugly
> command buttons. To perform any useful operation, the user must navigate
> from the "main" switchboard, to the next, to the next to finally get to
the
> form they want. Then to do perform another task, close the form and
navigate
> back up the chain of switchboards and down another. It's as though DOS had
> gotten a 3D look with customizable colors.
> I prefer to use a MDI form as my main form with menus to navigate, even if
> the MDI form only acts as a 'container' for several different forms.
> However, I've heard it argued (even here) that an MDI form should only be
> used for 'truly MDI' applications like a souped-up Notepad or Excel. But
IMO
> if I have only one instance of a customer info form and only one instance
of
> an invoice form, to me that is still multiple-documents.
> I only bring this up because I'm taking over a Point of Sale project. The
> original authors used the switchboard model and it drives me nuts. I'm
> supposed to do a new version to add functionality and fix many bugs. I'd
> like to tackle the UI at the same time.
> Any other thoughts or opinions?
> -Jason
>
>

[Kent]

My opinion, too. But, having said that, there are *some* users who do not or
will not look in a menu unless somebody has shown them which choice they
want to select from the menu. I'd be surprised if they could find Help in a
program the first time they opened it. If you want to tailor a program for
this type of user, then a switchboard of sorts makes a lot of sense.

Having a switchboard is still no excuse for clunky controls and gaudy
colours, though. IMHO, a good compromise would use standard buttons and
colours, start in a switchboard interface and have an option to use/start in
a "classic" interface.

--
Kent
rkcripps@softhome.net

JasonL <jasonl@wirelesszone.com> wrote in message
news:39465a36$1@news.devx.com...
> Hey all,
> Just a very generalized question/opinion. IMO one of the most annoying and
> over-used UI designs is the maximized forms and switchboards with big,
ugly
> command buttons. To perform any useful operation, the user must navigate
> from the "main" switchboard, to the next, to the next to finally get to
the
> form they want. Then to do perform another task, close the form and
navigate
> back up the chain of switchboards and down another. It's as though DOS had
> gotten a 3D look with customizable colors.
> I prefer to use a MDI form as my main form with menus to navigate, even if
> the MDI form only acts as a 'container' for several different forms.
> However, I've heard it argued (even here) that an MDI form should only be
> used for 'truly MDI' applications like a souped-up Notepad or Excel. But
IMO
> if I have only one instance of a customer info form and only one instance
of
> an invoice form, to me that is still multiple-documents.
> I only bring this up because I'm taking over a Point of Sale project. The
> original authors used the switchboard model and it drives me nuts. I'm
> supposed to do a new version to add functionality and fix many bugs. I'd
> like to tackle the UI at the same time.
> Any other thoughts or opinions?
> -Jason
>
>

[JasonL]

Kent <rkcripps@softhome.net> wrote in message news:3946eb67@news.devx.com...
> My opinion, too. But, having said that, there are *some* users who do not
or
> will not look in a menu unless somebody has shown them which choice they
> want to select from the menu. I'd be surprised if they could find Help in
a
> program the first time they opened it. If you want to tailor a program for
> this type of user, then a switchboard of sorts makes a lot of sense.
Good point. This reminds me of something I read by (I believe) Alan Cooper
to tailor the UI to the user. So if the user is going to seldomly or
sporadically use the application a switchboard may indeed ease the
navigation.
In my case with this Point of Sale application, I think I'm still going to
go with the MDI/menus/toolbars. The majority of the time the users will only
be creating new invoices. I'll provide hot keys (F** or ctrl-N) for this
function, so they actually don't have to go to the menu. For other rarely
used functions, they'll have to navigate the menus (though of course I'll
provide a user manual and help files that'll probably go unused).
My only fear with the MDI interface is that inexperienced users will often
open many forms without ever closing. I've seen that before, 80 or so
minimized windows in one app. But currently the users are creating multiple
instances of the application to achieve the multiple document effect, so I
think they're dictating an MDI interface.
Any thoughts on controlling the open/never close syndrome?

[Raymond R Cassick]

Have you considered using an 'Outlook' bar instead of a group of large
buttons for your switch board effect? It might look a little cleaner AND you
can offer a way to hide it and allow the user to use menus if they want.
This would offer a type of expert mode for users that know how the software
works, and a 'easy' mode for people that know how to use it.

"JasonL" <jasonl@wirelesszone.com> wrote in message
news:3947805f$1@news.devx.com...
>
> Kent <rkcripps@softhome.net> wrote in message
news:3946eb67@news.devx.com...
> > My opinion, too. But, having said that, there are *some* users who do
not
> or
> > will not look in a menu unless somebody has shown them which choice they
> > want to select from the menu. I'd be surprised if they could find Help
in
> a
> > program the first time they opened it. If you want to tailor a program
for
> > this type of user, then a switchboard of sorts makes a lot of sense.
> Good point. This reminds me of something I read by (I believe) Alan Cooper
> to tailor the UI to the user. So if the user is going to seldomly or
> sporadically use the application a switchboard may indeed ease the
> navigation.
> In my case with this Point of Sale application, I think I'm still going to
> go with the MDI/menus/toolbars. The majority of the time the users will
only
> be creating new invoices. I'll provide hot keys (F** or ctrl-N) for this
> function, so they actually don't have to go to the menu. For other rarely
> used functions, they'll have to navigate the menus (though of course I'll
> provide a user manual and help files that'll probably go unused).
> My only fear with the MDI interface is that inexperienced users will often
> open many forms without ever closing. I've seen that before, 80 or so
> minimized windows in one app. But currently the users are creating
multiple
> instances of the application to achieve the multiple document effect, so I
> think they're dictating an MDI interface.
> Any thoughts on controlling the open/never close syndrome?
>
>

[Tim Hitchings]

Is the POS a touch screen application?
If so I would think that menu's would be a no no.
If the user should never have to have two windows open the app should
never have two or more windows open.
I also agree that an outlook bar style navigation with a splitter
control that can host forms would be the way to go.
Why must customer info be on one form and invoices on another? Why not
customer info in one portion of a form with the ability to navigate thru
that customers invoices in another portion?
If initially ALL the customer info requires the entire screen to verify
before browsing invoices then collapse the full customer info to a
smaller amount of needed customer fields and then fill with invoice

"JasonL" <jasonl@wirelesszone.com> wrote in message
news:39465a36$1@news.devx.com...
> Hey all,
> Just a very generalized question/opinion. IMO one of the most annoying
and
> over-used UI designs is the maximized forms and switchboards with big,
ugly
> command buttons. To perform any useful operation, the user must
navigate
> from the "main" switchboard, to the next, to the next to finally get
to the
> form they want. Then to do perform another task, close the form and
navigate
> back up the chain of switchboards and down another. It's as though DOS
had
> gotten a 3D look with customizable colors.
> I prefer to use a MDI form as my main form with menus to navigate,
even if
> the MDI form only acts as a 'container' for several different forms.
> However, I've heard it argued (even here) that an MDI form should only
be
> used for 'truly MDI' applications like a souped-up Notepad or Excel.
But IMO
> if I have only one instance of a customer info form and only one
instance of
> an invoice form, to me that is still multiple-documents.
> I only bring this up because I'm taking over a Point of Sale project.
The
> original authors used the switchboard model and it drives me nuts. I'm
> supposed to do a new version to add functionality and fix many bugs.
I'd
> like to tackle the UI at the same time.
> Any other thoughts or opinions?
> -Jason
>
>

[JasonL]

Tim Hitchings <timh@shersoft.com> wrote in message
news:394795ee$1@news.devx.com...
> Is the POS a touch screen application?
No.
> I also agree that an outlook bar style navigation with a splitter
> control that can host forms would be the way to go.
Hmmm...everyone seems to like outlook bars, I'll have to look into that. I'm
already envisioning some possibilities, Thanks for your responses / ideas.
BTW, I haven't seen this as a builtin VB control. Is there a recommended
third party one, or should I create my own?
> Why must customer info be on one form and invoices on another?
Actually, they are on one form. Sorry, I gave a confusing example.
In my observations of users with the current system, they often run multiple
instances of the application. As they are completing an invoice for a
customer who just left (yeah, it's bad business practice IMO but they
actually sometimes leave several invoices printed but incomplete and
unposted until a later time) they are looking up an old invoice for the
current customer, and looking up several inventory items for another
salesperson who doesn't have access to a POS terminal, and oh, by the way
they accepted an A/R payment from a regular customer a few minutes ago and
haven't finished filling in that transaction in the POS. And users and
managers all agree that this type of multi-tasking must be available in the
new system.
Another idea I have had is to split the strictly POS functions into one,
simple/single form style app and the A/R, inventory, administration type
functionalities into a seperate MDI app.

-Jason

[Raymond R Cassick]

The one from vbAccelerator is great, FREE (a big plus) and includes soirce
code for it.

URL: http://vbaccelerator.com/

"JasonL" <jasonl@wirelesszone.com> wrote in message
news:3947a64e@news.devx.com...
>
> Tim Hitchings <timh@shersoft.com> wrote in message
> news:394795ee$1@news.devx.com...
> > Is the POS a touch screen application?
> No.
> > I also agree that an outlook bar style navigation with a splitter
> > control that can host forms would be the way to go.
> Hmmm...everyone seems to like outlook bars, I'll have to look into that.
I'm
> already envisioning some possibilities, Thanks for your responses / ideas.
> BTW, I haven't seen this as a builtin VB control. Is there a recommended
> third party one, or should I create my own?
> > Why must customer info be on one form and invoices on another?
> Actually, they are on one form. Sorry, I gave a confusing example.
> In my observations of users with the current system, they often run
multiple
> instances of the application. As they are completing an invoice for a
> customer who just left (yeah, it's bad business practice IMO but they
> actually sometimes leave several invoices printed but incomplete and
> unposted until a later time) they are looking up an old invoice for the
> current customer, and looking up several inventory items for another
> salesperson who doesn't have access to a POS terminal, and oh, by the way
> they accepted an A/R payment from a regular customer a few minutes ago and
> haven't finished filling in that transaction in the POS. And users and
> managers all agree that this type of multi-tasking must be available in
the
> new system.
> Another idea I have had is to split the strictly POS functions into one,
> simple/single form style app and the A/R, inventory, administration type
> functionalities into a seperate MDI app.
>
> -Jason
>
>

[Tim Hitchings]

Sheridan has an ActiveListBar and ActiveThreedPlus which has a splitter
that can host forms.
http://www.shersoft.com

"JasonL" <jasonl@wirelesszone.com> wrote in message
news:3947a64e@news.devx.com...
>
> already envisioning some possibilities, Thanks for your responses /
ideas.
> BTW, I haven't seen this as a builtin VB control. Is there a
recommended
> third party one, or should I create my own?

[JasonL]

Looked at it, and so far looks great. Thanks
-Jason
Raymond R Cassick <raycass@adelphia.net> wrote in message
news:3947bb14@news.devx.com...
> The one from vbAccelerator is great, FREE (a big plus) and includes soirce
> code for it.
>
> URL: http://vbaccelerator.com/
>
> "JasonL" <jasonl@wirelesszone.com> wrote in message
> news:3947a64e@news.devx.com...
> >
> > Tim Hitchings <timh@shersoft.com> wrote in message
> > news:394795ee$1@news.devx.com...
> > > Is the POS a touch screen application?
> > No.
> > > I also agree that an outlook bar style navigation with a splitter
> > > control that can host forms would be the way to go.
> > Hmmm...everyone seems to like outlook bars, I'll have to look into that.
> I'm
> > already envisioning some possibilities, Thanks for your responses /
ideas.
> > BTW, I haven't seen this as a builtin VB control. Is there a recommended
> > third party one, or should I create my own?
> > > Why must customer info be on one form and invoices on another?
> > Actually, they are on one form. Sorry, I gave a confusing example.
> > In my observations of users with the current system, they often run
> multiple
> > instances of the application. As they are completing an invoice for a
> > customer who just left (yeah, it's bad business practice IMO but they
> > actually sometimes leave several invoices printed but incomplete and
> > unposted until a later time) they are looking up an old invoice for the
> > current customer, and looking up several inventory items for another
> > salesperson who doesn't have access to a POS terminal, and oh, by the
way
> > they accepted an A/R payment from a regular customer a few minutes ago
and
> > haven't finished filling in that transaction in the POS. And users and
> > managers all agree that this type of multi-tasking must be available in
> the
> > new system.
> > Another idea I have had is to split the strictly POS functions into one,
> > simple/single form style app and the A/R, inventory, administration type
> > functionalities into a seperate MDI app.
> >
> > -Jason
> >
> >
>
>

[Raymond R Cassick]

No problem..

"JasonL" <jasonl@wirelesszone.com> wrote in message
news:394939ae@news.devx.com...
> Looked at it, and so far looks great. Thanks
> -Jason
> Raymond R Cassick <raycass@adelphia.net> wrote in message
> news:3947bb14@news.devx.com...
> > The one from vbAccelerator is great, FREE (a big plus) and includes
soirce
> > code for it.
> >
> > URL: http://vbaccelerator.com/
> >
> > "JasonL" <jasonl@wirelesszone.com> wrote in message
> > news:3947a64e@news.devx.com...
> > >
> > > Tim Hitchings <timh@shersoft.com> wrote in message
> > > news:394795ee$1@news.devx.com...
> > > > Is the POS a touch screen application?
> > > No.
> > > > I also agree that an outlook bar style navigation with a splitter
> > > > control that can host forms would be the way to go.
> > > Hmmm...everyone seems to like outlook bars, I'll have to look into
that.
> > I'm
> > > already envisioning some possibilities, Thanks for your responses /
> ideas.
> > > BTW, I haven't seen this as a builtin VB control. Is there a
recommended
> > > third party one, or should I create my own?
> > > > Why must customer info be on one form and invoices on another?
> > > Actually, they are on one form. Sorry, I gave a confusing example.
> > > In my observations of users with the current system, they often run
> > multiple
> > > instances of the application. As they are completing an invoice for a
> > > customer who just left (yeah, it's bad business practice IMO but they
> > > actually sometimes leave several invoices printed but incomplete and
> > > unposted until a later time) they are looking up an old invoice for
the
> > > current customer, and looking up several inventory items for another
> > > salesperson who doesn't have access to a POS terminal, and oh, by the
> way
> > > they accepted an A/R payment from a regular customer a few minutes ago
> and
> > > haven't finished filling in that transaction in the POS. And users and
> > > managers all agree that this type of multi-tasking must be available
in
> > the
> > > new system.
> > > Another idea I have had is to split the strictly POS functions into
one,
> > > simple/single form style app and the A/R, inventory, administration
type
> > > functionalities into a seperate MDI app.
> > >
> > > -Jason
> > >
> > >
> >
> >
>
>

[Matthew Cromer]

"Raymond R Cassick" <raycass@adelphia.net> wrote:
>Have you considered using an 'Outlook' bar instead of a group of large
>buttons for your switch board effect? It might look a little cleaner AND
you
>can offer a way to hide it and allow the user to use menus if they want.

Outlook <gaack, vomit> Bar <puke>?

(sorry, I can't stand outlook or the outlook bar. If you really want to
see the complete logical extension of the MS Outlook UI monstrosity, look
at InstallShield for Windows Installer).

[Raymond R Cassick]

Interesting...

I really am interested in why you are so revolted by the layout of outlook.
It see very little difference between the outlook bar and a tool bar as far
as navigation is concerned.

"Matthew Cromer" <matthew@sdaconsulting.com> wrote in message
news:397c7f10$1@news.devx.com...
>
> "Raymond R Cassick" <raycass@adelphia.net> wrote:
> >Have you considered using an 'Outlook' bar instead of a group of large
> >buttons for your switch board effect? It might look a little cleaner AND
> you
> >can offer a way to hide it and allow the user to use menus if they want.
>
> Outlook <gaack, vomit> Bar <puke>?
>
> (sorry, I can't stand outlook or the outlook bar. If you really want to
> see the complete logical extension of the MS Outlook UI monstrosity, look
> at InstallShield for Windows Installer).

[Darin Darin]

Someone else might have already mentioned this but there is another way.

Use UserControls. Create a user control just as you would a form. Create
a normal SDI form to host it.

Then, construct the SDI form as normal, when you need to show one of the
"mdi child forms", dynamically create the user control onto the SDI form,
position it and your done.

You need 2 child forms? just create 2 user controls.

Want to float the child form in a seperate window from the main form (for
whatever reason). dynamically create the user control into a different sdi
form.

This is one of the most underutilized techniques I know of in vb. MDI forms
aren't terribly good for very many types of apps. a well thought out SDI
app that makes good use of splitters and tabs works far better, IMO.

Check out the latest word or excel. MS themselves have even ditched MDI.
That said, I've still got MDI apps that work pretty dang nice too.

"JasonL" <jasonl@wirelesszone.com> wrote:
>Hey all,
>Just a very generalized question/opinion. IMO one of the most annoying and
>over-used UI designs is the maximized forms and switchboards with big, ugly
>command buttons. To perform any useful operation, the user must navigate
>from the "main" switchboard, to the next, to the next to finally get to
the
>form they want. Then to do perform another task, close the form and navigate
>back up the chain of switchboards and down another. It's as though DOS had
>gotten a 3D look with customizable colors.
>I prefer to use a MDI form as my main form with menus to navigate, even
if
>the MDI form only acts as a 'container' for several different forms.
>However, I've heard it argued (even here) that an MDI form should only be
>used for 'truly MDI' applications like a souped-up Notepad or Excel. But
IMO
>if I have only one instance of a customer info form and only one instance
of
>an invoice form, to me that is still multiple-documents.
>I only bring this up because I'm taking over a Point of Sale project. The
>original authors used the switchboard model and it drives me nuts. I'm
>supposed to do a new version to add functionality and fix many bugs. I'd
>like to tackle the UI at the same time.
>Any other thoughts or opinions?
>-Jason
>
>