That's exactly it. Instead of copying Apple's intent, competitors instead copy the result without ever giving a moment to consider the original motivation.
This reminds me of a post by Tog or someone similarly luminary. He explained that the Mac OS submenu behavior arose from multiple iterations, refining until everything worked easily. A big part of that was letting the user move their pointer at an angle into the next submenu region. A Fitts' law consideration -- this didn't require the user to be too methodical in their movements through the menus.
Then, when Microsoft borrowed the UI, getting into submenus required the user to exactingly follow the path of the currently-highlighted menu item in order to traverse into the next. Breathe the wrong way and your whole drill-down progress just disappears. Microsoft's solution? Insert a brief delay as you hover over a drillable menu option.
Result without intent.
As it happens, this reminds me of the UI for Windows Phone 7. It's like a suit said, "Hey, go design me something that looks really modern. And hip. With sans serif fonts. Apple uses those right? They're really hip."
And we end up with a UI that looks more like a magazine layout than a tool for using your phone.
Thanks for the description of the submenus in Mac OS!
I've been using Macs exclusively for the past two years and, after starting to use Windows again last week, I couldn't really point out why the menus annoyed me so much.
And it's exactly what you describe: on Mac OS, if a submenu is open I can go in a diagonal to the sub-item I want, even if I hover another item in the menu on the way. On Windows, as soon as I'm not hovering the original parent item, the submenu disappears, so I'm constantly going back and forth to reopen the submenu.
The delay is called "hysteresis". Gtk implements this through "gtk-menu-popdown-delay", and seems to be making sure the mouse is moving in a triangle region towards the submenu. (See gtk/gtkmenu.c, esp gtk_menu_set_submenu_navigation_region.)
That's brilliant. I'd never noticed that about Mac OS submenus (although I definitely noticed how arduous it was to navigate Windows submenus).
I do have one outstanding gripe about Mac OS menus, though, which is that if you misclick on some non-reactive part of the menu (a greyed-out option or divider line), it simply closes the menu. I can't think of any reason why this would be better behavior than leaving the menu open, since at least 90% of the time my intent was to actually click on something that would respond.
About the menu closing: I think the behavior comes from an older design. On older OS versions (I don't know if this changed with OS X or if it was earlier) you had to hold down the mouse button the whole time you traversed the menu. Letting go of the mouse button over anything but a menu item resulted in closing the menu. You can still do it this way. And now, even though the menus are 'sticky', they close when you click on anything that isn't a menu item. I'm so used to this behavior now that I use it to close menus. Still though, it would be interesting to try it both ways for a while.
I just tested this in Firefox on Windows, and it does support going in a triangle across other menu items at the same level as the one with a submenu. The delay permitted is a bit short though, which might be what they've tweaked better on the Mac. No Apple machine here, so I can't comment more directly.
This reminds me of a post by Tog or someone similarly luminary. He explained that the Mac OS submenu behavior arose from multiple iterations, refining until everything worked easily. A big part of that was letting the user move their pointer at an angle into the next submenu region. A Fitts' law consideration -- this didn't require the user to be too methodical in their movements through the menus.
Then, when Microsoft borrowed the UI, getting into submenus required the user to exactingly follow the path of the currently-highlighted menu item in order to traverse into the next. Breathe the wrong way and your whole drill-down progress just disappears. Microsoft's solution? Insert a brief delay as you hover over a drillable menu option.
Result without intent.
As it happens, this reminds me of the UI for Windows Phone 7. It's like a suit said, "Hey, go design me something that looks really modern. And hip. With sans serif fonts. Apple uses those right? They're really hip."
And we end up with a UI that looks more like a magazine layout than a tool for using your phone.