7 ms·
Computers can be really frustrating to use, the biggest offender in my opinion is hidden state. So many programs don't mention something has changed, and so if
by ehnto 6y ago
Computers can be really frustrating to use, the biggest offender in my opinion is hidden state. So many programs don't mention something has changed, and so if you fumble a click or a shortcut you can end up in a program state you didn't want to be in and may not even realise it until something goes wrong.
You wouldn't accidentally hit a switch on your car and now you can only go left, with no indication on why that is, and no transitional information given during the switch. Yet programs and websites will happily modify the state without so much as a brief text flash asaying "Oh hey, you're in Paint Only Mode now" for example.
My absolute favorite way to deal with this is small status indicators in some kind of toolbar, that when I hover over it, it gives me a tooltip on what it is and how to toggle it.
Accidentally hit debug mode? No worries, a little debug symbol just flashed briefly, I can go look for it in the toolbar and hover over it to figure it out.
- oblio 6y ago> Computers can be really frustrating to use, the biggest offender in my opinion is hidden state. So many programs don't mention something has changed, and so if you fumble a click or a shortcut you can end up in a program state you didn't want to be in and may not even realise it until something goes wrong. There is a high degree of irony to this when you think about the extremely popular Unix philosophy, which is kind of the antithesis to what you're saying. I know that it's meant for power users, but even for those in many cases it's still bad UX.
- TeMPOraL 6y agoIsn't Unix philosophy the one about small, focused tools that compose well? It fits the GP's view, since the composition is meant to be user-driven, explicit and visible. (Also composability usually implies lack of hidden state - in Unix-land, state issue may just come from the baggage of C language.)
- oblio 6y agoYeah, but all those tools by default don't print anything if they run successfully, which is indistinguishable from silent failure. If you look at all modern tools, this approach has been abandoned, especially for long running operations, since it's obviously bad UX.
- TeMPOraL 6y agoRight. That I agree with.
- marcosdumay 6y ago> which is indistinguishable from silent failure What is why the same tools do not have silent failures. And OS failures aren't silent. > If you look at all modern tools, this approach has been abandoned Gladly, you are wrong. Modern tools have indeed add optional noisy modes, nearly all opt-in.
- oblio 6y ago> What is why the same tools do not have silent failures. And OS failures aren't silent. Thankfully, there are no bugs in our software :-) > Gladly, you are wrong. Modern tools have indeed add optional noisy modes, nearly all opt-in. Almost everything network facing (which is almost everything, these days), is verbose by default. Git, curl, etc.
- marcosdumay 6y ago> Thankfully, there are no bugs in our software :-) Yep. Bugs are why OS failures are not silent. But you've got a point. Network facing software need some progress confirmation.
- GuB-42 6y agoYou mean like grep not returning anything when it searched for something and didn't find it? It is more about a lack of feedback than a hidden state. It is a problem but not the same one. Talking about Unix tools, the hidden state would be more like environment variables like the PATH or locale.
- marcosdumay 6y agoYou mean the "silence is golden" rule? If so, that's completely different. It just states that after the user change something and the thing actually changes the way the user expects it to do, you should not interrupt the UI flow. It has no realtion at all with hidden state. State on a classical Unix system is pretty much entirely explicit.