Does a "one size fits all" UI really fit anyone?

[Splitwirez]

Hi all,

I've observed that many apps which are available on multiple platforms use the exact same user interface on all of those platforms. I'm not sure this is really such a great idea. After all, native Windows programs tend to behave differently from the equivalent native macOS programs, and both of these behave differently from say, the KDE Linux programs, or their GNOME counterparts, or whatever else may exist in the Linux world.

I've heard some debate between those who advocate for a GUI Framework that acts as a wrapper for the underlying platform's "native" GUI system, and those who advocate for a GUI Framework which implements its functionality itself, doing so uniformly across all platforms it supports. Avalonia presently falls quite firmly into the latter camp...but I'm far from convinced that the question is so...binary.

Currently, most software does one of the following (listed in order of amount of work needed):

1. One GUI for all platforms (less maintenance, but worse UX)
2. One GUI for all desktop platforms and one GUI for all mobile platforms (2x maintenance for option 1, for marginally better UX)
3. Separately-implemented but more or less identically-designed GUIs for each platform (UX as bad as option 1 (or at least almost as bad), for as much maintenance as option 4 (or at least almost that much maintenance))
4. Completely separate GUIs for each platform (best UX, but also tons of maintenance)

I think it might well be possible to create a new option, which would be effectively the inverse of option 3. This could work as follows:
5. One GUI implementation for all platforms, which has specializations for each individual platform (UX potentially as good as option 4 (or at least close), for not a whole lot more maintenance work than option 1)

And, more importantly, I think Avalonia could be the GUI Framework to pioneer this new approach.

For some time now, I've been working on a library called Mechanism for Avalonia, which aims to provide controls and other tools to aid in this pursuit. One of the features of this library which I am most proud of - and which is most notable here - is PerPlatformUI, a handful of attached properties which can be used to show or hide certain user interface elements purely in XAML. This could be a starting point...but Mechanism only addresses the development half of this undertaking, and the fact that it is an external library limits its ability to do even that.

You see...in order to implement a user interface, that user interface must first be designed (or at bare minimum, it should be designed). Most developers - and likely some designers as well - don't necessarily have years of experience using 5 different operating systems (Windows, macOS, Linux, iOS, and Android), and thus they may not have a strong understanding of what users of each expect from the apps they run. Thus, it's not hard to see why this design stage often yields "one-size-fits-all" solutions. If Avalonia is to strive to solve this "one-size-fits-all" problem, it would be best if Avalonia (or rather, Avalonia's documentation, I suppose) provided not only the developer tools needed to implement platform-specialized cross-platform GUIs, but also the information designers need in order to devise how these GUIs should be built.

If it is true that Avalonia 0.11 will likely bring with it proper support for mobile platforms, then I'd argue that 0.11 is as good a time as any to bring in this kind of functionality and resources. As-is, for a designer or developer who values providing a good experience for each individual platform, Avalonia gaining mobile support may not be that big of a deal. That doesn't have to be the case. I believe that providing the tools to both design and implement one GUI that is specialized to meet the needs and expectations of each platform it runs on, could be quite the "killer feature", and the time is right for its introduction.

---------- End semi-coherent rambling ----------

So, what do you folks think?

[pr8x]

I think some of that could be implemented via Control themes (#2769). There could be a dedicated theme for every platform that can be used to fine-tune the appearance of controls. Might also consider some CSS-like media queries to build more responsive design for various screen sizes/orientations.

[Splitwirez]

I like these ideas.

Though as for platform-specific themes...that could go one of several ways. I'd argue that having a "decorator" control to draw the appearance of, for example, an msstyles visual style part on Windows, a...Cocoa(?) control appearance on macOS, or I guess a GTK element appearance on Linux would be vastly preferable to creating a theme that looks virtually identical to, for example, Windows 10's default theme, macOS Big Sur's default appearance, and...well, Linux is the prime example of why I think mimicry isn't a particularly good idea - there is no "default Linux theme", nor anything that could reasonably be treated as such.