Linked by Thom Holwerda on Tue 27th Jan 2009 13:46 UTC
Permalink for comment 345790
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/19/13 23:02 UTC, submitted by M.Onty
Linked by Thom Holwerda on 06/19/13 22:28 UTC
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
More News »
Sponsored Links



Member since:
2005-07-06
There are several flaws with the argument presented in TFA.
To start with, the crux of the argument seems to be: "Any time a technically-inclined user expresses opposition to changes to software, it's because they have an inherent, blind aversion to all change."
The most obvious & fundamental problem is that such an absolutist, sweeping generalization is a really poor foundation for *any* argument. Aside from that, it ignores two significant factors:
1) That argument makes no distinction between changes that result in real, practical benefit - and changes that are nothing but change for-the-sake-of change. Granted, some changes are actually improvements - but there's (at least) an equal number that are just "rearranging the deck chairs" to appease newness-addicts (the "If it's not new, it sucks" crowd).
2) And related to the above, it's usually the technically-inclined users who are in the best position to make an informed judgment as to whether or not a change is beneficial.
3) As others have already pointed out, advanced users are the ones whose productivity is most likely to suffer because of changes. If the cost of a change (in terms of lost productivity, time spent re-learning, etc) outweighs the benefits, then that's a situation where aversion to change is both informed and reasonable.
I also disagree with the notion that technically-inclined users have a greater aversion to change than non-technical users - at the very least, the reality is a little more nuanced than TFA paints it.
The bare, basic functionality of software usually doesn't change significantly between releases - and if someone doesn't use any features beyond the basics (more likely in the case of non-technical users), then there's much less chance of problems resulting from the changes.
And on the flip side, non-technical users are much more likely to depend on rote-memorization of a series of steps (without really understanding the overall path, or the reasons for the individual steps). Anyone who has done technical support or training of non-technical users can relate experiences where users become hopelessly-lost because of some minor change (E.g., one changed word in the label of a button or menu item).