Why am I the Only One Interested in Doing This?

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.