Version Fatigue

An anonymous reader writes "An article in TechCentralStation introduces a useful new term: "version fatigue," which describes what happens when you get tired of learning new ways to do the same old thing with each release of software. This is something that tech designers seem insensitive to, but that drives users crazy. Maybe it's because tech designers are more anxious to be creative than to produce things that users like?"

Comments

Not on Unix?

[Ed Avis]

It seems that the UI of most Unix software (the shell, Emacs, even X) has changed much less over the last 20 years than DOS/Windows, and is still changing more slowly now. Is this an explanation for why Unix users typically learn more of the intricate features of their software? Or does the causation run the other way round - because all the obscure Emacs keybindings are so well known by its users (and developers), they can't be changed?

Re:Not on Unix?

[reflective recursion]

well.. UI has changed somewhat. Let's look at Linux: when I started using it in ~1996, much was different. Default keybindings were different (I believe they have become more PC-friendly over the years.. with actual working backspace, tab, etc. in most distros). Besides that, color was becoming a big part of the shell. Today many Linux (and I know at least FreeBSD) users would never dream of using the shell without "ls" color highlighting. "ncurses" was becoming a bigger part of the shell, with many installation/config programs and even the kernel configuration based on it.

The nature of X makes it anti-change, in a way. They are about mechanism, not policy. You can see some changes in window manager features. If you looked at Linux in 1996, all you would have is twm, fvwm, and a few others. The biggest UI "eye-opener" was probably Enlightenment. But, before E a major change happened rather inadvertently. If you remember, someone made a fake X screenshot which had a transparent xterm. This is what, IIRC, led to a more eye-candy X UI, starting with E which eventually implemented a transparent terminal. Before E, no one really thought X could be "pretty." It always had that dull Motif/tk feel about it.

Later came KDE, followed by GNOME. They have the goal of transforming what is basically a high-graphics shell into a "desktop" with higher program interaction than what was available in the normal shell and X interfaces. X allows small things like copy-and-paste, but has no desire to handle program integration. IMO, neither KDE or GNOME have come very far and I'm not quite sure either are very much more than a glorified window manager + X at this point.

does the causation run the other way round - because all the obscure Emacs keybindings are so well known by its users (and developers), they can't be changed?

I think this is a large part of what is, to some people, "holding Linux back." It doesn't just happen with keybindings, either. The file system layout is a good example. A number of people have wished to change configuration from traditional /etc to something more "sane." There is always a huge argument when that idea comes up--simply because it is tradition.

Commercial *ix might not evolve as much as an open system, but I'm sure the open systems put great pressure on the commercial ones. I don't think you can purchase a commercial *ix today that does not have at least a few GNU-isms, such as gcc for example. Because of the open nature of software, it will evolve. And it will also remain the same. It will grow in every direction that people push it. If Red Hat came along today and said "there will be no bash shell in the next release," many people would have to adapt.

Is this an explanation for why Unix users typically learn more of the intricate features of their software?

I don't think this is the case at all. For me, I have never felt compelled to learn the intricate features of the majority of Linux software. I know a little about most, but usually not everything. I tend to pick it up on an as-needed basis. I'd also say that Linux demands the user to know more. To use pipes, you must first know a little about the shell. To use X, you must know a little about window managers. To use vi, well you need plenty of time and aspirin and a very open mind (coming from traditional text-editors). I would say that every UI that has ever been introduced into Linux is still there. What _is_ changing, is more UI's are constantly being added.

Re:Not on Unix?

[qweqwe]

Definitely. I've worked on both Unix and Windows. Windows "knowledge" goes out of date very quickly since every year or two the old API and UI is put in "maintenance mode" or completely dropped. In Unix, things are more stable.

Suppose you have a programmer in 1992 with 3 years experience and transported him/her to 2002. If that programmer was a Windows programmer, he'd have a hard time finding a job today and have a hard time adapting. If that programmer was a Unix programmer, he shouldn't find it too difficult to find a job or adapt to Linux today.

It's not that Unix hasn't changed much, it's just that most of the changes in Unix are not gratuitous. Technologies are more modularized and centralized and technical advances tend to build on established technologies. Technology and experience are investments so you want to maximize their returns.

In Windows, technology is fashion. It changes regularly and is dumped when it's no longer a buzzword. (Take a look at all the unrelated and obsoleted Windows database APIs that were introduced in the last 10 years.)

For an example of this difference, take a look at the Linux kernel and the Windows base OS. In Linux, nearly every new concept seems to want to use either the mmap model or the "everything is a file" model and follows common initialization and update APIs. In Windows, every new concept requires a new data structure with new APIs and new initialization and update APIs. There's a lot more to learn and programming on Windows tends to be a lot more complicated on Windows.

Are you kidding?

[ObviousGuy]

Except for Open Source Software, versions don't get upgraded so often. But since hardly anyone (1%) are using OSS, it doesn't really make a difference now, does it?

hahaha. *sigh*

Meanwhile, I'm still looking for hardware to load Debian 2.2 onto.

Thats MORE True With Development Environments

[quakeaddict]

look at what MS has done over the past 5 years with database access libraries.

We have had ODBC, Jet (various versions), SqlLib, RDO (various versions), ADO (many many versions). ODBCDirect, and now ADO.NET.

All do the same thing...Open the database, Get The data, close the database, and move on.

It is ridiculous.

Market forces

[David Kennedy]

This isn't a very useful new term - it's not even a new idea. Fact is that there is a central paradox in the world of commercial software - truly successful stuff doesn't sell. Or rather, it sells once, fixes all the user's problems, and you can't sell him anything else.

Without trying to be too cynical, this is a very obvious reason for the re-release of old apps with very minor changes to the previous version. How many NEW features of your latest word processor/IDE (delete as appropriate) do you really use? Chances are very few.

The re-release cycle is a real problem for consumer oriented companies. In a technical/business backend server market (like telecomms or banking) the problem is even worse - shift an app, which will run for ten years trouble free and provide full functionality, once and you may have destroyed your job! Who needs you once that ships?

Nah. Market forces dictate that broken or incomplete software will be much more dominant in the commercial marketplace.

Not "Creativity", indeciciveness...

[Nijika]

I find many developers and many development houses are afraid to lay down the law when it comes to things like usability. My personal philosophy here is that you have to weigh the change versus the impact it'll have on current users. No matter how cool moving the scroll bar from left to right would make an interface, or how much more clear changing a var name from "input" to "input_ts" would make things, it's ALWAYS going to screw people up. And if your product is mature, it'll screw up the users that are already established.

I see Apache 2.0 as an achievement in this regard. When I was researching the new 2.0 branch I was expecting a new mind-bending config that'll destroy most of the work I had done over the years in standardizing my Apache builds; not so.

I can't say the same for every other software package out there, including almost every new major release of RedHat.

This is arguably *the* most critical problem

[coyote-san]

I don't know who this AC is, but my friends and I are very much aware of the consequences of constantly changing the way you do things.

Our focus was on development, specifically why MS developers seem to have arrested development at about the level of 2 years of real experience. This isn't a slam against them - this was so widespread that we knew it had to be environmental.

We eventually figured out that the problem was Microsoft's constant reinvention of the wheel. We focused on the GUI, and compared the fact that we had been using the same libraries for a decade (Xlib for low-level routines, Motif for lists, menus, etc.), while in the same time MS Windows had released something like 4 separate, and incompatible, graphics libraries.

This mean that while we were able to build on our prior experience - and more importantly build on other organization's experiences as we brought in new employees with fresh ideas - the MS shops were constantly struggling to "stay in place" and there was essentially no institutional memory.

To be honest, I think much of the problems with MS Windows applications can be traced to this. After 10+ years of Unix experience, most people have been bitten by a fair number of "it could never happen" errors, and they instinctively take care to avoid a repeat. A MS Windows developer has probably seen as many errors, but how do you map the solution for a library three generations ago to the current one?

Re:This is arguably *the* most critical problem

[Badgerman]

Yes. Yes, exactly.

I'm an M$ developer for the most part (though I'm moving away as fast as my career will allows) and it gets utterly insane. After several years of ASP, VB, ADO development, suddenly I have to deal with .NET.

This is why I'm moving towards PHP, *nix, Java, and C++. This is insane.

Re:This is arguably *the* most critical problem

[mav[LAG]]

There's a quote I once read that sums it up:

"Unix may be a steep learning curve, but at least you only have to climb it once."

I think I finally understand what it's getting at now.

Pure Laziness

[kjz]

It's thus entirely rational not to want to learn this stuff until you absolutely need to use it. But that makes life more frustrating, since it puts you in "learning mode" when you're trying to do something new and possibly stressful...

Rant mode: On.

This is pure intellectual laziness. What is wrong with being in a "learning mode?" We do it our entire lives! Why should someone want to actually stop learning?

I've noticed a very disturbing trend lately. It could just be my perceptions, but it still gives me cause for concern. Many people (both general consumers and professionals in business) don't want to bother learning anything. They want to tackle complex tasks that could never be done before, but insist on not having to learn the tools to do it. I see it here at work with people who insist on holding on desperately to suboptimal programming tools when others would tackle the job more effectively. I even see it in my own family: I once got a call from my mother, while she was on vacation, asking how to access the voicemail for her cell phone. She called me at work, in the middle of the day, simply because she had never bothered reading the instructions from her service provider! (I taught her the meaning of RTFM that day.)

I understand that many products can be difficult to use, especially software. It takes effort to learn these products, and effort to use them. However, very often we barely have the technology working. How can you expect it to be easy to use as well? Automobiles, television sets, and radios are all products that many now consider fairly easy to use. Now ask the question: How long did it take for them to get to be so simple? Some of these products have been continually developed and refined for over a century. Now consider how long VCRs, camcorders, and software products have been around. By comparison, these are all fresh out of the R&D lab!

People need to realize that complex tasks can't generally be simplified overnight. It takes time to find the solution to the problems at hand, and even more time to refine the solution such that it is both effective and efficient (i.e. it requires a minimum of effort to use.) All of the complaining does nothing but add to the noise.

Rant mode: Off.

Thanks for reading. :-)

-kjz

Re:Pure Laziness

[poot_rootbeer]

This is pure intellectual laziness. What is wrong with being in a "learning mode?" We do it our entire lives! Why should someone want to actually stop learning?

There's a difference between learning and re-learning.

If I already know how to perform a certain task in Foo 5.0, I should be able to apply that knowledge when Foo 6.0 comes out instead of digging through
help files trying to figure out why the old method doesn't work anymore and what the new method is.

Adding new features is great. Changing the way existing features behave should be avoided unless there's an overriding NEED to do so

Re:Pure Laziness

[stinky wizzleteats]

This is pure intellectual laziness. What is wrong with being in a "learning mode?" We do it our entire lives! Why should someone want to actually stop learning?

Well, as a technology person, I can understand the sentiment. I too have been frustrated by the dangerous and ridiculous fear most users have of change. But you need to look at things from their perspective.

If you're anything like me, you are concerned with the nuts and bolts of IT. To us, new user interfaces are no big deal. We have to keep learning all the time, or we get like that old bitter, grizzled engineer who sits in the corner and talks endlessly about how great Lantastic was. This significantly divorces us from the world of those for whom IT is a tool, not their job. A lawyer who spends their life keeping up with contract law and reading 100 page briefs on a daily basis simply doesn't have the intellectual bandwidth to deal with where her fucking bullets&numbering button went in the new version of Word. This is not a reflection of her intelligence or ability to learn. It's a simple matter of not having the time.

If we can agree that the problem is unreasonable fear, then I would suggest that this notion that IT exists to serve itself is the real cause for this fear. Users think of us as self-serving elitist upstarts who don't care about their problems. Just look at this thread. Programmers bemoan the idea of writing quality code because it would put them out of a job. I guess I kind of thought quality code WAS their job. If they don't want to do it, then they don't deserve the work. This idea that IT should be a self-sustaining beast without the inconvenience of worrying about bothersome users is short-sighted and unethical.

I am no fan of Microsoft. In fact, I am a rather vitriolic critic. But if there is one reason by which their business success might be legitimately explained, it is that they look at their entire product line from the standpoint of the user. Features such as your Outlook journal automatically keeping track of when you work on Word documents, for example, are very cool toys for the user, but make a huge mess of the back end for us to deal with. They don't do this consistently, and they don't even do this well, (hell, they're the ones causing all this version fatigue!) but they are about the only people out there thinking of the user first and the server room second.

Until we can eschew our elitism, and develop some sense of a work ethic with regard to making IT work for the people who need it, we will not overcome the user fear barrier.

Two sides to it

[Badgerman]

First, I think the article is spot-on. Gods, I'm tired of adapting to so-called upgrades. I rarely upgrade things unless there's a reason, but there are times you're left with no choice (say, a company-wide decision).

The other side of this thats ignored is the programmers. A lot of us are NOT trying to ram out Spectacleware, we'd like to talk to the users, like to go "slow and steady" and don't get the options. We don't often get the chance to make that decision, however, because someone wants something out the door pronto.

Version fatigue? I'd say its being suffered on both sides because the people making the decisions don't care about users or programmers.

Well,

[mindstrm]

I, for one, agree. The longer people keep the same system and the same software, the better they learn it.

I don't buy this stuff about how unix is hard and other stuff is easy... I remember LOTS of yuppie boomers who learned old wordperfect just fine.. and that's certainly not wysiwig. Obscure keypresses, hidden markup codes, they understood it all.. and some were really good at it.

The problem is when things change rapidly. Totally.

Emacs keybindings aren't changed because there is no reason to change them. Nobody wants to re-write all that lisp.