←back to thread

Hidden interface controls that affect usability

(interactions.acm.org)
559 points cxr | 2 comments | 05 Jul 25 23:10 UTC | HN request time: 0s | source
Show context
BLKNSLVR ◴[06 Jul 25 00:08 UTC] No.44476587[source]▶
Only 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(13): >>44476895 #>>44476928 #>>44477052 #>>44477272 #>>44477296 #>>44477374 #>>44477562 #>>44477584 #>>44477638 #>>44477886 #>>44478017 #>>44478439 #>>44480726 #
6510 ◴[06 Jul 25 03:23 UTC] No.44477562[source]▶
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.)

replies(4): >>44477585 #>>44477716 #>>44478054 #>>44479571 #
jama211 ◴[06 Jul 25 04:01 UTC] No.44477716[source]▶
No one wants or needs an entire seperate device just to handle scrollbars that work absolutely fine currently…
replies(2): >>44477852 #>>44480107 #
6510 ◴[06 Jul 25 04:29 UTC] No.44477852[source]▶
It was just a vision from long ago. But okay, for sake of argument. It doesn't need to be ultra hd in a billion colors, it can go on the bezel and be screen height so that you don't have to aim to hit it. No need for it to glow intensely, perhaps not at all, perhaps simple single color LCD would do the trick.

I don't agree scrollbars work fine, they use to work fine, now they are to tiny to click on.

There also was/is the issue where the view port width needs to be adjusted when page state grows beyond the screen height then word wrap makes the content shift down. Is the solution to have one so tiny it is hard to use or should one always display a scrollbar? The one outside the screen is always there :)

I like things that do only one thing, do it well and in a simple way.

You could also go the other direction and put everything on the screen. Huawei just made a horrifying laptop where the keyboard is also a screen.

replies(1): >>44493667 #
jama211 ◴[07 Jul 25 19:11 UTC] No.44493667[source]▶
Why are you trying to actually click on a scroll bar? That’s my biggest question, the reason they’re small and out of the way is because 99% of people don’t use them 99% of the time. I can’t even remember the last time I actually clicked on one. That’s what scroll wheels/gestures are for.
replies(1): >>44498024 #
1. 6510 ◴[08 Jul 25 07:57 UTC] No.44498024[source]▶
It does a few things.

If you are reading (top to bottom) the wheel is really useful. It scrolls in chunks tho. A touch pad is more accurate but I always attach a mouse to my laptops. Not sure why but it feels less convenient than the scroll wheel.

If you need to travel slightly further dragging the middle mouse "button" is great. I have no idea how to do that with a touch pad but one can also use page up and page down (or [shift+]space when available)

If pages or documents are really long it isn't fast enough. I might roughly know where the thing I'm looking for is. Holding down the mouse button on that offset. Is faster.

The scrollbar does both extremely fast and fine scrolling. I rarely start reading a page of code from the top. The larger sections are usually the most relevant. Here I hold the scroll bar and move it up and down quickly and accurately while reading.

But the real trick is that it doesn't affect the cursor position. You can scroll then continue typing and it will jump to the cursor. [say] inline ccs, I'm typing some html but need to lookup what some class name was called. I can scroll to it, read and continue typing. Same for the name of functions and variables defined elsewhere in the same file. Or [say] I don't recall how to write someones name eventho I've already used it in the same article.

replies(1): >>44507436 #
2. jama211 ◴[09 Jul 25 08:12 UTC] No.44507436[source]▶
You make some good points, but for contrast I thought I’d share my workflow in those same situations. For scrolling in chunks, this isn’t the case with many mice and is OS dependent too - Magic Mouse on the Mac is a good example of a smooth scrolling experience with a mouse, but on my windows machine I use a Logitech g502 which had the ability to toggle between a clicked and unlclicked mouse wheel state, which I can use both for precision and for speed scrolling to the top or bottom (unclick, spin with wild abandon, click in again).

As for the text editor example I use the preview scroll pane on the right and drag that for that use case, it’s a huge grab target and a great example of a situation where this is relevant but it has its own solution.

Either way, if you really want scrollbars to always stay visible in your browser there are solutions to force show it all the time, but I’d say you were a rare user in actually wanting that.