[Signez]

> Native widgets: Instead of drawing widgets that look nearly identical to the platform's design, Boden uses native OEM widgets ensuring that your app will always have a truly native look and feel.

While I fully understand the underlying concept, I don’t understand why so many people seems to be bothered by that anymore; I used to care about that as an Android user, but most of the apps I use everyday on my phone (Twitter, Inbox, Slack, Youtube, even Google Photos or Maps) do not seems to use the pure platform widgets anyway.

[zapzupnz]

Native widgets don't just mean "look". They can also mean "feel". This is particularly true on macOS.

On macOS, I expect certain widgets in order to accomplish certain tasks. I expect that they will respond to mouseover and button presses in a certain way. I expect to be able to use certain key combinations to cause certain widgets to do certain things, I expect keyboard combinations to be able to be redefined in System Preferences.

On the accessibility front, I expect VoiceOver to be able to read what's on screen, I expect it to be able to tell me what a widget's behaviour will be, I expect to be able to get back to where I was using a standard key combo, I expect images to respect colour inversion settings, I expect text to scale according to the system's Dynamic Type settings.

When it comes to handling text; I expect fonts to have the system's native rendering; I expect that Unicode support is complete, I expect macOS' emoji picker to show up; I expect system-wide text replacements, smart quotes, and orthography checking to work as expected, I expect selectable text to show a list of system-wide Services in the context menu, I expect all text to be draggable and handled correctly by the receiver of the drag action.

There are plenty of other things that I can't think of, but this list could get quite long. Suffice to say, Apple put a lot of default behaviours into Cocoa, and apps that (A) don't use Cocoa, or (B) only use Cocoa for drawing but not inheriting behaviours, they don't just look a bit off, they feel _wrong_.

I think we may be immune to this to some extent on mobile, and Windows users haven't known anything other than complete inconsistency, even with Microsoft's own built-in interfaces. But for some of us, if the interface feels wrong, the app goes straight into the Trash.

[saagarjha]

Cocoa Touch, while being slightly simpler and less arcane than Cocoa, still has a lot of semi-hidden behaviors that are nonobvious to cross-platform UI framework implementers.

[zapzupnz]

I notice this most when playing games and I can't get context menus to show up with long presses.

[tokyodude]

I'm trying to find an example of this "long press shows context menu". Tried long pressing a link in Safari Mac no context menu appears. Ctrl-Click brings up context menu. Tried long pressing a shortcut, no context menu but ctrl-click brings up context menu. Tried selecting and long clicking a file in Finder. No context menu appears but ctrl-click brings up context menu. Tried selecting some text in TextEdit and long pressing, No luck. Ctrl-Click brings up context menu. Tried long pressing a tab in the ruler, same issue. It seems like even for Apple this isn't much of a standard.

[zapzupnz]

The person to whom I was replying was talking about Cocoa Touch, so this was about iOS, not macOS. If it interests anybody, the specific example was Pokémon Go's text fields which _do_ respond to Cmd-V, but I can't long press to get Copy|Paste to show up.

[tom_]

The takeaway here is that each OS trains you in its own way to look down at all those morons using one of the other ones.

[zapzupnz]

I don't see that at all. Rather, each OS has its benefits, and if the person who designs a toolkit doesn't account for them, you wind up with something middling and foreign that takes advantage of nothing.

For able users, that can come down to minor irritations. For users with special accessibility requirements, that's downright unacceptable.

If my listing of all the features of macOS might have come off as haughty, it's simply because I'm one of the ones who has special accessibility requirements, and the way macOS does things suits me well. Apps that don't use Cocoa, therefore, can really screw me over.

[mwcampbell]

In your experience, how do web applications compare to native Mac apps? Of course, a web app can be accessible with both VoiceOver and magnification (based on all the features you listed, I'm guessing you're low-vision). But are even the most accessible web applications noticeably less efficient for you than native Cocoa apps?

[zapzupnz]

You're correct, I have low vision. Enough to code and read relatively comfortably, but not for long; so I either make the text enormous or turn on VoiceOver. Below, I'm talking about macOS; I don't use VoiceOver on iOS.

I tend to find with web apps that they're pretty inaccessible with VoiceOver, depending on what they were made with. If it's Electron or React Native, unusable. I just make the text huge. No good for blind users who shouldn't be left out of the fun, but mightn't even be able to find the voice chat controls.

Even when I'm not using VoiceOver, web apps tend not to respect system accessibility settings like text size. When they have them built into the apps as a setting, that's nice but rarely the case. It would still be better to respect my accessibility preferences; I don't go to all the trouble of setting them up for nothing. It's also not like Apple's accessibility APIs have changed drastically over the years, they're pretty stable. I imagine this to be the same for Windows.

In websites, it's usually a different matter, sometimes a bit better. In general, the web version (that is, in a browser) version of a web app is usable to a greater extent, though that doesn't necessarily mean anything, because VoiceOver knows how to inspect the DOM — whereas it isn't expecting that at all with 'native' web apps.

Proper Cocoa apps always win.

[mwcampbell]

Interesting. Based on your description, it seems that NVDA on Windows fares better with Electron apps than does VoiceOver on Mac. NVDA's "browse mode" features work equally well whether it's Electron, Chrome, or Firefox (and to a lesser extent in IE and Edge).

In another thread, you wrote that Xcode is the best IDE you've found for Mac simply because it's native to the Mac. Have you tried Eclipse? Given that Eclipse's SWT widget toolkit is based largely on native widgets, it might be native enough. Then again, the editor is custom, so it may still fall short.

I ask you these questions because I'm interested in the perspective of a Mac user who has apparently learned to make very effective use of multiple Mac accessibility features.

[tokyodude]

I find native apps frustrating that they won't let me select what I want, only what they want to allow me to select, where as in a web page I can generally select whatever I want.

[phs318u]

While the intention of the design may not be what you describe, one of the consequences often is.

[gitoby]

Author here. The goal of Boden is very much that the applications should look and feel as if they were custom-coded for the specific platform. We also think that custom widgets often fall slightly short of the native feel, as other commenters have pointed out. While it is certainly possible to make them 100% consistent with other native apps on the platform, it is a lot of work to get all the details right. And not all frameworks manage to do that.

We wanted to try a different approach. Why not just use what the platform gives you and always get the right look & feel out of the box? That certainly creates its own challenges, like having to provide a good abstraction layer for the core application code. But you do not have to worry about look, feel, drawing performance, interactions with other OS features and the like. And when the OS changes something then the app is automatically up-to-date.

[kccqzy]

There are so many hidden behaviors in native widgets that once you get accustomed to, you can't go back any more. Here are a few of the ones:

* Right click the document icon on the title bar to reveal a menu bar for ancestor directories * Drag the document icon into things like an email client as an attachment * Support Emacs-style text editing shortcuts such as C-a C-e C-k everywhere, as well as user-defined ones (I added a bunch of other Emacs ones like M-f) * Trackpad shortcuts such as three finger press on a word to show dictionary and thesaurus * Drag and drop selected text to move it * Hold option while selecting text for rectangular selection

There are many others. I get upset if something doesn't work when I know it should work if the app developer is using native controls.

[zzo38computer]

Another thing is Xaw (X Athena widgets). Xaw supports using X resource manager to control some things, and also I like how scrollbars work in Xaw

[0xcde4c3db]

I might be totally off base here, but I get the sense that native widgets have become a skeuomorph for following the common UX conventions of the platform you're running on, with the latter being what brings the real value. The equivalent conventions for web apps and their desktop derivatives are much looser and don't yield as much consistency on which to build effective user expectations and habits. People who experienced the shift can tell something is missing, and the most obvious correlate is the disappearance of native widgets.

[SiempreViernes]

Maybe you mean that "native widgets" has become just a byword for "following platform conventions"?

[esrauch]

I think he means "things tend to either with follow conventions and use native widgets, or they do neither". Users can internalize that dichotomy, and recognize that as soon as they don't see native widgets they probably aren't getting platform conventions either.

[0xcde4c3db]

Basically that, yes. I don't think people are necessarily conscious of the association, though.

[jjnoakes]

Getting the native look and feel is nice. Using the native widgets had other benefits too, like accessibility for example.

[maxxxxx]

You also often get UI automation. I hate the trend to not use the built-in widgets. I am talking you, Microsoft...

[asituop]

Especially when Google itself is promoting Flutter which in a way is a non-native UI framework. I think as long as a framework is performant and implements well the design guidelines of the OS this is what really matters

[saagarjha]

Except that Flutter is pretty bad on anything that isn’t Android. The “Cupertino” theme needs significant work; it’s significantly worse than even Ionic is.

[nfin]

v1.0 final is not even out yet...

[zapzupnz]

I don't call that a defence when it's already out in the wild, and people are already talking about it like it's "good enough" when we are already able to use its version number as justification when it's clearly not.

[zapzupnz]

And now, Flutter is at 1.0 as of today.

[nitwit005]

It's often necessary to make all the native accessibility stuff work.

Sometimes new features come out which will immediately work well with native components, but which require a lot of reworking to work well with something custom. High DPI support is often an example of this.