It's basically 'fling your pointing device at the top' and 'go left or right to get the button you want'. Due to the lack of borders/stops, this would be harder if it was sandwiched between a titlebar and window content.
But the issue is Apple broke the whole mechanism with hot corners. Now if I move fast anywhere near a hot corner, it gets activated. And now the menu bar near the corners is tiny and hard to hit with a "huge" hot corner right nearby (the hot corner gets the benefit of the inifinte off-screen target). I find the same problems will full-size browsers (with tabs along the top), I'm always hitting the hot corners instead of the top lerpft and right tabs. I guess I can always change my corner settings.
Additional gripe about the top menu in MacOS: the biggest fault I've found is that it can be active for an app whose windows are hidden or that currently have any windows, thus creating a mismatch between what you see (other windows) and what is active (responding to keyboard shortcuts for example).
Well I always hated hot corners, and anyway by default they're disabled on macOS.
But WRT hot corners, the best part of hot corners is being able to assign a modifier key to them. Without using the modifier, it's crazy annoying, but having a modal aspect that requires active engagement seems to me the best of both.
Then again, I haven't actually engaged a hot corner in years. I find Keyboard Maestro the best option of all.
(P.S. just for anyone who doesn't know how to add a modifier to the hot corners, just hold down Ctrl, shift, option or CMD when selecting the setting).
You can use Cmd-Tab to activate an app that has no windows, in order to activate hotkeys that let you create new windows! Especially when you’re using multiple desktops, this ability is invaluable.
The close/resize/etc buttons are indeed a different issue, while the controls are often duplicated (File or window menu on most operating systems and window managers have the close/resize/max options too). At some point I think Ubuntu had a default desktop environment where the close/max/min buttons were added to the top menu bar. I thought it was quite a nice idea, but the implementation never spread to other systems and sadly, support wasn't very universal across all applications.
Thinking along those lines, what if you added the title bar at the top too, you'd end up without a border/bar at the top of the window, making it harder to find something to 'grab' with your pointing device. Some operating systems use a modifier key + the mouse to turn all windows draggable and disable inputs while doing it, but that hasn't had much success (aside from it being the default on certain window managers).
He then describes an experiment where he used a 21-inch monitor and a 13-inch monitor attached to a Mac, and had subjects change the color of folders on one screen by selecting menu items on the other. Even compared to a pop-up menu right under the mouse, the far-off edge menu bar was still faster.
Objects on a 2018 MacBook Pro can be 70% further apart (D) than on a 1984 Macintosh, but the edges of the screen are still infinitely big (W).
1. How fast can you get the pointer to the menu?
2. How easy is it to get the right item?
If you have a "large" screen, I would contend that having a dedicated menu button on your mouse/trackpad/trackball/pen is the best possible thing for any user who isn't a complete novice. Don't wave the pointer somewhere else, make the menu come to you.
If you can't do that for whatever reason, then having a high-acceleration pointer that can be flung all the way against an edge is next best. Going back to where you were, though, will be relatively hard.
This is something I remember very clearly since it was the explanation I was given when I first tried out the original Macintosh decades ago. Even with its tiny screen I had to lift and reposition the mouse, or otherwise move my whole arm, in order to go from one edge to the other. The other annoyance that stood out was menus that didn't stay open unless you held down the button, and a complete lack of keyboard navigation (I know about the keyboard shortcuts, but it doesn't compare to being able to browse through the menus with only the arrow keys, which could be done even with early Windows.)
Having to
-move the pointer diagonally across two screens, then pick something in a submenu (carefully, I think the submenu disappears if you don’t hit the end of the first menu and instead tries to move directly to the item in the sub menu)
- and back again
is one of the things I never miss.
What is at least as interesting is the cognitive load of tracking/pointing, clicking/chording . Mental load and apparent time appear to be the reason why typing can be slower than a menu system, but it feels faster. Similarly, people will report a feeling like a trackpoint (IBM keyboard nipple) takes longer than a mouse even when they're actually faster in hitting targets. Presumably, this is because they have to track the cursor to know velocity and position, while a mouse or touchpad uses your body's knowledge of hand position/velocity that is missing from a force based input.
What you're used to feels right in any case.
Fitts Law is specifically about targeting.
The 'feature' to wrap the pointer may compound targeting issues but it's secondary. Again, Fitts' is about distance to and size of a target.
I posted this in previous discussion too, a much simpler explanation : https://www.youtube.com/watch?v=E3gS9tjACwU
They also have the advantage that you don't need to focus your visual attention on hitting the target (which linear menus require), because you can move in any direction into a big slice without looking at the screen (while parking the cursor in a little rectangle requires visual feedback), and you can learn to use them with muscle memory, with quick "mouse ahead" gestures.
http://www.donhopkins.com/drupal/node/100
An Empirical Comparison of Pie vs. Linear Menus
Jack Callahan, Don Hopkins, Mark Weiser (+) and Ben Shneiderman. Computer Science Department University of Maryland College Park, Maryland 20742 (+) Computer Science Laboratory, Xerox PARC, Palo Alto, Calif. 94303. Presented at ACM CHI'88 Conference, Washington DC, 1988.
Abstract
Menus are largely formatted in a linear fashion listing items from the top to bottom of the screen or window. Pull down menus are a common example of this format. Bitmapped computer displays, however, allow greater freedom in the placement, font, and general presentation of menus. A pie menu is a format where the items are placed along the circumference of a circle at equal radial distances from the center. Pie menus gain over traditional linear menus by reducing target seek time, lowering error rates by fixing the distance factor and increasing the target size in Fitts's Law, minimizing the drift distance after target selection, and are, in general, subjectively equivalent to the linear style.
http://www.donhopkins.com/drupal/node/98
The Design and Implementation of Pie Menus -- Dr. Dobb's Journal, Dec. 1991
There're Fast, Easy, and Self-Revealing.
Copyright (C) 1991 by Don Hopkins.
Originally published in Dr. Dobb's Journal, Dec. 1991, lead cover story, user interface issue.
Introduction
Although the computer screen is two-dimensional, today most users of windowing environments control their systems with a one-dimensional list of choices -- the standard pull-down or drop-down menus such as those found on Microsoft Windows, Presentation Manager, or the Macintosh.
This article describes an alternative user-interface technique I call "pie" menus, which is two-dimensional, circular, and in many ways easier to use and faster than conventional linear menus. Pie menus also work well with alternative pointing devices such as those found in stylus or pen-based systems. I developed pie menus at the University of Maryland in 1986 and have been studying and improving them over the last five years.
During that time, pie menus have been implemented by myself and my colleagues on four different platforms: X10 with the uwm window manager, SunView, NeWS with the Lite Toolkit, and OpenWindows with the NeWS Toolkit. Fellow researchers have conducted both comparison tests between pie menus and linear menus, and also tests with different kinds of pointing devices, including mice, pens, and trackballs.
Included with this article are relevant code excerpts from the most recent NeWS implementation, written in Sun's object-oriented PostScript dialect.
https://www.youtube.com/watch?v=Jvi98wVUmQA
Demo of Pie Menus in SimCity for X11. Ported to Unix and demonstrated by Don Hopkins.
https://www.youtube.com/watch?v=SG0FAKkaisg
Pet Rock Remote Control: Pie menu remote control touch screen interface for sending commands to pet rocks.
https://www.youtube.com/watch?v=2KfeHNIXYUc
MediaGraph Music Navigation with Pie Menus Prototype developed for Will Wright's Stupid Fun Club: This is a demo of a user interface research prototype that I developed for Will Wright at the Stupid Fun Club. It includes pie menus, an editable map of music interconnected with roads, and cellular automata.
https://www.youtube.com/watch?v=-exdu4ETscs
The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo: This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts.
Any idea why these are not often used with touchscreen mobile interfaces, e.g. press for contextual pie menu? Even without OS support, they could be implemented within apps.
With touch screens, there's two major differences compared to the desktop:
1) You don't have screen edges that you can fling your cursor against, so placing UI elements at the edge does not make them easier to hit.
2) Users are generally quicker to traverse the screen and hit something, but are much worse at hitting something that's small, so you often want to make UI elements bigger (which does result in them being more spaced out) and then put the UI elements on several screens instead.
I invited Kevin to repost his old article that was posted in 2007 but never got any discussion on Hacker News: https://hn.algolia.com/?query=Visualizing%20Fitts%27s%20Law&....
