Why Don't We Version UIs?

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)?

7 points | by gruensk 20 hours ago

7 comments

gojkoa 19 hours ago
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.
[-]
- gruensk 18 hours ago
  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
  [-]
  - gojkoa 18 hours ago
    in theory yes, but in practice if each deploy is a version (and for us it is), with multiple deployments per day this becomes unsustainable to track. we settled on the backend always being "current" but supporting multiple front-end versions using the version parameter of the API calls.
codegeek 19 hours ago
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.
al_borland 9 hours ago
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.
pavel_lishin 19 hours ago
One counter-example is Reddit's old.reddit.com interface, compared to their new one.
[-]
- gruensk 18 hours ago
  Def good point!
brudgers 7 hours ago
For me, avoiding the upgrade treadmill is a reliable way of maintaining stable interfaces (and workflows).
Of course that lunch isn’t free.
Good luck.
toomuchtodo 19 hours ago
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.
[-]
- gruensk 18 hours ago
  Yea exactly its a choice I don’t see exercised
just60sec 14 hours ago
[dead]