How did anyone look at this and say “yeah nah, selecting text isn’t an important use case on the web”? Why does selecting text matter you ask? Some people use it to aid with reading by selecting the text they are currently reading, other people use it to(and I know this is wild) copy parts of the text, people with dyslexia use tools that read out selected portions of the text to help them read. Does any of this work with Flutter’s default, unselectable text? Fuck no!
One more broadside in the campaign against users by providers to take all the advantages of automation for themselves and leave none for us.
Unfortunately, I have a pretty good idea about how that happened and it’s one of those things I file in the “Battles not worth fighting anymore”, in the “Reasons why web apps should die a fiery death” binder.
With complex enough layouts built using enough CSS framework layers, the semantics of the page barely resembles what’s on the screen anymore. That leads to tragically funny situations where you want to select two or three lines of text in a column, but as soon as you get past the first line’s boundary, you’ve selected half the damn page, including four or five hidden elements that show-up when you paste them.
Fixing the damn layout is, by now, a Herculean task where you’re wrestling not just against the CSS engine but also against whatever framework you’re using. In time, it has led to this pseudo-fix where some parts of the page are just labeled unselectable. Can’t select them by mistake if you can’t select them deliberately, either, eh?
For single-page web apps, virtually all of the page is supposed to be unselectable by default at this point. This prevents user panic: some people (especially with touchpad gestures) end up accidentally dragging their cursor up or down for a bit and thus end up selecting the whole page.
How do I know this: yours truly, definitely not a web developer, implemented something like that eons ago. I was working on a prototype for a hardware gizmo that had a web interface, among other things. Some higher-up threw a tantrum about the sub-par user experience on his Macbook because of said selection accident and I wired something up, largely by copy-pasting off StackOverflow, since I had not written any web-related code in 7+ years at that point, did not know, or care, about any of that, and had far more important problems to solve with the prototype (like, say, the fact that it had a crap USB controller and enumeration didn’t always work as planned…).
A few years later a former colleague asked me if I remembered my solution having any browser portability problems (I didn’t, it took me a while to recall what solution he was asking me about and it was hardly my solution, too). Turns out it had bubbled its way up to a bunch of other components, precisely in order to “fix” that kind of but everywhere else. It also turned out that, over the years, the “bug” had been reported in terms of “page background changes when scrolling” on at least one occasion, too, as sometimes the behaviour was so weird that at least one person didn’t even realize they were selecting the damn thing.
Fundamentally, a single-page application is an application, not a document. The issues with “selecting text” / “restyling title” should be treated as accessibility issues in application, not that a webpage doesn’t conform to a document standard no more.
From that lens, this post basically complained the generic accessibility issues for all cross-platform UI toolchains that tries to be too ambitious and re-implemented everything from drawing layer. I happen to think this is the right way to build cross-platform UI with any cross-platform consistency. It just requires a lot of people power to get basics done, and then native accessibility right, and then ongoing maintenance to add more widgets and more platform-specific abilities There are a lot of failed attempts along this direction, but Flutter may have a chance with the vast resource from Google. Who knows.
Flutter Web has primarily been designed for actual web applications, as in, large web apps where the code sharing with mobile is critical. It’s not really designed for general-purpose web use and definitely not designed for stuff that could mostly be a static web page. That’s not to say accessibility isn’t important, and there is active work on improving this (which is part of the reason why this project is still in beta).
I was expecting a little more than “it doesn’t use semantic html” to qualify it as a “Fractal of Bad Design.” I get that that’s not good, but this article hasn’t really convinced me that i shouldn’t use Flutter Web, just given me a reason to be somewhat more wary of it than I would be otherwise.
It depends on the circumstances - difference circumstances have different requirement - sometimes I’m making a tool just for myself, so I don’t care that screen readers or userstyles don’t work. Also, the article doesn’t mention it, but Flutter does seems to care at least somewhat about accessibility, and Flutter Web is still in beta, so it seems quite possible that this will improve in the future. I’m not sure what the roadmap looks like (since I’ve never used flutter), but it seems likely that accessibility will improve in the future. Flutter also seems pretty open about the limitations of Flutter Web:
Not every HTML scenario is ideally suited for Flutter at this time. For example, text-rich flow-based content such as blog articles benefit from the document-centric model that the web is built around, rather than the app-centric services that a UI framework like Flutter can deliver. However, you can use Flutter to embed interactive experiences into these websites.
What I was expecting was a more in-depth report based on experience, rather than a “I looked at it for a few minutes and here are my first impressions”, which is what this post seems to be.
It’s almost unimaginable to release something like this in 2020 and not have a11y support, so I did a quick search and it seems like accessibility is possible with flutter. I don’t know how well that works in practice (I never even heard of “Flutter” before I read this post) and it’s entirely possible that it’s really bad, but it’s not even mentioned in this post which leaves me with the impression that the author doesn’t know either.
I agree. I think this is major flaw, and I think it’s suspicious that google has put out a major tool that essentially breaks automation.
But ‘fractal of bad design’ implies significant and unique design mistakes that culminate into something much more serious, across a multitude of surfaces.
And and top of that, the conclusion of
Flutter is a misguided attempt to achieve the impossible: quality cross platform experiences
Is I think a little hyperbolic, especially when the article doesn’t tackle any topic related to cross platform considerations at all.
Classic clickbait, but that shouldn’t take away from the concerns illustrated
I think the article is right about pointing (pretty horrific) drawbacks of flutter web. However, I think attributed that to bad design is wrong. I am not an expert in this area, but my understanding is that this is the only possible technical solution, given Flutter’s context.
Building non-web cross-platform UI toolkits is hard. I think most successful solutions take exactly the approach of drawing pixels to OpenGL context manually, and mimicking the OS conventions. QT, Swing, Gtk(not sure about this one), Sublime Text all take this approach. The most notable exception I know is Eclipse’s GUI toolkit, which indeed is based on OS controls (again, low-confidence knowledge). Heck, even the amusingly popular electron is this same approach, reduced ad absurdum.
What if you want to put such toolkit on the web? Well, you have two choices: either don’t do it, or do it i the way Flutter did, with all of the associated drawbacks.
Maybe I woke up on the wrong side of the bed this morning, or maybe it’s because I haven’t had a coffee yet, but I don’t appreciate the indignant style of this article. Like, it’s possible to convey the same informational content without being so derisive.
That said, these seem like legitimate shortcomings and I’m glad that I’m now aware of them. Screen readers and other accessibility tooling are not normally on my mind, so I can imagine that I would’ve done the same thing as the Flutter devs here.
Regarding Flutter non-Web: I occasionally dabble with mobile programming, and I found the Flutter Android experience so much better than trying to build the equivalent functionality “the Android way”.
I think it’s fine to call hot garbage what it is (if that’s the authors opinion, for instance).
It’s important to remember that not everyone on this site comes from an US-style – “somebody could be offended”, “it’s not the opinion of my employer” etc. – cultural background.
It’s important to remember that not everyone on this site comes from an US-style – “somebody could be offended”, “it’s not the opinion of my employer” etc. – cultural background.
I don’t know what this angle is, but it’s not where I’m coming from. It’s about how I prefer to receive criticism. If someone criticised my project in the way the author did Flutter, I’d be more likely to say “fuck you” and walk away. I would have to put in extra effort to extract the useful information and act on it. There are other more constructive ways to deliver the same information, where instead of feeling defensive, I’ll actually feel grateful that they told me.
I’m also wary of a pattern in tech circles where people use “shitting on tech” as a way to signal status, and this article gives me those kinds of vibes. It’s easy to talk shit about tech, but it’s not so easy to build tech that’s worth shit-talking.
You are acting like this is some random hobbyist project by a lone developer. It’s not.
It’s a project done by Google and considering how Google’s monopoly position ensures that every decision they make will affect billions of people, they deserve every little bit of scrutiny.
Let’s not even act like “text selection is broken”, “the DOM is gone”, “you cannot inspect the page anymore” weren’t explicit decisions demanded and signed off at the appropriate management level at Google:
You are not that stupid. I’m not that stupid. The author of that blog post isn’t that stupid. Let’s stop humanizing tax-dodging, multi-billion dollar companies by pretending they have feelings, while at the same time absolving them of any moral or ethical responsibility.
The linked demo application (Reply) brings my 2020 phone to a grinding halt. Apparently, re-implementing hardware accelerated UI components in canvas an javascript is slow (who’d have guessed?)
Flutter is a misguided attempt to achieve the impossible: quality cross platform experiences.
I don’t think it is impossible at all, just moderately difficult.
Anecdotally, I’ve been able to achieve a usable forum website which is compatible with Mosaic, Netscape, IE, Lynx, Links, Firefox, Chrome, Opera, in many different versions, with and without JS when applicable.
The beauty of bending over backwards for compatibility is that for each platform you adapt to, it becomes more likely it will work out of the box for the next one you try out of the box or with a small effort.
For example, the first time I know of a regular screen-reader user testing my site, they were able to complete all the tasks and didn’t have any issues, even though I had not designed anything specifically for screen-readers by that point.
When are developers going to stop using Google promo packet fodder as the basis for their projects?
Like, do people really not understand how this works?
One more broadside in the campaign against users by providers to take all the advantages of automation for themselves and leave none for us.
Unfortunately, I have a pretty good idea about how that happened and it’s one of those things I file in the “Battles not worth fighting anymore”, in the “Reasons why web apps should die a fiery death” binder.
With complex enough layouts built using enough CSS framework layers, the semantics of the page barely resembles what’s on the screen anymore. That leads to tragically funny situations where you want to select two or three lines of text in a column, but as soon as you get past the first line’s boundary, you’ve selected half the damn page, including four or five hidden elements that show-up when you paste them.
Fixing the damn layout is, by now, a Herculean task where you’re wrestling not just against the CSS engine but also against whatever framework you’re using. In time, it has led to this pseudo-fix where some parts of the page are just labeled unselectable. Can’t select them by mistake if you can’t select them deliberately, either, eh?
For single-page web apps, virtually all of the page is supposed to be unselectable by default at this point. This prevents user panic: some people (especially with touchpad gestures) end up accidentally dragging their cursor up or down for a bit and thus end up selecting the whole page.
How do I know this: yours truly, definitely not a web developer, implemented something like that eons ago. I was working on a prototype for a hardware gizmo that had a web interface, among other things. Some higher-up threw a tantrum about the sub-par user experience on his Macbook because of said selection accident and I wired something up, largely by copy-pasting off StackOverflow, since I had not written any web-related code in 7+ years at that point, did not know, or care, about any of that, and had far more important problems to solve with the prototype (like, say, the fact that it had a crap USB controller and enumeration didn’t always work as planned…).
A few years later a former colleague asked me if I remembered my solution having any browser portability problems (I didn’t, it took me a while to recall what solution he was asking me about and it was hardly my solution, too). Turns out it had bubbled its way up to a bunch of other components, precisely in order to “fix” that kind of but everywhere else. It also turned out that, over the years, the “bug” had been reported in terms of “page background changes when scrolling” on at least one occasion, too, as sometimes the behaviour was so weird that at least one person didn’t even realize they were selecting the damn thing.
Fundamentally, a single-page application is an application, not a document. The issues with “selecting text” / “restyling title” should be treated as accessibility issues in application, not that a webpage doesn’t conform to a document standard no more.
From that lens, this post basically complained the generic accessibility issues for all cross-platform UI toolchains that tries to be too ambitious and re-implemented everything from drawing layer. I happen to think this is the right way to build cross-platform UI with any cross-platform consistency. It just requires a lot of people power to get basics done, and then native accessibility right, and then ongoing maintenance to add more widgets and more platform-specific abilities There are a lot of failed attempts along this direction, but Flutter may have a chance with the vast resource from Google. Who knows.
Have people already forgotten how awful Flash-based websites were? This sounds like the same thing all over again.
Flutter Web has primarily been designed for actual web applications, as in, large web apps where the code sharing with mobile is critical. It’s not really designed for general-purpose web use and definitely not designed for stuff that could mostly be a static web page. That’s not to say accessibility isn’t important, and there is active work on improving this (which is part of the reason why this project is still in beta).
I was expecting a little more than “it doesn’t use semantic html” to qualify it as a “Fractal of Bad Design.” I get that that’s not good, but this article hasn’t really convinced me that i shouldn’t use Flutter Web, just given me a reason to be somewhat more wary of it than I would be otherwise.
If accessibility isn’t a good enough reason then what is?
It depends on the circumstances - difference circumstances have different requirement - sometimes I’m making a tool just for myself, so I don’t care that screen readers or userstyles don’t work. Also, the article doesn’t mention it, but Flutter does seems to care at least somewhat about accessibility, and Flutter Web is still in beta, so it seems quite possible that this will improve in the future. I’m not sure what the roadmap looks like (since I’ve never used flutter), but it seems likely that accessibility will improve in the future. Flutter also seems pretty open about the limitations of Flutter Web:
What I was expecting was a more in-depth report based on experience, rather than a “I looked at it for a few minutes and here are my first impressions”, which is what this post seems to be.
It’s almost unimaginable to release something like this in 2020 and not have a11y support, so I did a quick search and it seems like accessibility is possible with flutter. I don’t know how well that works in practice (I never even heard of “Flutter” before I read this post) and it’s entirely possible that it’s really bad, but it’s not even mentioned in this post which leaves me with the impression that the author doesn’t know either.
I agree. I think this is major flaw, and I think it’s suspicious that google has put out a major tool that essentially breaks automation.
But ‘fractal of bad design’ implies significant and unique design mistakes that culminate into something much more serious, across a multitude of surfaces.
And and top of that, the conclusion of
Is I think a little hyperbolic, especially when the article doesn’t tackle any topic related to cross platform considerations at all.
Classic clickbait, but that shouldn’t take away from the concerns illustrated
I think the article is right about pointing (pretty horrific) drawbacks of flutter web. However, I think attributed that to bad design is wrong. I am not an expert in this area, but my understanding is that this is the only possible technical solution, given Flutter’s context.
Building non-web cross-platform UI toolkits is hard. I think most successful solutions take exactly the approach of drawing pixels to OpenGL context manually, and mimicking the OS conventions. QT, Swing, Gtk(not sure about this one), Sublime Text all take this approach. The most notable exception I know is Eclipse’s GUI toolkit, which indeed is based on OS controls (again, low-confidence knowledge). Heck, even the amusingly popular electron is this same approach, reduced ad absurdum.
What if you want to put such toolkit on the web? Well, you have two choices: either don’t do it, or do it i the way Flutter did, with all of the associated drawbacks.
Maybe I woke up on the wrong side of the bed this morning, or maybe it’s because I haven’t had a coffee yet, but I don’t appreciate the indignant style of this article. Like, it’s possible to convey the same informational content without being so derisive.
That said, these seem like legitimate shortcomings and I’m glad that I’m now aware of them. Screen readers and other accessibility tooling are not normally on my mind, so I can imagine that I would’ve done the same thing as the Flutter devs here.
Regarding Flutter non-Web: I occasionally dabble with mobile programming, and I found the Flutter Android experience so much better than trying to build the equivalent functionality “the Android way”.
I think it’s fine to call hot garbage what it is (if that’s the authors opinion, for instance).
It’s important to remember that not everyone on this site comes from an US-style – “somebody could be offended”, “it’s not the opinion of my employer” etc. – cultural background.
I don’t know what this angle is, but it’s not where I’m coming from. It’s about how I prefer to receive criticism. If someone criticised my project in the way the author did Flutter, I’d be more likely to say “fuck you” and walk away. I would have to put in extra effort to extract the useful information and act on it. There are other more constructive ways to deliver the same information, where instead of feeling defensive, I’ll actually feel grateful that they told me.
I’m also wary of a pattern in tech circles where people use “shitting on tech” as a way to signal status, and this article gives me those kinds of vibes. It’s easy to talk shit about tech, but it’s not so easy to build tech that’s worth shit-talking.
You are acting like this is some random hobbyist project by a lone developer. It’s not.
It’s a project done by Google and considering how Google’s monopoly position ensures that every decision they make will affect billions of people, they deserve every little bit of scrutiny.
Let’s not even act like “text selection is broken”, “the DOM is gone”, “you cannot inspect the page anymore” weren’t explicit decisions demanded and signed off at the appropriate management level at Google:
You are not that stupid. I’m not that stupid. The author of that blog post isn’t that stupid. Let’s stop humanizing tax-dodging, multi-billion dollar companies by pretending they have feelings, while at the same time absolving them of any moral or ethical responsibility.
I congratulate Google on inventing their very own SilverLight.
The linked demo application (Reply) brings my 2020 phone to a grinding halt. Apparently, re-implementing hardware accelerated UI components in canvas an javascript is slow (who’d have guessed?)
I’m not worried about it taking over the web.
Why not? Because it has performance problems? Since when has that stopped people?
I don’t think it is impossible at all, just moderately difficult.
Anecdotally, I’ve been able to achieve a usable forum website which is compatible with Mosaic, Netscape, IE, Lynx, Links, Firefox, Chrome, Opera, in many different versions, with and without JS when applicable.
The beauty of bending over backwards for compatibility is that for each platform you adapt to, it becomes more likely it will work out of the box for the next one you try out of the box or with a small effort.
For example, the first time I know of a regular screen-reader user testing my site, they were able to complete all the tasks and didn’t have any issues, even though I had not designed anything specifically for screen-readers by that point.
The article means native apps on the platform. Android apps, not a web app running in an Android web browser.
Somewhat surprised to see this from google, of all web companies.