←back to thread

Hidden interface controls that affect usability

(interactions.acm.org)
561 points cxr | 1 comments | 05 Jul 25 23:10 UTC | HN request time: 0.244s | source
Show context
weinzierl ◴[06 Jul 25 03:23 UTC] 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 #
1. musicale ◴[06 Jul 25 04:30 UTC] 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.