3 ms·

> Just use the platform like it was intended to be used. You're not special. You're not smarter. If you assume that they are not less smart than the average en

> Just use the platform like it was intended to be used. You're not special. You're not smarter. 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.

K0nserv 5y ago
Or they have evaluated their potential solutions without understanding the choice they are making. For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't). 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.
- jackcviers3 5y ago
  This is the answer. This is always what happens. You use the fastest thing that will get the feature done or the bug fixed. To do that, you choose the components that provide the things you need to match your task's requirements. If the requirements don't list accessibility, then you do not care. Your job isn't design, it's implementation. The senior people are supposed to think of that stuff. You have enough work just keeping up with all the things you have to do at that scale. 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.
- sangnoir 5y ago
  > For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't). 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.
superjan 5y ago
Engineers like it when everything works the same. It is also easier for product marketing: the new features will be available everywhere, and they’ll work the same. Less to document and keep in your head. 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.
- jackcviers3 5y ago
  Also, the organization is ceding control to an other when they don't use their own stuff. That doesn't sit well when the needs of the other gets in the way of profits.
vlunkr 5y ago
I assume most of the time it's the higher-ups deciding these things, not the engineers. The boss decides they doesn't like something about the native UI and asks the team to build something new, without understanding the deeper implications.

K0nserv 5y ago

Or they have evaluated their potential solutions without understanding the choice they are making. For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't). 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.

jackcviers3 5y ago
This is the answer. This is always what happens. You use the fastest thing that will get the feature done or the bug fixed. To do that, you choose the components that provide the things you need to match your task's requirements. If the requirements don't list accessibility, then you do not care. Your job isn't design, it's implementation. The senior people are supposed to think of that stuff. You have enough work just keeping up with all the things you have to do at that scale. 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.
sangnoir 5y ago
> For example, they have only considered how something looks, not how it works(for both people using accessibility tech and those who don't). 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.

superjan 5y ago

Engineers like it when everything works the same. It is also easier for product marketing: the new features will be available everywhere, and they’ll work the same. Less to document and keep in your head. 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.

jackcviers3 5y ago
Also, the organization is ceding control to an other when they don't use their own stuff. That doesn't sit well when the needs of the other gets in the way of profits.

vlunkr 5y ago

I assume most of the time it's the higher-ups deciding these things, not the engineers. The boss decides they doesn't like something about the native UI and asks the team to build something new, without understanding the deeper implications.