The problem I see with many electron applications isn't just that they're bloated (they probably are in about the same relation to average RAM that Tcl/Tk apps were or early Gnome/Mono ones). [Edit: To clarify, I mean the average RAM at the time they were accused of bloat]
It's that they're quite non-native. And not just in the "button borders are 1 pixel wider than usual" sense -- they're usually styled to resemble web applications, with big data views, Material UI, etc.
Going from this to something more lightweight/native doesn't just require a different API, it requires a completely redesign.
In other words: The Big Rewrite That We're Definitely Going To Do Someday(tm).
I agree with this too but this problem can be addressed by caring. I care. You can find a bunch of non-native interactions in my app but every time I work on it I make it better and implement more of a native feel (like disabling selecting text when you shouldn't be able to, etc).
It's a balance - personally I think apps that focus on a specific platform is exclusionary. So accepting some non-native feel means more people can use my app.
> like disabling selecting text when you shouldn't be able to
This is the worst thing in computers. Why would you EVER _block_ the ability to select text? I am engaged enough to want to select something you made! Embrace that, don't stop it!
Think of all the thousands of tiny snippets of text and single Unicode characters that make up a UI. You definitely don't want to be able to select snippets within most controls, because selection interferes with using the control.
Examples: the text in a menu item, the text in a button, the Unicode x in a close icon, the bar between menus.
This is really noticeable in a few web applications where you can select the wrong thing and it interferes severely with using the UI (I have experienced this with Windows and Android).
Yes, you usually want to be able to select the main text. However many mobile UI frameworks just disable all selection, because that is the easiest way to also disable selection within UI controls (managing this issue is actually quite difficult from my experience writing a HTML UI framework).
So long as you don't want an OS native UI, yes I think so.
For example I use Visual Studio Code every day and the UI seems pretty good to me (panels, menus, tabs, check boxes, combos etc). I am presuming it uses a component framework (although I admit I haven't looked at the source).
I got one. Because my electron app is a game. I don't want you interacting with text as text, it's supposed to be more of a "texture" like one would expect from a native DirectX implementation
To simultaneously answer many of the "usually you don't want X to be selected":
So don't always allow selecting everything. If you start your selection inside "content", constrain to content, don't select labels. If you start on a label, select labels and maybe content too.
Native apps do this all the time in small degrees, people are used to it: "select all" selects content, not chrome, and it's context-sensitive in many cases (e.g. select all in a folder doesn't select parent folders even if they're visible).
having encountered some buttons with significant amounts of text: nothing is off-limits IMO. frequently tho, yea, "ok" isn't useful to allow to be selected.
On the other hand, getting people to copy what they see rather than read it out loud incorrectly can, pretty often, cut several rounds of back-and-forth out of remote tech support. It seems insane because it is, but yes - copying text in a button rather than having them say "I clicked the yes button" (when no such button exists) is a useful feature.
On the other hand I hate apps that have user interface elements where you can select the text by accident instead of interacting with the element that contains the text.
Imagine what it would be like if a click and drag on a window title bar moved the window but a click and drag on the text part of the title bar just selected text.
Back in the Amiga days there was a nice little app that let you go into selection mode and then draw a rect around anything and it would pseudo-ocr it. Surely something like that exists on current machines, but I havn't seen it.
I know what you’re saying. Our company settled on a well known cloud app for ERP/CRM and daily I deal with copying and pasting something from it that invariably brings along extra text/ui elements that I didn’t want. Sometimes it’s just extraneous space, sometimes it’s extra text I don’t even realize was highlighted.
Another example are tables that have selection boxes for records or “action” links in each row like print or view. If I could select this table without those columns coming along for the copy ride I’d cut at least one if not a few steps out for every time I copy/paste something.
I'd argue that despite all cries about non-native styling and behavior, MacOS Classic, OS X, Windows 95, OS/2, Next, Swing etc. had more in common with each other than they do with webapps (unless we're talking about ExtJS enterprise apps or the like).
This won't matter as much for rich-text chat apps or the like, which always looked horribly non-native, over-styled, skeuomorphic (cf. Trillian)…
But let's picture a database client or IDE. Those used to resemble regular desktop apps. Nowadays?
Note that I'm not arguing about your article or even approach, I was just chiming in on the dislike for Electron in general, where I think bloat is the least of our worries. All this wasn't something new, the downturn of desktop UIs started way before, as people are now used to mobile and webapps and expect that kind of look and feel everywhere. The OS manufacturers definitely seem to approve and comply.
You saw this happening in other places, before. Just look at enterprise Windows applications that were targeted to people used to terminal UIs (3270, VT220).
Current UI trends are the same, just with spurious rounded corners instead of closely-grouped form elements…
Yes, major desktop GUIs 20 yrs ago had more in common with each other than they have with web apps. They also had more in common with each other than with iOS and Android phones. Yet today, most people in the more-developed economies use desktop apps, web apps on desktop, phone apps and web apps on phone every day. Some even have GUI apps in their cars and on their wrists. And among the new desktop apps, they have apps that work with touch UI or keyboard and/or mouse, that are available on multiple platforms with significant UI differences, and that have mobile versions.
The result for most users is that they use a whole medley of different UIs daily and are far more flexible about UIs than back in the day when you were either a Mac person or a Windows person exclusively and all of your apps were native apps on your one machine. As clients continue to diversify, as Web apps spread, as companies like Apple keep bumping the Mac UI to lower and lower priority and claim Mac (which mustn't have touch)/iPod/iPhone/AppleWatch all need different UIs and all must have some sort of web support, and Google, Facebook, Twitter, and Amazon apps in their wide and ever-changing variety are used more and more...the demand for consistent UI in the fine details is not nearly as big an issue for most people as it used to be.
Also, as a user, I expect the UI of my apps to be somewhat inconsistent. If the app is perfectly consistent with the native guidelines, then that's a small plus. But any slightly inconsistent behavior can be quickly learned, and I don't consider it a big deal (again, as a user).
Of course, if every app out there was perfectly consistent, then perhaps it would be a different story.
I think it's quite possible that the majority of users are the moment have no idea how to recognize "native UI" and won't know the difference either way.
I do believe that a well-designed UI makes a difference, whether users realize it consciously or not.
I am not sure whether how much an app stick to OS "native" idioms is actually significant for a well-designed UI in 2019; I think users don't spend enough time off the web to be used to those idioms anyway.
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.
Which is why "design" is mostly visual and user interaction is at its poorest since the inception of the WIMP interface, never mind how many friggin' "UX" experts we got now strutting around.
Most of the time, I don't see an issue with non-native looking UIs. Oftentimes, non-native UIs look better.
VSCode and Atom both look great and they're non-native. I also think Slack looks pretty good too. Except for MacOS, native UI widgets generally seem to be pretty ugly.
Even Microsoft is embracing non-native UI for its own Microsoft Office platform.
> Most of the time, I don't see an issue with non-native looking UIs. Oftentimes, non-native UIs look better.
I think there's a threshold for this.
Throw 1 or 2 non-native designs (and UX) at me, I'm fine. I'll appreciate the aesthetics. Make every app have its own UX/design and I'm going to get lost very easily.
And there's a hidden context switch cost there that can accumulate.
Microsoft has never had a consistent look and feel across its suite of applications. Windows Live Mail, Zune media player, Windows media player, the Office suite, etc all looked different and they all looked different than other Microsoft applications.
Microsoft doesn’t even have a consistent look and feel within its operating system. Windows 8 forward has been an inconsistent mess of a half implemented tablet interface.
Microsoft Teams, Skype, VS Code, Internet Explorer, System Center. Not sure you could argue these are non-business applications, and none of them seem very consistent to me.
Interesting point, but that wasn't my experience. The office suite was consistent, but SharePoint differed markedly (at least in ~2010 when I last used it). IIS was different yet. I'm trying to think of other business-oriented MS products that I used (it's been a while)...
The normal tclkit runtime with Tk is 6.1 Mb of disk space and 10-15 Mb of ram.
The most bloated Tcl/Tk runtime I could find (undroidwish tcl/tk running on SDL + OpenGL and Anti-grain backend) is 23 Mb of disk space and 42 Mb of ram (including all the shared libraries).
Hard to compare with a web engine in functionality and ram usage.
I just tried to get started with tclkit to try it out. The first result for "getting started tclkit" has links with 404. I was able to download a prebuilt binary for macOS which does run, but I can't find any clear tutorials for how to start building apps (the top result for "getting started" is from 2008).
I decided to try some example apps instead, so downloaded some .kit files and tried to run them:
% ./tclkit-8.6.3-macosx10.5-ix86+x86_64 fractal.kit
2019-06-25 12:14:12.541 tclkit-8.6.3-macosx10.5-ix86+x86_64[18970:1942703] -[TKWindow setCanCycle:]: unrecognized selector sent to instance 0x10023a910
2019-06-25 12:14:12.542 tclkit-8.6.3-macosx10.5-ix86+x86_64[18970:1942703] * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[TKWindow setCanCycle:]: unrecognized selector sent to instance 0x10023a910'
It crashes.
Hard to compare with the ecosystem and maturity of the web.
I was comparing it to the average RAM of computers when Tcl/Tk was still in its hype cycle and you heard bloat arguments against it, which must've been the 90s. When Tk was still yellow-ish.
My fault, could've expressed it better. And as someone who actually like(d) Tcl/Tk, I understand the urge to defend it perfectly.
If we're comparing UI implementation languages, it doesn't look good from a historic perspective. PostScript was pretty much better than all its successors. Tcl/Tk had a decent approach as something Unix-y, and I don't even want to know what will come after JS/CSS/HTML if we're continuing that arc.
Please don't use Tk for new applications, unless they're just for your own use. Tk is completely inaccessible to blind users, and probably people with some other disabilities as well. As much as people may hate Electron, it is better in this area, or at least can be if the app uses good HTML.
To be fair, nobody cares. And I'm not just being snide.
One of the social apps proudly wore it's "hard to use" interface as a way to scare off the grownups.
And, personally, I'd rather have an app that scales it's interface elements nicely rather than the "detents" that we get at particular monitor resolution (Try scaling something like Reaper (They're not the only ones) to anything other than 2x on a 4K monitor--Umm, if I wanted a 1920x1080 monitor, I'd have bought one, thanks. What I want is for you to scale to about 150% so that I get more screen elements AND they're larger).
Add the fact that "screencasting" is much easier if the application renders all its elements, and you've got a lot of reasons to go non-native and never look back.
I think people do care, but they don't know what they dislike.
I mean, there are certain things we tolerate on the web, like a UI taking a while to load. We don't tolerate that in native apps — even if the content is missing, I still expect the interface to show up instantly.
It's not a question of native vs web apps. It's a question of "does this fulfil the expectations I set for native apps?"
My position is that frameworks like Electron and React Native aren't amenable to fulfilling those expectations but they are capable of doing so if the developers put in the extra work. It's just a shame that so many developers don't, and their sloppy efforts become the poster children for these web apps.
At the same time, my position is also that if you're going to put in that extra work to make web apps feel right natively, you could probably have done native UIs to start with.
It's that they're quite non-native. And not just in the "button borders are 1 pixel wider than usual" sense -- they're usually styled to resemble web applications, with big data views, Material UI, etc.
Going from this to something more lightweight/native doesn't just require a different API, it requires a completely redesign.
In other words: The Big Rewrite That We're Definitely Going To Do Someday(tm).