Why Don't We Version UIs?

1 points by gruensk ↗ HN
Maybe this is just an old man yells at clouds thought, but as was just hitting my daily aggravation of some "broken new UI" and just had this thought. Why don't we version UIs?

As far as I can remember, I don't think I've run into any site or app that let's you shift UI versions. APIs tend to keep versions around. Apps keep many versions around for much longer periods of time. This could also allow for real long-term testing of UIs and features.

I get that things change, etc. But I feel the general consensus from people around me, despite their age, is frustration towards these endless changes. I'm not here thinking somehow business will start being better, but maybe this would at least be a more rational way to handle UI changes (and avoid adding more frustration into the world)?

14 comments

[ 16.4 ms ] story [ 551 ms ] thread
You can if you want, it is a choice, especially if it is a consumer of a versioned API, just like you would version a mobile client.
Yea exactly its a choice I don’t see exercised
One counter-example is Reddit's old.reddit.com interface, compared to their new one.
Very true - but it was nice while it was still around!
I have seen some older Software/SAAS UIs displaying version numbers. But letting you switch may not make sense because usually a change happens both in backend and frontend and switching versions is not something vendors want to offer due to the complexity of switching required.
We've been versioning UIs since 2015, after dealing with a bunch of weird bug reports that we tracked down to people keeping tabs open for months. Needs careful backend planning and backwards compatible data handling, but it's a solvable technical issue. API calls from the front-end can send the active version with calls, letting the backend understand that something older is calling and do version upgrades of envelopes and payloads, and the front-end needs to be designed to ignore extra fields, but all of that is testable, and once things are in place they give you both the protection against weird inconsistency bugs, ability to experiment (running a/b versions in parallel) and detailed monitoring to troubleshoot weird issues.

It's quite sobering to look at the list of active versions and see a long tail of what's actually connecting to our backend.

Yea I’m sure it increases complexity in the backend unless the backend has mandated connection points not allowed to be changed. I wonder if an AI api endpoint would make this easier if it could intelligently route or translate btwn versions reliably
[dead]
They can't leave it alone. People at organisations change, and new people always want to put their own stamp on things. "Made some incremental improvements" doesn't look good on the resumé.
When there are big changes, I’ve seen a lot of sites, and even some applications, allow users to opt-in to the new version to try it out, or opt-out of the new version and return to the old one if it isn’t meeting their needs or they have a deadline and need their old workflow to meet it.

Reddit and Outlook are the two examples that come to the front of my mind, but I’ve seen many more. Even my power company did it.

This however is only for big changes, and usually just a toggle old|new, not fully versioned where a user can go back to any point in history. I would guess that would turn into a nightmare for maintenance, and unlike APIs, there is rarely code that is UI dependent… at least we hope not.

Most websites use undocumented RESTful APIs that are tightly bound to their current UI.

Versioning UIs means versioning their undocumented backend APIs as well. I did see some websites provide a button to "switch back to old version", but it's usually just a transition period to reduce friction.

So I think the answer would be "it iterates faster than we could version it".