If you were developing an application with menus, which would you use?
Printable View
If you were developing an application with menus, which would you use?
You didn't include BOTH! I didn't vote.
i would add both but its not letting me.Quote:
Originally Posted by dglienna
PM a moderator, and ask them to edit it. They can do it for you.
Might want to also include 'NONE'
As long as you are adding options.... "Neither" ....
It's different from "None" which would seem to indicate no menuing/navigation at all, while "Neither" indicates an alternative.
-tg
One app has a lot of forms, and is what used to be called "menu-driven", but is actually using command buttons that show up in the same place on different forms, with common functions being in the same place. It wouldn't make sense to have a menu to get to one part of the app, without going somewhere else first.
Some apps need a menu, some need a toolbar, and some need both.
Mine happens to need 'None" (or neither)
Haven't checked with Menus but with ToolBar you can't control the Validate Event of your controls (VB6.0)... :(
Though I use either on separate occasions/needs...
I did not vote in your poll because your poll sections are incomplete.
You should add a option for Both as has been previously suggested.
In my company, it is a development standard that both drop down menus and toolbars are used for EVERY piece of software we develop. It doesn't matter if it is one of our base products, or a utility program used in support of one of our base products, everything MUST have both.
Since we live in a MS-dominated world, my customers expect a FILE...EXIT menu - a VIEW menu - a HELP menu. These are so standard in app's.
My main VB client tool has menu's - 800x600 resolution/small physical monitor size means that you have to use real estate sparingly. But we also have a series of tool-bar like buttons in a square in the upper-left corner for users to navigate record selection/modification and saving.
Hi,
I agree with SZ.. We live and develop in a world where a generic design such as the first things an end user looks for is the
File, Edit, View blah balh blah
and such. Its the standard now set down by Microsoft, so if youve got an app developed without thsi, its gotta be pretty specfic in its nature to not have them.
The only one that springs to mind is a POS for bars where thouch screens are there for double quick access, but other than this, menus and toolbars are the norm, but event he back system that contols the front end of this kind of app is controleled by menus and toolbars, so they are always somewhere..
Kai
this is what my main screen looks like for an admin. many of the buttons/menus are not there for regular users by default.
I notice your drop down menu doesn't have a shortcut assigned to it (such as: Alt-F drops down File or Alt-A drops down Add, etc)
Those are pretty standard as well.
actually the drop downs do have alt tags assigned but for some reason, it never shows in the app until you hit the alt key. any fix for that?
I believe that is an XP thing - it happens in standard MS app's on my XP PRO workstations and laptop.Quote:
Originally Posted by BrailleSchool
I see that you have ADD and DELETE as main menus - it's closer to MS standard to put those in the FILE or EDIT menu. But being close to standard is what I believe users want.
Our menu bar is:
FILE EDIT VIEW FORMS OUTPUT HELP
FORMS and OUTPUT are not standard. FORMS is where our users go to see a drop-down menu of all the "maintenance forms" available. OUTPUT is where our users to get a drop down of REPORT and INFO DISPLAY query options.
Add, Edit, and Delete have the same options. They are used to Add, Edit, or Delete clients, operators, products. Of course, as I add more options, those menus will be updated accordingly. So if I put Add and Delete in the File menu, the Edit menu should go in there too, but then that wouldnt be MS standard. Unless I change Edit to Modify which would mean the same thing.Quote:
Originally Posted by szlamany
Poll options updated as per comments
Thank you si.
I have cast my vote for Both.
So you really don't use the ToolBar?Quote:
Originally Posted by szlamany
I've watched so many users struggle to figure out what toolbar picture means what functionality...Quote:
Originally Posted by dee-u
We created a frame with 9 buttons - NEW, VIEW, HISTORY, INQUIRE, PRINT, MODIFY, SAVE, CANCEL, DELETE.
They are clearly labeled - with words.
The user knows where they are (upper left - the kingdom of all screen space).
They get "hot" automatically as a user progresses through a procedure - so normally hitting ENTER is enough to trigger them.
We develop apps for users that were on mainframes three years ago. The biggest enemy is the mouse - since you must take your hand off the keyboard to navigate it. Granted, you cannot avoid the mouse 100% of the time, but every step you take towards that goal makes the "health claim entry processor" or the "cash window" processor happier.
But you can put Text in toolbars also?
Both. Like a web browser. Fx wouldn't be Fx if it didn't comply. Kiosk mode turns the menu off, and that just doesn't look right.
yes you can. you can put an image only, text only, or both. See examples I did :)Quote:
Originally Posted by dee-u
I use both in all of our apps.
You might also consider grouping related functions in menus more. For example, you could have a Prodcut menu, with the add and delete functions under it, an operator menu, with add, delete, etc under it, so that the layout of the menu tree matches your grouped boxes. I think it just makes it more intuitive for the user that way.
Bill
i am definately taking all your recommendations under consideration
Here's a screen shot of what we do:
mine is similar to yours then, just doesnt use a toolbar. just command buttons and the menu editor.
A difference that I notice is that you put buttons in a variety of spots.Quote:
Originally Posted by BrailleSchool
We subscribe to a philosophy that the upper-left of a screen is a "given" and that the right side and bottom are questionable.
We've had users connect to our app with less then 800x600 resolution - like really small stuff - and not be able to see flexgrid stuff on the right - so we know that they will do it if they can! ;)
We also believe that the motion of movement on the screen should be considered - so our lookup textboxes are very much near our command buttons which are of course right below the menu - so the real estate needed to travel is as tight as possible.
Users problably never notice this - maybe we are simply crazy :D
I know that without looking into your examples, I was just intrigued with szlamany's when he said "They are clearly labeled - with words." and I thought ToolBars could be labeled with words also... :)Quote:
Originally Posted by BrailleSchool
never used the tool bar control before yesterday, downloaded an example from PSC and it was pretty easy to figure out and remember. same with the data report, seems to be easy enough. wish VB was always like that hehe
But isn't the whole point of a toolbar to have "visual" buttons for NEW, OPEN, SAVE and the whole lot?Quote:
Originally Posted by dee-u
That's what a junior user expect - I believe.
I still don't know which toolbar picture in IE represents HISTORY vs. REFRESH...
If you are going to put TEXT into each TOOLBAR button, then you mine as well use COMMAND BUTTONS all over the screen - not quite a toolbar in the sense that the WINDOWS user expects.
The toolbar just seems to be more visually appealing but I got your point... :)
love the report icon, would you happen to have it?
Pinch it from the image that has been posted.
yeah, then id have to convert it to .ico.