Just so you don't think my tendency to #softwareGripe is a recent thing, possibly due to becoming
old middle-aged growned-up and cranky, here's one I wrote in 1997 as a mere stripling of 32!
One thing that drives me crazy on a regular basis is that well-known graphical user interface convention, the double click.
Certain screen widgets only respond to double clicks; however, the GUI (whether it be Windows, Mac, or Other) is pretty picky about the timing of these clicks, and I often find myself double-clicking over and over again with no response. Click too slowly, and the widget sees two single clicks -- it highlights itself and then goes back to sleep. Click too quickly, however, and some helpful code buried deep in the OS decides the mouse must have a dirty switch contact, and you really meant a single click. The OS may also be getting confused about which clicks are "paired"; e.g. was this click the second part of a double-click or the first part of the next double-click?
I could go off about how there ought to always be a way to adjust the minimum time (the “dirty single-click” ceiling) to accommodate users who click quickly sometimes and slowly other times, but really I think the whole double-click concept was poorly conceived in the first place. I'm convinced that GUIs ought to discard the double-click concept and instead respond to what I call state-based clicking.
So let's go back in time a little bit. We're designing the first GUI. We have widgets on the screen, and we have a mouse to point at them and a button to push (click). We find pretty quickly that there are two major things you might want widgets to do in response to a button push: select themselves (for inclusion in a set to be operated on by another control e.g. the keyboard or an application), or execute themselves (i.e. open a file or run a program).
So how do you signal which of two actions you want using only one button? Somebody decided that if you click twice in rapid succession, that should mean the more "active" of the two options, i.e. execute. Fair enough. But how about this: click once, the object selects itself. Click on a selected widget -- whether 0.025 seconds later or tomorrow morning -- and the widget executes.
Potential problem #1: what happens when you want to move a selected object? Possible solution: an object must not be selected before it is grabbed. If you accidentally select it first, de-select it by clicking anywhere else. Potential problem #2: what about dragging multiple widgets, which must be selected in order to be part of the drag-group? Solution: when more than one widget is selected, only dragging is possible.
I implemented this solution as part of a custom-made file-open dialog for an image processing program, and found it quite satisfactory. I never had to stop myself from clicking madly, wait a full second, and then carefully click in a deliberate and methodical way in order to load a file. (The other custom-made part was that the file dialog stayed open after the file was loaded -- but that's another rant.)
I'll be solving more of what's wrong with computers as time permits, and then we’ll start in on death and taxes. Happy clicking!
Bonus for those who read this far: here is the original, complete with deadname! ^.^
Mouse operations have obviously become a lot more complex since then, not to mention touchscreen stuff, but I always felt like we kind of went down the wrong path by making duration semantically significant in GUI interactions -- and the whole "press-and-hold" paradigm (now popular with power-switches and smartphones) feels like further digging in.
...but of course there are many more-obviously-terrible choices that computing has made since then, so this is kind of nitpicky anymore.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!