Slashdot Mirror
Ask Slashdot: How Do You Explain 'Don't Improve My Software Syndrome' Or DIMSS?
dryriver writes: I am someone who likes to post improvement suggestions for different software tools I use on the internet. If I see a function in a software that doesn't work well for me or could work better for everyone else, I immediately post suggestions as to how that function could be improved and made to work better for everybody. A striking phenomenon I have come across in posting such suggestions is the sheer number of "why would you want that at all" or "nobody needs that" or "the software is fine as it is" type responses from software users. What is particularly puzzling is that its not the developers of the software rejecting the suggestions -- its users of the software that often react sourly to improvement suggestions that could, if implemented well, benefit a lot of people using the software in question. I have observed this happening online for years even for really good software feature/function improvement ideas that actually wound up being implemented. My question is -- what causes this behavior of software users on the internet? Why would a software user see a suggestion that would very likely benefit many other users of the software and object loudly to that suggestion, or even pretend that "the suggestion is a bad one?"
You are just offering suggestions. Back it up with some actual fucking code. Otherwise you are simply one of the moaning masses wanting shit (usually for free).
if you don't code yourself, then you probably don't have any idea how much time and effort is required to implement your 'improvements', and/or perhaps your suggestions really aren't very good to start with, therefore annoying the dev, who spend perhaps months or years creating his end product, only to have some random guy from the Internets post 'suggestions' that come off as criticism.
Every single one of you dumb mother fuckers just break shit when you "improve" things.
You are most likely suggesting something that will increase the complexity of the project.
So that explains some of the resistance. However, I'd also bet that at least some of the resistance is from "This works fine for me right now. If you touch it, you will F it up. So don't touch it."
A great many programs have become sluggish pieces of bloatware due to well-intentioned feature creep.
One of two very very scenarios arises in my mind:
1) The person(s) does not want the software to change at all because they are comfortable with how it works. This is seen all the time when companies are pushing upgrades to a new version of Windows or Office or *insert a different product*
2) Your suggestions are really not all that useful and are rightfully be lambasted
Change is bad, unless it's great.
Maybe it's because your ideas are bad, and you should feel bad?
But seriously, I've seen that behaviour too, it's really strange. I could understand it if they knew that the suggested feature would actually have a negative impact on them, but most the time it seems to be a misplaced sense of loyalty to the vendor.
Sometimes what is an improvement to you is worsening for someone else. E.g. the australis redesign of firefox, was very highly disliked by many people. Some people are happy with the status quo and don't need a new "modern" re-do of their GUI or whatever.
Feature creep is a common problem with software projects. You eventually learn to resist it as a developer, and to fight it as a user.
If you didn't write crap like "a software" people might take you & your ideas more seriously.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
What I think may be an improvement may look to someone else to be a bad thing.
Don't step on the baby.
Many people are very tired of their software constantly changing and shifting for no good reason. Oblig car analogy: suppose that every night when you get home, park your car and go inside there was a good chance some random mechanic would come along and start tinkering - moving the controls around, swapping out the seats, adding go-fast stripes (then removing them), maybe switching the engine or making it an automatic. It would get old really, really quickly.
That's what it feels like sometimes with software. See for example Firefox over the last few years: features coming and going for no apparent reasoning, random changes, just generally irritating. It's enough to give you a case of PSSWIS.
I remember a user study a former employer did about a decade ago. They were looking at improving a system that had been out and well used for quite a while. At one user site, they (with permission) went to record existing users as they used the system.
At one point they moved the user's printer about 8 inches to make room for the camera. This guy's productivity was completely thrown off for the rest of the day as a result of that change in his setup.
People learn how to deal with the systems they have, and generally don't want to change once they do. Better the devil you know than the devil you don't.
Any yes, this is incredibly frustrating when you can see a deficiency clearly and just want to do the right thing and fix it.
The helpdesk closes the issue as "User error".
The engineer closes the issue as "Showed documentation".
The senior engineer opens an "Usability issue".
bash$
In good faith people can ask why you would want such a change, I don't see how that is being negative.
Nullius in verba
Users like their software to work. Most software only barely does, and every upgrade risks catastrophic regressions sold as "improvement".
As a current example, any website you use regularly might see an "upgrade"* causing it to no longer work with your browser, so you get to upgrade. Then you find your browser is no longer supported on your operating system, forcing you to apply lots of patches, or outright upgrade. Or both. Perhaps you now must use a 64bit version and since your hardware wasn't 64bit yet, you need to up grade the hardware. So simply trying to use a website that used to work peachy fine can easily cause you a week's work or more, and that's when you're tech savvy enough to do it all yourself.
Yes, you and plenty readers here will likely run cutting-edge systems. Random users, a much larger pool, probably will not. We tend to blame them for running "insecure" software, but really, the blame for the insecurity of the software squarely lies with the developers. Who choose to chase new features instead.
Honestly, it's the latter group, the people that prefer all that fancy tech to "just work", that is currently sorely underserved. Even by the big software vendors, perhaps especially by the big software vendors, that have "no training needed" and "it will just work" as the core of their marketeering.
* Perhaps not even in the website itself, but one of the many javascript libraries from elsewhere it depends upon! But likewise we saw several rounds of this with the "upgrade" to "HTML5", where even sites offering content no more fancy than text and some pictures suddenly stop working in older browsers for no other reason than that they like to chase what they imagine counts for modernity.
Because every change breaks someone's workflow. https://xkcd.com/1172/
Also, people are jackasses and ruin everything. It is easier to analyze software than people. Live and let live.
People hate useless change. People hate change that makes their lives harder. People hate "here's a new UI, take time off from the work you need to get done in order to learn it".
Version 1 - "Cool"
Version 2 - "WTF? Why are you doing this? I loved version 1! I'm going to Orkut!"
Version 3 - "WTF? Why are you doing this? I loved version 2! I'm going to MySpace!"
Version 4 - "WTF? Why are you doing this? I loved version 3! I'm going to Ebo!" (or whatever that black & white social network was called)
Etc..
Drill baby drill - on Mars
In the dev world, everything has a cost.
If you change an existing feature, it always takes getting used to. Often, there are extra actions required and/or configuration added.
If you added a button, you subtract elegance and clutter. Hide it behind menus and you just added an extra click for everyone. These things matter. Maybe not to you, but to some people it certainly does. I know I get mad every time something I used to do with a hover & click (say, 1 second) gets changed to click-move-click (1.2 seconds) - I learned be proficient and efficient with my tools, and changing it will (1.) render my time useless which isn't too bad, but will also (2.) require me to re-learn and sometimes even (3.) make the previous level of efficiency impossible. I'm using UI examples for their clear-cut nature, but this holds for a variety of areas.
In my 40 years of using software I have only very rarely noticed that an upgrade actually improves software. Usually, it is slower, and harder to use. No thanks!
"Fuck new shit" is perfectly rational. When features start to creep, the idea that a redesign will follow that fucks up your old workflow is a very real concern.
I find that Many code writers think their novel spin on things that work that way with every other program is the New Best Idea ever.
Window Programs with one of a kind novel interfaces that can be learn with out taking a class. Frameworks that just keep coming, then going.
Thread full of asking for a feature, with puzzled responses from its programmer.
Old Bugs that are never fixed, features removed without notice.
I think software is regressing, not advancing.
And about 30% of them are auto-updating with random "changes" that probably started out as one of your suggestions, but
BREAK MY WORKFLOW.
Stop breaking my workflow with your (skin changes, whack a mole GUI action area changes, changing all the menus into wizards, changing all the wizards into menus, ..., never mind all the extra opportunities for popup ads and other monetization schemes).
Make a new program if you want to, sure. Keep the old one, please. Let me do my own analysis of inefficiencies in my own work flow, and upgrade when it makes since for me.
There is not one true best, because we do not share the same value function. This starts with such basic things as language, visual acuity, finger size and dexterity, and end with my entire history of interaction with computers and software.
But sure, the idea you expressed after spending significant minutes of your time investigating a particular use case gets to trump all that.
PS - get off my lawn.
But its true, so I'm going to lay it on you.
Most people do not use software for the sake of using software.
I Know. I can hear you cry and see your tears. Get over it.
Strange as it seems, they use software to get stuff done. Its a tool. They learn the tool to get stuff done. They setup up processes that incorporate the use of those tools to get even more stuff done. And then *poof*... iPhones! Woo!
If you're constantly changing the tool, you're constantly changing the way people have to get their stuff done and constantly upsetting the process and increasing the cost of getting stuff done.
Try this for a mantra:
What do we Want?
Gradual Change!
When do we want it?
IN DUE COURSE!
Change is good, I'm on board. But take care how you fuck things up in the name of progress. Understand that yes, in some peoples view your wonderful improvement is fucking things up, and they are not in error . That doesn't mean your idea isn't great, it just means you probably haven't thought it through well enough. That said...
Usually people tossing out these ideas have little idea what they're talking about, with respect to what it would take to achieve.
OK, this is turning into recreational bitching (turning into?).
I have two shorter answers to this question, one polite, one less so
When you decide to express your personal brilliance to the developer, take the time to word it in such a way that it doesn't come across as condescending or undermining. Not to say that developers are all precious snow-flakes, but if the feature request is important to you then learning how to present it goes a long way towards gaining an outcome that you like, as with pretty much every other area in life when it comes to trying to get something done by other people.
Beautiful pitches like "...unless it has feature X it's not going to be considered professional", or "... I like your software but it would be better if ..." and you wonder why there's so much push-back. If you don't see what's wrong with statements like that are a problem, then it might be helpful to try think about it a bit more.
Of course, if you can't stand that, you can always try add the feature yourself, though saying "do it yourself" pretty much causes the same level of angst in the other direction.
I have four program managers (they manage the "program," not the program managers might be called product managers at other places), and I don't think in my six years here I've ever seen them take a suggestion from either developers or customers. They all think they know better.
Why would you even ask a question like that?
I don't know if you've been keeping an eye on things, but generally "improvements" aren't.
Examples:
There is a reason why User Experience (UX) people are so hated - because they take a nice, big, fat dump on existing users to improve things the way that THEY want, and, again, tough shit if you liked it the other way, and tough shit if it breaks the software for many users, or even if it breaks the machine. It's not unlike an interior decorator trying to make a "statement" in many cases. Not unlike one of those shows where they have someone come in and "redecorate" the house and it turns out to be a total nightmare. This is not helped by the fact that with many situations, updates are now FORCED, so you can't throw the interior decorator out. In many cases, companies and organizations act as if you don't own the computer (and in many cases, the companies want to own the computer you paid for, and they treat the software like they do in fact own the machine). And even if you do, they usually manage to cripple you in some way (usually compatibility) until you're forced to capitulate - and things are usually even worse by then.
Note, however, that this does NOT necessarily just apply to the UI, in case I've overemphasized that - it works with any and every aspect of the software that can be changed. In short, in
Simple enough. If something is working well enough for my purposes, then I'll tend to resist change. Actually, going beyond that, if it's working perfectly, then any change is going to make it worse. Doesn't matter that nothing is perfect if I think it is, or perhaps if I have adapted my purposes to fit with what the software is perfect for. (Or perhaps the real problem is that "perfect" is mostly a matter of opinion and the delusion is that there is a better solution for everyone.)
Solution: Don't fix it unless you can convince enough people to pay for the fix. In project form, describe EXACTLY what is going to be done and what success will look like.
Yeah, it's the old charity share brokerage idea again. Can you imagine a funding system so powerful that it could fix Slashdot? Me neither.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
Someone thought they had a better way starting with Windows 8 through 10 with the UI. I was soundly in the "DON'T TOUCH IT" camp for this crap UI show.
The reason for the syndrome that you describe is that people are broken, and need to make themselves feel powerful and important (and oh so cool) by being negative just about towards everything. This has been going on for years, and has just gotten worse and worse. It's become a reflex.
For decades now, programmers and PHBs have been forcing changes on users that were unreliable, that broke the entire workflow, that broke the software, that added counter-intuitive methods, that removed features they were used to using or merged into features they weren't using or didn't want or ask for, ad infinitum.
All this has trained people to hate UI and workflow changes. That and also trained that the majority of changes made to functions and UI are made by people who either do not use the program, only listen to a specific subset of users of the software, or only made for a specific niche of the software's full market that it was supposedly designed for in the first place but it turned out to be useful to many other fields.
You got problems though mate. They aren't "pretending" your suggestion is a bad one. They are certain it is. And honestly, they're probably right. While that one change might fit your needs perfectly, everyone else may find it cumbersome and useless at best, or downright terrible and workflow-breaking. While yes, your idea might actually make things better for *some* users, its never gonna work for everyone. And the ones it negatively effects are going to be the ones to speak up. Its just human nature, if something benefits you, you tend not to jump up and start shouting for joy, you just accept it and move on, but if it hurts you somehow, oh you better bet they are lighting torches and pitchforks.
The cure for laziness is "paying enough money". Likewise, "not a good idea unless it is theirs" is curable by "paying enough money".
First, I'm not your product validation engineer. Don't ship be a load of horse shit software and then expect me to test it for free, give you feedback, and then put up with daily version pushes. Fuck you for that.
Second, once I get something working, I'm terrified that your next bullshit unwanted "feature" update is going to break things, because 99.9% of the time, it does. Why? Because you don't test your shit before you ship it, because you think my reason for existing is to be your free product test engineer. Fuck you for that, too.
time is money. Anyone can divest the interests of another. Every contribution is a multidimensional Fibonacci Fork of TimeCube Gtfo my front lawn!
You are an idiot. If you weren't you could try to do it yourself.
You will break my workflow and turn a passable tool into a piece of useless junk.
You have no concern for others, and an overly inflated opinion of yourself.
You are an idiot.
When I was a younger programmer, I thought, "Features are great! Always add a feature, if it could help someone!" I overestimated the value of the feature, and didn't think at all about the costs of the feature. "I mean, how long does it take to implement this? 10 minutes? A couple days? What's that matter, vs. the utility that this would provide?"
What I didn't realize at the time was that every feature basically adds an exponential cost, and has an impact on everything else going on in the codebase. Features introduce new possibilities, and new possibilities create new state combinations, and new state combinations create new bugs and new need-to-test circumstances. New features usually have a user interface impact, several new features have a dramatic user interface impact. New features need to be supported by new or future-self programmers, who have to understand and navigate around the code. If the product is ported, the feature needs to be ported as well. New features also require additional documentation, and if the product is localized the new documentation requires new localizations.
I've heard that "the skilled Go player is reluctant to make a move." I think it's similar for the application developer, and for much the same reason.
Applied to every concept of programming. Just fork it!
Everyone (Many people) are suffering from some kind of version fatigue. It's as simple as that. Owning any software run device these days is like having someone come and and re-arrange all the furniture in your house every week. The novelty might seem nice at first, but after a while, any change that you don't specifically want becomes irritating.
.... or is this an attempt at humor/sarcasm/trolling/other? If you see a problem report it. The devs will look into it & keep on chugging.
If you were fixing someone's problematic code, then kudos for contributing. But you come across as a management "idea" person. Shudder
"Hey, I think it would be really cool if you embedded vi in your video player. That way I could edit the files in hex on the fly!! Just have it switch to vi when you right-click on play!"
There's about 5 people who would actually want that feature. There are an enormous number of people who will accidentally right-click on the play button and have no idea what is going on, leading to a massive decrease in usability in order to gain that feature.
Is it me, or is the most obvious answer going over this guys head.. I'm pretty sure the most likely reason that people ask why they would want a certain feature is that they don't actually see the use for a certain feature. So what he is really asking is, "why don't people want the features I do?". This is why gathering requirements for software is actually a job in itself and requiring of skills. If this person has absolute confidence that their ideas are good they need to put work behind it, learn to develop, make alternative product 'B' and win the market away from product 'A'.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
My best guess is that most of the people don't like your ideas because they don't think your suggestions would improve the product, not any innate refusal to change.
Think about how many times one of your favorite apps has changed its interface in a way you thought sucked. Do you really think the designers said, "Hey, we've got a great interface, let's make it worse?" No, just like you, they thought their changes would improve it, but they didn't.
A favorite example was when Google removed the Pegman from Maps, making using Streetview almost impossible.
The answer why so many negative comments are posted is that MOST people want to put everyone down. It is their way of feeling important Since they don't have the intellect to understand the issue they can only attack the postings. Those who do have insight will comment either positively or with specific reasons of why the idea should or should not be done.
This is the sickness that the world faces with anonymous posting. Even this posting will have someone pooh pooh it thinking that they are so 'funny', but they are just confirming their ignorance.
... the sheer number of "why would you want that at all" or "nobody needs that" or "the software is fine as it is" type responses from software users. What is particularly puzzling is that its not the developers of the software rejecting the suggestions -- its users of the software ...
You've answered your own question. To mix a few metaphors:
One of the things about software is that a LOT of people stand on the shoulders of each giant - by being users of his code. A change that isn't a straight augmentation (and even some that are intended to be) can shift the sand under their castles and bring them crashing down.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Rather than "immediately post suggestions", perhaps a slower & more deliberate approach would be better?
Or maybe you're convinced you really do know best, perhaps even reject this comment as merely the uninformed suggestion of someone not fully familiar with the specifics of your suggestions made to open source software projects?
PJRC: Electronic Projects, 8051 Microcontroller Tools
Consider seriously the real possibility that you are dumber than your users and that your ideas deserve more scorn than they have actually received.
Which doesn't help when the app is proprietary, and its developer responds to "actual fucking code" with an actual fucking lawsuit alleging infringement of copyright. See, for example, The Tetris Company with clones and Nintendo with Pokemon and Metroid mods.
Obviously not a coder.
I can definitely understand that sort of reaction for developers, especially if you're talking about small open source projects... those are projects which usually scratch the itch of the developer, so feature requests are definitely going to be an uphill battle if they aren't interesting to the developer (for some definition of "interesting" which might mean "actually useful", "fun to code/play with", "that code is shit and needs refactoring anyways", "suggestion in the form of a patch/pull request", etc).
I think users see software development effort as zero sum; if someone is working on a feature they aren't interested in, then someone isn't working on other stuff they think is important. It's a well-known phenomenon that often comes up when someone talks about the complexity of Microsoft Excel (in the form of the 90-10 rule)... users don't see the bigger picture and only care about their own workflow and how changes impact them.
The easy solution is to simply not give a crap about the opinions of other users of whatever software you use. They don't have your best interests in mind either.
Log in or piss off.
Seriously... you might just be one of those sorts of folks that has really terrible ideas...
That or English is a second language to the asker because the asker happens to have been born outside the territory of the Five Eyes.
Am I the only one who wants to see examples of these unquestionable improvements that must be agreed to?
Small application
1. Your suggestion isn't something they want, just because you think its good doesn't mean it is;
2. They don't really understand the suggestion and don't want to put in whatever effort is necessary to understand.
Big Application
1. Its reached critical mass, for every change made 1.X bugs are created, everyone is afraid to touch it. ...
2. They've had so much hassle with making changes in the past they just want the thing to stay stable for a couple of days/weeks/months/forever
3. No body wants to admit some or all of the source is missing.
4. The bureaucracy for getting changes approved is so painful nobody wants to accept any changes.
A range of conflicting forces offset each other to produce the software you see.
Developers wanted to use new technologies.
Architects had a vision.
Designers wanted a look.
The customer wanted it fast.
QA wanted it correct.
Ops wanted it deploy-able.
Changing the software would mean all those opposing forces would have to re-balance, possibly destroying the entire application.
stop walking around the building site telling everyone where to put stuff.
A range of conflicting forces offset each other to produce the software you see.
Developers wanted to use new technologies.
Architects had a vision.
Designers wanted a look.
The customer wanted it fast.
QA wanted it correct.
Ops wanted it deploy-able.
Changing the software would mean all those opposing forces would have to re-balance, possibly destroying the entire application
'pretend that the suggestion is bad' - do you listen to yourself? If you can't conceive that your suggestion may BE bad, then the problem is almost certainly you. Either in the way you approach things, or that your suggestions ARE bad.
Some hints:
You are not the only smart person on the internet. Statistically, you probably aren't any nearer the smartest than I am.
If you've been using a package for a couple of weeks you might have some suggestions. If you act like you can't possibly be wrong, then your attitude alone will make the old timers ignore you.
Perfectionism is the enemy of actually getting shit done. Small improvements that make me re-learn how to do things are a big time suck in the near term. You know, when I have to get shit done. Even if the change is long-term beneficial, the amount of time lost right now is probably not worth it.
Asking questions generally gets a far better response than 'you should change this!' comments. Asking why it's done like X instead of Y indicates a willingness to understand. And frankly in many cases there is (or was) some good reason that things were done a given way. Asking questions can get to the bottom of that, and in some cases make it easy to show that it should be changed (because the original reason is gone).
Code talks, bullshit walks. If it's open source and you don't like how it works, submit a change set. It may still get rejected, but no one will question your willingness to make things better. Just your judgement about what 'better' might mean.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
I have product "X". It works; most of the time. Mega Corporation has done everything they can to make it so I can't report problems, and all I can do is bitch about the problems on public forums and have people agree - the software has it's problems.
... without fixing any of the KNOWN issues, you want me to use and adapt Mega Corporation's next release "Y". I take a looks at it; and they have 'made it easier' ...( they have not); they have added features that I will NEVER use; frequently remove features that I do use, and to make it worse they have not fixed the bugs that I've seen, and later I read about new bugs in Mega Corporation's products (not to mention security issues).
... without fixes to old problems.
Now
And when this is scaled down from Mega Corporation to Mini Corporation; they are doing everything they can to just get by. New major features
It would be amusing is Mega Corporation actually released a "next version" that was nothing but bug fixes.
This is why I stick with old software, and "Do Not" upgrade {improve} my "old" Software.
people hate change. this is seriously one of the dumbest questions ever repeatedly asked.
I think you have your answer right there.
“He’s not deformed, he’s just drunk!”
One of the most notorious: uTorrent
This could easily be likened to things like Systemd and Pulseaudio. Both are really great. But not if they get in the way by aiming for only a select audience use needs. There are some that just like what they already know. Some just complain because someone else did. But some changes force a direction that can't be see, as a limitation, by those that like the change. They can't see why anyone would want to do it any different. In some cases you can change some compile flags and adjust applications to your needs. In other cases, you get unwanted bloat, or you have to work around an improvement that works against your use case. Just because it makes sense to you, and gets implemented, doesn't mean that you have made it better for everyone. Some innovations make things easier for people that are not as experienced. The end result can be narrowing the innovations of the experienced. Expression could be used as an example here as well. Not everyone can make out what is being expressed in a philosophical discourse. If you change the language to reach a larger audience, you'll possibly lose depth and potency. The "command line interface vs graphical user interface" is another good example. You can be fishing around clicking your way through someones idea of an intuitive graphical work flow; or pipe a few commands together that do exactly what you need. Both are different versions of simplicity. Users of either side may find the opposing alternative way annoying.
> maybe his suggestions are crap
Maybe his ideas are crap. There is no way to tell since he didn't give / link even one specfic example.
Maybe the way he presents his ideas is a problem. A very common problem os suggesting WHAT might be done, without mentioning WHY. You always need the why, and should lead with it. Think commercials "do you have this problem ... Our product will fix that problem for you. You'll benefit in three ways, X Y and Z." Often people suggest "let's do this" without clearly stating the problem it'll solve or the benefits of their suggestion. There is no way to tell if tje submitter does this since he didn't give / link even one specfic example.
What we DO know is something about the submitter's writing style. We know he *assumes* that his ideas should be implemented, and further assumes that we'll agree - without even telling us what any of his ideas are. Likely, he does the same thing in his suggestions - assumes that they should be done, assumes that everyone will agree that they should be done, and fails to provide even one example of what he's talking about.
Everybody thinks he's good at defining features and UI. "Look at this thing! It exactly matches the mental model I have! It's genius!"
Well, duh, making something that the inventor understands and likes is easy. It's making a thing that makes sense to everyone else that's the trick.
-Dave
??? I thought a speeding train has a lot of inertia and not much static friction. I don't see how the two are conflated.
Glad I looked see if anyone else caught that before I posted it myself! My parents are the same way, they don't trust anyone to do the job right, so if its mostly working leave it alone. No one wants to learn a new interface, or risk the down time. Some people are constantly fixing up their houses, others want to live in it as happily as they can before they are forced to do the next project.
Gnome2 -> Gnome3
Windows XP -> Vista
Windows7 -> 8/10
the ribbon in M$ Office
Every update of iTunes
Half the updates of Firefox
Speaking as a mere user, we're just sick of things we're told are better but that just put us back to having to learn stuff instead of getting on with our jobs. It's a cost/benefit thing. I know there are often 'under the hood' benefits, but what I see is an interface and the functions it provides. If the benefit is not real and immediate, it won't help me hit a deadline that is real and immediate and expensive if I miss it. A technical advance may not be a (readily apparent) productivity advance, and in the end it's productivity and security that I want.
Most changes requests that I see are phrased as:
This has two problems. First, it doesn't tell the developer why you want the change, and second, it is telling them that they are wrong.
I find that developers are far more receptive if you state your goals, and ask a question. Let them help you. Let them be in charge. For example:
I'm trying to do X, and I'm finding Y awkward. Is there some way we can make this easier? Maybe Z?
When you arrive to some forum and post a suggestion, you are in competition with other people who use the software and might not want to divert developer attention away from bugs or improvements already slated. Another probable reason is competition between suggestions by users vying for developer time. These people shooting down your ideas probably made some other suggestions and had them shot down by other users, or alternatively have some suggestions still pending, so they view your suggestion as a threat.
There could be technical reasons why your suggestion shouldn't be implemented and users may instinctively know this because they are often experts on that particular piece of software as they use it daily.
However, as a developer myself, I can assure you that I always dig deeper to determine if the users have valid feedback or if their feedback is only playing politics.
Good ideas always influence me, even if they are imperfect ideas and would need some adjusting to become viable.
The dangers of knowledge trigger emotional distress in human beings.
Software upgrades are often don't care about the existing userbase.
Time getting into a grove is actually pretty damn expensive..
\ And losing the grove because someone thinks "showing a bunch of file previews isn't that much of a slowdown, barely fifteen seconds" can really upset users who open that thing a thirty times a day --mostly with muscle memory--.
Just because you think it's an improvement doesn't make it so.
what makes you think your suggestions are better .. ?
typical couch reviewer .. write your own software and release it .. if its worth getting, people will switch to it .. simple ..
the arrogance of believing you're come up with some idea that is better than the creators .. without having done any real market research, usability study of the actual user base and haven't actually written anything .. shows what a waste of time even reading your suggestions would be to the developers ..
ugh .. now this was a waste of my time ..
"I am someone who likes to post improvement suggestions for different software tools I use on the internet."
TRANSLATON:
"I am someone who likes to post his half-baked ideas about how your software just needs feature X that I personally think would be SUPER DUPER MEGA COOL even though it's not really useful and would require YOU to code all sorts of shit for ME at my whim."
"Nice text editor, but why doesn't it include a window with NASA's live weather feed for Mars?? If you could just implement that, it would be AWESOME!1!!
Just cruising through this digital world at 33 1/3 rpm...
Or rather do, but don't force me to buy a powered screw remover that needs charging after 20 minutes of use and can only be controlled via bluetooth from an iPhone. Old versions of software should be at least sold it is indefinitely, or placed in public domain if the maker no longer sees a profit from a particular version when the new one is available. It would not be crazy to provide security patches and basic usability updates so long as that is economically viable.
What is actually happening today is worse. A lot of times it is not possible to reinstall or even use an existing install of a software version you paid for, when the new version has removed functionality that was your reason for buying the product.
Constant volatility has in turn devalued software. If I am sure that a particular application will consistently serve my regular needs for 10 years like a screwdriver does, an $1000 investment does not seem crazy. But if your company could go out of business tomorrow and I will be left out in the cold, how can I justify spending anything at all?
Having read your little screed, you struck me as being incredibly pompous, thinking your ideas are "right" and everyone else is "wrong".
Like your pretending your suggestions are good ones?
Both should only be done when absolutely necessary.
Both come with significant risk and a significant cost to the end-user/patient. Unless there is a dire need for each - do not do them.
If your idea is so much better than the status quo - it should be a separate and optional release, or a new product entirely.
The mantra in software seems to be "fix it until it's broken".
I doubt that you and I use the software in the same way. Your use case and mine are not the same. It is at least 50-50 that your "improvement" will break my use case (or make it more difficult). I did, after all, select the software, as it works today, because it solved one of my problems. BTW, there is a good chance I won't buy/install the next update to the software because it will probably "improve" it to the point it is no longer useable.
And so they have even less excuse for their mangling of the terminology, and definitely should be smiled at, nodded to, and ultimately, ignored other than when they have some kind of arbitrary coercive power over you, in which case, do it in your head anyway.
If you walk up to a nuclear engineer with your 140 IQ and ask him to "turn up the atumz", he should probably just call security and have your ass thrown out on the street.
Seriously. If you don't know even the basics of an industry's terminology -- it's time to leave off trying to involve yourself until you get that handled. If you do.
I've fallen off your lawn, and I can't get up.
I understand that the INTENT is to make the software better, or to improve the feature set. But in many cases - I'm going out on a limb here and say "in MOST cases" - those changes will result in new bugs being introduced, or even desirable features being removed to make way for the new.
who want a modern UI. You see this all over the web with pages flattening to fit with the iPhone look.
You're also forgetting about new tools. Writing a webpage with Angular is 10x simpler than Dojo. But if you're going to rebuild anyway you might as well modernize the UI.
If I'm writing software I want new users, not just the old ones. Unless those old ones are paying me enough to retire on an island, which they never do. Nobody likes paying for software if it's not a game.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
you're just not deep enough in the guts of the app to know what they are. UI re-writes are seldom if ever for the hell of it. There's a few good ones:
1. Switching to a modern and more maintainable toolkit. e.g. going from Dojo to Angular or God help us all a table layout + custom CSS to Angular. Like it or not at some point you are going to have to add features to stay relevant unless you're IBM. Oh wait, they're revenue's the the toilet. Or maybe you want a web site that scales from iPhone to phablet to Tablet to 4k desktop? Guess what it's time for a new tool kit.
2. You'd like some new users, but our crusty mid 90s UI is turning them off. Yeah, time for a re-write.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
the spork is better in every way. it's a spoon. it's a fork. it takes up less space. it's not like you ever use a spoon and a fork at the same time.
still, no one wants a spork.
a screwdriver could have a hammer on the other end. it doesn't. you don't want it to.
it's not about better. sometimes, it's just about the abstract concept of knowing what your tool is, and what it does. I can have two different tools for different things.
the all-too-common swiss army knife is completely useless. Have you ever actually seen any human being even try to use a swiss army knife? It's hillarious.
software features are the same way. it's 2017. do you think anyone uses office suite programs for anything more than they did thirty years ago? maybe 0.1% do. Maybe a whole 1% use pivot tables. Everyone else can write business reports and book reports and essays in wordperfect with plastic keyboard overlays. But now we have drop down menus, excuse me, ribbon bars, excuse me, drop down menus inside of ribbon bars! Even clippy couldn't have predicted that one.
Better, is often much more useless. It's like more storage-space in your car or in your house. There's a point at which you need an index to find your stuff. And that point is way sooner than people think. So your SUV, and your storage locker, and your attic, and your space bedroom, become piles of junk. That's not better.
software functions are the same way. I need to convert video basically between four different formats in 2017. And almost always between only two, now that flash is dead. But it's been ten years, and I still can't figure out how to get VLC to convert a video into anything usable. So I'm using a shitty shareware program that's far less capable, but doesn't give me the option of producing a 10x10 pixel, 6GB video, from a simple cell phone video. Asking me to select the bitrate in an age where internet speeds vary as much as they do is the all-time dumbest option. Nobody cares about the bitrate. Ask me to choose the filesize, which means way more. Or the general quality. Do you think I care about the pixel dimensions when the compression is horrible? High-res compression artifacts, yummy.
More software features is like a new employee. If you can't work with what you have, a new employee ain't gonna make the old ones any better.
"I am someone who likes to post improvement suggestions for different software tools I use on the internet."
Well, there's the problem.
Your "improvements" don't make the software or its use better for anyone, most likely.
Most of the reasons have already been stated, most likely, but if you don't comprehend them I will try re-phrasing them yet again so that maybe you CAN understand.
1) What you think is an improvement is not functionality desired by others. They don't need it or want it and would not use it if it was there.
2) It is simply a bad idea and/or not thoroughly thought out. Simple example- having a device gui that is consistent across multiple architectures and screen sizes is a great idea... at first. When taken to the extreme we end up with either 24" desktop monitors that can only show 8 HUGE buttons- but looks exactly like our cell phones OR we have phones with icons so small a magnifying lens is needed to see what they are. Most groups that have tried these things have dialed it back to more sane levels, but it does still exist. And I for one do NOT need a cell phone with a 24" display, thanks.
3) modern software is often incredibly complex and what SEEMS like a trivial change can sometimes require a total re-write. It is usually not quite that bad, but the ramifications of almost any code change need to be considered very carefully. You may have a good idea but the resources to accomplish it may simply not be available.
4) KISS. Keep It Simple Stupid. Many folks would much rather have 10 small, fast simple and simple to USE programs that each do one thing EXTREMELY well and reliably. Others want just one program that does it all even though it is far larger than the 10 separate programs are (due to complexity and inter-operation requirements) and, especially when used for just a few functions, far slower since the more complex program will, at the least, need to determine what portions of the program need to run. This is time wasted. Feature creep is a very real hazard in modern software.
The above list describes some of the most common issues and more details can be had by simply learning about things like SystemD, Powershell, Canonical's Unity, WIndows 10's UI, Metro, Gnome and much of more recent versions of KDE.
For the sake of argument, suppose the proposed features are superior for any reasonable user, programmer, manager, and bottom line. Therefore the objections must be unreasonable, and the question becomes: where do unreasonable objections to software improvements come from?
One factor is incompetence, or more typically _virtual incompetence_ -- even the smartest person around can act like an irritable fool if they're exhausted, or have chosen, or were forced, to spread themselves too thin.
This is made worse by ambition, or corruption; perhaps a maintainer has taken on many jobs not to actually _do_ many jobs, (assuming that were even possible), but rather to gain status (resume or cv padding) from having more titles or positions, and for the personal networking advantages. A corrupt policeman doesn't care about enforcing laws fairly, but loves being respected; a corrupt maintainer doesn't care about maintaining anything, but craves kudos.
If enough of one's peers are afflicted with ambition and fatigue, they evolve a self protecting toxic peer culture. These peers roll each others logs, but not those of strangers who can't "help" their careers, and haze those who inadvertently point out what mediocre standards they've settled for.
It couls be that if it works for some person or application, that that is all there is. UTILITY. Once anything is useful the obly way for it to go is down. More often than not, once something is useful, it is updated furiously with useless garbage until it as a whole also becomes entirely useless.
You're asking a question on /. where all the assholes you're talking about hang out.
When I see a new feature to software I've been using for years, I cringe because I know that means unnecessary bugs and that the guy that put his two cents into making it happen isn't thinking about compatibility, just as long as it works with his $3K 64-bit GPU monster of a machine, to which we don't all have. Even the people willing to test software are usually above average with their hardware. If this is a cloud computing issue, all that's happening is companies using open source software to destroy the point of open source software. Why would letting a server have all the final say be a good idea? That's just Window$ 10 level nonsense. We can't all have a server in our house to run our own settings or prevent from being spied on like cattle just because I want to run a graphic editing program; that's asking too much.
Personally, I think it's because they can't push a new architecture to trick people into to buying new computers like they did in the late 2000's, so they profit off of cloud services and advertising instead, creating "business standards" along the way that were never actually there (free-market murder), locking Fortune 500 companies and government agencies into licenses and contracts. Besides, please don't be that asshole trying to coin a phrase that is just going to end up contributing to the "newer is better" zeitgeists. There has been absolutely nothing invented in the last 5-10 years worth a damn to the average person. It's all been Kickstarter level BS, selling "solutions," or "look what our new super computer can do!"
The reality: "Oh that's awesome! When do I get a turn on that billion dollar tax payed badboy? :)...Why aren't you answering? Oh never? :(...You say there will be applications for it soon? Well, until then I'll enjoy contributing to biometric databases via Facebook & dating apps and and talk to my "friends" I've never seen in real life and play shitty mobile games. I have followers, ergo I have worth." Those "applications" are nothing more than over-glorified web browsers using incredibly limited or expert level API and offers an excuse to not improve hardware for the last 5-10 years while still charging outrageous prices. They can do this because your computer isn't doing any work, the "cloud" is. You have no privacy or freedom and people actually pay for this. And the bandwidth ISP's keep bitching about, the reality on that is because they can sell your browsing history, which would also include unencrypted cloud computing, this means that your government can legally "purchase" that information rather than going through warrants and red tape to only get the same information.
If anything, there's a "It's 1984; oh well" millennial syndrome, like they're "cultured" or something. They have so few life-threatening fears that they evolved to ignore privacy instead of physical threats. Currently, needs are being created over a bed of social Darwinist peer pressure that has been around too long for a company's customers to care about or remember. New features would of been great ten or twenty years ago, but now it's just tech companies taking advantage of the short-term memory "drones" that they themselves have carefully cultivated over the last decade. Some software even goes as far as removing features to only bring them back for "premium" users. That's bullshit. That's also why I use Linux and desktop FOSS software when ever possible.
I wish it were just that. I've been writing and deploying enterprise systems for years and it is still basically people just don't like change even if the change is vastly superior to what they had before. I've literally had people for the first month tell me how much this new system is terrible and was a waste of money and then I talk to them 3 months later after they actually have USED it and complete reversal with nothing but praise for the new system... Most people don't like learning is the bottom line. They want to show up, do the same thing they have for years, clock out and collect a pay check. Same thing for most users outside enterprise stuff too, they don't want the application to change because they hate to learn new stuff.
I develop game mods, so the point of each project is to modify the game for our community of players to re-explore. With every set of changes there are folks who complain that changes were made. They aren't complaining about specific changes, just that changes were made at all, despite the fact they they're playing a mod. I think the knee-jerk reaction of lots of folks is to complain without actually thinking about what they're complaining about or why.
My rule of thumb is that you can safely ignore criticism that doesn't include *why* they hate some change or idea. If you know the suggestion makes sense in a clear and explainable way, then go ahead and make the suggestion. If your suggestion is towards some company making money off their software, then try to back up that suggestion with dollars (e.g. an appeal to a new market niche or something).
by implying that the software isn't perfect. So the biggest fans will be the first and most vocal opponents of your suggestion. It's tragic when the product's greatest supporters are also its greatest impediment to improvement, but that's just human nature, unfortunately.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
systemD doesn't add anything of value. It only adds bloat and complexity to an already complex system. Adding bloat and useless features just adds another attack vector and additional bugs, systemd proponents haven't learned anything from history of computing. Add Java to browser then remove it, add flash player to browsers then kill it, etc.
...and they usually add up to a giant, steaming pile of crap.
I worked on a project once that did its best to implement all user requests in its product. By the time I started working on it, there were at least seven different ways to do any basic function, because different users thought it would be great if they each had their own way of doing the same damn thing.
The result? The software was bloated, and damned near impossible to adequately test. The permutations possible to do the exact same task were staggering. This resulted in a lot of weird bugs that weren't found during testing. It made the software brittle, and in the end the same users that wanted all these different ways of doing the same task (multiplied by a few dozen different tasks I might add) weren't happy with the resulting complexity. All that stuff that users thought would be simple and a good idea, in combination, sucked.
Sometimes it's a developers job to say no. It can be very difficult to decide when that time is, but projects that never say no are doomed to failure. Sometimes an over-arching vision as to how the product should work needs to win out over every single good idea some random user has.
I sometimes work with physical tools. And there are times when I'm using a wrench, but need to put it down and start using a hammer. I don't think it's unreasonable of the tool manufacturer to reject it when I suggest to them it would be great if they welded a hammer to all of their wrenches so I didn't have to put one tool down to use the other.
Yaz
I work in enterprise software, and this effect is widespread. It comes down to a generally deserved lack of trust, and the total failure that is a typical "requirements" process. Everybody has had an upgrade that made things worse, and if it is working now, then the risk of change is high. Moreover, the users have a low opinion of the Devs because the Devi often didn't understand why they were developing to begin with. Devi have a low opinion of users because the users complain, but never help them fix it.
Tl;dr- bad communication and leadership.
You haven't seen my entry in this thread, where someone with little to do with QuickBASIC dissuaded a QB64 developer from features.
Because you did the opposite and analyzed the submitter, not the code.
Your cures are not usually implementable.
If the SW is a commercial application, you do not control its feature set or delivery schedule. You take it or leave it. If it is open source, the author will most likely want total control over its direction as well. What are you going to do then? Attempt to fork it and find someone else who will come up to speed on it to make the custom changes to the branch you will maintain forever afterward? Don't make me laugh. That is not economical or practical for a number of reasons.
If you (your company) didn't write the software, you do not control it.
If it ain't broke, don't fix it.
Actually, a couple decades ago, I don't think most people would've minded since "update" was generally synonymous with "new features". But the last 15-20 years has seen a marked increase in the number of software updates which removed functionality. i.e. Stuff you could do previously, you couldn't do anymore after an update. That's led to people taking a defensive attitude towards software updates - unless the update delivers a crucial security patch or necessary feature, they'd rather not risk it and prefer to stick with the tried and true. Feeding developers mildly useful but not earthshattering ideas just gives them an excuse to shove an unwanted update down users' throats.
No. Merely that he has observed his ideas get shot down by people with no clear interest in the project. I have observed similarly.
Wait 'til they get a load of my "anti-Mimic Rescue" game with an ex-Human Federation military officer, "Samu" Japanization for "Same" of the "Same" Shapeshifter race, raised by a cult, "The Identity" out to destroy a "Mimic" race, that be
You start from the position that it is a good idea. But you miss the point that maybe you just have lots of really bad ideas. Maybe you're the common factor here
Why did you post this? Do you think it matters? It doesn't matter. Why are you wasting our time? /. is fine without your post.
I can't help but feel that all the major reasons given, would be rendered completely moot if the new feature was just designed as an optional module. Then people who like the old way can keep their simplicity, stability and workflow and those who find the feature useful can add the module when needed. At the end of the day, DIMSS arguments are valid but only because the fundamental principles of current software design are flawed; new features should be modular not integrated in the core and that not how most of today's software is written
(bad phone situ, on computer now) Mimic race who procreates by copying another being, except replacing the propagation info with its own and then killing the original. The "Same" race get its name by the fact that they inject a child member of its species into another culture to learn from it. Samu was destined for Human Space Pirates originally, but The Identity detected Mimic among the space pirates and swooped in.
This game is tailor made to toe the line but not cross it. It shares elements with Metroid and Star Trek. My dad's side's got a lot of lawyers and my dad's with the Ohio bar. Your move, Nintendo.
They invest the time and the learning to master a workflow. They expect a payoff from this investment in their ability to use these workflows to achieve other ends. When you mess with a workflow, you negate that investment. They have to spend time learning and mastering a workflow all over again before they can apply it toward their actual goals.
Nobody uses software "to be using software" or "for a good experience." They use it to get things done. If they have to spend two weeks mastering a new workflow then your improvements had better deliver a multiple of that value in return, or they're going to come back with "that's cool, but it would trip me up for all of my muscle and click memory to be invalidated."
People aren't averse to improvements. They're averse to evolutionary improvements that cost more to the user in practice (time invested and mistakes avoided) than they deliver on the other end. "Small tweaks" often fall into this category. Some dev moves a button to a more "logical" placement and for the next two weeks, the users lose five or ten seconds every single time they need to use it because their absent minded clicking—absent-minded because they're focusing on what they're really trying to accomplish, not on 'using the software'—keeps ending up in the wrong place vs. what they're accustomed to.
Dev says "BUT IT'S BETTER." User experience is actually that of being irritated and not getting things done as efficiently as usual, so their response is "IN PRACTICE, IN THE CURRENT CONTEXT OF MY LIFE, NO IT'S NOT."
STOP . AMERICA . NOW
I see this behavior surprisingly often as well. Any explanation I offered would just be conjecture, I'm afraid. I have some guesses about why people do this, but they're just guesses. I think it would make for an interesting psychology study.
Anyway, I'm mainly posting here to offset the toxic comments I see in response to your question. I, too, have been there. I've been attacked by onlookers for making suggestions, with the naysayers backing off only when the project leads decided that my suggestions were good ones. I've watched other people get attacked similarly, sometimes when I was a newcomer, and sometimes when I was the developer. It doesn't seem to matter if you're making suggestions for someone else to implement or offering to do the work yourself; some people seem just as likely to sling mud at you either way.
The internet has no shortage of obstructionist personalities, and the communities that gather around software projects are no exception. It makes me sad every time I see it, because to me, it is the antithesis of open software development. When it happens, everybody loses.
The only advice I can think of right now is to accept constructive criticism of your ideas, but also don't assume that your ideas suck just because some internet troll says so. A lot of them are wrong.
To quote Dr. Ulysses Cox: "Because end users are idiots, period."
R.I.P. Netflix Scrubs (D. May 02, 2017)
The only accepted meaning for DIMSS is DSN Integrated Management Support System. What you describe is the whining of an autistic shit user who wants changes based on his irrelevant wishes when the software works well for the vast majority. As it should be. Want something different? Make your own? Can't? Your problem. Won't accept it? Commit suicide and rid the world of an asshole.
It is other users, not devs, the OP has found have a problem with it. I don't understand why people think your comment is insightful.
Each day people come into work and have real new problems to solve. (E.g. how to not get bankrupt; or how to solve engine overheating / blowing up)
Relearning the tool is just an annoing distraction like fixing a flat tire.
(Tl;dr; I think "They want to show up, do the same thing they have for years" is too onesided and a tiny bit condescending view)
Ah, the "User Experience" people. They try to justify their own existence by being "creative". But, in most cases, the ideal interface is absolutely plain and conservative. You just read the operating system's HIG documentation and follow that shit like it's your fucking Holy Bible. Use standard buttons, standard borders, standard colors, standard fonts, standard everything. Don't deviate from the standard, unless you really have to.
... explain the Pointy-haired boss feature suggestiom syndrome?
Perhaps the answer is more to do with psychology than technology. We often assume that people want better software, new features et al, but in truth the technology is at a point where it creates too much noise and too much change for our primate brains. what an average human wants in life is rarely anything to do with tech.
I work for a pharmacutical company. Our drug manufacturing processes must be validated. This validation process also applies to the software applications used so that we comply with FDA regulations. The validation process takes months to complete and is very costly to perform. Even with dedicated teams continuously working on validation, we simply can't keep up to date and validate every small point software update. We end up living with legacy applications existing within Citrix bubbles because the cost to upgrade along with validation is astronomical. Process validation is probably not something many consider when coming up with new ways to improve things. You need only go through the process once to discover how much you hate it when a function within a user interface is even slightly changed.
You seems to be on the path of learning that you are not everybody else.
Maybe the great idea that you had wont benefit you and everyone else. Maybe only a very few would benefit.
More code more complexity and more bugs. That is something that i am sure wont benefitt everyone.
maybe submit patches instead?
From MMO makers that don't take input to XBMC devs that refuse to offer better caching settings. Devs don't get it. You don't have to take advice from users. That being said it's the only metric that counts. Offering attitude instead of gratitude for another data point is self destructive.
How do you present those proposals? If you do not explain them well and in a concise manner pointing to the clear advantages others might not understand it properly. They may only read the title of the submission or even may be the person who suggested to make it work the current way.
You also claim that your proposals "could work better for everyone else". How do you know? Did you run a usage analysis, conducted surveys, ran A-B testing, and compiled a report that showcases the clear preference of a large majority? The tricky part in application design is to accommodate a diverse group of users of drastically varying skill level with different expectations. You should drop the idea that your proposals work for everyone else. Some might agree with you, but surely not everybody.
People hate change. If they went through the trouble of finding a solution that satisfies their needs and they figured out how to operate it, they want it to stay as is. Look at mobile apps, people still rate apps highly that are awkward to use and crash often. These apps solve a problem and the occasional restart or the seven taps when two would suffice are accepted.
Quality feedback is always welcome. Keep up your good work and hone your skills. Also think about getting more involved in design teams or even start a career as product analyst or UX design expert. Slick designs paired with performance and stability will always go a long way.
Per other posts, if 'improve' means 'a period where software that used to work for me in a predictable way, no longer does, until I take the time to learn the new way' then I'd argue improve - independent of side by side new vs old comparison.
Or just, the Russian space program mantra.
Because increasing the complexity of the software requires additional support which you, the suggester, are not going to provide. Software isn't free.
We'll make great pets
At times it is also much easier to blame an inanimate object like the software for procedural or management failures. I come across this often, users do not operate the system properly, import bad data, have high turnover and no budget for training...and in the end it is the stupid software's fault that folks do not show up for work on time.
For most users, software is a tool that they have invested time to learn how to use. Change requires unlearning and relearning how to tasks. More importantly, the consequences of a proposed change are unknowable to the user. If "they" change my software to do X, will I still be able to do A, B, and C? New versions of software often break or remove functionality by accident or sometimes on purpose.
People can be cunts. That' about 100% of the problem.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
There are two reasons to NOT change the software - or at least the view seen by the users:
1) Training - learning an application represents a significant investment in time and mental energy. Making a significant change in the interface (or worse, the actual workflow) means relearning the app, sometimes from worse-than-scratch because you already know what's wrong! So, if you have to relearn, you can relearn another app that doesn't have the feature and workflow churn.
2) Reliability - adding code adds bugs. Code that once worked fine now doesn't. This again forces users to consider if it's time to learn another application and workflow simply to get away from the bugs.
Assuming your suggestion really is a good one, and most of the times it isn't, it may compete with other people ideas.
Users have different priorities and developers can't do everything. So if you make a suggestion that some people aren't interested in, and developers implement it, it may delay the treatment of their own issues.
It even applies to obvious bugs. For example, if you post a bug report saying that a crash can occur if you open a file containing Arabic text, you may get dissed by people who don't have this problem. They may give out weak arguments like "full Arabic support would require a complete redesign of the GUI" when the only thing you asked is for the software not to crash. They fear your suggestion may divert the attention of developers.
Apple and MS are constantly changing the look and arrangement of their OS with each new version and then app developers for some reason feel the need to change and match that for whatever reason, and we end up with constantly rearranged and reskinned GUIs. Desktop OSes need to stop changing this stuff at the basic level and encourage consistency.
Personally I'm sticking with GNU/Linux, first Gnome 2, now Cinnamon... I've been having a fairly consistent experience for about a decade
Twinstiq, game news
After scrolling though many comments, there seems to be an energy similar to the very topic at hand (which isn't so crazy). First off, as a developer who has (at the very least) touched over 100 different languages (compiled, interpreted, whatever, you name it), I can say that for me personally, if a user has a suggestion for improvement, I'm all ears. Outside critiques and suggestions should not be corralled by the complexity of implementation. Anyone who argues otherwise is naive in my opinion. Not stupid, naive. Please don't twist my words or intention there! It's very easy as a developer to power through creating a "thing", which the MVP (minimum viable product) and fluff features, as well as everything in-between, and miss some usability bullet points or even expected functionality. Some users might not care about those things, perhaps they never even use functionality that is missing (queue X-Files theme song). What matters is, the validity of a suggestion. If a user writes up a detailed explanation of an improvement or quality-of-life suggestion, and it's good, that is free and powerful. We should be thankful, and I'd go so far as to say we should shun the jerks that foster negativity towards that type of communication within our users' communities. There is a certain level of user, surfer, whatever you want to call them, on the internet nowadays that is far too selfish for the good of us all. They have to be right, they have to be first, if it wasn't their idea, it sucks. If you disagree with them, you're a bigot or a troll. It's a waste of bandwidth. It's inefficient. It's my opinion that these types make up a good brunt of the naysayers that are in the DIMSS class, with only small amount of intelligent and valid types taking up the rest of the pie graph.
More likely, based on the description, is that the functionality does not exist, so people don't use it. If they needed it, they would ask for it.
Now there is a community of like minded people who don't need this new thing, and they mostly agree, since no one suggested it.
Some new guy comes in and points out that your software is defective or deficient. Even if you didn't write it, you feel protective and defensive. It's mentally easier to write off the suggestion, than consider that people who aren't you might want or need minor tweaks.
It's Wikipedia Syndrome, where minor improvements are seen as unnecessary because they weren't there before and everyone was happy that way. It's basic sociology, really. Digital Sociology needs to be a thing, applying the field to a new era.
Look at any of these:
FIREFOX
GNOME 3
KDE 4/5
UNITY (shot in back of head recently)
etc
If I have spent time learning or using a piece of software then I have a vested interest in keeping it static. The only way I am going to want a change is if I personally need that change.
You're going to change how the software interacts with the user because you got a nifty tool kit upgrade? Because you went from Programing Language Not Currently in Vogue to Programing Language De Jour? You think the software should work on a desktop bolted to a desk at a shipping department just like it works on your child's IPAD? The latest iteration of homo-sapiens isn't fawning over the fully functioning design? You should get out of programming and move into a more useful career: Ocean water garbage removal. Sure, it might seem like a good idea for the UI to be changed so that some feature can better fit in to the latest UI concept, or even be cool to the latest crop of budding consumers just entering college, but changing how something works is a huge deal - not for you programmers, but for the millions of people that actually use the software to get things done.
Software is a tool, not an art project to stick in your effing portfolio. First off, UI design must be functional and then elegant. It matters not one wit if the UI is pretty or even if it wins awards for its looks if the thing doesn't effectively and efficiently do the damn job its supposed to do. Changing the UI design, especially deleting functions or moving them around is equivalent to breaking the software. It doesn't work like it did yesterday and NOW it is neither effective nor efficient. Now it requires learning, and then re-learning, and if used often will require UNLEARNING the old way -- something humans don't really do well at all. If you can't make the changes you need to the code to both improve the underlying performance, add a feature, appeal to the "youts of 'murica", and still keep the old stuff where it was and working as it was, then get out of programming. Just quit. Save me the time and aggravation of figuring out what is going through that two cell based life form you call a brain while I have a multi-million dollar project idling because the people working on it can't figure out where those vital features are now located or worse deprecated, a fancy word for too fucking lazy to keep a feature working.
And don't get me started on the "what we changed in the latest upgrade" document. I get better change logs in World of Warcraft patches than any other piece of recently "upgraded" software. Hiring some stoner you met at the Weed Works to write "We changed stuff" and hide it in a PDF buried more effectively than landslide victims in Washington State, isn't sufficient so mitigate the change chaos. SO stop lying to yourself about how it's really okay and people will get over it. No THEY WON'T. We don't get over being blamed for the consequences of some anonymous jackass programmer's design changes. We get to SUFFER because of it. And that is NEVER going away. We remember it because you're the reason the budget was blown, the system failed, we missed a deadline because the software got upgraded. We didn't get new training because we had to spend the training budget on teaching folks how to use the upgrade instead of something that might actually get our productivity up. Yeah, change that UI, will ya? We need more stress and aggravation.
Remember when Microsoft moved the print function in office? That little bitty change was a juggernaut of wasted time and effort trying to first, figure out where this common function had be re-located, and then passing that knowledge on to people who really only want to print documents as a part of their job. That's right, printing documents was the core piece of their job and one night it got upgraded into some other part of the software. Brilliant. Now we have employees approaching retirement age who already hate computers and software trying to figure out how to print documents so that they can ship product to customers while the trucks are idling outside the office at $200/hour demurage causing the shipping department to watch their quarterly bonus vanish as they struggled to figure out how to PRINT. Yeah that was a great move. I'm sure those guys w
Creative Spelling Copyright (2002). May use without Persimmons
Paraphrasing George Carlin (On religion):
"Remember that? The Divine Plan. Long time ago, Programmer made a Divine Plan. Gave it a lot of thought, decided it was a good plan, put it into practice. And for billions and billions of scrum sprints, the Divine Plan has been doing just fine. Now, you come along, and ask for something. Well suppose the thing you want isn't in Programmer's Divine Plan? What do you want Him to do? Change His plan? Just for you? Doesn't it seem a little arrogant? It's a Divine Plan. What's the use of being Programmer if every run-down shmuck with a two-line-long feedback form can come along and fuck up Your Plan?"
Better is the enemy of good enough.
It already works and does what it's supposed to do.
I like it now; leave it alone, dammit!
Who do you think you are to decide what 'improvements' I need?
Everyone gets used to doing things a certain way, and gets irritated when things are improved.
An example among data-entry types is being able to use keyboard shortcuts vs having to use a mouse, It slows them down to have to use a mouse.
Another is the Microsoft Ribbon, where people had the old menu system totally memorized, and suddenly couldn't find anything because it had been "improved" and "re-arranged for you convenience". Instead of making it an option that you could toggle, it was a mandatory upgrade.
This is totally irritating, especially when the new version has improvements that are geared to the enterprise, or software profit margins. I have talked to too many people who would routinely tell me this. This is a minor point of contention.
I still have an old computer that works just fine thank you, and run an old word-processor without a lot of this extra fluff. Heck, George R. Martin uses an old dos word processor because it is more convenient for him.
In this context, I am reminded of the old video about choices in spaghetti sauce. turns out, that in the world of spaghetti sauce, there is no one perfect spaghetti sauce, despite decades of advertising to the contrary. The truth is that there are many perfect spaghetti sauces (chunky, vegetable, extra spicy, etc) and you get more sales by catering to the individual tastes of people. Which is why we now have multiple varieties of sauces, etc on the shelves these days.
You can watch the full video here: https://www.youtube.com/watch?...
Large companies like MIcrosoft are still in pursuit of "the perfect software" or "the perfect user interface" when they should give users options and choices when it comes to user interfaces and performance behavior. There is no one best interface, etc. just like there is not one best spaghetti sauce. While there should be an update for security reasons, etc. what does that have to do with the sort of an interface a person likes?
Similarly, there can be genuine product improvements when you do things a certain way, but also it is merely the pursuit of the cool and novel vs actual improvement. I upgrade systems because I need a certain functionality, and sometimes it is a royal pain when I cannot
I am a constant crank about software as a service. Especially if I can do what I need and keep a system running well for many many years, so that it is cheaper than paying a yearly fee.
"It is a greater offense to steal men's labor, than their clothes"
To really see where "why would you want that at all" or "nobody needs that" or "the software is fine as it is" or such ilk come from, I recommend reading "Understanding Media" by Marshall McLuhan.
United States
My experience is that the actual developers are usually willing to listen to improvements. But almost always when I file a bug report to an open-source project, there are gatekeepers who want to keep things just exactly as they are. These seem to be people who don't really understand coding or UI design, but are wannabes who have volunteered time for a task that others don't want to do, which is to screen bug reports.
In those cases where a project is basically just one guy with maybe a few helpers, like 100% of my suggestions get implemented. In those cases where it's a large open-source project, approximately 0.00% of my suggestions get implement. I ask, is it me, or them?
Meanwhile, I'm one of those people who says "don't change it" whenever someone wants to change the UI. As has been noted here many times by others, these days these changes are suggested either by artists who aspire to be Michelangelo, or by those who have to change something to prove they are actually doing something, often just following the latest fad started by morons at MIcrosoft. Usually, when these losers want to change the UI, they do not offer any "legacy" way to stay with the old one. If these systems were cars, one day they would put the steering wheel in the back seat, then have you drive facing backwards, watching the coming road in the front-view mirror, then remove the seats in favor of stools, ...
Hey, making up a "syndrome", even with cool acronym (btw. why didn't you try to fit it into DISMISS?) may be a start, but your post is just a 3/10 on the logarithmic troll scale.
>Maybe the way he presents his ideas is a problem.
All too often seen this - especially in 'multinational' projects where one has to think about cultural differences and mutual understanding in distinctive languages.
Bloat and feature creep are real problems for graphic artists. The less feature creep, the less often I have to buy new hardware to simply scan and process images. The majority independent illustrators I know have come to hate Apple and Adobe, who conspire to lock artists into the walled garden / soldered battery + memory hellscape by bloating software to the point hardware upgrades are required.
People don't do what I want. Waaaaaaa!
Princess, maybe the issue isn't with other people. Maybe the issue is you -- specifically, your self-absorption. Even if your suggestions are good ones, your arrogance turns people off.
I'm not a religious man but, sometimes, the Bible provides some excellent material: "Why do you look at the speck of sawdust in your brother's eye and pay no attention to the plank in your own eye?"
> Use standard buttons, standard borders, standard colors, standard fonts, standard everything. Don't deviate from the standard, unless you really have to.
The problem is, the projects changed the standards to utter bullshit.
checkbox? Too easy, make it a slider! Write to the left and right, what the directions mean? Too ease, write it below the sliding part. Yeah, who cares, that moving the slider to the side with the text "ON" now turns it off and shows OFF on the inactive side. We color it to show, if it is active (like checkboxes before). But lets not make it obvious, choose the colors so, that the user first needs to see both states, to decide if he thinks the thing is currently active or inactive.
Android, Gnome, i look at you.
No
Try arguing someone in the checkout line about your improvement on his grocery list, what do you expect?
If you want people to do things *you* want, you either:
Really, kindergarten stuff.
I often see people asking why so many users are willing to keep shelling out all the money it costs for products like Adobe Acrobat Pro, when free or inexpensive commercial or shareware alternatives are all over the place that would allow you to edit a PDF document and save a modified copy. Same goes for Adobe Photoshop, or even Microsoft Office.
The answer is most cases is that the familiarity makes it worthwhile. I mean, yes, in a minority of cases, you actually have users who need advanced features or functionality that's not provided by any of the alternatives. But I'd say the vast majority of the time, it's simply that someone spent years using those "name brand" products for the work they do, and switching to something else that has menu options in totally different places, and toolbars with different icons for the functions they're after doesn't seem like a good value to them.
...don't fix it.
As for the specific example of software; you're talking about changing a tool they use, possibly one they use every day in their job. While a suggested change may add a useful feature or greatly improve work-flow, they are afraid they will have to learn more about the tool they have come to take for granted. (There are good reasons why Linus Torvalds rants so scathingly when developers make changes that break userspace or user workflows after all)
If it was just a bug patch, those are usually invisible to the majority of users. For those affected by the bug, affects them in the more subtle sense of negative evidence. (in other words, people really notice when something breaks, but when something doesn't break like it used to, that is harder to notice and appreciate) However; from your description, you are primarily advocating adding features or explicitly changing work flows (even if in minor ways). Without more specific information, I certainly can't judge the possible merits of your suggestions. At minimum though, I think your suggestions would require :
1) Adding items to menus, possibly adding new menus altogether. That requires the users learn these new options. With enough new menu items, the devs may decide to revamp the whole look and feel just to drive home the idea that the software has changed and to prove to their bosses that they are actually adding something meaningful to the code. {I'm looking at you Microsoft Office 2007},
2) Changing or adding to the underlying mechanics of the application, which runs the risk of adding whole new sets of bugs to what is hopefully a previously stable release.
3) Convincing the software company or developers that your changes are positive enough, and in enough demand by the user base to justify devoted the time, eyeballs and above all Money to making your changes. Keep in mind that quite often, once an application has been released and the initial flood of user reports have ebbed, most dev teams get cut down, programmers reassigned to other projects and so on. A few are sometimes kept for bug chasing, something which takes proportionally much more time than new code development. The few bug chasers (the code monkey kind, get your mind out of the gutter) will push back against creeping feature-itis and managers will often just decide to add your suggestion to the list for the dev team of the next major version to consider.
I need a wheelchair van for my son. Help me get the word out. https://www.gofundme.com/wheelchair-van-for-jj
Hmmm. Let's take a look at this.
My car comes with an over-improved radio/gps/phone interface with a 300 page manual. I can't figure out half the features.
My TV comes with a 45 button remote control that I'm the only one in the house that can operate.
My Samsung phone as four ways to get email, five ways to sign in, (at least) five ways to send messages, and every time I open something up, I'm either told to update an app, download a dedicated app, or create a password for something - all with permission requests that seem beyond the scope of what's necessary.
The Microsoft Ribbon.
The Windows 10 start menu.
Apple dongles.
The constant, continual interface changes in everything made by Adobe - where I have to spend too much time learning it, and then hours in "personal tech support" to employees, co-workers and families who are baffled by the changes, and call me because they can't make it work anymore -- the way it used to.
The software I deleted because it was continually over-improved: WinZip, Winamp.
The software that I need to use, but dread every update: Windows, Microsoft Outlook, Word, Firefox, TurboTax, Quickbooks, Quicken.
What I'm getting at here is beyond user fatigue. It's tech fatigue. Users have been burnt so many times, and grown so tired of what - to them - appear to be capricious, not-particularly-helpful changes that they just wish you'd stop over-improving stuff that already works fine. They don't need a hammer that also dices vegetables. They don't look at software as fun. It's a tool, that they have to use, to get stuff done.
So why are people pushing back on you? Because at this point, they've learned from experience that most of the 'improvements' just make their lives more difficult.
Because chances are your ideas truly are shit. Just because YOU think they're good ideas, doesn't mean than anyone else will think they're good ideas, or even that they are objectively good ideas. Stop thinking that when everyone else disagrees with you that they must all be wrong, and admit that it's probably YOU who are wrong.
People are like geese - they seem to exist solely to annoy each other.
So let me see if I got this right. You find a complex piece of software. You use it for a day or so. Just long enough to get an idea of what it does. You don't read the documentation. You sign up to an established community of developers and experienced users. Your first contribution is about your clearly brilliant idea that nobody has ever raised before.
You left out OS software makers like GIMP changing saving as JPEGs to be an export function instead of a save function. That little fuckup pissed so many of their users off cause some committee dipwad got his panties in a twist about terminology.
Who! Fucking! Cares!
It was a change for no real reason other than being a pedantic shitstain who wanted to be "right" instead of make users happy. And this shit happens all the damned time.
As parent says, do not change the damned UI.
At work, on internal projects where we don't get enough time and resources to "do it right" I am annoyed when we deliver a release and someone says "oh why didn't you..." or "why isn't this..." but we did think of it , we just didn't have time to do it because whatever was done had higher priority. Yet people look at it as if we didn't know what to do, and don't appreciate that there just wasn't time to do everything. Nobody likes to hear that their idea isn't the most important one but we have a maanger , he prioritizes the features , and never takes the blame for what isn't there.
Thank for the Tip!
So, I guess it is better to let your app die a slow death by abandoning it and starting a new one under a related or even different name in that case
So all your set-in-their-ways annoying users stay away from the improved version
And when the old app dies, too bad but they will have to adapt anyway ...
And you don't get to hear the whining ...
Nice and insightful! (And already happening, change will happen wether you like it or not, people have to learn that)
captcha: upkeep
My experience with successful products is that they get a ton of suggestions which fall into one of two buckets:
1) The suggestion is just plain dumb, either completely unrelated to the project, or showing a gross misunderstanding of the goals of the project.
2) The suggestion is obvious, but very hard to implement.
The reason this is the case is because with a successfully project, all of the obvious and easy suggestions have already been implemented. All that's left are the impossible ones and the ones which don't make sense.
[Here I use "successful" to mean "Enough people use it and work on it that people constantly volunteer suggestions without volunteering patches."]
A lot posts above have talked about workflow. Let's think about skill, and learning a new skill. See:
https://en.wikipedia.org/wiki/Four_stages_of_competence
In the final stage, if you get that far, you are unconsciously competent. Whether riding a bike, playing a musical instrument or using some software. What this means is you have a thought or intent of a desired result, maybe play this melody or navigate a pothole covered street on your bike while dodging a god, without being aware of every little action you do, and not bringing up to conscious thought how you are using the tool(s), you simply use the tools to get to the desired end result.
Think about riving a car. If you had to think about every movement: okay, lift foot off gas, move foot to brake pedal, apply evenly. Only beginners do it that way. It takes a lot more time to do it that way, and if done that way is risking a crash.
Experienced users simply do it, without needing to bring up every minute action to conscious thought.
And then someone moves a button.
That is why there are so many passionate replies above.
Simple. The existing user is happy if the software does not change, and continues to do what they want it to do without them having to learn anything new. They don't care about new features, they just want it to keep doing the old ones in the same way. The company makes money if their software changes enough over time that people have to keep buying new copies. There are a bunch of different ways to accomplish this (e.g. changing file formats - aka Officescation - so that earlier versions can't cope with the default file format of newer versions) but they want to make the minimum changes necessary to sell the software again, so they don't waste resources fixing things that aren't broke.
No one wants to make it easier to use for new users. There's no money in it. Old users will find the old interface - and absolutely nothing else - to be easy to use, because they already know how it works. New users are stuck solving a problem, and are forced to learn something no matter what. They don't have the choice, and will spend whatever time is necessary to solve their problem, in the process becoming the next round of "now I know how to make it work; just don't touch anything" voters. In the meantime, the harder the system was to learn, the more likely that the people invested in it will want to leverage their existing knowledge rather than learn a new system, so the more likely they are to become "loyal" customers.
Seriously. Just google "wordstar keybindings" if you don't believe me.
(This post was written in emacs. I rest my case.)
they don't want the application to change because they hate to learn new stuff.
No, they don't want the application to change because they don't want to waste time learning new stuff.
Particularly when the new stuff has a good chance of being junk software written by junk programmers with egos way out of proportion to their abilities.
The reality is that quite a lot of so-called improved software is nothing of the sort, just disorganized messes that claim to be pretty and have lots of new functions but don't actually solve the problem in a clean, effective, fast, efficient, reliable, predictable, consistent, comprehensive and thoughtful way.
People feel like you devalue their emotional investment in struggling to learn how to use the dysfunctional software.
He who experiments learns much but reboots/reinstalls often.
It's pretty simple... Most software users don't see the software as an abstract thing that can be better or worse, they see it as a tool they use to perform a task. Their goal isn't to use the software, it's to get their task done, and any change to the software (even a small one that benefits lots of other people) means that they will have to invest time in learning this new feature, which will take away from the time that they have to do the task that they want to get done.
It's a pretty straight forward calculation: I use Word to write school reports. I don't care that adding a step to the save dialog which other users (or even me) to do things in a more "logical" fashion. I've got my process, and I've probably even got some procedure in place to deal with the "inefficiency" that this new feature fixes. So if you make that change, then suddenly my old process will stop working, and i'll have to take an unplanned hour or two out of my day to learn how to use this new feature that you've implemented, when I was already on a time crunch for the thing I was doing. Sure, maybe your new feature will save me 8 hours over the course of the year, but the short term impact to my schedule is *really* frustrating.
https://en.wikipedia.org/wiki/Unix_philosophy
"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features".
I wish I had mod points. My frustration with arbitrary, whimsical, and capricious software changes over the past 5 years is beyond my ability to articulate. Everything from an obsession with "flat" to hiding central features as Easter eggs - it all just makes me wish there were someone with the authority and sense to fire these people who seem so hellbent on destroying usability.
Software jumps the shark at some point after some number of updates. It gets more bloated, the features stop working or are removed or buggy after updates, then it turns spyware, then it gets shutdown or the replace all their internals with Chrome. Like Opera Browser. It was shareware, it was amazing, then it went free, then they kept rewriting it and it got some bugs or stopped working the same. Then they changed all the shortcuts to pander to firefox user complaints, etc. then they changed all the code to Chrome, then they sold it, and then finally, it was eviscerated and has no features whatsoever. It's dead and worthless. Maybe Vivaldi will partly right that wrong, but it's still Chrome.
And all the spyware. Firefox keeps getting all these vastly complicated config things that are confusing and multiple ways of overriding turning off spy features.
Abiword is another example. Old versions work great. new versions have bugs and Ctrl + Shift and arrow keys doesn't work or other bugs. I don't know, but it started getting bugs and I hate it now.
People are still doing anything serious with QuickBasic?
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
I haven't seen anyone mention some of the recent studies on people and how they feel about change in general. These seem to show that change, just change, hurts. It causes stress, anxiety & other actual biologic issues. People in general seem to prefer the known to the new. That said there are a lot of forces at work in why people may react poorly to the suggestion of change. A lot of them have been mentioned here: not all change means better, not all change helps everyone, change can induce other issues, changes may not be implemented well, change may come too fast for people to keep up... But a the same time change may be necessary or it may bring better things. It's a matter of knowing when to change, what changes to make, and doing them well. Sometimes "good enough" is good enough.
All things in moderation,
The Anonymous Coward
Language is an art, like painting. Technical language is an art where miscommunication leads to real world problems, and where evidence of lack of expertise leads to well justified lack of confidence up front.
With language, as with painting, you can paint like a master, or you can finger-paint like an addled child.
Which do you think will carry you further in life and in your career? Which do you think will result in more actual pathos?
I've fallen off your lawn, and I can't get up.
don't fix it.
Greed is the root of all evil.
Amen. Was reading this post and I was forcibly reminded of the out-of-touch developers at Blizzard working on WoW.
The add a feature that is utter hot garbage, their forums tell them in no uncertain terms it is exactly that, and they ignore it thinking they did a great job.
Rinse and repeat for years (CRZ, ability pruning, mission tables, profession revamps, ilv scaling, RNG).
By now, they are probably noticing most of their users are either pissed off at them, or have already left and are STILL trying to find ways to blame the user and trying to figure "what's wrong with them?"
I have a news flash to anyone asking this question: it's probably not you users - it's you. The ones determining what users like are USERS not YOU!
Just because it's new, does not mean it's better. Revert, and try to find a new way to solve the problem (after carefully re-examining whether the problem was ever really a problem to begin with. If no one was complaining about it, then was it ever really broken?). If your pride does not allow you to do this objectively, then, for your users' sake, find another line of work.
Great! So you're totally fine if I swap all your QWERTY keyboards for Dvorak ones while you sleep?
Dvorak is clearly a better keyboard layout, so your user experience and productivity are going to be SO MUCH BETTER!
No, no, you don't need to thank me! Just trying to be helpful is all.
Same
Or, idunno, you could keep the backend updated, use a customer-driven development process to add features only when they're actually wanted and fit them in with the existing UI, and change the user experience only if they actually *want you to*.
Radical thought, I know.
I mean I get that this doesn't work when you're developing for attention-strapped tweakers finger-banging bubbles on smartphones, but most people just want to do their fucking job and then go home and see their spouse and kids.
It's easy to explain: you suck at communicating.