alt Hacker NewsOnly tangentially related, and a seemingly lost old-man battle: stop hiding my scrollbar.
Interesting article. Some points I didn't quite agree entirely with. There's a cost and practically limitation to some things (like a physical knob in a car for zooming in and out on a map - although that was probably just an example of intuitive use).
I just recently switched a toggle on a newly installed app that did the opposite of what it was labelled - I thought the label represented the current state, but it represented the state it would switch to if toggled. It became obvious once changed, but that seems the least helpful execution.
Replies
There was such a confusing toggle at the ticket machines for the train here in Austria many years ago. It was for immediately validating your ticket, which is a potentially costly mistake.
About the scroll bars: Also stop making them so thin that I have to have FPS skills to hit them! Looking at you, Firefox! (And possibly what standard CSS allows?) Yeah, I can scroll, but horizontally the scrollbar would be more convenient than pressing shift with my other hand.
> I thought the label represented the current state, but it represented the state it would switch to if toggled. It became obvious once changed, but that seems the least helpful execution.
Such ambiguous switches are often associated with "opt out" misfeatures.
Right! If you want it to denote an action, you need to include the verb: "TURN ON" would be entirely clear. It's even clear if you sometimes DO want to show state / not a button "IS ON" is also perfectly clear. There's only a few that might he confused when the verb is shown, like "INCREASE," although I would have to work a little to imagine the UI where it's not clear whether the button is showing the verb or noun.
In macOS you can have the scroll bar always on, globally (using System Settings) or per-app (using Terminal command)
Reading through the responses of your comment, I came to the conclusion that the topic is on point. There are many complains about people missing things (please add ...), and people responding with a solution because it's already there - just hidden.
I can't recall the app but it was a similar toggle with a label, when you flipped the toggle the label lit up green indicating it was turned on. But the default state was off but how would you know?
Yeah, a hidden scroll bar makes a UI unusable if you prefer a touch screen, as I do.
I recently used the washroom at a Starbucks. The one where you have to enter a code to get in. Once I was inside, there were no knobs or any mechanical way to lock the door - just one circular button with a lock icon on it. I pressed it, and the button lit up as green. Pressed it again, it lit up as red. No indication on what light colour meant what. Does red mean it's unlocked? Or does it mean it is locked, since red usually indicates no entry.
It made for the quickest pee break ever.
I absolutely despise switches. I'm also constantly asking myself if the label represents the current state or the state it would switch to.
In the 90's I had this vision that the menu and the scrollbar should be physically separated from the screen.
If you have (next to your monitor on the left side) a narrow physical display with menu entries in it. You get 4 things for "free", the user will expect there to be menu entries, the developer will understand the expectations to have menu entries, there is limited room to go nuts with the layout or shape of the menu and last but most funny, you won't feel part of the screen has been taken away from you.
The physical scrollbar should be a transparent tube with a ball (or ideally a bubble) floating in it.
Usage could be moving the pointer out of the screen. The scrollbar led goes on and you can hold the button to move the page. When using the menu the pointer [also] vanishes and the menu entry at that height is highlighted. (much better usability) Moving the mouse up or down highlights the above or below entries, if there are a lot of entries it may also scroll. It may be a touch screen but the most usuable would be a vertical row of 5 extra wide (3 fingers) keyboard buttons on the left with the top 4 corresponding to the 1st, 2nd, 3rd, 4th menu entry and the 5th one for page down. (scrolling down 4 entries) Ideally these get some kind of texturing so that one can feel which button one is touching.
This way knowledge in the world can smoothly migrate to knowledge in the head until eventually you can smash out combinations of M keys in fractions of a second without looking at the screen or the keyboard. The menu displayed is always in focus, you don't have to examine the view port to use it. Having a row of horizontal F keys is a design fiasco. Instinctively bashing the full row of those might come natural after learning to type, then learning to type numbers, then symbols and only if you frequently use applications that have useful F key functionality. I only really know F5 and F11 but I cant smash them blindly as I pretty much never use them. I just tried F1 in firefox and no help documentation showed up... I think that was what it was suppose to do? Not even sure anymore.
Having the antenna menu (file, edit, etc) at the top of the viewport is also ugly. For example, smashing the second then the top M key could easily become second nature. CTRL+Z is fine of course but it aint knowledge in the world. Does anyone actually use ALT+E+U for undo? Try it on the CTRL+F input area. It's just funny. Type something in the address bar then compare ALT+E+U with using the Edit menu.
A separate display would take many of these "design" privileges away from the clowns.
(note: I think it is ALT+E+U as the Dutch layout is forced on me by windos. Edit is called Bewerken and the shortcut is ALT+W!?! ALT+E does nothing.)
I hate toggle switches IRL too. They are just as ambiguous there. Checkboxes and pushed-in buttons are far clearer, but have unfortunately been sacrificed at the altar of "modernity".