Hacker News Reader

> A dedicated menu button on mouse is hard to discover.

For what it's worth, it really wasn't. The meaning of at least the left and menu buttons was literally the first thing you would find out when being shown how to use the machine, and was on the intro sheet in the (extensive and excellent) printed guides.

The difficult-to-discover part was the right button ('adjust'), defined as doing whatever the left button did but a bit differently. So the left button might select a file, while the right button might add a file to the existing selection. Or a left click on the scroll bar 'down' arrow scrolls down, while a right click scrolls up (which was actually quite useful in pre-scroll wheel days as it saved a lot of precision mouse movements when searching documents etc.)

This is really analogous to the discoverability problems that guis have with modifier keys - the right button is basically a sort of ctrl-click without needing to put your hands on the keyboard.

But the menu button was just how you used menus. It was available and worked the same in essentially all applications and was really pleasant to use.

Ctrl-click is equally hard to explore. A beginner user's experience is entirely different.

> Mac & Windows did away with always-visible menu bars just fine.

is this sarcasm? it appears disjointed from your comment and disagrees with your thesis.

> Remember how Windows 8 tried to hide the start menu and how it had turned into the worst UX experience in the last decade ever.

part of that is surely that trigger start in windows 8/8.1 closed (hid/whatever) you were working on before, forcing an unnecessary context switch. i can't print or save documents in office anymore for the same reason - if you choose “File”, it closes your current file.

note that mac os, windows, and to a much greater extent iOS and Android have abandoned the visibility principle. having a dedicated button vs a “force click” feature? i'd prefer the button.

your objections to dnd depend on it not being well implemented. but when it's core, it is well implemented. i use dnd, even sometimes to copy/paste on windows.

° "Drag & drop to open" has other issues too. For one, there is no orthogonality between open & close. Do I drag away the icon to close the file or is there a standalone "close" option without an open?

i don't understand your objection here. is there orthoganality between open/close on other systems? i have never thought so. i close by clicking x (windows, gnome) or just going back home (android). but i open by doubling click the file (linux) or doing something ad hoc (windows, android)

> is this sarcasm? it appears disjointed from your comment and disagrees with your thesis.

Not sure how it contradicts with my points. Can you clarify?

> is there orthoganality between open/close on other systems? i have never thought so.

Yes, there is always a "Close" menu option right in the same menu with the "Open". The close "X" is for closing windows, not opening them, and it also has orthogonality. You open the window by clicking on an icon, and you close it by clicking on another icon.

Going back isn't "closing" on Android. It's just the opposite of navigating forward which also makes sense in a navigational context.

> [Mac] also prevents you from examining your options without needing to click anything.

But it bundles selection-specific and system-general commands up in a remote menu bar that requires a lot of to and fro to operate. The beauty of right-click is that it gives a contextual menu specific to the object right there. I'd argue that it's fantastic UX.

> "Drag & drop" has too much user friction

Yet it's universally used for moving windows around the UI; click-drag on the title bar.