Hacker News Reader

Comment by jlongster | Hacker News Reader

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.

I agree that browsers make it hard though.

View on HN

> 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).

In other words, HTML UI frameworks are still far behind native frameworks and actually not really usable yet.

In other words, poorly written components don't work well: which happens in other GUI toolkits and not just HTML.

Good HTML UI frameworks don't make this mistake.

Are there any good HTML UI frameworks yet?

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

This is one of the reasons I despise touching Windows. Why on earth are error dialog boxes not selectable??

Yeah. However, when the dialog is focused you can press ctrl+c to copy it's contents to the clipboard.

Who thought this was a good UX?

The same people who wrote the Windows API, I guess.

WHAT?! This changes everything.

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).

Don't block selection please.

I don't want to select text in a button

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.

Reply on news.ycombinator.com