Why is there a menu show delay, anyway?


One of the reactions to my note on how the window manager uses the double-click time as a way to tell how good your reflexes are is bemusement, well okay, not so much bemusement as outrage, over why we need a menu show delay in the first place.

Imagine, you're navigating a deeply-nested menu hierarchy and then you want to move to one of the items in the most recent fly-out, but instead of moving the mouse directly to the right then down, you move it ever so slightly diagonally down. Boom, the entire menu collapses and you have to start over. There's a place for maddeningly fiendish mouse dexterity games, but trying to create a pivot table is not it.

I run into this problem all the time on the Web. Web site designers forget to incorporate a menu show delay, resulting in frustration when trying to navigate around them. For example, let's look at the navigation bar on the home page of The Discovery Channel. Hover over TV Shows, and the menu appears. Suppose you want to go to Koppel on Discovery, but instead of moving the mouse straight downward, the way you hold your arm on the desk moves the mouse in an arc that happens to swing to the right before it arcs downward. You touch TV Schedules and your navigation is screwed up. You have to start over and make sure to move the mouse exactly straight down.

This phenomenon is even worse for sites that position their submenus as a horizontal bar below the main navigation bar, such as EVA Air or NBC. On the NBC site, for example, hover over Schedule and a band appears below the navigation bar with more options. But you can't move the mouse diagonally to, say, Pacific; if you do, you'll accidentally touch News & Sports and the Schedule submenu will be disappear. If you just move and click in one motion, then boom, congratulations, you just clicked on Access Hollywood. You have to carefully move your mouse straight down (being careful not to touch anything else that might open a different menu or cause the existing menu to auto-dismiss), and then straight sideways (being careful not to accidentally move it upward three pixels, causing the secondary navigation bar to be replaced with a different submenu). It's like its own miniature mouse dexterity game. But one you didn't elect to play.

The folks over at TechNet Magazine did take the menu show delay into account, though it's still not as long as I'd like. Hover over the word TechCenters in the navigation bar, and a submenu appears. If you move toward Script Center and happen to touch TechNet Magazine ever so briefly (like one Planck time), the TechCenters menu stays up. On the other hand, the menu animation is abysmally slow if you use Firefox, so one step forward, one step back.

Comments (55)
  1. Anonymous says:

    Instead of introducing a delay which slows down response, wouldn’t some cleverness of the menu behaviour be a better thing to do? Why not unrolling submenu immediately but still allowing user to move the mouse outside of the current box without unwanted results? Not as easy as just having a delay, but I believe it can be done.

    Why should "show menu/submenu delay" and "everything disappears if I move a bit outside delay" be the same?

  2. Anonymous says:

    acq: You mean, for example, that it should be OK to let the mouse BRIEFLY pass over another menu item without having that menu’s submenu fly out.  For some period of time or other: after all, if you move your mouse over another (different) menu item and leave it there for a long time, then presumably, you would like the sub-menu for THAT menu to appear.

    So let’s say that we want that period of time to be adjustable.  OK, what shall we call the adjustable time delay?

    Let’s call it the "menu show delay" or something.  Good idea!

    That’s exactly what has been implemented.

    "Unrolling a submenu immediately" is exactly what gives rise to the problem:  If your mouse moves over another top-level menu item on its way to a submenu item, you don’t WANT the submenu for that top-level menu to fly out IMMEDIATELY; you need to give the user some time to get to a sub-menu item.  That’s the whole point.

  3. Anonymous says:

    This is my number 1 annoyance with the Internet today (number 2 being focus stealing).  It actually took me like 20 seconds to navigate a 3-level menu one time; very frustrating.  The worst part about it is that you have to be pixel-perfect; if you stray outside the box by just one pixel, you have to start all over again.

  4. Anonymous says:

    IIRC, Apple addressed this problem not by adding in a delay, but by making the menu "virtually larger" than it actually appears on screen. When a menu is open, the rectangle the mouse can travel in is larger than the visual appearance of the menu, thus "fudging" if the user’s mouse leaves the menu on the way to somewhere else. I may be wrong, it’s been a long time.

    In any case, this is a demonstration of why (IMHO) web apps (and open source apps that use their own written-from-scratch menus and windows) are a bad idea. If you write a normal Windows or .Net app, you get usability niceties like this for "free". If you’re using a program with a UI written from scratch, all bets are off, but odds are they’ve screwed it up:

    https://sourceforge.net/tracker/?func=detail&aid=1865630&group_id=95717&atid=612382

  5. Anonymous says:

    To me, if you need to come up with a hack like "menu show delay" you need to rethink your menu/UI.

    It’s one of those things that drove me totally nuts about XP’s "enhanced" start menu – it was two items wide and always bringing up the wrong thing.  For example, the log off/shut down buttons are hard to get to because as soon as you hit "all programs" they get covered up.

    I don’t have the solution, but menu show delay isn’t the right one.

  6. Anonymous says:

    >"To me, if you need to come up with a hack like "menu show delay" you need to rethink your menu/UI.

    It’s one of those things that drove me totally nuts about XP’s "enhanced" start menu – it was two items wide and always bringing up the wrong thing.  For example, the log off/shut down buttons are hard to get to because as soon as you hit "all programs" they get covered up."<<

    But the delay is supposed to help keep you from accidentally opening the "all programs" submenu.  And that’s also easy to close — it’s much better than the menus Raymond described where you need to start over when you make a mistake.

    I think the menu show delay is more of an enhancement than some kind of "hack."  I mean, you could really use that word to disparage anything… er, "To me, if you need to come up with a hack like ‘doorknobs’ you need to rethink your entrances."

  7. Anonymous says:

    Remember old versions of Windows did not have this problem? Remember why? Because sub-menu did not open when mouse moved over an item. You had to click a menu item to get sub-menu. Consequently, it did not disappear on its own. You had to click a different item to hide the sub-menu. I still think this was way better than what we have now. Similar thing with toolbar buttons that "magically" become brighter or whatnot when you move mouse over them. In real life things do not change when you look at them, do they?

  8. Anonymous says:

    the MSDN updated site is one of those that has HUGE menus and no delay, it is painful to navigate it and a tremendous mouse accuracy exercise

  9. Anonymous says:

    "In real life things do not change when you look at them, do they?"

    Heisenberg may disagree.

  10. Anonymous says:

    "Because sub-menu did not open when mouse moved over an item. You had to click a menu item to get sub-menu. …. In real life things do not change when you look at them, do they?"

    It could be worse – or better, depending where you’re coming from. Many X Windows (UNIX) systems have activation follow the mouse: i.e., the focus changes as you hover the mouse over a window, no click required. It works on systems where the keyboard is the primary input device. But Windows is too mouse-driven these days and the GUI usability "enhancements" slows down keyboard navigation.

    With regards to menus, keyboards are a pefectly accurate mouse replacement. Arrow keys always move to the correct item (assuming the correct arrow keys are used!) But the menu-show-delay slows down kybd navigation and file/folder navigation in Explorer as well. What’s worse are applications that hardcode their own menu-delays instead of using the system preferences. Arrrg!

  11. Anonymous says:

    @Paul M. Parks

    "I can resist everything except temptation" (C)O.Wilde

    So here are my snarky comments:

    1) There’s enough uncertainty in Windows already, no need to appeal to Heisenberg

    2) So this is quantum computing, Microsoft way?

  12. Anonymous says:

    So Raymond, you’re saying you’re a Firefox user? :)

  13. Anonymous says:

    "For example, the log off/shut down buttons are hard to get to because as soon as you hit "all programs" they get covered up."

    And pigs fly. What version of XP are you running? All Programs is above those buttons, and the menu is anchored to match the bottom of the All Programs item.

  14. Anonymous says:

    On my XP, at least, there’s still a draw delay that is directly related to how many icons need to be displayed in the sub-menu, and this is infuriating – especially considering that Windows 95 didn’t have it and ran on inferior hardware.

    In the words of Dwight from The Office over at NBC, "If you can’t work your menus without a menu show delay, then you must be an idiot."

    Okay, perhaps the menu show delay is useful from an accessibility point of view, perhaps if  one has a withered mouse hand, or such.

  15. Anonymous says:

    I too get frustrated by this. My hand isn’t always steady enough, especially on a laptop on my lap.

    BTW, the NBC example is pretty funny because they seem to have a bug.  If you accidentally move up, such that you touch the ad, the ad expand over the menus.  When the ad rolls back, the site seems to lose track of the state, and the menus no longer work.  Or so it works for me with Firefox 3.

     KC

  16. Anonymous says:

    Ironically, I’ve seen a lot of web menus which manage the (relatively difficult) task of implementing this delay quite sanely, yet also make a horrendous mess of the (much easier) detail of making the submenu actually line up with the parent, leaving a few pixels gap between the two. Move to the submenu too slowly, and you’re left with just the parent menu showing again!

    I’m hoping this is at least a mistake, rather than some web designer somewhere actually having thought this was a competent way to implement menus. If I’m wrong about that, the gene pool desperately needs extra chlorine.

    Talking of delays, the rather tedious Start menu drawing Joe Butler mentions has always infuriated me. Drawing a menu with a few dozen small icons and bits of text is hardly rocket science; you’d think a system which can decompress frames of MPEG-4 realtime should be able to draw such a trivial block of text and graphics in a single screen refresh, not multiple seconds, but apparently not.

  17. Anonymous says:

    Apple’s solution is to pay attention to the speed and direction you’re moving the mouse in – the submenu will stay open if you’re moving the mouse towards it, even if you go over other menu items on the way.  It works pretty well.

  18. Anonymous says:

    The Start menu icon delay has nothing to do with drawing and everything to do with loading the icons. Though even that shouldn’t take so long IMO.

  19. Anonymous says:

    What you’re talking about here isn’t a menu show delay, but a menu hide delay, IMO.

    One thing I wish windows did was give the system caret to the window the mouse was hoving over without the need for a click (KIND of like X Win, but not entirely in that I don’t want the window necessarily to become the focus). Another useful feature would be if if could hit Windows-H or something and my windows all became translucent so I could see the content of windows beneath the one I have open (and usually maximized).

  20. Anonymous says:

    Too many sub-menus is a bad design anyway, especially on the web. On web sites I think menus that collapse (a bit like http://www.asp.net/AJAX/AjaxControlToolkit/Samples/CollapsiblePanel/CollapsiblePanel.aspx) are better.

  21. Anonymous says:

    If the submenu contains more items than will fit between the top of the screen and the bottom of the "All Programs" item, it does indeed cover up those buttons.  

    But if you’re accidentally hitting "All Programs" on the way to those buttons, you’re really taking the scenic route.  (And you can always click directly below "All Programs" to dismiss the submenu.)

  22. Anonymous says:

    > "To me, if you need to come up with a hack

    > like ‘doorknobs’ you need to rethink your

    > entrances."

    Doorknobs are there to allow you to open the door.  An analogy with doors (with knobs) falls down on one key point:  doors with knobs typically don’t open simply because you are standing in front of them.

    Doors that DO open when you stand in front of them DON’T have door knobs.

    i.e. the designers of doors HAVE performed the necessary re-thought.

    :)

  23. Anonymous says:

    <quote>"In real life things do not change when you look at them, do they?"

    Heisenberg may disagree</quote>

    Until you ask him…

  24. Anonymous says:

    Robert C. Barth:

    One thing I wish windows did was give the system caret to the window the mouse was hoving over without the need for a click (KIND of like X Win, but not entirely in that I don’t want the window necessarily to become the focus).

    SystemParametersInfo/SPI_SETACTIVEWINDOWTRACKING

  25. Anonymous says:

    It’s been in windowsw since 16 bit Windows. From Winini.wri (RK Version)

    MenuShowDelay=<milliseconds>

    Default: 0 for 386 computers; 400 for 286 computers

    Purpose: Specifies how long to wait before displaying a cascading menu.

    To change: Use Notepad to edit the WIN.INI file.

    I find 20 ms is a good figure. It’s 400ms from 95 onwards.

  26. BryanK says:

    Well, even if you wanted to add a menu delay to your JS-based HTML menu, you’d run into problems trying to figure out what the system’s menu delay value actually is.  It’s not like you can get JS to call SystemParametersInfo (or the equivalent on other OSes), and as far as I know there’s no way to get this value through the DOM either.  To do it with CSS, you’d need a way to have CSS’s :hover pseudo-class *not* apply until after the timeout.

    What might help is some way to set up a menu using just HTML tags, which is *semantically* a top-level menu strip and set of menu items, not just a list.  Then the user agent can go get the system menu settings, and replicate them.  The HTML3 <menu> tag doesn’t work, because it’s just a container for list items; the user agent doesn’t do any kind of animation or fly-out behavior.

    I seem to remember HTML5 or XHTML2 was going to introduce something like this, but I don’t remember which.  Looking at HTML5, it appears that the combination of <menu> and <command type="command"> would work, once HTML5 is finished, and once user-agents start to handle this part of it correctly.  That will be several years (at least), though.

    I bet the method referred to by James Schend above would be doable in JS.  That might be another option, if you don’t mind the behavior not necessarily following the OS standard.  Of course, you have that today, so it’s probably not a huge issue.

  27. Anonymous says:

    On my XP, at least, there’s still a draw delay that is directly related to how many icons need to be displayed in the sub-menu, and this is infuriating – especially considering that Windows 95 didn’t have it and ran on inferior hardware.

    Windows 9x used (often corrupted) shelliconcache file. Win2K+ seemed to get rid of it. So instead of using proper synchronization to prevent corruption, Microsoft decided just screw it. This is also why when you log in, the desktop draws the icons so slow.

  28. Anonymous says:

    "For example, the log off/shut down buttons are hard to get to because as soon as you hit "all programs" they get covered up."

    "And pigs fly. What version of XP are you running? All Programs is above those buttons, and the menu is anchored to match the bottom of the All Programs item."

    I forgot to mention that I move the taskbar up to the TOP of the screen so it’s a drop DOWN menu.  Been doing that since 95.  As a result, on XP the log off button is covered up when I mouse DOWN from the start button towards log off.  I much prefer either 2000’s look or Vista’s start menu to the fugly look of XP.

  29. Anonymous says:

    The biggest reason why usablity testing can uncover bugs:

    http://folklore.org/StoryView.py?project=Macintosh&story=Disk_Swappers_Elbow.txt

  30. Anonymous says:

    Excellent reasoning Raymond.

    I too have been annoyed by those hide&seek web page menus. Lately though I’ve gained yet another pet peeve: Re-implementing standard Windows controls in JavaScript.

    One page I used to visit used to have a standard <select size="1"> thingy (resulting in a standard Windows combobox). Now they’ve opted for some JavaScript deathtrap instead. Keyboard input? Gone. Mouse-hunting exercises? A new feature. :(

    Implementing data-entry applications in HTML is plain madness, yet such monstrosities are pushed upon the unsuspecting public all the time. (don’t ask me what my current project is — needless to say that nobody are really happy about it as we already have a perfectly fine Windows application that is easy to deploy…)

  31. Anonymous says:

    If I understand Raymond correctly,  delaying  menu drawing is the solution route to the users challenge of targetting a too-small (for their input-device & eyesight) target menu item first time.  

    Have you got a blog post listing the other soultuions were considered and why ere they rejected.

    I love spending my winter evenings trying to navigate my XP cascading start menu with my shakey hand,  fading eyesight and tocuhpad,  and I’m not even 50 yet!

    http://wendyhome.com/2007/10/19/darlings-cascading-start-menu/

  32. Anonymous says:

    ..clearly the way to fix a bad design is to put a kludge on top of it.

  33. Anonymous says:

    Ray: I also have my start menu at the top of the screen. But then again, I primarily use the keyboard so getting to the logoff/shutdown buttons is Ctrl+Esc, Up-arrow.

    But using the mouse, instead of moving the pointer straight down after clicking the start button, you can move it diagonally across the start menu and bypass the All Programs entry entirely. Also, thanks to the menu delay Raymond is discussing, the All Programs menu only shows up if you hover over All Programs. So unless you’re moving the mouse incredibly slowly, or have decreased your menu delay to a very tiny value, this shouldn’t be a problem at all.

  34. Anonymous says:

    DriverDude wrote:

    With regards to menus, keyboards are a pefectly accurate mouse replacement. Arrow keys always move to the correct item (assuming the correct arrow keys are used!)

    Do it on the XP start menu: You are on "all programs" and you want to go to "execute" with the cursor key. Bang, "all programs" opens instead. You have to go back left. Now, you have two choise: Go left (sic!) again, or go up and then to the right, and then down.

    Not to mention what happens if the mouse happens to be somewhere where the menu opens. Instead of following your key presses, the start menu will follow your mouse. This seems to be related to the fact that when you type on the keyboard, the mouse makes very minimal moves. But these moves are enough for the system to be recognized.

    So, don’t tell me the keys are an alternative. I try to avoid the mouse as much as possible, but with menus, it doesn’t work in all cases.

  35. Anonymous says:

    "You are on "all programs" and you want to go to "execute" with the cursor key. Bang, "all programs" opens instead."

    Press the oh so discoverable Shift+Right to move between sides of the Start menu without opening the submenu. I can’t help thinking that would be useful in normal drop down menu’s as well.

    I like all the criticisms of the XP menu. Wouldn’t it be great if they replaced the hideous cascading menus with something like a list. Maybe a tree for backwards compatibility with subitems. What would also be great in this day and age would be if we could search the items as well! When will Microsoft fix the Start Menu and make it more like…oh…Vista?

  36. Anonymous says:

    Whether or not it was worth the wait is debatable, but I do like the vista start menu a lot

    (and the new event log performance stats, and the stability graph thingy that tracks installs, bluescreens, crashes etc, and the power management, and the wireless networking public/private thing, and the network map…)

    I wouldn’t go out and buy vista, but any computer that happens to come with it isn’t getting downgraded to XP…

  37. Anonymous says:

    "Apple’s solution is to pay attention to the speed and direction you’re moving the mouse in – the submenu will stay open if you’re moving the mouse towards it, even if you go over other menu items on the way.  It works pretty well."

    This is nothing short of genius.

  38. Anonymous says:

    @itsme:

    You’re saying that when you’re on a menu item that indicates it will open to the right and you hit the right arrow key it does what it says it’s going to do.

    I would agree if that happened when you were sitting on, say, Internet Explorer’s icon or something in the Pin List.  But neither of those result in that behavior.

    That said, I wish Vista had MacOS’ handling for menus sometimes.  But there are times where the MacOS’ method for handling menu delays is just as annoying.

  39. Anonymous says:

    Seems like Discovery and NBC use CSS to do the menus. Since there’s no :hovering-but-only-after-a-while pseudo class in CSS, it can’t be done without modifying the DOM from a Javascript, which won’t work for everyone.

  40. Anonymous says:

    @blah: "And pigs fly. What version of XP are you running? All Programs is above those buttons, and the menu is anchored to match the bottom of the All Programs item."

    You’re wrong IF the number of items in the All Programs menu requires the full vertical resolution of the monitor.

  41. Anonymous says:

    What’s always angered me about ShowMenuDelay is that it is a solution for a problem Windows’s Start menu, but it’s forced on all applications.

    I want to opt out of it.  We have advanced users with a lot of dexterity and there are useless delays with context menus because of this.  And if they turn off the delay, it screws up the rest of windows.

    We know this is a big issue, because applications that do not use the standard windows menu ‘feel faster’ to the user.  Our app felt sluggish.

    Our solution??  We created our own menu widget and we stopped using the Windows one!  A blessing too, the HMENU API is just terrible and confusing.  Error prone.  Leads to leaks easily.

  42. Anonymous says:

    >I like all the criticisms of the XP menu. Wouldn’t it be great if they replaced the hideous cascading menus with something like a list. Maybe a tree for backwards compatibility with subitems. What would also be great in this day and age would be if we could search the items as well! When will Microsoft fix the Start Menu and make it more like…oh…Vista?

    Let’s not get into the "gynaecologist’s interface" that is Vista’s Start Menu, shall we?

    Why, when large *widescreen* monitors are commonplace, somebody decided that a menu/pane with a *fixed* width was a good idea, I’ll never understand.

  43. Anonymous says:

    >I like all the criticisms of the XP menu. Wouldn’t it be great if they replaced the hideous cascading menus with something like a list. Maybe a tree for backwards compatibility with subitems. What would also be great in this day and age would be if we could search the items as well! When will Microsoft fix the Start Menu and make it more like…oh…Vista?

    Let’s not get into the "gynaecologist’s interface" that is Vista’s Start Menu, shall we?

    Why, when large *widescreen* monitors are commonplace, somebody decided that a menu/pane with a tiny fixed width was a good idea, I’ll never understand.

  44. Anonymous says:

    Ask Tog http://www.asktog.com/columns/022DesignedToGiveFitts.html question 6 gives the Apple way of dealing with the problem.

    No idea which is better, or even how you’d go about deciding.

  45. Anonymous says:

    So the fact that the menu *disappears* too fast was fixed by adding a delay in *showing* it :-)

    This is one of the first things I set to zero when I first install a system (thanks TweakUI :-)

  46. Anonymous says:

    I can’t repro on Vista, but I believe windows 2000 (or XP?) applied the menu delay as well to calls to TrackPopupMenu, before it shows the *initial* menu at all (not just a sub-menu), at least if you use them on mouse down.  

    This made the application feel sluggish at the sub-conscious leve.  Any of these 200-800 ms delays are imperceptible to developers or blazé users, but they have the effect of making software feel slow and frustrating to power user.  

    Again, this is especially obvious if you compare to an app that has a custom menu or palette class that has no such artificial delay added in.  This is what pushed me to replace the windows menu with a custom class, using Raymond’s menu code example.

    I’m working on a large CAD-like application, with users pounding the app with mouse gesture all day.

    Vista is like that everywhere.  Small little delays, animations, that make the system feel sluggish even though it really isn’t. You can’t measure that with automated testing.

  47. Anonymous says:

    ICR wrote:

    "Press the oh so discoverable Shift+Right to move between sides of the Start menu without opening the submenu."

    Thank you very much! Although I use the keyboard very often, I did not know this!

    It’s good I came up with this topic here. :)

  48. Anonymous says:

    I hate such delays. I remember games which slowed down the typematic rate because the game couldn’t handle if the user pressed 30 chars/s. Its a lousy solution to a lousy design.

  49. Anonymous says:

    @SM: Any GUI requiring delays is flawed and need rethought. It puts an upper bound on productivity. It gives a very strong, conscious or inconscious feeling of unresponsivity.

    The best example of awful GUI element is tooltips. They take ages to appear but quickly disappear!

    Why cannot my computer think at the same speed than me?

  50. Anonymous says:

    Sadly whilst there are a few Raymonds, there are many, many UI designers who don’t understand this most simple of concepts, and the bright sparks who wrote the Silverlight version of MSDN downloads fall into that category. Practially unusable. Grr.

    Go get them Raymond.

    [Disclaimer: I don’t actually expect Raymond has any say in this, nor do I actually expect he’ll be ‘getting’ anyone, other than potentially getting me more wound up over this]

  51. Anonymous says:

    I still dont understand. Delays on opening a menu and delays on closing a menu are two different things. Also, please imagine having a 1920×1200 screen, deep menu hierarchies are no problem.

    [You’re moving the mouse from point A to point B. In between is point C, a menu. The menu pops open, covering B. Maybe you are smart and avoid C as you go from A to B. I’m stupid. I even get messed up by deeply nested menu hierarchies on large screens. -Raymond]
  52. Anonymous says:

    You wimps.  If you just used CTRL-ESC and the arrow keys, you wouldn’t have this problem.

    Mouse-free and proud since 2005.

  53. Anonymous says:

    Broken! Multiple menus down http://www.whatisitmadeof.com/image/screenhunter_452.jpg

    So it’s javascript I still like to break it you can make multiple menus fall and stay.

  54. Anonymous says:

    I find it quite bizarre that in most modern GUIs, menus behave so inconsistently; Why does it require a click to open the first menu, but not thereafter? Why does it require a click to activate a menu item, but not if the item triggers a child menu?

    Personally, in order to minimize this inconsistency I often use the classic Mac style "click and hold" method of operating menus.

    Unfortunately, the start menu acts even more inconsistently if you do this; it works for items on child menu, but not the start menu itself.

    I propose some simple rules for GUI menus:

    1) Only one menu childless menu may be visible at any one time.

    2) When the user clicks outside of a menu, it must automatically and immediately close, unless it is an ancestor of a menu where the click occurred.

    3) The "ESC" key will automatically and immediately close all menus on screen.

    4) No menu shall perform any action (including the opening of a child menu) unless the user activates it (by mouse click or keyboard).

    5) When the user clicks on a menu item, it will either:

      a) Disappear and perform the action specified.

      b) Remain visible (and active) and display a child menu.

    Of course, Windows hasn’t changed its behaviour since Windows 95 and since there are so many different implementations of menus in Windows itself and first and third-party products (and the fact that Microsoft seems to be trying to kill off menus altogether) its behaviour will probably never change again.

  55. Anonymous says:

    First off – thanks for the previous post about, um, “other things” being based off of the double-click speed… I’ve always wondered why the @&$!*! my scrolling speed was so out of control; I generally have my double-click speed set nearly all the way down to avoid launching an item in Explorer when I wanted to rename it.

    It seems to me, though, that a better way to handle the menu delay problem would be to do something akin to what one user posted: display a submenu iff the mouse pointer is either being held fairly still, or is moving (say) within 20 degrees of horizontal.

    [Holding still is what the menu show delay does, and “within 20 degrees of horizontal” doesn’t help the menu bar scenario. -Raymond]

Comments are closed.