Much less frequent, somehow—to the point of being almost totally absent from my experience—are sentiments along the lines of “I prefer modern UIs, for the following specific reasons; they are superior to older UIs, which have the following specific flaws (which modern UIs lack)”.
I think maybe what’s going on is that people who are good at talking about what they like generally prefer older approaches? But if you run usability tests, focus groups, A/B tests, etc you see users do better with modern UIs.
But note that this objection essentially concedes the point: that the pressure toward “modernization” of UX design is a Molochian race to the bottom.
I do think there’s a coordination failure here, as there is in any signaling situation. I think it explains less of what’s going on than you do, and I also don’t think getting UX people to agree on a code of ethics that prohibited non-feature-driven UI changes would be useful. (I also can’t tell if that’s a proposal you’re still pushing.)
The amount of work is really not that much
I have a hard time believing that you are serious, here. I find this to be an absurd claim.
To be specific, I’m estimating that the amount of work required to build and maintain a simple and constant UI wrapper around a browser rendering engine is about one full time experienced engineer for two weeks to build and then 10% of their time (usually 0% but occasionally a lot of work when the underlying implementation changes) going forward. The interface between the engine and the UI is pretty clean. For example, have a look at Apple’s documentation for WebView:
A WebView object is intended to support most features you
would expect in a web browser except that it doesn’t implement
the specific user interface for those features. You are responsible
for implementing the user interface objects such as status bars,
toolbars, buttons, and text fields. For example, a WebView object
manages a back-forward list by default, and has goBack(_:) and
goForward(_:) action methods. It is your responsibility to create
the buttons that would send theses action messages.
The situation on Android is similar. Hundreds of apps, including many single-developer ones, use WebView to bring a web browser into their app, with the UI fully under their control.
in large part because of anti-competitive behavior and general shadiness on the part of Google
Not sure what you’re referring to here?
Once again, it is difficult for me to believe that you actually don’t know what I’m talking about—you would have to have spent the last five years, at the very least, not paying any attention to developments in web technologies.
I’ve been paying a lot of attention to this, since that’s been the core of what I’ve worked on since 2012: first on mod_pagespeed and now on GPT. When I look back at the last five years of web technology changes the main things I see (not exhaustive, just what I remember) are:
SPDY, QUIC, HTTP/2, HTTP/3, TLS 1.3 (and everything moved to HTTPS post-Snowden)
Most sites can develop only for evergreen browsers (no dealing with IE8 etc)
Service workers, web workers
WebAssembly
Browsers blocking identity in third-party contexts
I think maybe what’s going on is that people who are good at talking about what they like generally prefer older approaches? But if you run usability tests, focus groups, A/B tests, etc you see users do better with modern UIs.
I do think there’s a coordination failure here, as there is in any signaling situation. I think it explains less of what’s going on than you do, and I also don’t think getting UX people to agree on a code of ethics that prohibited non-feature-driven UI changes would be useful. (I also can’t tell if that’s a proposal you’re still pushing.)
To be specific, I’m estimating that the amount of work required to build and maintain a simple and constant UI wrapper around a browser rendering engine is about one full time experienced engineer for two weeks to build and then 10% of their time (usually 0% but occasionally a lot of work when the underlying implementation changes) going forward. The interface between the engine and the UI is pretty clean. For example, have a look at Apple’s documentation for WebView:
The situation on Android is similar. Hundreds of apps, including many single-developer ones, use
WebViewto bring a web browser into their app, with the UI fully under their control.I’ve been paying a lot of attention to this, since that’s been the core of what I’ve worked on since 2012: first on mod_pagespeed and now on GPT. When I look back at the last five years of web technology changes the main things I see (not exhaustive, just what I remember) are:
SPDY, QUIC, HTTP/2, HTTP/3, TLS 1.3 (and everything moved to HTTPS post-Snowden)
Most sites can develop only for evergreen browsers (no dealing with IE8 etc)
Service workers, web workers
WebAssembly
Browsers blocking identity in third-party contexts
JavaScript modernization: Promises/async/await etc
I’m still not sure what you’re referring to?
(As before: I work at Google, and am commenting only for myself.)