4 ms·

Front-end dev is optimising for a different set of constraints than HIG-era UIs. Primarily that constraint is "looks good in a presentation for an MBA with a 3

Front-end dev is optimising for a different set of constraints than HIG-era UIs. Primarily that constraint is "looks good in a presentation for an MBA with a 30-second attention span". Secondarily "new and hook-y enough to pull people in". That said... HIG UIs are good at what they're good at. But there is an element of a similar phenomenon to how walled-gardens (Facebook most of all, but also Google, Slack, Discord..) took over from open, standards-based protocols and clients. Their speed of integration and iteration gave them an evolutionary edge that the open-client world couldn't keep up with. Similarly if you look at e.g. navigation apps or recipe apps. Can an HIG UI do a fairly good job? Sure, and in ways that are predictable, accessible, intuitive and maybe even scriptable. But a scrolly, amorphous web-style UI will be able to do the job quicker and with more distinctive branding/style and less visual clutter. Basically I don't think a standardised child-of-HIG formalised UI/UX grammar could keep up with the pace of change the last 10-15 years. Probably the nearest we have is Material Design?

mckn1ght 2y ago
> walled-gardens (Facebook most of all, but also Google, Slack, Discord..) took over from open, standards-based protocols and clients. Their speed of integration and iteration gave them an evolutionary edge that the open-client world couldn't keep up with Seems to me to be a combination of things, none of which indicate that the new products are implicitly better than the old. The old products could’ve incorporated the best elements of the new. But there are a few problems with that: - legacy codebases are harder to change, it’s easier to just replace them, at least until the new system becomes legacy. slack and discord are now at the “helpful onboarding tooltip” stage - the tooling evolved: languages, debuggers, IDEs, design tools, collaboration tools and computers themselves all evolved in the time since those HIG UIs were originally released. That partially explains how rapidly the replacements could be built. and, true, there was time for the UX to sink in and think about what would be nice to add, like reactjis in chat - incentive structures: VCs throw tons of money at a competing idea in hopes that it pays off big by becoming the new standard. They can’t do that with either open source or an existing enterprise company
- Earw0rm 2y ago
  I'm not arguing that the new products are better, just that they were evolutionarily successful. I think the issue was less one of legacy codebases, and more that getting consensus on protocols and so on is _always_ slow and difficult, and that expands exponentially with complexity. And as the user-base expands, the median user's patience for that stuff drops. "What the hell is an SMTP Server and why should I care what my setting is" kind of stuff. Meanwhile the walled gardens can deliver a plug-and-play experience across authentication, identity, messaging, content, you name it. And this against a background of OS platforms (the original owners of HIGs) becoming less relevant vs Web2 property owners, and that strict content/presentation separation on the Web never really caught on (or rather, that JS single-pagers which violate those rules are cheaper and sexier). Plus a shift to mobile which has, despite Apple's efforts, never strictly enforced standards - to the extent that there's no real demand from users that apps should adhere to a particular set of rules.

mckn1ght 2y ago

> walled-gardens (Facebook most of all, but also Google, Slack, Discord..) took over from open, standards-based protocols and clients. Their speed of integration and iteration gave them an evolutionary edge that the open-client world couldn't keep up with Seems to me to be a combination of things, none of which indicate that the new products are implicitly better than the old. The old products could’ve incorporated the best elements of the new. But there are a few problems with that: - legacy codebases are harder to change, it’s easier to just replace them, at least until the new system becomes legacy. slack and discord are now at the “helpful onboarding tooltip” stage - the tooling evolved: languages, debuggers, IDEs, design tools, collaboration tools and computers themselves all evolved in the time since those HIG UIs were originally released. That partially explains how rapidly the replacements could be built. and, true, there was time for the UX to sink in and think about what would be nice to add, like reactjis in chat - incentive structures: VCs throw tons of money at a competing idea in hopes that it pays off big by becoming the new standard. They can’t do that with either open source or an existing enterprise company

Earw0rm 2y ago
I'm not arguing that the new products are better, just that they were evolutionarily successful. I think the issue was less one of legacy codebases, and more that getting consensus on protocols and so on is _always_ slow and difficult, and that expands exponentially with complexity. And as the user-base expands, the median user's patience for that stuff drops. "What the hell is an SMTP Server and why should I care what my setting is" kind of stuff. Meanwhile the walled gardens can deliver a plug-and-play experience across authentication, identity, messaging, content, you name it. And this against a background of OS platforms (the original owners of HIGs) becoming less relevant vs Web2 property owners, and that strict content/presentation separation on the Web never really caught on (or rather, that JS single-pagers which violate those rules are cheaper and sexier). Plus a shift to mobile which has, despite Apple's efforts, never strictly enforced standards - to the extent that there's no real demand from users that apps should adhere to a particular set of rules.