GNOME v. KDE, December 2005 edition [LWN.net]

GNOME v. KDE, December 2005 edition

Posted Dec 13, 2005 19:33 UTC (Tue) by cventers (subscriber, #31465)
In reply to: GNOME v. KDE, December 2005 edition by jdub
Parent article: GNOME v. KDE, December 2005 edition

You're right, but the critical swinging point here is the concept of
'plenty'. You see, you can make lots and lots of users happy (the 5-nines
you refer to elsewhere) by having an advanced desktop that has a
well-designed layering exposing more advanced functionality to more
advanced users as they drill down. The cost is that you will occasionally
get the layering wrong and make small minds be overwhelemed. Here we have
KDE.

The other option is to use the idea that you're designing for the
majority as a reason to not implement features or configurables at all.
You'll *please* a small number of users this way because you're going to
be lucky and get a good handful of them that find not a thing more than
they need. But these people would have been *happy* if you had more, as
long as you managed it wisely. Here we have GNOME.

And I know you've stated that you don't design for the "majority", but as
far as I can tell you're just saying that:

>> That's a very different class of user to, say, my doctor. He's a smart
>> guy, but totally doesn't give a shit about computers. I want to make
>> Free Software that works for him.

Is the "totally doesn't give a shit about computers" not the majority
crowd? What exactly do you call it if the word "majority" is banished?

(Log in to post comments)

WYSIAYG

Posted Dec 27, 2005 0:03 UTC (Tue) by Baylink (subscriber, #755) [Link]

The problem on point is referred to as What You See Is *All* You Get, and it's the traditional argument made against GUI's by command-line partisans, as well.

It *is* a problem, though, and the *real* problem that it is, is this:

Non-power-users *don't stay that way*.

People learn. And regardless whether your interface failed to scare them away when they were newbies, if they *can't get their work done* now that they're *not*, they're leaving, anyway.

So the "progressive complexity" partisans are the ones closest to right.

The as-yet unsolved problem is one corollary to "*why* is that menu item greyed out when I want to use it?" -- *how* do you let the user know that there are more powerful commands hidden from them that are pertinent to what they're doing?

Once someone comes up with a good, portable, intuitive solution to that which app writers can deploy without great pain, we'll really be going somewhere.

You heard it here first. ;-)