6 ms·

> 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 alwa

by Signez 8y ago

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

jjnoakes 8y ago
Getting the native look and feel is nice. Using the native widgets had other benefits too, like accessibility for example.
- maxxxxx 8y ago
  You also often get UI automation. I hate the trend to not use the built-in widgets. I am talking you, Microsoft...
asituop 8y ago
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 8y ago
  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 8y ago
    v1.0 final is not even out yet...
    - zapzupnz 8y ago
      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 8y ago
        And now, Flutter is at 1.0 as of today.
0xcde4c3db 8y ago
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 8y ago
  Maybe you mean that "native widgets" has become just a byword for "following platform conventions"?
  - esrauch 8y ago
    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 8y ago
      Basically that, yes. I don't think people are necessarily conscious of the association, though.
zapzupnz 8y ago
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 8y ago
  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 8y ago
    I notice this most when playing games and I can't get context menus to show up with long presses.
    - 8y ago
kccqzy 8y ago
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 8y ago
  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
nitwit005 8y ago
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.
gitoby 8y ago
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.

by Signez 8y ago

jjnoakes 8y ago

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

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

asituop 8y ago

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 8y ago
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 8y ago
  v1.0 final is not even out yet...
  - zapzupnz 8y ago
    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 8y ago
      And now, Flutter is at 1.0 as of today.

0xcde4c3db 8y ago

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 8y ago
Maybe you mean that "native widgets" has become just a byword for "following platform conventions"?
- esrauch 8y ago
  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 8y ago
    Basically that, yes. I don't think people are necessarily conscious of the association, though.

zapzupnz 8y ago

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 8y ago
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 8y ago
  I notice this most when playing games and I can't get context menus to show up with long presses.
  - 8y ago

kccqzy 8y ago

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 8y ago
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

nitwit005 8y ago

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.

gitoby 8y ago

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.