Why is native/normal feel the end-all-be-all of UI systems? I've never quite understood why this is so desirable. Or why the answer seems to be using a shoddy UI system stuffed in a browser frame.
Because chances are that whatever custom UI/UX design you come up with isn't going to be better (or even as good as) OS UI toolkits that've been designed by experts, battle tested for decades, and used for every type of application known to man.
Applications with native UIs also tend to give a a better impression of responsiveness, and they reduce mental load for your users since they're don't have to relearn much (if anything). They can rest assured that every button and popup menu and text field (for example) functions identically to every other such control they've encountered on the system and in other native apps. This is worth way more than most people think.
One easy example of this is text fields in OS X. Native text fields there all have a form of emacs key bindings built into them to make powerful text navigation and manipulation a systemwide thing. Every application built with Cocoa gets this for free, but more often than not applications using non-native UIs don't implement this functionality at all. This is highly frustrating when you've worked said bindings into your workflow.
I know a great coder who refuses to start personal projects because he can't find UI libraries which are:
1. Cross-platform across mac-win-linux-android-ios
2. Built for a compiled language such as pascal or C++
3. Built to use native controls
4. Integrated to registered libraries through an interface like activex
5. Accompanied by a UI builder with design-time and runtime states and component builders.
6. Easily integrated to embedded and server-side SQL.
Sometimes we impose too many constraints on ourselves and never actually start anything. Fear of success?
Good point. And actually, Delphi matches many of those bullet points. Expensive, though. (The promo of the free Delphi 10.1 Berlin Starter version just got over on Aug 9. First time in a a while, maybe, since Turbo Delphi Explorer.)
I think writing an IDE or anything else with editor integration during the editor wars would be a similar analogy:
- you could push one or the other
- you could try to support users on both side based on the editor variable
- you could go the new route where only users who care enough to invest do
- you could go the Jed simplicity route.
In the end, IDEs like jetbrains have the new route with plugins for the factions. Most lower investment cases do the Jed route which is more like web neutral. No one who pushed the unwanted editor on its opposing group seems to be still standing.
It is a good idea because you reduce the learning curve for end-users of application by the use of common controls. Think about the MS-DOS era, and then Windows came along, with the ubiquitous F1 key everywhere, Ctrl-P and Ctrl-S, not to mention the toolbars, etc.
