UI standardization is critical if you want users with different physical, sensory, and mental capabilities to be able to use your app. Your beautiful whiz-bang UI just confuses screen readers, makes navigation for people with motor disabilities impossible, and confuses users who have cognitive issues.
Even that but I’m profoundly annoyed by the breaking of an expected pattern. Generally humans are pattern-matchers, so I should not be alone with this.
Certainly some software, say accounting or spreadsheets or video editors, can be made more efficient by riffing off the expectations, but if these types of apps break the basest of menu structures, they’re a turnoff.
I don’t think screen readers should be stuck poorly-simulating already-bad visual UIs. Instead, audio-based UIs should actually be tuned to audio modalities. (Of course, this requires people to actually care – and caring is the core problem with all UI design issues, not just accessibility.)
Learning to use a standard UI in an awkward way to solve a common problem it’s ill-suited for isn’t easier than learning to use a non-standard UI in a natural way to solve a common problem it’s well-suited for. That’s sort of the point. Only power-users are familiar enough with “standard UIs” to be able to generalize about them between applications enough to benefit from their standardization when they’re a poor fit – everybody else is re-learning the process from scratch for every use case.
A good non-standard UI is not “beautiful” or “whiz-bang” necessarily. It’s an accurate mapping of the user’s model of their problem. This means it won’t look “minimalist” the way Apple products do, nor will it contain unnecessary elements or visual cruft the way the rococo UIs of the 90s often did.
(Ideally, we’d have one UI per user. The only way to make this feasible is to make it straightforward for users to build or heavily customize it in an incremental way – in other words, to apply the flexibility that command line systems have had for 50 years to GUIs.)
Couldn’t read this due to the medium registration wall.
Please consider hosting your own blog…I’m sure folks here would be happy to help you with basic installation instructions for say Octopress or something.
I’ve rehosted it on gopher, for people who can’t view medium: gopher://fuckup.solutions/0enkiv2/medium-backup/2018-04-01_Against-UI-standardization-791b8bbc4fbe.txt
UI standardization is critical if you want users with different physical, sensory, and mental capabilities to be able to use your app. Your beautiful whiz-bang UI just confuses screen readers, makes navigation for people with motor disabilities impossible, and confuses users who have cognitive issues.
Even that but I’m profoundly annoyed by the breaking of an expected pattern. Generally humans are pattern-matchers, so I should not be alone with this.
Certainly some software, say accounting or spreadsheets or video editors, can be made more efficient by riffing off the expectations, but if these types of apps break the basest of menu structures, they’re a turnoff.
I don’t think screen readers should be stuck poorly-simulating already-bad visual UIs. Instead, audio-based UIs should actually be tuned to audio modalities. (Of course, this requires people to actually care – and caring is the core problem with all UI design issues, not just accessibility.)
Learning to use a standard UI in an awkward way to solve a common problem it’s ill-suited for isn’t easier than learning to use a non-standard UI in a natural way to solve a common problem it’s well-suited for. That’s sort of the point. Only power-users are familiar enough with “standard UIs” to be able to generalize about them between applications enough to benefit from their standardization when they’re a poor fit – everybody else is re-learning the process from scratch for every use case.
A good non-standard UI is not “beautiful” or “whiz-bang” necessarily. It’s an accurate mapping of the user’s model of their problem. This means it won’t look “minimalist” the way Apple products do, nor will it contain unnecessary elements or visual cruft the way the rococo UIs of the 90s often did.
(Ideally, we’d have one UI per user. The only way to make this feasible is to make it straightforward for users to build or heavily customize it in an incremental way – in other words, to apply the flexibility that command line systems have had for 50 years to GUIs.)
Couldn’t read this due to the medium registration wall.
Please consider hosting your own blog…I’m sure folks here would be happy to help you with basic installation instructions for say Octopress or something.
I’ve rehosted it on gopher, for people who can’t view medium: gopher://fuckup.solutions/0enkiv2/medium-backup/2018-04-01_Against-UI-standardization-791b8bbc4fbe.txt
An unexpected development, but welcome nonetheless.
I figure, if we’re going to distribute plain text, we might as well go whole-hog & remove the overhead of HTTP, HTML parsing, and CMS.
For those too lazy to install a “real” client, curl is happy fetching gopher.
Or if you already have lynx installed, that will do as well.
Or netcat, for that matter.
can’t you just disable javascript & cookies. Not saying you should have to…