Most active commenters
  • DidYaWipe(15)
  • layer8(4)
  • devnullbrain(4)
  • int_19h(3)
  • gmueckl(3)
  • fuzzy2(3)

←back to thread

559 points cxr | 53 comments | | HN request time: 3.307s | source | bottom
1. weinzierl ◴[] No.44477561[source]
I get why you would hide interface elements to use the screen real estate for something else.

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?

replies(8): >>44477624 #>>44477657 #>>44477684 #>>44477720 #>>44477854 #>>44478558 #>>44480234 #>>44484094 #
2. ryncewynd ◴[] No.44477624[source]
I agree, I know those buttons are there and how to activate them, but I still occasionally stare blankly at the screen wondering where the buttons are before remembering I need to hover them
3. autobodie ◴[] No.44477657[source]
Intellij on Windows also buries the top menus into a hamburger icon and leaves the entire area they occupied empty! Thankfully there is an option to reverse it deep in the settings, but having it be the default is absolutely baffling.
replies(1): >>44477724 #
4. wizardforhire ◴[] No.44477684[source]
In some apps I don’t know more controls are not hidden, at least have the option to hide them. Looking at you google maps.
5. nine_k ◴[] No.44477720[source]
Some people complain about "visual clutter". Too many stimuli in the field of view assault their attention, and ruin their concentration. Such people want everything that's not in the focus of attention be gone, or at least be inconspicuous.

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.

replies(2): >>44477860 #>>44479817 #
6. DidYaWipe ◴[] No.44477724[source]
Microsoft pulls the same BS. Look at Edge. Absolute mess. No menu. No title bar. What application am I even using?

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.

replies(5): >>44478065 #>>44478385 #>>44478435 #>>44479181 #>>44481690 #
7. musicale ◴[] No.44477854[source]
> I get why you would hide interface elements to use the screen real estate for something else.

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.

8. musicale ◴[] No.44477860[source]
This is a good idea. In basic/beginner mode, every control should be readily visible and discoverable.
replies(1): >>44478750 #
9. aniforprez ◴[] No.44478065{3}[source]
For your complaints about the taskbar, yes I too find it incredibly annoying that they compress all the application windows into a tiny thumbnail but there is a setting to expand thumbnails to include titles and separate them if there are multiple windows which is what I use. I don't currently have access to my windows machine or I'd help you out with the exact setting but it's there somewhere in the "taskbar settings"
replies(1): >>44479338 #
10. userbinator ◴[] No.44478385{3}[source]
No title bars or menus... now you can't tell what application a Window belongs to.

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.

replies(3): >>44479320 #>>44480257 #>>44482283 #
11. int_19h ◴[] No.44478435{3}[source]
This isn't just a Windows thing. Look at Gnome for another example. macOS of late also likes to take over the title bar for random reasons, although there at least the menu bar is still present regardless.
replies(3): >>44478993 #>>44479299 #>>44481233 #
12. 9dev ◴[] No.44478558[source]
> There is this little target disc that moves the selection in the project tree to the file currently open in the active editor tab.

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.

13. theturtle32 ◴[] No.44478750{3}[source]
In practice, "beginner mode" just makes inaccessible all controls deemed by the designer to be outside the realm of basic use cases.
14. gylterud ◴[] No.44478993{4}[source]
At least on Linux you have 100 choices of window manager (and 100 themes of KDE). 101 if you roll up your sleeves and roll your own.
15. ajolly ◴[] No.44479181{3}[source]
Turn on never combine taskbar labels in the taskbar settings
replies(1): >>44479324 #
16. DidYaWipe ◴[] No.44479299{4}[source]
I've always considered the Mac's shared menu bar a GUI 1.0 mistake that should have been fixed in the transition to OS X. Forcing all applications to share a single menu that's glued to the top of the screen, and doesn't switch back to the previous application when you minimize the one you're working with, is dumb.

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.

replies(2): >>44479616 #>>44487001 #
17. DidYaWipe ◴[] No.44479320{4}[source]
Amen. And then there's the idiotic peek-a-boo UI that hides controls until you accidentally roll over them with the cursor... not saving any space at all.
18. DidYaWipe ◴[] No.44479324{4}[source]
How does turning that off help? Does it let you bring an entire application to the foreground (all of its windows) at once?
replies(1): >>44482299 #
19. DidYaWipe ◴[] No.44479338{4}[source]
Thanks very much. But it doesn't sound like that would help. First, I doubt a giant network path would fit in the title of a thumbnail.

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.

replies(1): >>44487701 #
20. danaris ◴[] No.44479616{5}[source]
...The Mac menu bar is what it is for a very good reason. Being at the top of the screen makes it an infinitely-tall target.

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.

replies(3): >>44479883 #>>44481637 #>>44487855 #
21. layer8 ◴[] No.44479817[source]
This is why we used to have customizable toolbars, and relevant actions still accessible via context menu and/or main menu, where the respective keyboard shortcuts were also listed. No need to compromise. Just make it customizable using a consistent framework.
replies(1): >>44481595 #
22. layer8 ◴[] No.44479883{6}[source]
This argument never made much sense to me, although I do subscribe to Fitts' Law. With desktop monitor sizes since 20+ years ago, the distance you have to travel, together with the visual disconnect between application and the menu bar, negates the easier targetability. And with smaller screen sizes, you would generally maximize the application window anyway, resulting in the same targetability.

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.

replies(1): >>44480264 #
23. devnullbrain ◴[] No.44480234[source]
I really disagree.

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'.

replies(1): >>44482852 #
24. devnullbrain ◴[] No.44480257{4}[source]
We don't do desktop computing like we did then. Most of what was separate applications then are now done in-browser: it's like running a virtual machine inside your OS.

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.

replies(1): >>44480493 #
25. danaris ◴[] No.44480264{7}[source]
> With desktop monitor sizes since 20+ years ago, the distance you have to travel, together with the visual disconnect between application and the menu bar, negates the easier targetability.

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.

replies(2): >>44480895 #>>44487005 #
26. iamtedd ◴[] No.44480493{5}[source]
This argument would make more sense if it wasn't in a thread talking about all the other apps besides the browser that does this.
replies(1): >>44480568 #
27. devnullbrain ◴[] No.44480568{6}[source]
My point is that there rarely are other 'apps' in use.
replies(1): >>44487736 #
28. layer8 ◴[] No.44480895{8}[source]
I’m not saying it’s necessarily harder to reach a menu bar at the top of the screen, given suitable mouse acceleration. But you also have to move the mouse pointer back to whatever you are doing in the application window, and moving to the top menu bar is not that much (if at all) easier to really justify the cognitive and visual separation. It that were the case, then as many application controls as possible should be moved to the border of the screen.
29. mjmas ◴[] No.44481233{4}[source]
At least on Linux (depending on wm) I have Alt/Gui + Drag to move around from anywhere in the window. (And installed a program that does the same for Windows)
30. gmueckl ◴[] No.44481595{3}[source]
There is a subtlety here. Having a configurable UI requires that all the buttons and menu entries have a somewhat consistent behavior among themselves. That isn't the case sometimes.

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.

replies(1): >>44481742 #
31. gmueckl ◴[] No.44481637{6}[source]
There are videos out there where CHM interviewed Bill Atkinson. One part has him go over old Polaroids of Lisa interface drafts. There, he justifies the menu bar at the top of the screen differently: they couldn't figure out what to do when the menu was too wide.for the window when the user made it narrow.
replies(1): >>44493273 #
32. Avamander ◴[] No.44481690{3}[source]
> This stupidity seems to have spread across Windows. No title bars or menus... now you can't tell what application a Window belongs to.

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.

replies(1): >>44490420 #
33. layer8 ◴[] No.44481742{4}[source]
There can certainly be subtleties. Though in your example, I would argue the mode toggles then belong in a toolbar on each of the instances, which would be a configurable toolbar just like the global one.
34. fuzzy2 ◴[] No.44482283{4}[source]
> now that they have multiplied many times in resolution

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.

35. fuzzy2 ◴[] No.44482299{5}[source]
And when was that ever a thing on Windows?
replies(1): >>44490426 #
36. xboxnolifes ◴[] No.44482852[source]
What part do you disagree with?
37. burnte ◴[] No.44484094[source]
> I have no idea why some interfaces hide elements hide and leave the space they'd taken up unused.

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.

38. int_19h ◴[] No.44487001{5}[source]
I fully agree with you that the menu bar placement in macOS is really weird and confusing and rather inconvenient (regardless of any claimed benefits per Fitt's Law). It's ironic that it ended up being a benefit in the age of UX enshittification solely because it forces apps to have the menu in the first place (although I increasingly see apps that do the bare minimum there and hide the rest behind hamburger menus in the apps).
replies(1): >>44487773 #
39. int_19h ◴[] No.44487005{8}[source]
Mac is my primary desktop these days and has been for over a year now, and it's still annoying.
replies(1): >>44487925 #
40. aniforprez ◴[] No.44487701{5}[source]
Yes there are limits to how long the title will go until it starts getting truncated so it is possible it won't fit a network path. I'm not sure if the behaviour of the taskbar was always to bring every window of an app to the foreground? But yes I don't think that's a thing either.
41. DidYaWipe ◴[] No.44487736{7}[source]
That assertion is absurd.
replies(1): >>44490633 #
42. DidYaWipe ◴[] No.44487773{6}[source]
Exactly. The single menu causes quite a few problems, both obvious and subtle.

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.

43. DidYaWipe ◴[] No.44487855{6}[source]
Ah yes, this old argument. Except nobody slams his cursor against the top of the screen in real life, assuming that the menu bar is "infinitely tall." Watch real users interact with a Mac's menu, and you simply won't see this behavior. Not to mention that it doesn't work if you're using a laptop and a second monitor positioned behind and above 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.

44. DidYaWipe ◴[] No.44487925{9}[source]
I've been on Mac for 20 years and it's still annoying as hell.

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.

45. DidYaWipe ◴[] No.44490420{4}[source]
Except of course when it's not obvious at all.
46. DidYaWipe ◴[] No.44490426{6}[source]
I don't know. Was it?
replies(1): >>44491063 #
47. devnullbrain ◴[] No.44490633{8}[source]
It is not novel to point out that more things are webapps or Electron.
replies(1): >>44493246 #
48. fuzzy2 ◴[] No.44491063{7}[source]
No, that's kind of the point. It's not something Windows XP/Vista/whatever made worse by hiding it or even taking it away. It simply is not available.

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

replies(1): >>44493298 #
49. DidYaWipe ◴[] No.44493246{9}[source]
"More things" than what? And novelty has nothing to do with it. This is about validity.
50. DidYaWipe ◴[] No.44493273{7}[source]
Huh. I wonder why they thought this was such a big deal. I mean... the user caused the problem, and could easily fix it by enlarging the window. Other windowing GUIs handle this just fine.
replies(1): >>44506895 #
51. DidYaWipe ◴[] No.44493298{8}[source]
I'm not really exploring the origin of the problem; I'm just saying it's dumb and a pain in the ass.
52. gmueckl ◴[] No.44506895{8}[source]
I'm not sure if it was user tested, but IIRC part of the problem was that there was no visual indication that the menu bar is cut off and some of the commands are inaccessible. We need to remember that this was new - they were introducing a GUI to the masses for the first time ever. Everything hat to be extremely clear.
replies(1): >>44514868 #
53. DidYaWipe ◴[] No.44514868{9}[source]
Good point, and surely a valid concern... one that Apple has forgotten in some places today. Look at the utterly useless icon/thumbnail view in Finder: Contents don't wrap within the window. There could be dozens or hundreds of files off-screen in limbo, and you'll never know.

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.