Hidden interface controls that affect usability

I have no idea why some interfaces hide elements hide and leave the space they'd taken up unused.

IntelliJ does this, for example, with the icons above the project tree. There is this little target disc that moves the selection in the project tree to the file currently open in the active editor tab. You have to know the secret spot on the screen where it is hidden and if you move your mouse pointer to the void there, it magically appears.

Why? What is the rationale behind going out of your way to implement something like this?

Some people are like airliner pilots. They enjoy every indicator to be readily visible, and every control to be easily within reach. They can effortlessly switch their focus.

Of course, there is a full range between these extremes.

The default IDE configuration has to do a balancing act, trying to appeal to very different tastes. It's inevitably a compromise.

Some tools have explicit switches: "no distractions mode", "expert mode", etc, which offer pre-configured levels of detail.

This stupidity seems to have spread across Windows. No title bars or menus... now you can't tell what application a Window belongs to.

And you can't even bring all of an application's windows to the foreground... Microsoft makes you hover of it in the task bar and choose between indiscernible thumbnails, one at a time. WTF? If you have two Explorer windows open to copy stuff, then switch to other apps to work during the copy... you can't give focus back to Explorer and see the two windows again. You have to hover, click on a thumbnail. Now go back and hover, and click on a thumbnail... hopefully not the same one, because of course you can't tell WTF the difference between two lists of files is in a thumbnail.

And Word... the Word UI is now a clinic on abject usability failure. They have a menu bar... except WAIT! Microsoft and some users claim that those are TABS... except that it's just a row of words, looking exactly like a menu.

So now there's NO menu and no actual tabs... just a row of words. And if you go under the File "menu" (yes, File), there are a bunch of VIEW settings. And in there you can add and remove these so-called "tabs," and when you do remove one, the functionality disappears from the entire application. You're not just customizing the toolbar; you're actually disabling entire swaths of features from the application.

It's an absolute shitshow of grotesque incompetence, in a once-great product. No amount of derision for this steaming pile is too much.

Except that screens on phones, tablets, laptops and desktops are larger than ever. Consider the original Macintosh from 1984 – large, visible controls took up a significant portion of its 9" display (smaller than a 10" iPad, monochrome, and low resolution.) Arguably this was partially due to users being unfamiliar with graphical interfaces, but Apple still chose to sacrifice precious and very limited resources (screen real estate, compute, memory, etc.) on a tiny, drastically underpowered (by modern standards) system in the 1980s for interface clarity, visibility, and discoverability. And once displays got larger the real estate costs became negligible.

I hate when applications stuff other controls (like browser tabs) into the title bar --- leaving you with no place to grab and move the window.

The irony is that we had title bars when monitors were only 640x480, yet now that they have multiplied many times in resolution, and become much bigger, UIs are somehow using the excuse of "saving space" to remove title bars and introducing even more useless whitespace.

Don’t quote me on this, but I vaguely remember there being an option to toggle hiding it, if not in the settings it is in a context menu on the panel.

That thing is a massive time saver, and I agree—keeping it hidden means most people never learn it exists.

Windows and Unix GUIs had it right: Put an application's menu where it belongs, on the application's main frame.

But now on Windows... NO menu? Oh wait, no... partial menus buried under hamburger buttons in arbitrary locations, and then others buried under other buttons.

Second, I want to give focus to the entire application at once. ALL of its windows need to be brought to the foreground at once.

All you have to do to get to it is move your mouse up until you can't move it up any more.

This remains a very valuable aspect to it no matter what changes in the vogue of UIs have come and gone since.

The fact that you think that you've "minimized the application" when you minimized a window just shows that you are operating on a different (not better, not worse, just different) philosophy of how applications work than the macOS designers are.

The actual historical rationale for the top menu bar was different, as explained by Bill Atkinson in this video: https://news.ycombinator.com/item?id=44338182. The problem was that due to the small screen size, non-maximized windows often weren't wide enough to show all menus, and there often wasn't enough space vertically below the window's menu bar to show all menu items. That's why they moved the menus to the top of the screen, so that there always was enough space, and despite the drawback, as Atkinson notes, of having to move the mouse all the way to the top. This drawback was significant enough that it made them implement mouse pointer acceleration to compensate.

So targetability wasn't the motivation at all, that is a retconned explanation. And the actual motivation doesn't apply anymore on today's large and high-resolution screens.

An IDE, and the browser example given below, are tools I'll spend thousands of hours using in my life. The discoverability is only important for a small percentage of that, while viewing the content is important for all of it.

This is exactly when I will have the 'knowledge in the head'.

I don't need to know that what I'm using is Edge/Chrome/Firefox any more than I need to know that what I'm using is Windows/etc.

Try it on a Mac; the way its mouse acceleration works makes it really, really easy to just flick either a mouse or a finger on a trackpad and get all the way across the screen.

For example, if the GUI can have more than one instance of the same view open, toggle buttons for view modes become specific to individual view instances. Putting those into a global toolbar is wrong.

I disable the title bars on almost everything I use. Except some custom applications that resist such attempts. I do not give a rat's ass what is open, it's already immediately obvious. Just wasting valuable screen real-estate.

Did they though? Quite a few laptops barely have 720 pixels in (scaled) height. That's less than your CRT with 1024x768, back in the days.

UI has been taken over by graphic designers and human interaction experts have been pushed out. It happened as we started calling it "user experience" rather than "user interface" because people started to worry about the emotional state of the user, rather than being a tool. It became about being form over function, and now we have to worry about holding it wrong when in reality machines are here to serve humans, not the other way around.

But yeah... now I'm relieved when I go home from work and get back on my Mac. I waste so much time hunting for stuff on Windows now... it's just incredible.

Pompous pedants used to trot out "Fitt's Law" in defense of the Mac's dumb menu all the time, when in fact it contra-indicates it:

"Fitts’ law states that the amount of time required for a person to move a pointer (e.g., mouse cursor) to a target area is a function of the distance to the target divided by the size of the target. Thus, the longer the distance and the smaller the target’s size, the longer it takes."

Right, so where should an application's menu go? ON ITS WINDOW. Not way up at the top of the screen. It's as if the people citing this "law" don't even read it.

And we're talking about a GUI here, so when I minimize an application's GUI then yes, I expect that I've minimized the application. And again, I think you'll find that the vast majority of users work under this M.O.

But your observation raises another usability issue caused by the single menu: Instead of an "infinite" desktop, the Mac reduces the entire screen to a single application's client area... so, historically, Mac applications treated it that way...littering it with an armada of floating windows that you had to herd around.

The problem is that turning the whole screen into one application's client area fails because you can see all the other crap on your desktop and all other open applications' GUIs THROUGH the UI of the app you're trying to use. It's stupid.

So, to users' relief, the floating-window nonsense has been almost entirely abandoned over the last couple of decades and single-window applications have become the norm on Mac as they have been on Windows forever. Oh wait, hold on... here comes Apple regressing back to "transparent" UI with "liquid glass;" a failed idea from 20+ years ago.

Full circle, sadly.

Another side effect is the uselessness of the Help menu. What help am I looking at? The application owns the menu, so where's the OS help?

Oh right, it's just all mixed together. When I'm searching for information in some developer tool I'm using, I really enjoy all the arbitrary hits from the OS help about setting up printers, sending E-mail, whatever.

macOS works like this though, IIRC, and no other way.

There are, of course, ways to indicate "more controls this way" with an arrow or other affordance when there's a toolbar or menu overflow, though.

Anyway, the point is that by the time OS X came along, other platforms had solved the problems but Apple rejected those widely-accepted solutions.