6 ms·

I disagree that there should be libraries for GUI components. As soon as you try that, you end up compromising the UX with either non-native UI components, or l

by scosman 11y ago

I disagree that there should be libraries for GUI components. As soon as you try that, you end up compromising the UX with either non-native UI components, or lowest common denominator APIs that try to bridge iOS/Android. Write your models/controllers and other logic in Go, but keep your views native and use go's bind tool. Sidenote: You can write OpenGL ES apps in Go (aka games). These typically don't use native UI controls so that's a great use case for go mobile.

miguelrochefort 11y ago
How important is native UI to users? Is there any literature on the subject? I've always assumed it was important, but I keep seeing big name apps reinventing the UI and going the custom route.
- scosman 11y ago
  Who are the big names you're referring to? Many of them highly customize the look of the controls (Spotify, AirBnb, MSFT) but they are still the native controls. The back stack, physics, etc are all native.
- mwcampbell 11y ago
  In addition to providing the look and feel that users expect, native UIs are the most practical way to achieve accessibility for people with disabilities, e.g. blind people using screen readers like VoiceOver (iOS) and TalkBack (Android). You can implement the platform accessibility APIs for a non-native UI, but it's a lot of work; just ask the relevant developers of Chrome and Firefox. Addendum: If your app uses a web view, it can be accessible, as long as you use standard semantic HTML elements and/or add the appropriate ARIA attributes and focus behavior for custom widgets. But in this comment, I was comparing a native UI to something completely custom.
  - bengoodger 11y ago
    I've seen this argument repeated ad nauseum over the past 15-20 years. I think it depends on what you want. Yes to some having consistent elements of UI make some users feel very happy about using your software. Most probably won't be able to articulate why, they'll just feel a bit happier. I don't think there's an absolute in this discussion though. The web has proven that people value having access to more capability more highly than how well every aspect of that capability works. You could view the lack of integration as a weakness of the web, but for me it reads as flexibility/empowerment for the developer. It's possible to view developer empowerment as a negative, but in the case of the web it's enabled it to tackle some interesting use cases that you might miss if you stick to the rules too zealously. BTW, I think it's possible to build crappy UI natively too. It's a mindset thing. The web isn't native on any platform yet there are some web apps with great UI. There are also some non-native client apps (like Chrome) that I think (admitting my bias in Chrome's case) do a pretty good job.
NateLawson 11y ago
Yes, direct GL access with a thin app delegate is the most common way C++ game engines like Unreal Engine, Crytek, and Marmalade are packaged for iOS and Android. There's no reason you couldn't do that in Go too, except for the lack of other libraries like scripting, mesh, etc. I'm not talking just a simple GUI abstraction wrapper, which has earned a deservedly bad reputation. The more full-fledged UI models have gotten much nicer, like in React Native or Xamarin.
mratzloff 11y ago
I agree. > Unless a third-party fills this vacuum, Golang on mobile will remain a curiosity. No, it will be used for shared libraries, as intended.
- NateLawson 11y ago
  Yes, that's a good point. Though I'm not sure what Go library would be worth the couple MB runtime overhead purely by itself. Ideas?
  - scosman 11y ago
    About 1MB in my experience. Worth if if your app has a ton of custom logic.

by scosman 11y ago

miguelrochefort 11y ago

How important is native UI to users? Is there any literature on the subject? I've always assumed it was important, but I keep seeing big name apps reinventing the UI and going the custom route.

scosman 11y ago
Who are the big names you're referring to? Many of them highly customize the look of the controls (Spotify, AirBnb, MSFT) but they are still the native controls. The back stack, physics, etc are all native.
mwcampbell 11y ago
In addition to providing the look and feel that users expect, native UIs are the most practical way to achieve accessibility for people with disabilities, e.g. blind people using screen readers like VoiceOver (iOS) and TalkBack (Android). You can implement the platform accessibility APIs for a non-native UI, but it's a lot of work; just ask the relevant developers of Chrome and Firefox. Addendum: If your app uses a web view, it can be accessible, as long as you use standard semantic HTML elements and/or add the appropriate ARIA attributes and focus behavior for custom widgets. But in this comment, I was comparing a native UI to something completely custom.
- bengoodger 11y ago
  I've seen this argument repeated ad nauseum over the past 15-20 years. I think it depends on what you want. Yes to some having consistent elements of UI make some users feel very happy about using your software. Most probably won't be able to articulate why, they'll just feel a bit happier. I don't think there's an absolute in this discussion though. The web has proven that people value having access to more capability more highly than how well every aspect of that capability works. You could view the lack of integration as a weakness of the web, but for me it reads as flexibility/empowerment for the developer. It's possible to view developer empowerment as a negative, but in the case of the web it's enabled it to tackle some interesting use cases that you might miss if you stick to the rules too zealously. BTW, I think it's possible to build crappy UI natively too. It's a mindset thing. The web isn't native on any platform yet there are some web apps with great UI. There are also some non-native client apps (like Chrome) that I think (admitting my bias in Chrome's case) do a pretty good job.

NateLawson 11y ago

Yes, direct GL access with a thin app delegate is the most common way C++ game engines like Unreal Engine, Crytek, and Marmalade are packaged for iOS and Android. There's no reason you couldn't do that in Go too, except for the lack of other libraries like scripting, mesh, etc. I'm not talking just a simple GUI abstraction wrapper, which has earned a deservedly bad reputation. The more full-fledged UI models have gotten much nicer, like in React Native or Xamarin.

mratzloff 11y ago

I agree. > Unless a third-party fills this vacuum, Golang on mobile will remain a curiosity. No, it will be used for shared libraries, as intended.

NateLawson 11y ago
Yes, that's a good point. Though I'm not sure what Go library would be worth the couple MB runtime overhead purely by itself. Ideas?
- scosman 11y ago
  About 1MB in my experience. Worth if if your app has a ton of custom logic.