(Enough said.)
I've moved to Emacs, TUI, and CLI tools to escape the madness, not because they'r e better, but they let you do stuff and are at least stable so you don't have to alter your workflow every quarter.
Also IRC looks and works like ass. As a teenager I used it without putting in the time to getting used to it, and it was really really impenetrable.
The problem is when we are getting inconsistent themes with wildly varying contrast levels shoved down our throats, in what is supposed to be productivity applications.
(They grouped against the first paragraph of his section instead of the fill the section)
I think the lesson here is people have different desires and priorities, and that’s ok.
(This also illustrates the fallacy with the sibling comment blandly asserting that scrollbars should 'simply be hidden when not necessary'.)
Case in point: I tried to install ChromeOS Flex on one of my laptops. After booting from the USB drive, the installer went through a series of screens. On the 3rd or 4th screen, it would hang and make no progress. I rebooted and re-installed. Same thing. Tried a third time. Same thing.
On the 4th try, I accidentally discovered that the dialog box had an invisible scrollbar. WTF. If I two-finger scrolled on the dialog box after moving the mouse pointer into it, it would reveal some additional text on the bottom which indicated that it was not hanging but doing some work.
After I had finished installing ChromeOS, I discovered ChromeOS has a Settings option to "always display scrollbar", but the Chrome browser completely ignores that flag. Awesome. I blew away ChromeOS Flex on my laptop.
I'm 38 and have used computers since I was 5.
But at least I got more whitespace on my screen now...
Letting you go from a song you like to its respective album (or really, doing any navigation other than “start/pause this algorithmic playlist”) is counterproductive to that goal and so needs to be disallowed, or at least made as difficult as it can be.
Same as on/off controls, they should have clear external labels, e.g.:
Off |X | On
This is a generic problem in Blender. You can't do something because you're in the wrong state, but nothing tells you that you're in the wrong state.
GNU GIMP has always been much worse than Photoshop in this way. When inserting text, the text is in a default size. If you change the size, and then click on a new insert point, it goes back to the default size. Whether or not the last change has been committed is not obvious, and until it has been committed, many menus and icons do nothing, silently. Selection vs. layers vs. commits are very confusing. Just keeping the dockable menus visible is tough.
My recollection is that MsWord is particularly bad at this, but since I no longer have it installed (one reason is exactly this!), I can't show it.
But I do have Ms's Visual Studio Code on-screen. There is (thankfully) a real menu, with File, Edit, View and Help (the latter no longer exists on most Microsoft products). I happen to have a terminal open; it has six mostly indecipherable icons across the top of its pane. All the panes--the terminal, the file edit panes, and the "bar" at the right-hand side, have a '...', which seems to be the equivalent of a hamburger menu for that pane. Finally, the status bar down at the bottom of the window has still more indecipherable icons near the left end, and a few info things near the right end, some of which are controls ("Select Interpreter", inexplicably highlighted in brown with yet another icon), and some of which appear to be just info (line and column)--except these at the bottom of the window turn out to pull down a special menu item at the top of the window. For example, the control labeled "Ln and Col" (the latter means the character within the line, not the column in a tab-delimited file) pulls down a menu item that allows you to go to a particular line (but not a particular "column").
However, I just noticed one big UI flaw in this interface. The keyboard shortcuts for finding the next and previous occurrences of the search phrase (enter and shift-enter respectively) are not easily discoverable. They ought to be mentioned in the tooltips for those buttons.
EDIT: And another problem: the next and previous buttons aren't even correctly marked as buttons. It's worse than the "flat" buttons used elsewhere, it's "stealth flat" buttons that only appear when you mouse over them.
I think that the Mac, possibly even the Lisa had that before the CUA. https://andymatuschak.org/files/papers/Apple%20Human%20Inter..., page 23: “A dialog box appears whenever the user chooses a menu item that is followed, in the menus itself, by an ellipsis (…)”
https://news.ycombinator.com/item?id=44043157
TL;DR: I use gnome only indirectly. In the past I've cut them slack, because (I thought) they were designing for touchscreens etc. Turns out they indeed destroyed the usability of their desktop but somehow forgot to make it work for touchscreens.
I have a starlite linux tablet where no gnome video player works acceptably, and I've tried around five. More than one looks like it is made for touch, big round corners/buttons, etc, but requires a keyboard for all but trivial functions... like rewind 15 seconds. WTF, can't tap?
Freetube, Netflix, and Kanopy work fine from a browser, so the problem sure as hell ain't the hardware. Defeat snatched from the jaws of victory.
it's a bankers box (a cardboard box for files) which I guess is not a thing one sees often now? skeuomorphism doesn't work on a digital generation because all the real world touchpoints for information have been replaced by digital
A labeled archive box. https://kagi.com/images?q=archive+box
This raises the question of the universality of icons. They are contextual to territory and time. Until recently, a diskette was the universal icon for saving. Yet nobody under thirty today has probably ever seen one.
- Having keyboard commands is helpful.
- Good documentation is very helpful; a program is understandable if it is documented.
- Some of the difficulty seems to be due to the programming environments and libraries that are used for making these programs; due to badly designed UI libraries and programming environments, the result will also be bad. However, this is not the only thing that can cause these problems.
- On a computer it should also be helpful that the operator is able to make other external programs and can interact with them too, with your software. Command-line programs, user configuration settings, API, etc, can also be helpful in doing this.
Not just having keyboard commands, but using standard ways to make them discoverable, such as by tooltips, menu item annotations, and underlined characters in labels.
Another aspect in today’s UIs is that they often introduce latency in operations (due to network communication, among other things) while not buffering keystrokes accordingly, which makes it borderline impossible to press memorized sequences of keyboard shortcuts in quick succession, because you always have to double-check that the application is in the right state to receive the next keyboard shortcut. That goes against developing muscle memory for frequently performed operations, and forces a conscious back and forth and constant ascertaining that the command was correctly received by the application, instead of being able to blindly trust it and thereby reduce cognitive overhead.
tsunamifury•4h ago
But to the authors point about power tools usability likely the core issue is new customers need an easier entry point into a power tool than existing customers. This results in simplified designs.
If they don’t do that cruft design builds up over time and you end up in a different usability trap like adobe products in the mid 2000s
mcswell•2h ago