3 ms·

I doubt most consumers ask for a native look. It's more like an HN meme. I don't even think native macOS UI is so great cross-plat programs should target it. I

I doubt most consumers ask for a native look. It's more like an HN meme. I don't even think native macOS UI is so great cross-plat programs should target it. It's full of its own weird conventions like a "New item" button being a tiny "+" at the bottom of the left sidebar, the last place I always look. Safari is an example of UX that has stuck to hard macOS conventions and was always worse off for it. Not until recently did it begin relenting, and now it's bearable to use as a daily driver. Xcode is another classic example of hostile native macOS UX conventions. Finder.app is another. I'd rather software ask "what's the UX that makes the most sense?" rather than "how can I make my UI look native?" On HN people seem to think by solving the latter, you solve the former. But that isn't the case.

Bjartr 2y ago
> I doubt most consumers ask for a native look. It's more like an HN meme. The preference for native look was once about the impact of familiarity on usability. When 95% of people's interactions with computers was a single OS and native apps, they would expect controls to look a particular way. They could figure out other variants, sure, but from a UX design perspective, there's little reason to add that minor cognitive overhead needlessly. Today, people's experiences are less likely to be monoculture like they once were, which dilutes one of the values of native controls. That's not to say designing with familiarity of controls in mind doesn't have value, just that it's less about, for example, buttons looking like buttons native to the OS, and more about visually reading as "this is a button" more generally.
ducktective 2y ago
>I doubt most consumers ask for a native look. It's more like an HN meme. So you're ok with a mp3 player that takes 6 seconds to start up, is janky when it starts, takes 300MB of RAM, every row item is 100px high and every interaction with every UI element takes a noticeable delay on the order of 100x milliseconds? And you're gonna tolerate the same story with the file explorer app, the archive/zip app, the WiFi SSID selection dialog, etc?
- VertanaNinjai 2y ago
  What did any of your points have to with the topic of “native look”?
- Zak 2y ago
  This comment responds to the idea of native look being important with a list of performance issues. Whether software should be efficient and responsive is separate from whether it should look native to the OS it's running on.
  - Pet_Ant 2y ago
    Having a bespoke widget tool kit with themeing etc uses more memory and cycles instead of just being a simple app with the native desktop widgets.
    - klabb3 2y ago
      Even if that is true in the general case (it isn't necessarily - there are many factors), it’s a matter of what’s acceptable, not a race to 1000fps. If you build a webview based app (using eg tauri) I can assure you that it can be extremely snappy, <1% cpu while active and low memory, provided you use sensible dev practices like not import half of npm. Contrary to popular HN belief, web browsers are ridiculously optimized both in terms of rendering and JITed JS execution. The reason web based applications are often perf hogs is not because, but despite the execution environment. Businesses simply don’t prioritize perf, independent of platform. As an example, look at typical popular iOS apps: they’re often 100-500 Mb, even though they have absolutely no reason to be. LinkedIn is 400Mb, random airline app is 300Mb. Banking app? 350Mb. Is it bad to bundle Chrome and NodeJS? Yes, undoubtedly (but that’s already changing). Is that the only way to deploy web-based apps to desktop? No. Is native UI gonna fix it? Temporarily at best, while the platform’s native ecosystem is simply too small to cause that level of bloat.
    - rafaelmn 2y ago
      Unless you think native UI runs on magic - it's not that hard to outperform native rendering - you have to be way less general with a bespoke framework (up to a certain point of complexity).

Bjartr 2y ago

> I doubt most consumers ask for a native look. It's more like an HN meme. The preference for native look was once about the impact of familiarity on usability. When 95% of people's interactions with computers was a single OS and native apps, they would expect controls to look a particular way. They could figure out other variants, sure, but from a UX design perspective, there's little reason to add that minor cognitive overhead needlessly. Today, people's experiences are less likely to be monoculture like they once were, which dilutes one of the values of native controls. That's not to say designing with familiarity of controls in mind doesn't have value, just that it's less about, for example, buttons looking like buttons native to the OS, and more about visually reading as "this is a button" more generally.

ducktective 2y ago

>I doubt most consumers ask for a native look. It's more like an HN meme. So you're ok with a mp3 player that takes 6 seconds to start up, is janky when it starts, takes 300MB of RAM, every row item is 100px high and every interaction with every UI element takes a noticeable delay on the order of 100x milliseconds? And you're gonna tolerate the same story with the file explorer app, the archive/zip app, the WiFi SSID selection dialog, etc?

VertanaNinjai 2y ago
What did any of your points have to with the topic of “native look”?
Zak 2y ago
This comment responds to the idea of native look being important with a list of performance issues. Whether software should be efficient and responsive is separate from whether it should look native to the OS it's running on.
- Pet_Ant 2y ago
  Having a bespoke widget tool kit with themeing etc uses more memory and cycles instead of just being a simple app with the native desktop widgets.
  - klabb3 2y ago
    Even if that is true in the general case (it isn't necessarily - there are many factors), it’s a matter of what’s acceptable, not a race to 1000fps. If you build a webview based app (using eg tauri) I can assure you that it can be extremely snappy, <1% cpu while active and low memory, provided you use sensible dev practices like not import half of npm. Contrary to popular HN belief, web browsers are ridiculously optimized both in terms of rendering and JITed JS execution. The reason web based applications are often perf hogs is not because, but despite the execution environment. Businesses simply don’t prioritize perf, independent of platform. As an example, look at typical popular iOS apps: they’re often 100-500 Mb, even though they have absolutely no reason to be. LinkedIn is 400Mb, random airline app is 300Mb. Banking app? 350Mb. Is it bad to bundle Chrome and NodeJS? Yes, undoubtedly (but that’s already changing). Is that the only way to deploy web-based apps to desktop? No. Is native UI gonna fix it? Temporarily at best, while the platform’s native ecosystem is simply too small to cause that level of bloat.
  - rafaelmn 2y ago
    Unless you think native UI runs on magic - it's not that hard to outperform native rendering - you have to be way less general with a bespoke framework (up to a certain point of complexity).