The GNOME project at 15
Posted Aug 15, 2012 22:23 UTC (Wed) by hp
In reply to: The GNOME project at 15
Parent article: The GNOME project at 15
I think developers and designers often take flames and polls and the like as a data point saying "there is a pain here" -- but not as a prescription for how to solve it.
Most of the time flames boil down to the following:
- I am a busy person with stuff to do.
- I've learned a lot of half-unconscious habits that I use often to do my stuff.
- I upgraded and some of my habits don't work anymore.
- This is super annoying and I don't have time for it.
- Who are these jerks hosing me? Just change it back.
This is completely understandable and I have the same emotion pretty often. I frequently avoid upgrading software especially to the ".0" release.
Sometimes, software should not have been changed. It's not better enough.
If there was some reason to change, the developer is in a tricky spot. They have to figure out how to satisfy both the reason for the change, and patch up the pain of the change. This is often genuinely hard.
Often when people are frustrated by a change they aren't willing to rationally discuss any option other than "just change it back" and that's what most of the flames end up being about. Developers may feel it's best overall (for users in general) to find a solution other than "just change it back" but if you're in the midst of being aggravated and unproductive you don't have the patience for trying to find the best answer. Having the development process out in the open just pisses people off in this situation, sadly, because they aren't looking to participate. They are just frustrated and trying to get stuff done.
It devolves into all kinds of tangents and speculations we're all familiar with (about people's motivations and what's wrong with the software industry and somehow everyone's complaints are what "the community" wants and my identity is at stake and I'm switching to XYZ and I should have been consulted and so on). Lots of drama.
Eventually somebody just has to buckle down and say "here are all the known issues and some possible solutions and pros and cons and let's figure it out," make another change that might improve matters, get feedback on that one, iterate again...
It's tempting to believe that software design can be a matter of taking a poll or doing some usability tests or some other mechanical system, but unfortunately that doesn't work. It would be nice if it did.
to post comments)