> Revery is the same - aside from platform-specific behavior, if your app looks or behaves differently on another platform, that's a bug!
I want my applications to feel like they belong to the platform and not identical on every platform
I want my applications to feel like they belong to the platform and not identical on every platform
After all the whole webapp-everything somewhat shows that people don't care that much, they are happy to use GMail for example. Another family of examples would be the big software packages like the Adobe or Autodesk stuff, they tend to have a fairly custom look&feel.
IMO it's probably sufficient for the thing to look "modern" (ie up to date wrt to UI fashion trends). Then you get the huge upside of easier maintenance and less bugs.
I disagree; the benefit isn't overrated, it's underrated because it's not realized, thanks to most apps doing their best to _not_ fit in the platform. What full platform fit enables is consistent UX and interoperability. Lack of the latter places an actual cap of what users can do (except for the small percent that can force an app to interoperate, whether it likes it or not).
In my not so humble opinion, the current UX trends are based on circular reasoning - users don't demand functionality, interoperability and ergonomic design because those are rarely given to them, so they don't know they could have it. And since they're not demanding, this is used as a justification to not give it.
> After all the whole webapp-everything somewhat shows that people don't care that much, they are happy to use GMail for example.
It doesn't show that. It's just that people don't have much choice anyway. Crappy and bloated GMail UI vs. Thunderbird that requires a little bit of knowledge to set up. That's the choice.
Most software, including webpages, isn't substitute goods. Fastmail isn't a substitute to GMail once you have an account. LibreOffice isn't a substitute for Google Docs, not once someone shares a document with you through Google's cloud. Network effects are powerful, and they reinforce the basic way normal people treat software - as magic, "gift from gods", something that works the way it works because that's how it works.
I'm just pointing this out, because I hate the constant use of "the market decided" and "users voted with their wallets/eyeballs" as justification for bad engineering. It's mostly circular reasoning.
> Another family of examples would be the big software packages like the Adobe or Autodesk stuff, they tend to have a fairly custom look&feel.
Those are somewhat special cases, because they need so much functionality packed in the UI that they replace platform's conventions with ones better suited to the problem.
(Sometimes it leads to weird stuff, like Photoshop and its dialog boxes, in which buttons change meaning when you hold down CTRL.)
At first I did agree. But then my second thought was: this calls into question some very significant and very experienced brands. To think that many, that big, are doing it wrong naturally doesn't feel right.
Businesses don't innately care about doing what's right, so optimizing for brand differentiation over a unified platform experience is what one would expect to happen in most cases.
We’re in a world where there are a large number of platforms asking for support, and I just don’t have time for that. If I’m able to support a single app for all, that’s a major win.
- Does it receive proper keyboard focus?
- Does it respond to keyboard input?
- Does it adhere to the OS color theme?
- Does it break OS accessibility features (high contrast/voice over/invert colors/grayscale/font sizes/etc. etc.)?
- Does it respect scaling and resolutions?
- Is font rendering consistent with the rest of the system?
- Are keyboard shortcuts consistent with the rest of the system? Including input fields? Including window/app?
- Does it break the principle of least astonishment? I.e. does it look and behave as other platform-native apps or not?
- Does it handle multi-monitor and multiple resolutions?
- Does it integrate with OS menus/trays/notification centers/what not?
- Does it use and respect the OS clipboard?
- Does it respect left-to-right and right-to-left settings and writing modes?
- Does it integrate with OS services such as system-wide autocorrect? Screen keyboard? Symbols palette/picker?
- Does it respect OS locale settings for dates, times, week numbers and week days?
- Does it follow the OS' HIG and its alternatives?
- Does it integrate with the OS energy management systems?
- Does it integrate with OS-native file dialogs, storage permissions and requirements?
the list just goes on
Electron apps often enjoy many of the things in the list for free because it's essentially a browser window disguising itself as an app. And browsers get a lot of stuff "for free" from the OS (not without issues, of course).
[1] https://en.wikipedia.org/wiki/Human_interface_guidelines
It is absolutely ridiculous that, in 1995, I could completely change the font sizes and color scheme of my UI radically and it would work with the vast majority of applications, but in 2019 I have to wait for a developer to decide to add a theme or provide some kind of customization facility unique to their software.
Nowadays, we expect the same services to work on our laptop, our work computer, our personal iPhone, our work Android, our smart TV... the importance of parity between versions is much higher.
In case people don't believe this, there was an update for Office THIS WEEK for Outlook to support Dark Mode on OSX Mojave.
To me, dark mode is the prime example of the flimsiness of relying on native GUI solutions...for years Apple ignored users and apps that wanted dark guis, despite the fact that dark mode is legitimately a lot better for a lot of people
We could tune up our own universally applied dark mode in 95 quite simply, but now each application has to implement that itself.
You don't get that from your typical web app in an Electron shell.
But also, take a look at VSCode, and Atom and notice how much of those applications are actually rebuilt skins from the ground up. Even the exit buttons in the Windows version are rebuilt from scratch, not using the platform "components".
The number of times I've ever heard anyone complain that VSCode reimplements clickable regions that look exactly the same on all platforms instead of using some ugly stock Windows buttons: zero.
The number of times I've been annoyed that Electron apps break some semi-obscure but nevertheless important macOS feature: quite high, and it would be much higher if I hadn't sworn off Electron apps long ago.
There are so many small details, like proxy icons and commonly accepted shortcuts for particular actions. These are things you either get for free or nearly so when writing native apps using the system frameworks, or they are things that people trying to make a consistent app across multiple platforms miss.
As a user, the consistency isn’t really a feature for me. I don’t use windows or Linux on the desktop regularly, so having my editor/chat client/etc behave the same on all three isn’t useful.
Leaving aside the visual aspects (which are important for at least some users), this is what actually matters the most. Breaking keyboard shortcuts or having weird replacements for them is a big no-no for Electon based apps.
All menus lack basic/expected items, both in the menu bar to contextual menus (if they exist).
No standard find and replace. Missing options for pattern matching, diacriticals, case sensitivity, weird UI, etc. if this is included at all.
Low-accessibility, not even basic text to speech support for visual impairments.
Drag and drop support being poor and lacking, both for capturing data and importing data. Despite electron apps being glorified webpages, even selecting content is inhibited in most places.
Odd spacing of controls that is either too much or too little. Everything looks off and stands out in a bad way, like no one cares.
Electron apps are a total UI and UX mess and are worst-class citizens on macOS. If your idea of cross-platform makes a dev add platform specific BASICS, devs will simply not add them, assuming they know or care about them at all.
When I see an Electron app I think “this is an ass app from an ass dev” and throw most of them in the trash.
Probably because the people who do care don't use electron apps.
I agree 100% that it isn't always the proper trade-off, though - there's another ReasonML project called Brisk [1] that is similar in spirit to Revery, but with platform widgets.
In fact, we're working together on several infrastructure pieces (the core 'reconciler' - the native React-like piece - is actually developed by the Brisk team). So if you're interested in ReasonML + native app development - that might be one to follow!
We see the potential too for some exciting hybrid approaches - perhaps you prototype a cross-platform app in Revery, but then switch to Brisk for platform-specific projects, etc. Or even embed Revery in Brisk.
But...
For me that means it's not really "native". Native as in CPU native is just to say it's reasonably fast and efficient. It's nice, but I'm looking for platform native.
When your application is native in the first sense, you are competing with almost everyone. Games, even applications written with SDL are native in this sense. And almost every cross-perform widget toolkit out there - Qt, GTK+, FLTK, Fox Toolkit, IUP, Juce...
I think that then you also need to state if you handle accessibility. If you don't handle it _yet_ you better have a plan to do so. With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out.
Now I'm wondering is there a toolkit that started as a crossplatform accessibility library and then gained rendering capabilities? I think accessibility is harder, so when it's bolted on later it's even harder.
You might be thinking of wxWidgets.
I'd like to see accessibility baked-in because that would be my preferred path to a fully-addressable/programmable UI, and UI-QA-as-code. The way we QA UI's today is way too hack'ish. I want to be able to write unit tests for the UI within the development flow of writing the UI itself, not in some external, bolted-on fashion. Part of what seems missing is I can call the UI to perform some action on my behalf, but querying the compositor upon the final results sitting on the display output seems to be haphazardly available; I can query for some elements, but not all, or I can query for pixels but not what UI element those pixels belong to.
I'm the exact opposite. I could care less about the underlying platform... I want my apps to behave exactly the same everywhere.
For applications that are mostly for that OS, I would prefer they adhere to the tenets of design for that OS.
This is less a matter of wanting it to feel a certain way and more a matter wanting familiarity and utility out of the applications I'm most likely to experience on different operating systems when I'm on them. Function is much more important than form for me in this case.
I know, for instance, that I'm likely the only person on Hacker News that actually likes the Slack Desktop application, and I'm glad it works very similarly on both my Mac and PC.
Then use the wxWidgets library. It has bindings for many languages, so it probably has bindings for yours.
But more recent applications like SublimeText try a unified look in all platforms, and as long as it is fast enough and crash free, I am OK with that.
* The wrong keyboard shortcut for redo (Cmd-Y instead of Option-Cmd-Z) * Mixing native tabs and it’s own implementation
The very few 'desktop' apps I use today don't really implement platform UI behaviour, rather, the apps seem fairly consistent across platforms.
Adobe products, Android Studio, Ableton, VS Code, Atlassian products - they seem more similar to me than otherwise across platforms.
Mobile platforms I think are quite different in this regard, whereupon they have considerably more 'specific' features.
But on the desktop - I think as long as the common keyboard binding/shortcuts are respected ... then this is ok.
Yeah, Electron already does that. I can hardly say I am looking for more of it.
Electron apps don't look like they belong on the platform.
And to be clear, what we're talking about is more options for folks that want to ship to all platforms and focus on perfecting one UI.
Is it better than doing a truly native app on each platform? Of course not, but that's outside the realm of possibility for the resources most developers have
As does everybody sane except every product manager in existence.