4 ms·

The problem with modern, native-looking UI surfaces is that they are hard to design and maintain on cross-platform applications. How do you design and implemen

by Yaina 5y ago

The problem with modern, native-looking UI surfaces is that they are hard to design and maintain on cross-platform applications. How do you design and implement an interface that feels native across platforms? First there is the easy approach: The common denominator elements. Essentially what you get when creating a Java Application. The UI will probably look kind of native, but also outdated. Think Windows 89-Style Settings. You're also limited in how you can present options because you have so few form elements to play with. The other approach to native is to use modern UI elements. For one thing these are not easy to get. While on macOS Cocoa bindings are at least available, on Windows it is pretty much impossible to get anything but the Windows-89 style form elements. Even if all the bindings were available, which also has to take various Linux Desktop Environments into account, then you had to design for and maintain multiple versions of the same settings menu. So I hope this explains why non-native controls are a sensible approach. You create your own design system that is (mostly) consistent across platforms. Designers only have to design one surface, they can create new patterns if necessary and engineers only have to maintain one implementation. Of course they have to be accessible and they are. I say "mostly consistent" by the way, because Firefox still respects some UI conventions from operating systems. For example it uses system fonts, system font-scales, and changes naming conventions and button orders appropriately. This reduces work but of course it still is work to update and maintain that surface. about:preferences in Firefox has quite become quite messy over the years and is neither loved by designers nor engineers, but it's time and resource intensive to update it.

userbinator 5y ago
but also outdated Bias towards fashion trends is one of the biggest problems in the software industry.
eek2121 5y ago
hard disagree here. Let us look at Windows and macOS for a second here, and exclude Linux, because Linux (rather, Linux + your favorite DE) is realistically the issue (due to KDE, GNOME, and a gazillion other types/styles). If you design around a given language for the most recent versions of a native OS, you'll never have issues. Both macOS and Windows include common libraries that map to their respective styles. Microsoft, for example: https://docs.microsoft.com/en-us/windows/apps/design/ https://docs.microsoft.com/en-us/windows/apps/design/ (link on bottom if you want to drill down to code). "What about users that want to customize things?" Give them an alternate path. The browser loads slightly slower (the same as now), and they still get their ability to customize. The rest of us can use the default, faster path.
- prmoustache 5y ago
  > Let us look at Windows and macOS for a second here, and exclude Linux, because Linux (rather, Linux + your favorite DE) is realistically the issue [...] If you design around a given language for the most recent versions of a native OS, you'll never have issues. Both macOS and Windows include common libraries that map to their respective styles. That is a bold statement and largely not true. Most DAWs are only developed and maintained for Windows and Mac. Almost all of them are using their own set of widgets/gfx because they want control on their style and they want it to be the very same on both Windows and Mac. Their software is very specific and want their tool to look and feel like hardware, not a regular software. It is mostly about control. Linux doesn't have anything to do with that and any software maker can decide to only support GTK or QT, libwine or whatever toolkit it wants to use and stick with it. Linux users are used to run QT apps on Gnome or GTK apps on KDE, they are not the one that would complain and given the market share, the software companies are happy to give the middle fingers if they do so anyway.
friendzis 5y ago
Well, your argument is based on an assumption that chasing latest trends of micro web apps is somehow inherently THE path to strive for. Redesigning around latest trends with web frameworks getting obsolete quicker than you can realistically complete a large project is really inefficient in itself. Is it really more efficient to maintain a design framework chasing latest web trends instead of having separate native interfaces?
- Yaina 5y ago
  I didn't say anything about web frameworks or chasing latest trends. Developing a cross-platform app that uses native interface elements is extremely time intensive and sometimes laughably complicated[1]. With design system I meant that designers create a spec how the UI should look like and behave (eg. the primary button in Firefox) and then engineers implement that in a reusable way. Designers can then use their own specs to create new surfaces and engineers can use their reusable components to make the specs real. This is a lot more efficient than either maintaining three code paths for the whole UI or building and maintaining a complex abstraction framework for native surfaces. That's what XUL was. That's the reason why there are barely any UI-heavy cross-platform apps and a lot of web-apps. [1]https://den.dev/blog/windows-priority-shuffle/ https://den.dev/blog/windows-priority-shuffle/
  - friendzis 5y ago
    > With design system I meant that designers create a spec how the UI should look like and behave This is the core of misunderstanding. Once you define your goal as "the app should look the same across platforms", you inevitably set yourself up for these shenanigans. In order to keep consistent look and feel across platforms you either implement (and maintain!) a complex abstraction layer over platforms or reduce the design to "common denominator elements". Web (both remote and electron) seems to be an attractive solution, because it offers the more pleasing abstraction option and a lot of heavy lifting is handled by browser and framework developers. You base your argument on consistent look being the ultimate goal and desktops being somewhat moving targets. Well, the web is a target moving even faster and I see no reason to regard consistent look as the ultimate goal. It could be easily argued that platform native look is an even better option. Essentially, it boils down to two fuzzy metrics: fraction of users regularly moving between platforms and preferring consistent look (a windows-y app on mac will look off, webby app will look off on both platforms) and long-term cost of maintaining the consistent look versus maintaining separate fully native interfaces. Somehow I tend to believe that in the long run native interfaces are the better option. Web only makes it easier to build cross platform MVP and forces one to release features in tandem across platforms.

by Yaina 5y ago

userbinator 5y ago

but also outdated Bias towards fashion trends is one of the biggest problems in the software industry.

eek2121 5y ago

hard disagree here. Let us look at Windows and macOS for a second here, and exclude Linux, because Linux (rather, Linux + your favorite DE) is realistically the issue (due to KDE, GNOME, and a gazillion other types/styles). If you design around a given language for the most recent versions of a native OS, you'll never have issues. Both macOS and Windows include common libraries that map to their respective styles. Microsoft, for example: https://docs.microsoft.com/en-us/windows/apps/design/ https://docs.microsoft.com/en-us/windows/apps/design/ (link on bottom if you want to drill down to code). "What about users that want to customize things?" Give them an alternate path. The browser loads slightly slower (the same as now), and they still get their ability to customize. The rest of us can use the default, faster path.

prmoustache 5y ago
> Let us look at Windows and macOS for a second here, and exclude Linux, because Linux (rather, Linux + your favorite DE) is realistically the issue [...] If you design around a given language for the most recent versions of a native OS, you'll never have issues. Both macOS and Windows include common libraries that map to their respective styles. That is a bold statement and largely not true. Most DAWs are only developed and maintained for Windows and Mac. Almost all of them are using their own set of widgets/gfx because they want control on their style and they want it to be the very same on both Windows and Mac. Their software is very specific and want their tool to look and feel like hardware, not a regular software. It is mostly about control. Linux doesn't have anything to do with that and any software maker can decide to only support GTK or QT, libwine or whatever toolkit it wants to use and stick with it. Linux users are used to run QT apps on Gnome or GTK apps on KDE, they are not the one that would complain and given the market share, the software companies are happy to give the middle fingers if they do so anyway.

friendzis 5y ago

Well, your argument is based on an assumption that chasing latest trends of micro web apps is somehow inherently THE path to strive for. Redesigning around latest trends with web frameworks getting obsolete quicker than you can realistically complete a large project is really inefficient in itself. Is it really more efficient to maintain a design framework chasing latest web trends instead of having separate native interfaces?

Yaina 5y ago
I didn't say anything about web frameworks or chasing latest trends. Developing a cross-platform app that uses native interface elements is extremely time intensive and sometimes laughably complicated[1]. With design system I meant that designers create a spec how the UI should look like and behave (eg. the primary button in Firefox) and then engineers implement that in a reusable way. Designers can then use their own specs to create new surfaces and engineers can use their reusable components to make the specs real. This is a lot more efficient than either maintaining three code paths for the whole UI or building and maintaining a complex abstraction framework for native surfaces. That's what XUL was. That's the reason why there are barely any UI-heavy cross-platform apps and a lot of web-apps. [1]https://den.dev/blog/windows-priority-shuffle/ https://den.dev/blog/windows-priority-shuffle/
- friendzis 5y ago
  > With design system I meant that designers create a spec how the UI should look like and behave This is the core of misunderstanding. Once you define your goal as "the app should look the same across platforms", you inevitably set yourself up for these shenanigans. In order to keep consistent look and feel across platforms you either implement (and maintain!) a complex abstraction layer over platforms or reduce the design to "common denominator elements". Web (both remote and electron) seems to be an attractive solution, because it offers the more pleasing abstraction option and a lot of heavy lifting is handled by browser and framework developers. You base your argument on consistent look being the ultimate goal and desktops being somewhat moving targets. Well, the web is a target moving even faster and I see no reason to regard consistent look as the ultimate goal. It could be easily argued that platform native look is an even better option. Essentially, it boils down to two fuzzy metrics: fraction of users regularly moving between platforms and preferring consistent look (a windows-y app on mac will look off, webby app will look off on both platforms) and long-term cost of maintaining the consistent look versus maintaining separate fully native interfaces. Somehow I tend to believe that in the long run native interfaces are the better option. Web only makes it easier to build cross platform MVP and forces one to release features in tandem across platforms.