Why am I the Only One Interested in Doing This?

Suppose you have a popup menu that drops down from the menu bar and this popup has a list of items to be checked or unchecked. Further suppose that the typical user has to check/uncheck 5 items before doing something else. Isn't this a common scenario?

Normally, doing this will take 10 mouse clicks because, after clicking each item, the popup disappears and the user will have to click on the menu bar to have the same popup reappear over and over again. If the user wants to make certain of the last entry, that takes one more click for a total of 11 clicks. You don't have to be an ergonomic genius to figure out that this would only take 6 mouse clicks if the popup didn't disappear.

So, why am I the only one interested in preventing popups from disappearing when items are checked/unchecked? Are programmers ergonomically retarded?

http://www.codeguru.com/forum/showth...hreadid=207994

Quote:

---

You don't have to be an ergonomic genius to figure out that this would only take 6 mouse clicks if the popup didn't disappear.

---

You don't need to be a genius to further figure out that if the menu does not automatically disappear before the user has a chance to click the 7th time, but not until after the 6th mouth click. And what if the user made 3 mouse clicks and wants the menu to go away?

Menus are never meant to be used to fill out multiple checkboxes at a time. Dialog boxes are more appropriate for this purpose.

Quote:

---

Originally posted by AnthonyMai


You don't need to be a genius to further figure out that if the menu does not automatically disappear before the user has a chance to click the 7th time, but not until after the 6th mouth click. And what if the user made 3 mouse clicks and wants the menu to go away?

Menus are never meant to be used to fill out multiple checkboxes at a time. Dialog boxes are more appropriate for this purpose.

---

Your first sentence makes no sense.

If the user wants to make the popup menu go away, the user can do this by clicking anywhere on the window. If the user clicks on the title bar, this counts as one extra click, but, more than likely, the user will click on another item on the menu bar or on the popup, in which case, this does not count as an extra click.

Regarding your last sentence, why should I care what Microsoft's intent behind a menu was? There are only three relevant issues here:

1. Is it better?
2. Can it be done?
3. How can it be done?

I have proven that it is better. I know it can be done because I did it using Borland OWL classes. Now, I want to know how to do it with MFC.

Quote:

---

Regarding your last sentence, why should I care what Microsoft's intent behind a menu was?

---

Well, you might care, since 99.99% of users will expect the default windows behaviour.

I'm sorry to say this, but I agree with A Mai here. If you need to do this, then your GUI design should probably be different. Why not have a toolbar with buttons that can be on / off ?

Anthony:
microsoft has implemented this feature in MS Word for a few menus: certain menus of the "drawing" toolbar have a small top stripe that turns the menus into floating toolbars

the geoworks suite allowed to "pin down" all menus, and I must say working with this feature was great.

OTOH I share (some of) your concerns: it would be a non-standard feature, and essentially the menu drawing would have to be implemented manually;
I already digged into the docs for a solution, but nay, I found no way twisting the built-in menus, so if someone wver implements that, s/he will be constantly hunting behind MS changes of the menu look.

There are applications that provide "tear off" context menus. You right-click to get the menu, then click some "sticky" item, or drag a pull-off bar, and it becomes like a text toolbar with an x in the corner and a small window bar so you can move it around.

It is quite useful and handy.

gimp by gnu uses this, for instance.

Jeff

i dunno abt the techi gods but u ask me i say on the right click throw up a small dialog box... change its border settings and all that jazz to something simple and neat... this way any modifications to be made later is a lot simpler as the details are separated... well this is my opinion or this is how i would normally tackle this situation..

u might have to remember some values each time u throw/close the dialog box.. but (never tried this .. will try it now) can i make the dialog box dynamically in the constructor of the owner window's class and keep calling ptr->DoModal() each time and assume the previous values will be retained?? like if i had checked a button will the button remain checked?? and lets say the destructor frees the pointer.... hope this works would make some code of mine better.. thanx a lot..


Ganesh

In designing a UI interface, it is important to do it in a standard way that the user is familiar with.

Menu was NOT the invention of Microsoft. And menu was designed for selecting one action or task at a time. That's why menus disappear after one mouse click. If you have to do two mouse clicks to make the menu go away (one to select your item, and the other to "click away" the menu), that is very none-intuitive and inconvenient to use.

If you really want to do it, there is always plenty of ways of doing it the way you want. The bugger problem is how do you educate/persuade your users to accept the none-conventional menu?

It's possible to have the best of both worlds with the tear-off scenario.

Menus work normally until they are torn off.

When they are torn off, they become a separate dialog, behaving like a floating toolbar. It would not be necessary to use this to do anything. It's merely a convenience, and one that might be greatly appreciated.

Jeff

Right, Jeff :) Then again, in a majority of smaller applications, it is sufficient to have seperate toolbars and menubars. I have to say that Gimp is neat and a good program, but I don't like its UI. Why not ? Well it's based on a "Unix paradigm" that it's more important to be powerful than to be accessible. Its UI is not intuitive and you'll have to spend some time with it to actually appreciate it.

The best solutions combine both things, they are both intuitive and powerful in the long run.

Of course this is only my opinion ;)

Quote:

---

Originally posted by Yves M


Well, you might care, since 99.99% of users will expect the default windows behaviour.

I'm sorry to say this, but I agree with A Mai here. If you need to do this, then your GUI design should probably be different. Why not have a toolbar with buttons that can be on / off ?

---

For some programs, e.g., image editing programs, a tool bar is unnecessary clutter that obstructs the view of the client area, e.g., an image.

If some method is ergonomically better without consideration of the user's prior expectations, that is sufficient ethical reason to institute that method. The user should be educated of better methods and programmers should not yield to standard practices that are bad habits in disguise. And, it doesn't matter who invented the bad habits or how good their intentions were at the time. In the long run, society will benefit from abandoning their bad habits.

aruzinsky,

I think you have to be careful of branding some behaviors as bad/good habit.
For some people eating snails or shrimp is disgusting, for other it is considered to be delicacy. It is highly subjective and you should not generalize your opinion or force it on users since their opinion is what counts.

For me change from VS 6.0 to VS 7.0 (.NET) was (is) hard since MS changed all shortcut keys that I was accustomed to since Visual Studio was called Visual Bench (very beginning of visual tools). I found it hard to follow especially double key shortcuts and I think MS should have left it alone.

There is nothing impossible in windows programming it is just question of justification for time invested in changing default behavior. Menu is very special animal an you are free to reinvent a wheel…

Question remains if user will appreciate it.

As John points it out, it is not always clear what a bad habit is. I definitely agree that if something is bad then it should be changed. But menus aren't inherently bad. They are just bad for your UI. So instead of changing the behaviour of a menu, I rather suggest you use something which is not a menu and fullfills your needs.

Yes, you can have buttons which only get pushed if you press the right mouse button. This might actually be useful in some application, but then make it not look like a button and don't call it a button, or the user will get confused and tired of the program.

Quote:

---

Originally posted by JohnCz
aruzinsky,

I think you have to be careful of branding some behaviors as bad/good habit.

---

I am careful, it is you who carelessly brand some conventional methods as "Good," while branding my unconventional method as "Bad."

Quote:

---

Originally posted by JohnCz
It is highly subjective and you should not generalize your opinion or force it on users since their opinion is what counts.

---

There is nothing subjective or opinionated about counting the number of mouse clicks and key pressings needed to accomplish a task. If someone has a method that uses a smaller number of mouse and key clicks, I will immediately revise my thinking on this matter. But, don't accuse me of being subjective when your reasons for not doing it my way include such nonsense as "menus weren't meant for that," or "99.99% of users expect a dialog box for this." I suggest that programmers should start counting the number of clicks needed to accomplish a task.

1. Right-click -> select Properties (or whatever you want to call the dialog box).
2. Select/deselect your options.
3. Click OK

In your example, this takes 8 clicks (5 check/unchecks). Your version takes 7 clicks, if you count the click to close the popup. This solution not only solves your problem without an inordinate number of "extra" clicks, but doesn't force a non-intuitive interface upon a user who is trying to learn how to use your program.

The above posters are right, by providing a common interface, a user knows what to expect when a particular type of interface is presented. Examples: menus go away when an item is selected; menu items with a "..." at the end bring up some other interface steps; dialog boxes stay there until the "OK" or "Cancel" is clicked; right-click menus are sensitive to the location of the click, while menu bar menus aren't, etc., etc.

Deviation from these common behaviors confuses and intimidates the user, which is exactly opposite of the goal of a UI programmer. In addtion, any other programmers that have to try to figure out your code will see a popup menu and assume one thing, forcing them to dig deeper to figure out what you were doing.

When developing software, you need to evaluate all of the consequences of the decisions you make, and be open to other solutions that are better all around, not just in one area.

Bottom Line: Just because you can do a thing doesn't mean that you should.

Quote:

---

Originally posted by JohnCz

For me change from VS 6.0 to VS 7.0 (.NET) was (is) hard since MS changed all shortcut keys that I was accustomed to since Visual Studio was called Visual Bench (very beginning of visual tools). I found it hard to follow especially double key shortcuts and I think MS should have left it alone.
[/B]

---

U can set the IDE to be VC++ 6 like with all the shortcut keys from the start page.

The whole reason windows is so "usable" is not because this usability
is inherent but rather because every application behaves the same
way - thus ALT F-O opens a file and escape cancels a modal dialog
in almost every application I use. These may not be the best key
combinations - but we get so used to them and users take them for
granted.

There are many other possibilities - and if you use Unix a lot you
get used to every application having a different shortcut key (as
well as certain very familiar windows keys producing groups of weird characters when you press them for no apparent reason!!). Some of the apps on unix perhaps have better chosen sets of short-cut keys than the windows ones - but their interfaces will never succeed in general unless everyone accepts them - which just won't happen.

So if you choose a non-standard way of implementing a feature
it has to work in the standard way too. So pressing a key must
cancel a menu even if it is frustrating - but having a "tear-off" line
at the top of the menu would be acceptable as it doesn't interfere
with standard usage (much!).

Adrian

voidspace,

You missed a point. That was an example on how frustrating change can be if you are accustom to some thigs behaving certain way.
Thanks for your advice but “switching to VC++ 6 like with all the shortcut keys from the start page” does not do what is promising to do. Try it.

aruzinsky:

After this post I am not going to participate in this discussion since you are getting personal and angry with issue that needs cool head. Cool head is healthier for any discussion. One need to be world-centric rather than egocentric, since world does not spin around us, it happens to be the other way around.

There is no such a thing like objective opinion; this is human nature and you are a human so this law applies to you too whether you are able to comprehend it or not.

You are quoting my post and yet you are putting your words in my mouth – that is not a good practice. You are stating things that maybe somebody (rightly though) posted. Non of your comments apply to my post. I have not make statements you are referring to; I would suggest you read my post again and stick to the point.

I gather from other’s programmer’s posts is that nobody is telling you not to do what you are planning, they simply say that it is difficult and goes against water flow.

As I have mentioned previously, noting is impossible in Windows if you know how to do it, so invent your own menu that will comply with your requirements and stop complaining about how MS did a wrong job doing something that you do not approve.

I have been working with Windows since the beginning of windows and I also had “crazy” ideas, but instead wasting my energy and trying to fix unfixable I have worked my own solution.

For example one of my customers required me to have child windows with own menus; and that was impossible using MS functionality built into child window. I did it nonetheless by inventing my own “menu”.

You always have ultimate choice: if you do not like (approve) MS Windows’ OS you can always turn and choose other one: Unix being one of them.

Xwindows’ menus by the way behave the same way as MS Windows, so it was not only MS idea. The same applies to Mac OS functionality.
Menu is generating commands and menu items are checked only to show state of objects that is toggled (like visual state of status bar) whether you approve it or not.

U folks have forgotten to eat chicken chops, which is why u folks forgot 1 key point.

U see, if you've Windows 98+ with Internet Explorer 5.0+ installed, go to the Start menu, click Programs, and right click on one of the program names and click Delete from that menu. The Start menu doesn't disappear......it's still there! This is something like what aruzinsky said : clicking on a menu item(in his case, checking and un-checking) and the menu is still there until the user clicks else where.

In his case, it's really more convinient that way, but then, since I'm such a great advocate of GUI standards, I would say it's better to group these stuff into a "Options" kind of dialog box and allowing to user to do his stuff from there. :):D:)

Xeon, Xeon, Xeon,
I do not know if you have noticed but right click causes another menu to show while program menu is still in modal loop. The top men disappears right after clicked, and that does not cause program menu to exit menu modal loop until next event causes it.

In conclusion: there is nothing that is extraordinary, or different from default behavior.

What your new avatar symbolizes?
:D

Quote:

---

Originally posted by Dave Volland
1. Right-click -> select Properties (or whatever you want to call the dialog box).
2. Select/deselect your options.
3. Click OK

In your example, this takes 8 clicks (5 check/unchecks). Your version takes 7 clicks, if you count the click to close the popup. This solution not only solves your problem without an inordinate number of "extra" clicks, but doesn't force a non-intuitive interface upon a user who is trying to learn how to use your program.

The above posters are right, by providing a common interface, a user knows what to expect when a particular type of interface is presented. Examples: menus go away when an item is selected; menu items with a "..." at the end bring up some other interface steps; dialog boxes stay there until the "OK" or "Cancel" is clicked; right-click menus are sensitive to the location of the click, while menu bar menus aren't, etc., etc.

Deviation from these common behaviors confuses and intimidates the user, which is exactly opposite of the goal of a UI programmer. In addtion, any other programmers that have to try to figure out your code will see a popup menu and assume one thing, forcing them to dig deeper to figure out what you were doing.

When developing software, you need to evaluate all of the consequences of the decisions you make, and be open to other solutions that are better all around, not just in one area.

Bottom Line: Just because you can do a thing doesn't mean that you should.

---

No, as I explained earlier, my method takes between 6 and 7 clicks depending on the application. I would guess 6.2 on average. An example of a 6.0 click application, would be a menu with a list of 5 check items that only affect the properties of several other items on the same menu. In this scenareo, checking/unchecking the 5 items is always followed by by clicking on another item on the same menu. This last click closes the menu but does not count as an extra click because it would have been made anyway. As a more specific example, consider an image processing menu in which the check list consists of 3 or 4 color channels and the other menu items are operations such as sharpen, blur, brighten, etc. which can be applied to any combination of color channels. The user selects which color channels to apply an operation to and then selects the operation. Granted, at first the user may be surprised that the menu doesn't go away after a color channel is checked, but I think the user will quickly figure out what to do next, and thank me later. Of course, my last statement is my opinion, but, so is your evaluation of the worth of a common interface because you never performed a scientific study of people's ergonomic preferences. The bottom line is that my method saves between 1 and 2 mouse clicks.

No, the bottom line is that saving 1 or 2 clicks is not worth the confusion and intimidation that the average user will experience trying to use your product. (By the way, I would still argue that you are only saving one click. The click to close your popup menu should not (necessarily) perform any action, since the user may accidently click on an undesired option in their effort to close the "popup menu that won't go away")

Better yet, the bottom line is that saving mouse clicks is not the top priority. An easy, intuitive interface is. Saving the user steps is important, but not at the expense of a common intuitive interface. The less an application deviates from the common usage of its tools, the more comfortable a user will be using it.

To answer one of your points: True, I have never "performed a scientific study of people's ergonomic preferences", but do you really think that one has never been done? Don't you think that somewhere along the line, some of these companies have? I would wager that millions of dollars and countless man hours have been spent toward this end. The result of this is the common interface which you so adamantly want to change.

By the way, what if, in your scenario, the user wanted to check only one option. You have just increased the number of clicks that the user has to press to choose his option. Quickly selecting one context sensitive command is what these right-click menus were designed for. Changing multiple options is what dialog boxes wre designed for. Each tool is designed for a specific purpose, and it's strengths and weaknesses are designed appropriately. What you are trying to do is fit a square peg into a round hole, just for the sake of fighting the system.

Furthermore, if we take your argument to its logical conclusion, than why am I prompted to save my work upon closing an application? If I had wanted to save it, I would have, right? All these designers are doing is adding an extra click to the operation, right? Wrong. Certain destructive actions require protecting the user from misfires. The flat-out addition of a mouse click is invaluable to the user, when they could have lost everything they have been working on for hours. Again, bottom line, the reduction of mouse clicks is not the most important goal of a UI programmer.

I have found that programmers often forget that their knowledge, experience, and adaptiveness with computers is not the norm. Most users do not have the adeptness with computers that we do. We, as UI programmers, need to think outside of our own level of understanding and experience and consider the needs of the less experienced user. We need to think not only of what we would like in an interface, but also consider the other factors I have mentioned in this thread, as well as quite a few others. Your original subject says it all: "Why am I the Only One Interested in Doing This?". Maybe you shouldn't concentrate on why, but realize that if you are the only one who wants to do this, then maybe it's not worth being done. Remember that we are not designing for ourselves, but rather for these end users.

Something to think about....

Oh Saint John(Cz)!!!!!!!
Why do u always make me look like a fool!!!!!!!

Oh my God.......so, I was talking rubbish after all, just when I was thinking that I was giving great opinions!!! How embarrasing! Oh ****! :):D
(but then, isn't this typical of Xeon's posts)

And oh! My new avatar is the face of the terrible blasting devil lord in Digimon Season 3. Don't laugh : kinda childish, perhaps. But who cares! Folks who're happy live longer and happier, that's why.

Here's the full picture :

http://www.angelfire.com/rebellion/i...nblastmode.jpg

and here's the full picture for this avatar :

http://www.bandai.com/poll_images/big/beelzemon.gif

Real cool, eh? :) :D

Quote:

---

Xeon:
Why do u always make me look like a fool!!!!!!!

---

It was definitely, positively, indubitably not my intention.

Thank you all for your replies. You have answered my question. The reasons that you are not intested in this technique include the following:

1. You believe that the average user prefers a dialog box for check items to saving one or two mouse clicks with a menu.

2. Sometimes this belief is based on the assumption that traditional methods are based on a scientific study, but you cannot cite a reference to this study.

3. Sometimes this belief is based on the very popularity of the belief, i.e., so many people can't be wrong and, if they are wrong, you believe that you are nevertheless in good company.

4. You place popular subjective beliefs over objective measurement.

5. You ignore overwhelming evidence that mass delusions are a common occurrence. Remember when almost all medical doctors thought that female hormone replacement therapy was good for the heart?


Well, now I know why nobody helped me with my MFC programming problem. Thank you.

Happy to help.
Glad to see you came at this with an open mind.

Relax. People are trying to warn you that diverging from standards is not something to take lightly. They are right. Just because they are right does not mean you are wrong. Whatever you decide to do, the advice given here is good advice, and even if you don't heed it, you should pay attention to it.

Jeff

Nobody is interesting in this technique because it has poor usability. As someone rightly pointed out, simply reducing mouse clicks is not the be all and end all of usability.

As was also pointed out application menus now have a globally accepted mode of operation with a single caveat: Under the Mac, the menu stays open only as long as you hold the mouse button down and keep the mouse in the menu--this is called the non-persisant model. Windows uses what's called the persistant UI model.

The problem with your solution is that there is no UI element present to close the menu. At one point you, or someone else, stated that you could just "click anywhere on the window."

But how does the user know that that will close the menu? Since the menu is "sticking", the user will likely assume that clicking elsewhere on the window will trigger an action there, even if it is to simply move the carat.

So what does that extraneous click do?


You stated:

Quote:

---

You place popular subjective beliefs over objective measurement.

---

Have you spent ANY money at all doing usability research? I don't see anywhere were you have done objective measurement. Yet Microsoft has and their conclusion was that Menus should not persist beyond a single action.

(IE does violate this, but I can assure that Microsoft didn't make this addition lightly.)

There is another issue; and that is modality, a very misunderstood UI concept (and one that VS.NET violates way too often.) How does the user know that several options must be set before continuing with another action? Furthermore, how does the user even relate those options to the additional action that will be taken?

This is best left to a dialog box.

You also complain that nobody is helping. Quite to the contrary, several posters offered suggestions such as making the menu a "tear off" or making a custom menu, etc.. Have you tried those solutions?

(You do know that you can't use the standard Window's Menus for this? They simply don't work that way. You'll have to roll your own--it isn't very difficult, just time consuming.)

Quote:

---

Originally posted by CallMeJoe
I don't see anywhere were you have done objective measurement.

---

You must have a blind spot a mile wide. I have answered this question several times and you still do not see the answer. Counting the number of clicks required to perform a given task is an objective measurement and it cost me nothing.

Quote:

---

Originally posted by CallMeJoe You also complain that nobody is helping. Quite to the contrary, several posters offered suggestions such as making the menu a "tear off" or making a custom menu, etc.. Have you tried those solutions? [/B]

---

No, I am not an experienced Windows programmer and I do not know how to do this. I would prefer to know why my original simple solution (which works with OWL) does not work with MFC. My request for help is not in this post so I will duplicate it here:


BEGIN_MESSAGE_MAP(CChildView, CWnd)
ON_COMMAND(CM_X, CmX)
ON_UPDATE_COMMAND_UI(CM_X, CeX)
END_MESSAGE_MAP()

extern CMenu menu;

void CChildView::KeepPop(int item)
{
RECT rect;
GetMenuItemRect(GetTopLevelFrame( )->GetSafeHwnd( ),menu.GetSafeHmenu(),item,&rect);

CRect crect;

GetClientRect(&crect);

menu.GetSubMenu(item)->TrackPopupMenu(TPM_LEFTALIGN|TPM_LEFTBUTTON,rect.left,rect.bottom,this, crect);
}

bool flag = 0;

void CChildView::CmX()
{
if (flag) flag = 0;
else flag = 1;
KeepPop(2);
}

void CChildView::CeX(CCmdUI* pCmdUI)
{
pCmdUI->SetCheck(flag);
}


The problem with this is that the current proper status of the check mark is not displayed by the TrackPopupMenu menu. Instead, it shows the check status that was last instituted by the regular menu. I suspect it has something to do with the CCmdUI class because, with the OWL TCommandEnabler class, this approach works just fine. I suspect that there exists a simple modification to the CCmdUI class that will correct the problem.

Objective measurement of usability is not counting mouse clicks! It's about how easily a user can accomplish a task or series of tasks.

To illustrate. If you open a project's properites in Visual Studio, you have to click the mouse several times to find the category of item you are looking for and to change it. If mouse clicks were the definitive usability parameter, ALL the options should be in a single long list and that list would be maximized to fill the screen.

Ironically, when you do that, it almost always takes the user LONGER to accomplish a given task regardless of how many mouse clicks they do. (Yes, this has been measured.)


Why didn't you mention OWL to begin with? Why didn't you post the code you did? Why did you state your original posting as a theoretical question? If you had just posted the last half of your last posting, there wouldn't be dozens of replies.


In the past, many classes in OWL didn't use the underlying Windows constructs, though this may have changed. I suggest you step through the OWL code and see what they are doing differently. If I remember right OWL also handles menus differently than MFC (it's been eight years since I did OWL programming and then it was for one project.)

I suspect that OWL linked the popup menu handler with all the menu handlers.

In MFC you need to call menu.EnableMenuItem() or menu.CheckMenuItem() for those items you want to enable/check, before you call TrackPopupMenu.

As to how to make the menu "stick"; I don't have a clue.

Hey,

don't know what you all are getting worked up about. Doesn't anyone ever try to do something just to see if they can do it?

anyway, Just programmatically call/display that popup menu in the window's message function for each check/uncheck menu item. That way, each time the item is selected to check/uncheck, it will redisplay the popup. No need to rework the menu functionality, just manipulate what is there. Might have a slight flicker, but probably not noticeable.

Did this solve your problem?

The reason I was bothered is that the original post asked the theoretical question:

Quote:

---

Why am I the Only One Interested in Doing This?

---

It then led off with "Suppose...."

What ensued was a long discussion of reasons of why this type of interface is not a good idea. Most the posts were intelligently written with the intent of dissuading aruzinsky from imposing such a design on his/her users.

In response aruzinsky engaged in ad hominem attacks, until the end, never indicating that this was anything more than just a theoretical question.

Incidentally, Stryder's solution has problems since there is no way to know when the user is done selecting/unselecting the various options. If you add "close" as a menu item, then why not use a dialog box in the first place since that's essentially what was just created?

Quote:

---

Originally posted by CallMeJoe
Objective measurement of usability is not counting mouse clicks! It's about how easily a user can accomplish a task or series of tasks.

---

Click counting is an objective measurement of something that contributes to usability. All else equal, it is the deciding factor of usability. In the absence of objective information concerning the nature of "all else," I found that it is best to base my decisions on an "all else equal" model. This model has worked well for me in the past and I will continue to use it.

Quote:

---

Originally posted by CallMeJoe
[B]Why didn't you mention OWL to begin with? Why didn't you post the code you did? Why did you state your original posting as a theoretical question? If you had just posted the last half of your last posting, there wouldn't be dozens of replies.

---

I did. Look at the link on the bottom of my original post in this thread:

Quote:

---

Originally posted by aruzinsky
Suppose you have a popup menu that drops down from the menu bar and this popup has a list of items to be checked or unchecked. Further suppose that the typical user has to check/uncheck 5 items before doing something else. Isn't this a common scenario?

Normally, doing this will take 10 mouse clicks because, after clicking each item, the popup disappears and the user will have to click on the menu bar to have the same popup reappear over and over again. If the user wants to make certain of the last entry, that takes one more click for a total of 11 clicks. You don't have to be an ergonomic genius to figure out that this would only take 6 mouse clicks if the popup didn't disappear.

So, why am I the only one interested in preventing popups from disappearing when items are checked/unchecked? Are programmers ergonomically retarded?

http://www.codeguru.com/forum/showth...hreadid=207994

---

Quote:

---

Originally posted by CallMeJoe
[B]In the past, many classes in OWL didn't use the underlying Windows constructs, though this may have changed. I suggest you step through the OWL code and see what they are doing differently. If I remember right OWL also handles menus differently than MFC (it's been eight years since I did OWL programming and then it was for one project.)

I suspect that OWL linked the popup menu handler with all the menu handlers.

In MFC you need to call menu.EnableMenuItem() or menu.CheckMenuItem() for those items you want to enable/check, before you call TrackPopupMenu.

As to how to make the menu "stick"; I don't have a clue.

---

Thank you. I was hoping that this problem had a well known solution that many professional programmers knew off the top of their head. My mistake. Sorry to trouble you.

Quote:

---

Originally posted by Stryder
Hey,

don't know what you all are getting worked up about. Doesn't anyone ever try to do something just to see if they can do it?

anyway, Just programmatically call/display that popup menu in the window's message function for each check/uncheck menu item. That way, each time the item is selected to check/uncheck, it will redisplay the popup. No need to rework the menu functionality, just manipulate what is there. Might have a slight flicker, but probably not noticeable.

Did this solve your problem?

---

Thank you. Could you elaborate? Remember, I am not an experienced windows programmer nor a programmer by formal training. If you could show me some example code, I would appreciate it.

"All else equal" makes your entire statement subjective.

Moreover, I think the consesus of the discussion was that a "standard" designed dialog box was better than the confusion caused by a non-standard menu (which is an objective fact.)

I do not disagree that click counting, and mouse movement, contribute to usability, but that's all they are; contributing factors which must be balanced against the overall usability of your software in relation to the system.

(Window's Menus require two clicks, Mac menus one, yet I prefer Window's style menus. But, were I to write a Mac program I would not impose the Window's menus on it. Rather I would write to the standard to which Mac users are acustomed.)

As for the code; I did not use the link. For not doing that I apologize. However I do think your posting was confusing, much like your menus will be:)

What a thread. I agree with keeping a standard in place for UI. Having spent time developing a Clinical Information System that is widely used by nurses/doctors I certainly wouldn't want a nurse standing dumbfounded at a PC trying to decide if that button really saves her changes, just because some other programmer decided he wanted to word the button different. I'd kinda wanna the nurse at my bedside doing what a nurse is good at...nursing. And we did have them asking us, why are the buttons different in certain places. Gee, umm well Gee..

But as a side note what is the whole deal about this usability, you want usability, implement accelerator keys. The nurses barley (must be happy hour time if I'm typing that) touched the mouse, it was far faster to use the shortcuts, and not because of the GUI design.

If a customer demanded I do things differently after I've explained the standards to them and why they should do it this way, then so be it I'll code it that way...but it's on them not me :)

And lets all remember that aruzinsky has said he's not a programmer. So I'm gonna assume he hasn't develop applications big and small for a large number of customers. So, we have the experience of knowing what works and thinking on the same page. He's probably frustrated (and it shows sometimes in his posts) that we the collective group are all pretty much telling him no you can't do it that way, or shouldn't. But, then I'm not much of a judge of the human condition, I'd rather hang out with a tree, they rarely disappoint :)

That's my 2 cents, take it and make change, or leave it in the cup for the next person.

If anyone is interested in performing an ergonomic evaluation, the following code works, although it probably is not the best code for doing this.


BEGIN_MESSAGE_MAP(CChildView, CWnd)
ON_COMMAND(CM_X, CmX)
ON_UPDATE_COMMAND_UI(CM_X, CeX)
END_MESSAGE_MAP()

extern CMenu menu;

void CChildView::KeepPop(int item, UINT command, bool check)
{
RECT rect;

GetMenuItemRect(GetTopLevelFrame( )->GetSafeHwnd( ),menu.GetSafeHmenu(),item,&rect);

CRect crect;

GetClientRect(&crect);

CMenu &smenu = *menu.GetSubMenu(item);

if (check) smenu.CheckMenuItem(command, MF_CHECKED|MF_BYCOMMAND);

else smenu.CheckMenuItem(command, MF_UNCHECKED|MF_BYCOMMAND);

smenu.TrackPopupMenu(TPM_LEFTALIGN|TPM_LEFTBUTTON, rect.left, rect.bottom, this, crect);

}

bool flag = 0;

void CChildView::CmX()
{
if (flag) flag = 0;
else flag = 1;
KeepPop(2, CM_X, flag);
}

void CChildView::CeX(CCmdUI* pCmdUI)
{
pCmdUI->SetCheck(flag);
}

Sheesh, what's wrong with adding a further menu item that will allow you to 'check all the above'. Or add it to and options dialog.