I can only conclude there are other factors at play:
- Muscle memory will have an impact since the menus are in the same location for every program.
- The mouse acceleration means you can get the pointer to the top of the screen very rapidly.
- Once the mouse gets to the top aiming is only horizontal, controlling a mouse in one dimension is easier then controlling it in two.
Getting to the top of the screen is a flick of the wrist, this only gets you to the rough area. Once you are in the rough area getting to the specific menu is then very quick. It's a two stage process and Fitts' law applies does indeed apply to both, individually.
If the menu is not at the top aiming has to be in 2 dimensions and this is more difficult. Try drawing an exact circle quickly, this is very difficult. Try drawing a circle quickly with a mouse, it's even harder and acceleration only accentuates the errors. Aiming a mouse is difficult enough in two dimensions but acceleration means you're likely to overshoot, making aiming even harder.
This does not mean putting menus or controls on windows is somehow unusable (you can click on a web link can't you?), but if you have high mouse acceleration it does make getting to them can be slower than points on the edge of the screen.
However, it's still not that simple, it may well be the case that with low mouse speed / acceleration it is better to have the menus on the window - try moving menus around and changing mouse speed, at a low mouse speed moving around the entire screen is quite a chore.
I don't believe Fitts' law it is the be-all and end-all some seem to describe it as but it is a useful guideline none the less, though the differences between the original law and modern computer interfaces need to be taken into account, as do individual user preferences.
Usability is not just about the GUI, it should apply to everything, even the command line. English (or other natural language) commands have been around since MS-DOS and probably even before that. IBM have had a slightly cryptic but very easy to use shell for decades. However the concept of usability appears to have completely passed by the common Unix shells where bizarre acronyms abound making them all but impenetrable to the casual user. What exactly does "Grep" mean?
Command lines are very useful tools and they are in many cases better suited to tasks which would be difficult to represent well in GUIs. However, there is no reason they should be so complex as to require a reference book to use them, they should be available to all users, experience on other platforms has shown this can be the case with a well designed naming scheme.
In our new platform I'd like to see a shell with the power of bash but with commands such as "list", "remove", "search" etc. There'd also be an extensive help system for using the commands. The system should boot with a GUI as standard so this should be used to enhance the console, displaying options, help etc. Unix users may scoff at the idea of a system booting with a GUI by default but many different desktop systems have been doing this for a very long time with no ill effects. Just because X can be flakey does not mean other graphics systems are the same.
Another thing Unix geeks are not going to like is the removal of case sensitivity [Case], it is yet another hangover from the past, serves no useful purpose and is a potential source of confusion, so why have it? Google and other search engines are by default case insensitive, they'd be a pain to use if they were not. I would however keep keep case preservation.
A sensible naming scheme should also apply to the file system structure, it could be organised beginning along the lines of:
- /System - OS files
- /Applications - 3rd party applications and libraries
- /Home - All user files in here
The user and system files are separated to simplify backing-up, to backup or move your files you just copy "/Users/My Name" to the desired destination (something else I'd fix is the ability to use spaces in file names).
When a user downloads an application it and it's libraries should be automatically moved to the relevant applications area, this should be indicated to the user along with the application's global settings (i.e. type of app, who can use it etc.) so they can be changed.