[jedberg]

If you want a true lesson on design, check out Ask Tog, starting here:

https://asktog.com/atc/principles-of-interaction-design/

Tog was the original design engineer for the Mac, and arguably one of the first true HCI engineers.

Then read the rest of his website. He goes into where Windows tried to copy Mac and got it horribly wrong.

One of my favorite examples is menu placement. The reason the Mac menus are at the top is because the edges of the screen provide an infinite click target in one direction. So you just go to the top to find what you want. With Windows, the menu was at the top of each Window, making a tiny click target. Then when you maximized the window, the menu was at the top, but with a few pixels of unclickable border. So it looked like the Mac but was infinitely worse.

If you're making a UI, you should read all of Tog's writings.

[hakfoo]

I understand the Fitt's Law concepts behind a top menu bar, but I wonder if this is a scenario with moving goalposts.

On a 1984 Mac, you had like 512x384 pixels and a system that could barely run one program at a time. There was little to no possible uncertainty as to who owned the menu bar. (Could desk accessories even take control of the menu bar?)

But once you got larger resolutions and the ability to have multiple full-size programs running at once, the menu bar could belong to any of them. Now, theoretically, you should notice which is the currently active window and assume it owns the menu bar, but ISTR scenarios where you'd close the window but the program would still be running, owning the menu bar, or the "active" window was less visually prominent due to task switching, etc.

The Windows design-- placing the menu inside the window it controls-- avoids any ambiguity there. Clicking "File-Save" in Notepad couldn't possibly be interpreted as trying to do anything to the Paintbrush window next to it.

[canucker2016]

The problem with the Mac UI is that the app's menubar can only be accessed by the mouse (can't remember what accessibility-enabled mode would allow).

Under Windows, one can access the app's menubar by pressing the ALT key to move focus up to the menubar and use the cursor keys to navigate along the menubar. If you know the letter associated with the top-level menu (shown as underlined), then ALT-[letter] would access that top-level menu (typically ALT-F would get you to the File menu). So the Windows user wouldn't have to move the mouse at all, Fitt's Law to the max (or is it min? whatever, it's instant access).

For the ultrawide monitors these days (width >= 4Kpx), if you have an app window maximized (or even spanning more than half the screen), accessing the menu via mouse is just terrible ergonomics on any major OS.

[wmf]

AFAIK Windows 3.x flipped a bunch of Mac decisions to avoid being sued and then MS felt that they had to keep those choices forever for backwards compatibility.

[jonhohle]

And in my experience, when people moved from Windows to the Mac they're so annoyed that there are differences. When I try to explain that these were present in the Mac long before Windows, people start to understand.

[pixelesque]

> So it looked like the Mac but was infinitely worse.

On single monitor setups maybe: but on early OS X multi-monitor setups, you then had the farcical situation where the menu would only be shown on the "primary" display, and the secondary display didn't have any menu at all, so to use menus for windows that were on the secondary display, you had to move the cursor onto the other primary display where the menu was for all windows (or use keyboard shortcuts).

I think 10.6/7 (not sure exactly) was when they started putting the menu bar on both displays rather than just the primary.

[kryptiskt]

> So it looked like the Mac but was infinitely worse.

"Infinitely worse"? Some people really need to cool off the hyperbole.

Having each window be a self-contained unit is the far better metaphor than making each window transform a global element when it is selected. As well as scaling better for bigger screens. An edge case like that may well be unfortunate, but it could be the price you pay to make the overall better solution.

[jonhohle]

That was the point of Tog's conclusion: edges of the screen have infinite target size in one cardinal direction, corners have infinite target size in two cardinal directions. Any click target that's not infinite in comparison, has infinitely smaller area, which I suppose you could conclude is infinitely worse if clickable area is your primary metric.

This wasn't just the menu bar either. The first Windows 95-style interfaces didn't extend the start menu click box to the lower left corner of the screen. Not only did you have to get the mouse down there, you had to back off a few pixels in either direction to open the menu. Same with the applications in the task bar.

The concept was similar to NEXTSTEP's dock (that was even licensed by Microsoft for Windows 95), but missed the infinite area aspect that putting it on the screen edge allowed.

[jedberg]

The infinitely worse part was when you maximized the window so the menu bar was at the top, but Windows still had the border there, which was unclickable.

So now you broke the infinite click target even though it looked like it should have one.

[bediger4000]

You can generalize this observation to a lot of Microsoft's decisions: a problem exists, so they solve it in a nifty way, a way that makes everything else harder or more error prone. An example: byte order mark. That sure does solve the problem of UTF-16 and UTF-32 byte order determination. It makes every other use of what should be a stream of bytes or words much harder. Concatenate two files? Gotta check for the BOM on both files. Now every app has to look at the first bytes of every "text" file it opens to decide what to do. Suddenly, "text" files have become interpreted, and thus open to allowing security vulnerabilities.