Live data from Hacker News

Users hate change

gist.github.com

81–90 of 315 posts

Re: Users hate change

#81
post #75

Earlier quoted context omitted.

That was feasible in a world where every computer was air-gapped because there was no such thing as the Internet. Now every app needs to stay up to date for security reasons, even if it doesn't directly use the internet itself.

What types of security vulnerabilities could apps like LibreOffice or Photoshop have?

Programs that manipulate binary files are common vectors for attacks. A malformed file can trick even well-written and well-tested parsers into executing code that they shouldn't, or corrupting aspects of the user's environment.

For example, cvedetails.com, some random website I found from Googling, lists 13 vulnerabilities for Photoshop and 31 for Libreoffice in the last few years.

Re: Users hate change

#82

Why not allow users to toggle btwn versions of software/UI/etc?

Because in many cases this is not possible. For example when Twitter added polls no other client than the default one was able to display them. If they kept some older version around they would not have feature parity. Then they introduced threads, these would look weird. Now imagine if they introduced nesting, the database model could change in a way that all older versions would require a substantial update. Maintaining an older version may very well mean maintaining two products and two synced versions of the database. Now you have doubled your engineering cost.

Re: Users hate change

#83
post #33

It's interesting to compare the user responses to updates by Facebook and Twitter respectively. Facebook's UI has changed significantly over the last 15 or so years. Features have appeared and disappeared, boxes have been arranged and rearranged. But there's rarely a big fuss beyond it getting a little slower each time (roughly commensurate with consumer hardware speedup, in fact). People don't really notice and they…

That's a great observation. I've had similar thoughts about Windows 8/10 changes and the reaction of their long term users. Incremental does seem to be the best way. People also tolerate dramatic changes well if there's an option to revert to the old ways.

Which is something Microsoft used to do well. Almost every big user-facing change, like the Aero desktop, could be reverted back to "Classic" if the user wanted. Or a feature considered obnoxious could be disabled. Either via the Control Panel, or via a group policy. It's difficult to hate a new feature or UI change if you can simply turn it off. But, with 8 and 10, they switched to a much more restrictive attitude and their reputation took a considerable hit.

This is something Apple is doing well with iOS. Obviously, 6->7 was a disruptive (and controversial) transition. But since then, their incremental approach seems to have worked very well.

Re: Users hate change

#84
post #75

Earlier quoted context omitted.

That was feasible in a world where every computer was air-gapped because there was no such thing as the Internet. Now every app needs to stay up to date for security reasons, even if it doesn't directly use the internet itself.

What types of security vulnerabilities could apps like LibreOffice or Photoshop have?

There have been plenty of attacks targeting image and document viewers/editors over the years. It's a great vector, because recipients are more likely to open a document than run an executable.

Some of the very "best" vulnerabilities of all time have been attacks taking advantage of scripting features in Office.

Re: Users hate change

#85
post #70

My pet theory is that every software product has a "peak version". Before that peak version, the product is not yet in a complete state, and it is fairly obvious, both for the developer and user, what features are missing. Once the peak version is reached, new features are not added because they improve the product, but to justify selling the product again to existing customers, and to 'keep the team busy'. Instead o…

Subscription model is actually way better if you don't want to end up with feature bloat. Because you actually get money from users even if you only ever fix bugs and improve performance. If you freeze your features you will soon arrive at a point where everybody who wanted your software bought it and then the revenue stops.

I think you are forgetting tech support. Depending on the product and the types of users you have, it can be time-consuming and quite expensive for the company.

The primary reason subscription model makes sense, and why many software shops are switching to it, is because you never want to find yourself in a situation where you have to generate new sales to afford supporting the existing customer-base.

Re: Users hate change

#86
I agree 100%. In my view every change you make to your software (that is not a bug fix) is just as likley to reduce the perceived value for your current customers as to increase it. Spread these changes over time and you segment the customer base across different states of pleased and unhappy. Naturally as the customer base denormalizes against any given state affinity you reduce the overall population's feelings about your app.

IMHO this is one of the hardest problems to solve with long lived applications. What changes can be made, what features can be added or changed and what "look and feel" changes can be made without tilting the affinity of the current users vs expanding the value proposition for new ones.

Re: Users hate change

#88
>when you have a product that works, and an existing customer base - freeze it. ... simply leave the product the way it is, bar minor BAU and bug-fix work. Instead devote effort into building a new, next-generation product ...

As a counterexample, Apple did this with Final Cut Pro and suffered years of criticism from customers for “abandoning” their installed base. Of course, being Apple, they didn’t seem to care. :) The new version eventually got to parity and beyond, but in the meantime people were seriously unhappy (and I’m sure many still are).

People don’t like change, and people also don’t like being abandoned.

Re: Users hate change

#89
post #70

Earlier quoted context omitted.

Subscription model is actually way better if you don't want to end up with feature bloat. Because you actually get money from users even if you only ever fix bugs and improve performance. If you freeze your features you will soon arrive at a point where everybody who wanted your software bought it and then the revenue stops.

Unless you have competitors and they offer (niche) features that you suddenly want as well.

Depending on how small the niche is you can sacrifice a small amount of users if they switch to keep the code simpler. Also it's not like the model prevents you from adding features. But it gives you more freedom to pick the ones that make the most sense to implement because you do not need to constantly chase new users.

Re: Users hate change

#90
Some corollaries:

Upgrading from v1 to v2 of your product is no different than migrating from your product to your competitor's product, except you probably have better compatibility. If your competitors offer good-enough compatibility, or you break backwards compatibility, even this advantage is lost.

Just as with data structures, we should build software itself as generally immutable. The successor to version X, in most cases, is version Y of something else. The exception seems to be filling out features. If your v1 is good but sparse, then adding missing features is an obvious win for users, too. That means, though, that you need to publish your roadmap. Customers can't plan around arbitrary releases and mystery features.

Post reply on HN