alt Hacker NewsIf 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.
Replies
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.
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.
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.