Why Don't We Version UIs? | Hacker News Reader

Why Don't We Version UIs?

10 pointsgruensk15 comments

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

View on HN

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

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.

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".

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.

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.

Def good point!

reddit wants to kill old reddit though. it already shows only for people logged in.

and with it, kill /r/all (they are killing /r/all for new reddit)

https://old.reddit.com/r/modnews/comments/1ujtebf/logging_in...

https://old.reddit.com/r/self/comments/1vqrs7h/old_reddits_e...

https://old.reddit.com/r/reddithelp/comments/1qvz91a/where_d...

https://old.reddit.com/r/OutOfTheLoop/comments/1to1wc9/what_...

Very true - but it was nice while it was still around!

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.

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.

I get why companies don’t do it. Keeping the old UI around sounds simple until every new feature has to support two different versions.

But man, some redesigns really do feel like change for the sake of change.

If the old thing worked and people liked it, maybe just leave it alone lol.

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é.

Reply on news.ycombinator.com