The amount of work Apple, Google and others have put into making all this work is staggering, and life changing for people who are blind. Please don’t throw all that work away in your apps just because you think some UI toolkit is shiny.
Facebook and Twitter both spend dozens if not hundreds of man-years trying to make HTML lists (tweets, posts) scroll as fast as native. Google is spending IDK how much hours painstakingly redrawing all the native components for both iOS and Android into Flutter, having to catch up every time they make a change.
Just use the platform like it was intended to be used. You're not special. You're not smarter. You're forgetting most of what the authors have already solved.
And, if you're at the scale of the Facebooks and co, you have the engineers to build it. You have the engineers to rebuild your whole app from scratch a dozen times over. And if you don't, it'll be trivial to find and hire them at the rates you're paying.
I’m personally falling into the belief that we’ve fooled ourselves regarding UI. That one single UI library could actually be the ideal choice for every possible app, and that we just need to keep trying until the absolute perfect set of tradeoffs appears. I think this is enticing because UI is very hard and full of problems you would have to solve over and over if you had multiple UI frameworks, whereas these things could be amortized if there were less.
I don’t think so. I do think the UI ecosystem, as it slows down, could become more modular and share more core components. I expect to see “base” rendering libraries, like Skia or Pathfinder, powering next generation UIs, and hopefully someone will also make a cross-platform library to provide accessibility and IME primitives for Windows TSF/macOS/etc. I think smaller bits like that can clearly be minmax’d to ideal conditions for given use cases. But if you were hoping for a future of “just use the native toolkit!” I think it’s not likely, at least not until software slows down a lot more. Even then, lowest common denominator libraries like wxWidgets often end up being disliked by users and developers alike, due to the compromises needed for them to accomplish their goals. I’ll admit the story has gotten better with React Native and its success on mobile, but even that is not a perfect story: performance on Android was apparently not good enough for Discord, which may in fact be a pretty good signal for why something like Flutter is a good idea anyways: it can mature over time on existing platforms and then possibly even become the first class toolkit for something.
I do agree that most developers should prefer native over vanity, but it’s a false dichotomy, as there are plenty of valid reasons to not do native. No more is this clear than Windows, where virtually nobody does “native” anymore. (It can still be OK, but it’s not great. Having true HWNDs for every component is a great way to have things flicker whenever you delete/create new widgets.)
> I do think the UI ecosystem, as it slows down, could become more modular and share more core components
I think things like Flutter will take another few years to become performant compared to even Electron/Tauri/Webview+JS
Yes, it is sad that we redesign UI (even web UIs) every so often, but it is an unforgiving world. I am not sure if it is the fickle users or the product manager(s) to blame, but we seek fancier and fancier UI with every update. There are exceptions like the craigslist website, but those are rare.
I agree with all other points.
It's not fanciness, it's maturation.
Compare YouTube from 2006: https://web.archive.org/web/20060202021427/http://youtube.co...
to now: https://web.archive.org/web/20210430000812if_/https://www.yo...
The new design puts content first. There are no superfluous borders, backgrounds, or gradients. Every visual element exists for a good reason. This is good, functional, accessible, design.
And YouTube of 2006 is a conservative example, we (well, most of us) can remember the UX/UI atrocities that existed back then.
I'm planning to do this for accessibility. I don't think I have the expertise to cover IME though. Do you think they both need to be done in one library, or can they be decoupled?
If you assume that they are not less smart than the average engineer, then a reasonable assumptions is that they weighed the trade-offs and went with what worked best for them, and you're missing some context (or give different weighting to importance of native widgets - which comes at a cost).
There are pros and cons to using native widgets or cross-platform libraries/UIs that go back to when UIs and platforms became a thing. I know of the SWT vs. Swing debate in the Java world some decades ago - there are likely many precedents before then. All I know is there is no right answer, just trade-offs you have to weigh.
If you look at a screen produced by, say, Flutter and compare it to Aplpe's native toolkit you might conclude that you can produce the "same" thing with Flutter as you'd get with Apple's native toolkit. To boot you can do it in less time.
The thing to consider is: Did you really produce the same thing? Maybe you produced two things that look the same, but aren't even close to equivalent in many other important ways.
When Sun or Google created their own, non-native toolkits designed to run on Mac OS/iOS, they were fully aware of what doesn't work. However, they balanced that con against the pros of the ability to write cross-platform code once (ground floor engineers), and on strategic level, they wanted to commoditize Mac OS/iOS into a dumb pipe (one of many other dump pipes to deliver code/content to), rather than a platform with inherent value - they consciously considered this to be more important than users' griping at the weird scroll-speed curves. One can create a shim for native widgets like QT does, but you'll be at the platform owners mercy when it comes to release cadence.
It's good business practice to commoditize your complement - seen in that light, the decisions are far from "not smart". Not great for some users, for sure, but they come from deliberate decision-making over control.
In the initial meetings where you talk about making new component libraries, someone who worked on the old one says, "We reinvented the wheel last time, then standards changed, and we couldn't keep up. We need to take current standards into account before doing anything new, including accessibility."
And the new boss says, "That's a good call-out, but accessibility isn't a problem if nobody can even load the component list and scroll to the thing they want, and with the current ux and stats, we're getting close to using most of the available memory on devices just to scroll our content. We don't want to change the content we can scroll, we just want to make scrolling more efficient. Everyone agrees the current design is at its limits. We need to start over at the beginning. Accessibility is step 3. We're at step 0. Let's focus and move forward." And while they are right, they need to demo an map to an abled-person boss, so accessibility gets pushed farther back as technical things take priority.
Often, this leads to teams over time producing lots of things without accessibility, and you build new things from old things, and it just snowballs.
Suddenly a user appears, and they aren't served, and now a whole new bunch of juniors are scrambling to add accessibility to old things without breaking current usage.
The advantage is mostly that it is easier to manage for the organization building the app. There is no real benefit for the users, in this case most likely slower, larger, and resource intensive apps, that avoid platform integration.
Where's the magical bit that means they can't use a native UI toolkit?
This kind of team structure also causes other strange-looking technology choices, such as CSS-in-JS: they have to do stuff like that because they literally cannot prevent different members of the team from writing CSS class names that collide.
Also, the app has sooooooo much more functionality than people realize. Plus, there is a lot of functionality that ships with the app but is behind a feature gate, meaning that it is turned off for the majority of users. There's lots of internal tools for adjusting feature gates on a per-user, per-region, per-whatever basis, in the name of user research as well as just safely deploying new features at scale.
But I don't believe you're correct, honestly feature flag rollout, even among insanely specific cohorts, isn't actually a hard problem and it's essentially been solved at this point - it isn't easy, not by any measure - but the components and how they interact are rather easy to comprehend. Facebook's main complexity (IMO) is from trying to build essentially a full OS on top of the browser from which to serve a variety of integration apps into their platform and, while I'm not a board member of Facebook or at all familiar with their earnings, that particular goal seems to have been, essentially, a dud.
Being able to play farmville with your friends may have been a decent income source once upon a time but it's very far from what their core competencies now are. Facebook now primarily uses API hooks into other native standalone apps for that particular class of data collection, but their pure web based collection seems to be where they really get value. The fact that they can see precisely where users are going on the web is, IMO, their main value proposition at this point - the social network stuff needs to exist to support that and ease the process of identifying users - but anything related to games seems utterly unnecessary and that core platform they have could be vastly simplified while still delivering the same value to the company.
That all said, they've invested a whole lot into their existing platform so I can see why business would be very very hesitant to try anything that might rock the boat, if they can sustain their platform being fast and responsive they can minimize their corporate risk.
I'm sure a lot of developers on here try and minimize their use of integration branches in the day-to-day (they are necessary for some things but keep them short and sweet) and try and get in-progress features into master ASAP - that's largely due to the fact that maintaining multiple copies of the same basic logic can quickly become extremely difficult to manage.
Localization is a really big exception to this but that's why, whenever possible, you'll see game companies limit localization to strings only - including logical statements in the realm of information to be localized can make security issues extremely fun to track down along with causing frequent usability breaks in less used localizations.
I don't know - whatever the reasons for it and no matter the resources FB has - this stuff increases in cost exponentially and if they do have a really fragmented codebase it's likely that the majority of their labour goes into process definition and QA to make sure that they don't break the Swahili language version of the landing page for China when they change their contact us link.
It works poorly on mobile, where users are not keen to reinstall an app every few days, and some do not update for months and years, because of lack of space, scarce bandwidth, old hardware, or just neglect.
Additionally, at least where Facebook is concerned and IIRC, they actually do heavily utilize out-of-app data in their mobile app. There is a good deal of code, but a lot of the UI ends up being tweaked by data that's being served to the client.
This stuff was solved in the early 90s and everyone's bored now.
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Are you saying Facebook would take more time to compile natively than an open world game including baking maps?
I'm not visually impaired outside of garden-variety nearsightedness, but I sort of have a strong appreciation for "boring" websites that have very utilitarian "Header, subheader, body of text, etc...". They work well with text-only browsers, but also are trivial to make work with various text-to-speech things which I find occasionally useful; sometimes it's just easier for me to understand something if it's being read along to me while reading it, particularly if the font is small.
All of which means less CPU, fewer network requests and less power used which means a longer-lasting planet.
I think I mostly get annoyed with stuff like news websites of personal blogs having all this extra crap added to it. At the end of the day, I view these things as somewhat utilitarian; I don't go onto a blog to be wowed by a million JavaScript effects, I go there to read text, and maybe some pictures to help elaborate on stuff.
Doing exactly this right now. I use a bookmarklet to make anything I click start speaking, on any website. It even shows the progress by fading away read words. I've been doing this for at least 7 years, always using Alex from MacOS, at 1.3x. I used to have it work on PDF's as well, but that went away when Chrome's PDF viewer was changed from PDF.js
.NET MAUI also seems very promising, and I like that they're actively blogging about it[1], but it hasn't been officially released yet.
Anyway, it seemed to me that basically all the others either aren't accessible at all, or are only accessible on one or two of the target platforms, or have long-standing accessibility bugs that seem like they would render the UI unusable.
[1]: https://devblogs.microsoft.com/xamarin/the-journey-to-access...
I decided the latter opinion was the one I cared more about.
I'm admittedly trying to play it very safe. I have zero proficiency with screen readers, so I'm not really able to independently verify any of this. All I know is that the GUI toolkit is one of the most expensive things to have to change later, so I want to be as close as I can possibly be to 100% sure that I won't end up in a situation where my projects have accessibility issues that I can't fix without changing the GUI toolkit.
From what I've read, JavaFX apparently has its own accessibility problems; for instance, I vaguely remember reading that if you used Alt+Tab to switch to or from a JavaFX window, JavaFX would automatically activate the menu bar. I've never used a real JavaFX-based app though.
As much as some of us might dislike it, I think the safest choice is Electron, or just making it a web app if that's an option.
Electron does have its downsides. On the upside, one nice thing about making screen reader support non-negotiable is that it took so many options off the table. So I was at no risk of analysis paralysis, and I don't have to worry about second-guessing my decision.
Neither have I; from what I can tell, the only place that JavaFX seems to have a foothold still is "intro to software engineering" classes in colleges.
That's not nothing. Blind students need to be able to participate in those classes.
They have done all that work to avoid problems in the lucrative market that is the US.
Microsoft has done similar work for the same reasons. Business reasons. Bottom line reasons.
People often forget there are humans on the other end developing things, not just faceless corporations.
People often forget that companies are not humans.
The point is it's not all mutually exclusive.
The companies are just as committed on principle as a real estate developer who puts in curb ramps to stay out of court.
That doesn’t mean the designer who drew the plans and the building inspector who approved them don’t care about the plight of the disabled. But the ramps are there because of the law not goodwill.
Its the same here - Apple had some legal obligations, but they didn't need to make their phones so insanely accessible to blind people. The situation is kind of absurd - the software on ios for blind people is so good that blind people prefer to use iphones (which are pure touch screen devices) over phones with keyboards. And they have since some of the very first iphones, back when there was real competition.
Desktop computers from a few years ago didn't do any of this. Screen reading software on windows used to be 3rd party software, and it sort of sucked. Apple could have made some APIs for that and forced someone else to make expensive, janky software for blind people. The law also has no problem forcing blind people to buy expensive electronic braille keyboards and things like that. (Which used to cost upwards of $3000.) Again, they could have done the same with the iphone - forcing blind people to type with $3000 external bluetooth braille keyboards. But they didn't do that. They built everything blind people need into the operating system. They made it work well.
Be cynical if you need to. I have no shortage of criticism for the way Apple handles the app store. But credit where its due - Apple has gone above and beyond to make accessibility for blind people great on the iphone. And I think accessibility on android isn't too far behind. The software on modern phones is a massive enabler for blind people the world over. It didn't happen by accident, and it wasn't written to pass the minimum bar set by the legal department. Real people poured love into modern smartphone accessibility, and it shows. They deserve credit and respect for their work.
https://www.reuters.com/article/us-usa-court-dominos-pizza/u...
[1] https://api.flutter.dev/flutter/widgets/Semantics-class.html