CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 3 123 LastLast
Results 1 to 15 of 39

Thread: Why am I the Only One Interested in Doing This?

  1. #1
    Join Date
    Sep 2002
    Posts
    173

    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

  2. #2
    Join Date
    Jul 2002
    Location
    American Continent
    Posts
    340
    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.

  3. #3
    Join Date
    Sep 2002
    Posts
    173
    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.

  4. #4
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    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 ?
    Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
    Supports C++ and VB out of the box, but can be configured for other languages.

  5. #5
    Join Date
    Nov 1999
    Location
    Dresden / Germoney
    Posts
    1,402

    actually...

    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.

  6. #6
    Join Date
    Mar 2002
    Location
    California
    Posts
    1,582
    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

  7. #7
    Join Date
    Aug 2002
    Location
    Bangalore
    Posts
    23

    well...

    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

  8. #8
    Join Date
    Jul 2002
    Location
    American Continent
    Posts
    340
    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?

  9. #9
    Join Date
    Mar 2002
    Location
    California
    Posts
    1,582
    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

  10. #10
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    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

  11. #11
    Join Date
    Sep 2002
    Posts
    173
    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.
    Last edited by aruzinsky; September 4th, 2002 at 04:04 PM.

  12. #12
    Join Date
    May 1999
    Location
    DELAWARE, USA
    Posts
    9,917
    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.
    There are only 10 types of people in the world:
    Those who understand binary and those who do not.

  13. #13
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    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.

  14. #14
    Join Date
    Sep 2002
    Posts
    173
    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."

    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.

  15. #15
    Join Date
    Mar 2001
    Location
    BFE
    Posts
    101
    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.
    Dave Volland

    That which does not kill us makes us stronger. Or smarter.

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)