Printable View
U can set the IDE to be VC++ 6 like with all the shortcut keys from the start page.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]
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
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.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, 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
It was definitely, positively, indubitably not my intention.Quote:
Xeon:
Why do u always make me look like a fool!!!!!!!
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:
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.Quote:
You place popular subjective beliefs over objective measurement.
(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.)
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
I don't see anywhere were you have done objective measurement.
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: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]
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.