Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

701–710 of 748 posts

Re: We're forking Flutter

#701

Earlier quoted context omitted.

I can appreciate that as a developer, but as a user I don’t particularly care that some company wants to ship identical looking apps on every device under the sun. I would prefer the apps I use to work and behave in a consistent way, using the same platform idioms I am used to. The software available and how it works was a large part of the reason I chose the platform I did. Of course, I recognise that, a. most peopl…

Only on HN do I hear anyone talking about platform native controls versus unified UI across devices. I have not once heard of such a complaint in the real world and indeed, I have more often heard users wanting a unified UI over one that changes with each platform, simply because these days we have multiple devices where we expect apps to work the same.

People have multiple devices, sure, but in my experience (among non-HN people) it's iPhone+iPad or iPhone+mac dominating, with a decent contingent of iPhone+Windows, and rarely Android+Windows. (This is of course US-centric; the iPhone is more popular as a mobile platform, and that often entices people to buy into other aspects of the Apple ecosystem.)

It is exceedingly rare for the multiple devices to span the UI toolkits of more than one or two company-platform. For people in the Apple ecosystem, they don't want to see something that looks like it belongs on Android.

Regardless, "unified UI" doesn't mean it can't use native controls. More important from a UX perspective is that controls are in the same places and behave similarly, and that the app is organized in a similar manner, plus or minus what might naturally change because of differences in screen size and input method. And that's another useful point to make too: mobile, tablet, and desktop experiences are often quite different, and that's normal and expected at this point.

Another consideration: it's a lot more difficult to make an accessible app when you draw your own custom UI controls with your own custom behavior. If you use the native UI controls, you get a lot of the accessibility features for free, and have to do much less work to make sure everything works for people who are vision or mobility impaired. From what I understand after reading about blind people's experiences on various platforms, most companies that do custom UI don't bother, and the accessibility of their apps is atrocious.

Re: We're forking Flutter

#702
post #382

Earlier quoted context omitted.

I'd also like to meet all these mythical users that have devices from every platform and want all their apps to look the same across all platforms. 99% of people I know IRL are in one ecosystem, with the exception of some that have an iPhone/iPad + Windows PC

In a previous company when we were looking at precisely this problem, building out multiple platform support, we did UX studies where this question in particular came up. The vast majority of people said they wanted apps to act consistently across devices. Most people on the planet use Windows with Android, statistically speaking, which are not similar devices at all, at least on Apple platforms you can use Swift for…

> The vast majority of people said they wanted apps to act consistently across devices

... which you can absolutely do while using native UI controls. "Act consistently" (UI controls are in similar places and present themselves with similar UX) is not the same as "look consistently" (UI controls are drawn using whatever system theme or drawing style is in use).

Certainly there is some overlap between look & act: a platform-native "dropdown menu" looks and acts a little differently on Windows vs Android vs iOS. But I think these differences are not in the majority, and when users say they want apps to "act consistently" across platforms, you an absolutely achieve that with native UI controls, and it's not even that difficult.

This is a big problem I've run into when doing user studies myself: you need to be very precise with your language when asking users questions, and even then you often need to dig in and ask for details about what they mean by their answer. And of course having visual examples and functional mockups for users to play with helps a ton.

Another problem is the leading nature of questions you might ask during a user study: if you simply say "do you think it's better if the app acts consistently across platforms", of course users are going to say "yes". Saying "no" to that question feels kinda stupid, TBH. But if you were to give a user an iPhone and Android phone, with the same app, using native controls on both platforms, and ask them if you believe that the apps "act consistently" with each other, users are probably going to say "yes", as long as the design and UX of the apps in general are consistent with each other.

(And even that's a contrived test: very few people use both an iPhone and Android phone regularly!)

Re: We're forking Flutter

#703
post #379

Earlier quoted context omitted.

They want both implementations to compete, and then they deprecate one of them.

Thats an excellent summary, and its fair for you to assume that question has been settled.

(On a serious note), inside Google you tend to get more easily promoted if you launch new products than if you maintain existing products, so it could be tempting for the employees themselves to follow in that direction.

Re: We're forking Flutter

#704

Earlier quoted context omitted.

I'm not quite sure why this was downvoted. It's true.

It's because while it's true on the company side, this comment is making it seem as if the company is doing this against their users' will, while in reality, most users genuinely want a unified experience across platforms for their apps, as seen by some of the comments here.

Right, but you continually conflate "unified experience" with "using custom UI controls".

Re: We're forking Flutter

#705

Earlier quoted context omitted.

Depends on what's being developed, I guess. No tables/trees is probably ok for a lot of lighter end-user sorts of apps but doing without them for many desktop-first apps and utilities would be rough. Desktop file managers, media library apps, and email apps for example would be quite a lot less useful without multi-column tables at the minimum.

I almost never use email on anything but my phone, and Gmail doesn't use a table. They do some tree stuff for the conversation threads, but conversation threads are obnoxious anyway and I have no idea why anyone likes them, they don't reflect face to face conversations well and always create mistakes where someone forgets to reply to all. I've replaced a lot of tables in my apps with modal dialog UIs, it's nice to ha…

This is something I have a difficult time agreeing on. I expect a certain level of information density and configurability in desktop UIs, which shoehorned mobile-style UIs don't do well to provide. Deep modality is also a peeve; on desktop there's often no benefit to burying things in mulitple layers of modals — within reason, the most important things should never be more than one click away and great consideration should be put into putting upwards of 2 clicks between the user and their destination.

That said, I do think it's fine to have a simplified mobile-ish UI as an option, but it shouldn't come at the cost of more classical desktop style layouts for those who can leverage them well.

As a sidenote, this is part of why apps like the mac version of Apple Mail and Thunderbird have a considerable number of hardcore adherents, particularly among power users.

Re: We're forking Flutter

#706
post #564

Earlier quoted context omitted.

Developers who think that way have no clue what their users want. Most iOS users want a native experience, not something else. When I see an app that doesn't have that, I quickly lose interest. Having the app look the same on all platforms is a dumb idea to start with.

Are these the same users that prefer websites without CSS?

Websites and apps aren't directly comparable when it comes to this metric.

Re: We're forking Flutter

#707

Earlier quoted context omitted.

It didn't "just happen" the early architects of the web designed a system to make it easy to share and remix content and subsequent generations of companies and their UX designers have so far failed to fully claw back user freedoms.

Content as in significant text and media content, not selecting the text off a button element. I agree, seems like this is just a post facto rationalization of a mistake from a system that was originally designed for content, not application functionality.

Maybe I need to copy-paste the text from the buttons so I can accurately ask which one I should click. Maybe I have a screen reader that needs to access that text to read it out loud. Maybe I want to copy-paste the UI elements into a translation program so I can understand them in my own language. Maybe I want to copy the UI text so I can make a better re-implementation of your site...

Re: We're forking Flutter

#708

Earlier quoted context omitted.

Content as in significant text and media content, not selecting the text off a button element. I agree, seems like this is just a post facto rationalization of a mistake from a system that was originally designed for content, not application functionality.

Maybe I need to copy-paste the text from the buttons so I can accurately ask which one I should click. Maybe I have a screen reader that needs to access that text to read it out loud. Maybe I want to copy-paste the UI elements into a translation program so I can understand them in my own language. Maybe I want to copy the UI text so I can make a better re-implementation of your site...

Those are some of the most niche use cases I've ever heard, and that is stretching it even on HN, much less anyone in the non HN bubble. Things like screen readers work just fine on non browser apps that don't have selectable text, for example.

Re: We're forking Flutter

#709
post #704

Earlier quoted context omitted.

It's because while it's true on the company side, this comment is making it seem as if the company is doing this against their users' will, while in reality, most users genuinely want a unified experience across platforms for their apps, as seen by some of the comments here.

Right, but you continually conflate "unified experience" with "using custom UI controls".

I never said they must be custom, merely that custom makes it easier to implement.

Re: We're forking Flutter

#710
post #702

Earlier quoted context omitted.

In a previous company when we were looking at precisely this problem, building out multiple platform support, we did UX studies where this question in particular came up. The vast majority of people said they wanted apps to act consistently across devices. Most people on the planet use Windows with Android, statistically speaking, which are not similar devices at all, at least on Apple platforms you can use Swift for…

> The vast majority of people said they wanted apps to act consistently across devices ... which you can absolutely do while using native UI controls. "Act consistently" (UI controls are in similar places and present themselves with similar UX) is not the same as "look consistently" (UI controls are drawn using whatever system theme or drawing style is in use). Certainly there is some overlap between look & act: a pl…

You can achieve them with native controls but only at the bottom-most layer, if you actually want consistency. Spotify for example does not use Material on Android, Human Design Guidelines on Apple, and Fluent on Windows (well, they use Electron, bypassing native desktop entirely), they use their own custom controls that may at the very bottom layer be based on native text inputs, but they rebuilt all the actual UI stuff from scratch to achieve a unified look and act.

This is all well and good but the people I see on HN are ones that say that the app should actually look native on each platform, ie Material on Android etc. This opinion is what I'm pushing back on, not the fact that ctrl + C works on Windows and CMD + C works on Mac.

Of course, this is the reason why cross platform frameworks are so popular, if you're already gonna have to rewrite the UI for every platform, why not just do it once and save yourself the effort? After all, users won't care, as they've shown, because they care much more about new features coming out. There are always tradeoffs because time is finite.

> This is a big problem I've run into when doing user studies myself

Sigh, do you really think that all of these weren't considered when we did user studies? This is like 101 material, frankly almost insulting to imply that we didn't, therefore it can justify your priors, even though I agree with your points to some extent as said before.

Post reply on HN