←back to thread

559 points cxr | 1 comments | | HN request time: 0s | source
Show context
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 #
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 #
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 #
gmueckl ◴[] No.44481595[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 #
1. layer8 ◴[] No.44481742[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.