10 ms·

While this has little relationship to the original article... We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries li

While this has little relationship to the original article... We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. For example, in macOS Cocoa, textboxes have universal readline-esque keybindings (and is configurable globally) which, as an Emacs user, very, very useful. Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can benefit these keybindings. Another example of this directly benefiting users is the addition of tabs in macOS Sierra. macOS Sierra added tabs to Cocoa apps, and applications could get the feature without additional modification. I can use tabs in any application, with the same look-and-feel, in all apps. Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!) Adding Flutter or any other UI library that draws everything from scratch is a bad idea.

Const-me 7y ago
> Windows apps usually just re-invent all kinds of UI elements It wasn't always this way. Before Win8, most apps used native controls on Windows. When it became apparent GPU rendering is the way forward, MS re-implemented them in WPF. It does draw everything from scratch, because the backend is now DirectX 9. But it was a first party reimplementation, the UX is good. Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX. Now windows phones are shut down, but UX on PCs still suffers the consequences. The new GUI framework is better then ever, but there's no consistent UX on top.
- pcr910303 7y ago
  > Before Win8, most apps used native controls on Windows. Yeah, it's true but the problem is that the native controls were very limited. There was no central notification system so every Windows messaging app reinvented notifications(unlike macOS which converged to Growl and later, the Notification Center), no standard Ribbon Menu widget (at least when it was first introduced, I'm not sure about the current status) so everyone reinvented it, e.g. > Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX. This is so true... Windows 8/10 has a such mixed up UX that some system components are using the new 'metro' style while some others are old Win32 ones that don't support HiDPI... And, (while currently not true) Windows 10 had two settings app that worked differently for a few years. :-(
  - Const-me 7y ago
    > There was no central notification system… no standard Ribbon Menu widget True, but if MS wanted to, they could have added both to the old ecosystem, without jumping ship. They had mayor parts of notification system already, Shell_NotifyIcon API from Shell32.dll. They were adding more features to NOTIFYICONDATA structure with every OS version. They did release ribbon widget; it just took them a few years. Introduced in Office 2007, the widget is from Win7 i.e. 2009: https://docs.microsoft.com/en-us/windows/win32/windowsribbon/-uiplat-windowsribbon-entry https://docs.microsoft.com/en-us/windows/win32/windowsribbon...
    - zerr 7y ago
      They (VS team) licensed the ribbon control from the 3rd party company. The Office team didn't share the original one with them :)
      - Const-me 7y ago
        I don’t work for MS but I think the reason why they did not, it was hard to do, not because they didn’t want to share. That’s quite complex UI and UX in that control. Very likely, the office implementation is coupled too tight with the rest of the office code, i.e. very hard to refactor into a reusable control. The office is cross-platform, their implementation of ribbon has to be designed to work on OSX too, contributing to the complexity.
        WorldMaker 7y ago
        Given just what was visible to Office Extension Developers ("RIBBON XML", the giant pile of C++ MACROS, etc), the original Office Ribbon control was probably quite a complex beast. On the other side: the new "Simplified Ribbon Control" that is in now in OneNote (the real one, not 2016) and Outlook (and eventually the rest of Office) is supposed to be the exact same code as the UWP/Fluent Ribbon that is eventually going to be open sourced into the WinUI library.
    - Kipters 7y ago
jazoom 7y ago
>Adding Flutter or any other UI library that draws everything from scratch is a bad idea. Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
- pcr910303 7y ago
  > Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea. Yeah, that's true. I'm looking forwards to React Native (AFAIK it uses the native JS engine + native toolkits) and libui. I'm also hoping for declarative UI frameworks like SwiftUI so that the underlying framework/runtime can generate the appropriate UI for the exact target platform.
  - krzat 7y ago
    > underlying framework/runtime can generate the appropriate UI for the exact target platform This may seem like a good idea, but it's not. What you will get is a leaky, lowest common denominator API that will break on each new OS version.
    - alex_suzuki 7y ago
      Well put.
    - saagarjha 7y ago
      I don't understand how you got to this conclusion.
      - krzat 7y ago
        I worked on Xamarin app and saw how things worked there. I also think that it's a logical conclusion from these conditions: 1. You want to support N native platforms. 2. Each of these platforms has it's own way of doing this, bugs, etc. 3. Each of these platforms is being actively developed. 4. There are differences between those platforms. One doesn't have guassian blur, the other one doesn't have right-to-left languages.
IshKebab 7y ago
I think the popularity of Electron has shown that is actually isn't very important to users to use native controls. Also on Desktop, macOS is the only one that even has a single official "native" toolkit.
- aikinai 7y ago
  Electron is popular with developers, not users.
  - moksly 7y ago
    Then why are Discord and Visual Studio Code both so popular and well liked by their users?
    - dgellow 7y ago
      Because they provide features their users care about. Not because of their choice of framework.
      - dragonwriter 7y ago
        Proving that features are important, native controls...not so much.
  - thiht 7y ago
    Any data backing that up? Don't forget HN users are a bubble. I'm actually pretty sure standard users don't even notice a difference between Electron and native apps. I for one sometimes prefer Electron apps over badly designed and ugly native apps.
- obliviousonions 7y ago
  UWP is actually pretty easy to use and looks great & native on Windows.
  - paulddraper 7y ago
vijaybritto 7y ago
The massive success of Electron apps shows that users don't really care about native controls. Even though electron is terrible in resource usage it enables unmatched development speed for teams. If libui or other libraries can give this experience then most teams won't hesitate using it!
- MisterTea 7y ago
  I liken Electron to McDonalds. Gets the job done in a pinch but is awful in every single way. (edit: spelling)
  - vijaybritto 7y ago
    Exactly!
  - jayd16 7y ago
    If my app is only as successful as McDonalds, I'll take it.
    - projektfu 7y ago
      Electron is successful like McDonalds. McDonalds's customers, not so much?
- pjmlp 7y ago
  What success? It helps when sometimes there isn't any options to start with. I use Slack as job requirement, outside work I keep my PC Electron free. Same applies to VSCode, only because of TypeScript and Rust, otherwise it wouldn't be on my computer.
  - vijaybritto 7y ago
    Success as in being the UI for a multi billion dollar company like Slack. It's undeniably terrible but what other options do we have? I don't think any tech is gonna withhold against the web! I'm actually willing to switch to any platform that can offer amazing development experience at the same time being super performant.
rohan1024 7y ago
You yourself said > Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!) and on next line you say > Adding Flutter or any other UI library that draws everything from scratch is a bad idea. The first thing you said is the reason why we need something like Flutter. There might be a standard way of doing things on Mac but on Windows and Linux there isn't. Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base. That isn't bad thing.
- jcelerier 7y ago
  > Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base well, no, it just adds another standard. QtQuick already allows the exact same thing that Flutter (one UI, shared across all platforms both in terms of code and looks). (QtWidgets instead is more geared towards applications that fit in the host platform's guidelines).
nnq 7y ago
> Coherent UI is a very important point to users Nah, it ain't. At all! I used to believe it did. That's what we geeks think. And on mobile it doesn't matters for us either - keybings working consistently doesn't matter you're only using touch... Same thing with React Native, everyone thought it's awesome because native UI controls. But users never care about that. For touch UIs it's more user friendly to have you app be friendly by being unique. The thing that "users prefer native" was just because users like fast and responsive UIs, if Flutter can provide fast and responsive UIs, nobody cares if it isn't native. Even on desktop, the best UIs I've ever seen (take the new Blender's 2.8 widely appreciated UI) just use OpenGL and draw their own widgets. People say they care about "coherence" or "consistency" when they are too clueless to figure out what's actually broken about their UIs, so they assume this is the issue. An awesome UX/I is one that would keep being awesome even if each and every button would have a different and inconsistent style, what matters is higher level. Let us stop bitching about things being incoherent or inconsistent when the actual issue is the lack of ability to figure out what is so wrong with a UI that it hinders users! (Oh, and everyone will always want custom branding and styles, whether we like it or not... We need technology that can embrace uniqueness and incoherence and inconsistency and make it work properly and shippable in time!)
- mstade 7y ago
  Neither you nor the parent poster substantiate your assertions with sources, which made me curious of what research might have been done in this area. Some cursory searching lead me to this reasonably well sourced answer, which suggests the parent poster is right in this case: https://ux.stackexchange.com/a/39295 https://ux.stackexchange.com/a/39295
  - nnq 7y ago
    Sorry, but your linked source is off-topic, ancient (2013!), and compares the wrong things (native mobile apps vs. old-generation-hybrid-web-mobile apps). The relevant comparison here would be between: - (1) truly native uni-platform mobile apps (native Android and native iOS apps) - (2) cross-platform mobile apps using native widgets (not sure if there's any alternative to React Native here) - (3) cross-platform mobile apps that draw their own ui, but NOT using web technologies: Flutter is the only obvious example (there are older things like Kivy which uses Python and OpenGL but I think it was mostly used for games and kids app, not that popular) Web-techs-based hybrid-mobile apps are a different thing (Cordova, Ionic etc.) and, yes, there everyone agreed they feel inferior to users, just as mobile optimized websites feel inferior. Unfortunately this is the problem here, it's incredibly easy to compare apples to oranges here, I don't blame, just saying that all sources are misleading, probably it's better to play with few things and see the "gut feeling"... it's pretty obvious that underlying tech and whether the widgets are drawn natively or not is NEVER a differentiator between successful and unsuccessful apps, it's always all the other things :)
nicoburns 7y ago
I'm hoping a cross-platform UI takes over the world. Then it will be the "native" UI's that seem inconsistent.
- vbsteven 7y ago
  In a sense that already happened with the web stack. In tech like Electron developers write most of their app once and use a “shell” like Electron to interact with the host OS. Unfortunately the web stack is very bloated with years of legacy and this requires these shell projects to embed a full browser engine making these apps bloated as well. Flutter is an approach at making a new shell that provides rendering and host OS interaction without all the web bloat.
  - nicoburns 7y ago
    Ah yes. I should have specified: a high-performance, low resource usage cross-platform UI. Flutter's a nice idea, but I somewhat suspect it will never make it out of its relatively small niche. I have my eye on the Rust UI work. It's a long way out, but it has the potential to be a really solid foundation for a universal UI platform.
    - Isomorpheus 7y ago
      Don't forget Revery! https://github.com/revery-ui/revery https://github.com/revery-ui/revery
bernaferrari 7y ago
Author here. Never expected it to reach here. 24k views and it's been ~14 hours since I wrote it. I agree with you. There is currently a competition between kotlin multiplatform and flutter, a shared backend vs a shared UI. Guess what, exactly what you said, it's a lot easier to share the backend than recreate the full UI like a game does. I'm not against flutter, but it feels too immature for now and the pains really show up. Apple showed up their new UI toolkit for developers, which does animations in the best way possible, Flutter team reaction was "you can make a library to improve it if you want" and "we should improve our docs" but no one will recognize there are issues in the framework that could be improved.
- sebe 7y ago
  BMW seems happy with flutter and are opensourcing some of their flutter libs. Quote from CTO Connected Company at BMW “By combining Dart and Flutter we have the first true cross-platform mobile toolkit; we feel it is a game changer to ensure feature parity for digital touchpoints and IoT. By moving forward with world class tooling, automation and modern functional programming patterns we can improve feature cycle time, security, and cost of delivery of features for the business.” https://www.youtube.com/watch?v=80pRyn7fZRk&feature=youtu.be&t=1234 https://www.youtube.com/watch?v=80pRyn7fZRk&feature=youtu.be...
  - seeekr 7y ago
    It feels like he could have said that about any of the relevant frameworks. They're happy they've started down the cross-platform path using one of the solid available alternatives -- good on them!
dgellow 7y ago
> Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. If you’re talking about macOS, then I agree with you, that’s something I cared about when I was using Apple’s OS. Recently I moved to Windows for my personal machine, on this system you really don’t have coherence between applications, even between things developed by the same company or for applications tightly coupled with the OS! It’s just a big mess where each interface has its own set of rules incompatible with others. I would understand if people more familiar with Windows don’t care at all about the overall coherence given how random things seems to be.
stelonix 7y ago
I agree with this 90%, but I'm not sure about the state of GUI apps after Windows 7. Up to Win7 though, most applications simply used native controls, sometimes wrapped by WPF or WFC. I used to write for WINAPI/GDI and I used to loathe it; I mostly disliked the way messages were handled by default: huge switch statements. After switching to Linux and checking out the many "toolkits" I find myself craving for some GDI-esque toolkit. GDI was bad, outdated when I started writing it (circa 2009) but things "just worked", looks were consistent and controls would do the same across applications. The GNU/Linux counterpart is a mess: drag & drop sometimes works across toolkits, sometimes it does not; some toolkits are unwillingly to standarize with each other; the looks are all different, the functionalities too. Need an IME? Well here's one for KDE and another one for GTK. And if you use a different toolkit, chances are there's no IME for you. Right clicking on text-boxes and getting the same default options is great, so is being able to extend the same text-boxes systemwide. This is simple on Windows, but GNU/Linux requires one implementation per widget type per toolkit. It's all fragmented and no one cares. I miss GDI, I crave for a simple standard X11-wide widget system. Users do care about widgets working the same on different applications and they don't care about which toolkit is being used, specially non-tech savvy people. I believe those issues are more linked to the meme of "year of the desktop Linux" never arriving than anything else, really: UX should be consistent. Well now I'll end my rant.
- buckminster 7y ago
  Minor nit: GDI was the graphics API. The user interface came from USER.
mamcx 7y ago
> We really should be trying to use the native GUI toolkit Yes. The problem with that is that it requiere experience * each toolkit and that is pain-full for many. This cause a FORCED split (when multi-platform): - You want easy to use and fast iteration. You NOT use native UI. Reach for mediocre options - You want the BEST of the BEST of the BEST. You pick native UI. However sometimes that toolkit is nuts (Windows API, Android, Linux. Ok like all of them?) Or if lucky you know the other alternative (Windows -> Delphi, Android -> Kotlin, Linux -> ????) ---- This is not a fair fight. UI is too hard everywhere. C++ toolkits are nuts. And it not need to be this way. I think today we already have a good idea in how truly a good toolkit must be done: https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_what_a_good_gui_system_would_need/ https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... - A lot can be actually cross-platform: Layouts, Units, colors, fonts calculation... - Widget definition with a DSL (like SwiftUI) This allow: - Real-time drawing of widgets AND easy drag-drop UI creation like Delphi or HyperCard (this is where HTML beat almost everything) The above are candidates for cross-ui then you need: - Rendered by each toolkit. With native controls - Some way to communicate the backend to this front-end I think this is alike a game engine: 1- You define the UI: <Window title="hello"><UIButton if="iOS"> <Button if="the others"> 2- You have a driver that launch the UI: UI derived from BaseUI.. //customize it for my project or create a new platform UI.register(UIButton... UI.register(UIWindow for "Window" //Attach listeners.. UI.listen(...) //Run the UI UI.run(the UI directory) When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic. --- To be clear: This is almost the same as usual. Except it work like a interpreted language: It have a monolithic core but is possible to code a specific version per platform (if desired). The critical component is the ability to register to the engine (very easily!) new widgets, listeners, behaviors. etc.
russellbeattie 7y ago
Add to this Accessibility: Standard widgets normally have accessibility features built in, working well and tested to make sure apps work correctly with various assistive technologies like screen readers, zooming, key controls, etc.

Const-me 7y ago

> Windows apps usually just re-invent all kinds of UI elements It wasn't always this way. Before Win8, most apps used native controls on Windows. When it became apparent GPU rendering is the way forward, MS re-implemented them in WPF. It does draw everything from scratch, because the backend is now DirectX 9. But it was a first party reimplementation, the UX is good. Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX. Now windows phones are shut down, but UX on PCs still suffers the consequences. The new GUI framework is better then ever, but there's no consistent UX on top.

pcr910303 7y ago
> Before Win8, most apps used native controls on Windows. Yeah, it's true but the problem is that the native controls were very limited. There was no central notification system so every Windows messaging app reinvented notifications(unlike macOS which converged to Growl and later, the Notification Center), no standard Ribbon Menu widget (at least when it was first introduced, I'm not sure about the current status) so everyone reinvented it, e.g. > Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX. This is so true... Windows 8/10 has a such mixed up UX that some system components are using the new 'metro' style while some others are old Win32 ones that don't support HiDPI... And, (while currently not true) Windows 10 had two settings app that worked differently for a few years. :-(
- Const-me 7y ago
  > There was no central notification system… no standard Ribbon Menu widget True, but if MS wanted to, they could have added both to the old ecosystem, without jumping ship. They had mayor parts of notification system already, Shell_NotifyIcon API from Shell32.dll. They were adding more features to NOTIFYICONDATA structure with every OS version. They did release ribbon widget; it just took them a few years. Introduced in Office 2007, the widget is from Win7 i.e. 2009: https://docs.microsoft.com/en-us/windows/win32/windowsribbon/-uiplat-windowsribbon-entry https://docs.microsoft.com/en-us/windows/win32/windowsribbon...
  - zerr 7y ago
    They (VS team) licensed the ribbon control from the 3rd party company. The Office team didn't share the original one with them :)
    - Const-me 7y ago
      I don’t work for MS but I think the reason why they did not, it was hard to do, not because they didn’t want to share. That’s quite complex UI and UX in that control. Very likely, the office implementation is coupled too tight with the rest of the office code, i.e. very hard to refactor into a reusable control. The office is cross-platform, their implementation of ribbon has to be designed to work on OSX too, contributing to the complexity.
      - WorldMaker 7y ago
        Given just what was visible to Office Extension Developers ("RIBBON XML", the giant pile of C++ MACROS, etc), the original Office Ribbon control was probably quite a complex beast. On the other side: the new "Simplified Ribbon Control" that is in now in OneNote (the real one, not 2016) and Outlook (and eventually the rest of Office) is supposed to be the exact same code as the UWP/Fluent Ribbon that is eventually going to be open sourced into the WinUI library.
  - Kipters 7y ago

jazoom 7y ago

>Adding Flutter or any other UI library that draws everything from scratch is a bad idea. Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.

pcr910303 7y ago
> Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea. Yeah, that's true. I'm looking forwards to React Native (AFAIK it uses the native JS engine + native toolkits) and libui. I'm also hoping for declarative UI frameworks like SwiftUI so that the underlying framework/runtime can generate the appropriate UI for the exact target platform.
- krzat 7y ago
  > underlying framework/runtime can generate the appropriate UI for the exact target platform This may seem like a good idea, but it's not. What you will get is a leaky, lowest common denominator API that will break on each new OS version.
  - alex_suzuki 7y ago
    Well put.
  - saagarjha 7y ago
    I don't understand how you got to this conclusion.
    - krzat 7y ago
      I worked on Xamarin app and saw how things worked there. I also think that it's a logical conclusion from these conditions: 1. You want to support N native platforms. 2. Each of these platforms has it's own way of doing this, bugs, etc. 3. Each of these platforms is being actively developed. 4. There are differences between those platforms. One doesn't have guassian blur, the other one doesn't have right-to-left languages.

IshKebab 7y ago

I think the popularity of Electron has shown that is actually isn't very important to users to use native controls. Also on Desktop, macOS is the only one that even has a single official "native" toolkit.

aikinai 7y ago
Electron is popular with developers, not users.
- moksly 7y ago
  Then why are Discord and Visual Studio Code both so popular and well liked by their users?
  - dgellow 7y ago
    Because they provide features their users care about. Not because of their choice of framework.
    - dragonwriter 7y ago
      Proving that features are important, native controls...not so much.
- thiht 7y ago
  Any data backing that up? Don't forget HN users are a bubble. I'm actually pretty sure standard users don't even notice a difference between Electron and native apps. I for one sometimes prefer Electron apps over badly designed and ugly native apps.
obliviousonions 7y ago
UWP is actually pretty easy to use and looks great & native on Windows.
- paulddraper 7y ago

vijaybritto 7y ago

The massive success of Electron apps shows that users don't really care about native controls. Even though electron is terrible in resource usage it enables unmatched development speed for teams. If libui or other libraries can give this experience then most teams won't hesitate using it!

MisterTea 7y ago
I liken Electron to McDonalds. Gets the job done in a pinch but is awful in every single way. (edit: spelling)
- vijaybritto 7y ago
  Exactly!
- jayd16 7y ago
  If my app is only as successful as McDonalds, I'll take it.
  - projektfu 7y ago
    Electron is successful like McDonalds. McDonalds's customers, not so much?
pjmlp 7y ago
What success? It helps when sometimes there isn't any options to start with. I use Slack as job requirement, outside work I keep my PC Electron free. Same applies to VSCode, only because of TypeScript and Rust, otherwise it wouldn't be on my computer.
- vijaybritto 7y ago
  Success as in being the UI for a multi billion dollar company like Slack. It's undeniably terrible but what other options do we have? I don't think any tech is gonna withhold against the web! I'm actually willing to switch to any platform that can offer amazing development experience at the same time being super performant.

rohan1024 7y ago

You yourself said > Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!) and on next line you say > Adding Flutter or any other UI library that draws everything from scratch is a bad idea. The first thing you said is the reason why we need something like Flutter. There might be a standard way of doing things on Mac but on Windows and Linux there isn't. Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base. That isn't bad thing.

jcelerier 7y ago
> Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base well, no, it just adds another standard. QtQuick already allows the exact same thing that Flutter (one UI, shared across all platforms both in terms of code and looks). (QtWidgets instead is more geared towards applications that fit in the host platform's guidelines).

nnq 7y ago

> Coherent UI is a very important point to users Nah, it ain't. At all! I used to believe it did. That's what we geeks think. And on mobile it doesn't matters for us either - keybings working consistently doesn't matter you're only using touch... Same thing with React Native, everyone thought it's awesome because native UI controls. But users never care about that. For touch UIs it's more user friendly to have you app be friendly by being unique. The thing that "users prefer native" was just because users like fast and responsive UIs, if Flutter can provide fast and responsive UIs, nobody cares if it isn't native. Even on desktop, the best UIs I've ever seen (take the new Blender's 2.8 widely appreciated UI) just use OpenGL and draw their own widgets. People say they care about "coherence" or "consistency" when they are too clueless to figure out what's actually broken about their UIs, so they assume this is the issue. An awesome UX/I is one that would keep being awesome even if each and every button would have a different and inconsistent style, what matters is higher level. Let us stop bitching about things being incoherent or inconsistent when the actual issue is the lack of ability to figure out what is so wrong with a UI that it hinders users! (Oh, and everyone will always want custom branding and styles, whether we like it or not... We need technology that can embrace uniqueness and incoherence and inconsistency and make it work properly and shippable in time!)

mstade 7y ago
Neither you nor the parent poster substantiate your assertions with sources, which made me curious of what research might have been done in this area. Some cursory searching lead me to this reasonably well sourced answer, which suggests the parent poster is right in this case: https://ux.stackexchange.com/a/39295 https://ux.stackexchange.com/a/39295
- nnq 7y ago
  Sorry, but your linked source is off-topic, ancient (2013!), and compares the wrong things (native mobile apps vs. old-generation-hybrid-web-mobile apps). The relevant comparison here would be between: - (1) truly native uni-platform mobile apps (native Android and native iOS apps) - (2) cross-platform mobile apps using native widgets (not sure if there's any alternative to React Native here) - (3) cross-platform mobile apps that draw their own ui, but NOT using web technologies: Flutter is the only obvious example (there are older things like Kivy which uses Python and OpenGL but I think it was mostly used for games and kids app, not that popular) Web-techs-based hybrid-mobile apps are a different thing (Cordova, Ionic etc.) and, yes, there everyone agreed they feel inferior to users, just as mobile optimized websites feel inferior. Unfortunately this is the problem here, it's incredibly easy to compare apples to oranges here, I don't blame, just saying that all sources are misleading, probably it's better to play with few things and see the "gut feeling"... it's pretty obvious that underlying tech and whether the widgets are drawn natively or not is NEVER a differentiator between successful and unsuccessful apps, it's always all the other things :)

nicoburns 7y ago

I'm hoping a cross-platform UI takes over the world. Then it will be the "native" UI's that seem inconsistent.

vbsteven 7y ago
In a sense that already happened with the web stack. In tech like Electron developers write most of their app once and use a “shell” like Electron to interact with the host OS. Unfortunately the web stack is very bloated with years of legacy and this requires these shell projects to embed a full browser engine making these apps bloated as well. Flutter is an approach at making a new shell that provides rendering and host OS interaction without all the web bloat.
- nicoburns 7y ago
  Ah yes. I should have specified: a high-performance, low resource usage cross-platform UI. Flutter's a nice idea, but I somewhat suspect it will never make it out of its relatively small niche. I have my eye on the Rust UI work. It's a long way out, but it has the potential to be a really solid foundation for a universal UI platform.
  - Isomorpheus 7y ago
    Don't forget Revery! https://github.com/revery-ui/revery https://github.com/revery-ui/revery

bernaferrari 7y ago

Author here. Never expected it to reach here. 24k views and it's been ~14 hours since I wrote it. I agree with you. There is currently a competition between kotlin multiplatform and flutter, a shared backend vs a shared UI. Guess what, exactly what you said, it's a lot easier to share the backend than recreate the full UI like a game does. I'm not against flutter, but it feels too immature for now and the pains really show up. Apple showed up their new UI toolkit for developers, which does animations in the best way possible, Flutter team reaction was "you can make a library to improve it if you want" and "we should improve our docs" but no one will recognize there are issues in the framework that could be improved.

sebe 7y ago
BMW seems happy with flutter and are opensourcing some of their flutter libs. Quote from CTO Connected Company at BMW “By combining Dart and Flutter we have the first true cross-platform mobile toolkit; we feel it is a game changer to ensure feature parity for digital touchpoints and IoT. By moving forward with world class tooling, automation and modern functional programming patterns we can improve feature cycle time, security, and cost of delivery of features for the business.” https://www.youtube.com/watch?v=80pRyn7fZRk&feature=youtu.be&t=1234 https://www.youtube.com/watch?v=80pRyn7fZRk&feature=youtu.be...
- seeekr 7y ago
  It feels like he could have said that about any of the relevant frameworks. They're happy they've started down the cross-platform path using one of the solid available alternatives -- good on them!

dgellow 7y ago

> Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. If you’re talking about macOS, then I agree with you, that’s something I cared about when I was using Apple’s OS. Recently I moved to Windows for my personal machine, on this system you really don’t have coherence between applications, even between things developed by the same company or for applications tightly coupled with the OS! It’s just a big mess where each interface has its own set of rules incompatible with others. I would understand if people more familiar with Windows don’t care at all about the overall coherence given how random things seems to be.

stelonix 7y ago

I agree with this 90%, but I'm not sure about the state of GUI apps after Windows 7. Up to Win7 though, most applications simply used native controls, sometimes wrapped by WPF or WFC. I used to write for WINAPI/GDI and I used to loathe it; I mostly disliked the way messages were handled by default: huge switch statements. After switching to Linux and checking out the many "toolkits" I find myself craving for some GDI-esque toolkit. GDI was bad, outdated when I started writing it (circa 2009) but things "just worked", looks were consistent and controls would do the same across applications. The GNU/Linux counterpart is a mess: drag & drop sometimes works across toolkits, sometimes it does not; some toolkits are unwillingly to standarize with each other; the looks are all different, the functionalities too. Need an IME? Well here's one for KDE and another one for GTK. And if you use a different toolkit, chances are there's no IME for you. Right clicking on text-boxes and getting the same default options is great, so is being able to extend the same text-boxes systemwide. This is simple on Windows, but GNU/Linux requires one implementation per widget type per toolkit. It's all fragmented and no one cares. I miss GDI, I crave for a simple standard X11-wide widget system. Users do care about widgets working the same on different applications and they don't care about which toolkit is being used, specially non-tech savvy people. I believe those issues are more linked to the meme of "year of the desktop Linux" never arriving than anything else, really: UX should be consistent. Well now I'll end my rant.

buckminster 7y ago
Minor nit: GDI was the graphics API. The user interface came from USER.

mamcx 7y ago

> We really should be trying to use the native GUI toolkit Yes. The problem with that is that it requiere experience * each toolkit and that is pain-full for many. This cause a FORCED split (when multi-platform): - You want easy to use and fast iteration. You NOT use native UI. Reach for mediocre options - You want the BEST of the BEST of the BEST. You pick native UI. However sometimes that toolkit is nuts (Windows API, Android, Linux. Ok like all of them?) Or if lucky you know the other alternative (Windows -> Delphi, Android -> Kotlin, Linux -> ????) ---- This is not a fair fight. UI is too hard everywhere. C++ toolkits are nuts. And it not need to be this way. I think today we already have a good idea in how truly a good toolkit must be done: https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_what_a_good_gui_system_would_need/ https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... - A lot can be actually cross-platform: Layouts, Units, colors, fonts calculation... - Widget definition with a DSL (like SwiftUI) This allow: - Real-time drawing of widgets AND easy drag-drop UI creation like Delphi or HyperCard (this is where HTML beat almost everything) The above are candidates for cross-ui then you need: - Rendered by each toolkit. With native controls - Some way to communicate the backend to this front-end I think this is alike a game engine: 1- You define the UI: <Window title="hello"><UIButton if="iOS"> <Button if="the others"> 2- You have a driver that launch the UI: UI derived from BaseUI.. //customize it for my project or create a new platform UI.register(UIButton... UI.register(UIWindow for "Window" //Attach listeners.. UI.listen(...) //Run the UI UI.run(the UI directory) When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic. --- To be clear: This is almost the same as usual. Except it work like a interpreted language: It have a monolithic core but is possible to code a specific version per platform (if desired). The critical component is the ability to register to the engine (very easily!) new widgets, listeners, behaviors. etc.

russellbeattie 7y ago

Add to this Accessibility: Standard widgets normally have accessibility features built in, working well and tested to make sure apps work correctly with various assistive technologies like screen readers, zooming, key controls, etc.