Can we, as an industry, please stop pointing to some strawman "majority of users" to justify our poor decisions? I'm kind of sick of everything sucking too, but can we at least admit that they suck because of us?
I know what you're saying, but I think there's something here that isn't just BS or an admission of defeat.
What if the way most people use their computers/devices now, sticking to a standard "OS native" design language simply doesn't benefit them.
Then if it takes you more time/money to do so, that is time/money spent without actually helping anyone, when you could have been working on something that did. I'm not even talking about "helping your startup succeed", I mean literally, helping the users.
Design matters, I'm a big believer in that. But you've got to design for your actual users in the actual world they are in, designing for the world you wish you had with the users behaving how you wished they behave... is the programmer's fallacy.
I think it's a legitimate question, does an app "behaving native" (as far as UI/UX elements and the OS design patterns) actually help the users? Or do we just imagine/wish it would? Does it actually matter? Does it actually benefit real people users in the actual world?
Maybe. I'm not sure it doesn't. But I'm suspicious enough to ask.
> I think it's a legitimate question, does an app "behaving native" (as far as UI/UX elements and the OS design patterns) actually help the users?
Hmm... does an application behaving according to the UX language of the rest of the system actually benefit the people using that system? Let me think about that.
Nothing about the current trends in UI design are about a better experience for the user. Nothing. Ask anyone who relies on accessibility features, for instance. I'm sure we all love hijacked scrolling, pop-in content, pop-up boxes, etc. which is why they're there right?
No, as usual users are just resigned to putting up with the bullshit that crappy developers deliver to them, and it is getting easier over time as they forget that things used to be better.
You're not designing for users, you're designing for money, so at least take responsibility for making shit suck so you can put food on the table.
An article written by a blind programmer[1] was posted on HN a while ago, and he said he uses Notepad++ because it's a native applications and plays nice with screen reader.
Notepad++ may be "native" in some sense but it certainly does not "behave according to the UX language of the rest of the system". It uses tabs rather than multiple windows, its icons are not the standard windows ones for new/open/..., and its menu bar, file selection dialogue and so on all look slightly "off".
> does an application behaving according to the UX language of the rest of the system actually benefit the people using that system?
The answer is of course, no. Unless your target audience is already technically-minded people, most users will struggle the same and simply do not internalize the "UX language of a system", only noticing when the departures are huge.
Examples of such departures that can actually make a noticeable dent on the average users' productivity with software are:
- the move from classic menu -> ribbon menu
- single desktop -> multiple desktop
- stacked windows -> tiling by default
Examples of changes that do not affect anyone's productivity but annoy UI purists:
- Input doesn't glow the same way native input does when selected
- OK and cancel swapped places or are aligned to the other side (I'll grant you the importance of swapped buttons if they pretend to look native)
- The menus are behind the titlebar instead of using the global menu
- Using a custom set of icons for standard behavior
- Hierarchy of background colors is not respected
- It's using the horrible Qt file picker again
All of this is coming from an UI purist that has seen how cross-platform development looks like. Having a good language design that is good enough for all targets requires work to come up to but is well-treaded ground (and there are many already out there you can just copy). Alternatively, having 3 codebases for the same app multiplies the cost of frontend development by anywhere from 1.5x to 3x depending on the feature and architecture and that is simply absurd for the overhwelming majority of applications given all options.
