[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: An aid for usability development
From:       Segedunum <segedunum () actuaria ! co ! uk>
Date:       2004-07-25 11:57:07
Message-ID: 200407251257.42059.segedunum () actuaria ! co ! uk
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Frans,

I went through KUA 2 and made some additions and improvements (attached). I've 
slightly toned down some of the language, but the overall message is still 
very much there. I really felt your pain in that document. I am a power user 
and I totally agree.

Let me know what you think.

Cheers,

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBA6Al53OaWc7M8G0RAoDLAKCfU27FMx7EqBPFaGLgOOUsIZArGgCgnKm+
U3VenZ3g2N3hVJXEi8nnyM8=
=Hn5R
-----END PGP SIGNATURE-----

["kua2" (text/plain)]

Name: KUA2 KDE's userbase

Description: Defines KDE's userbase and discusses how it should be considered when \
designing and building software.


Be it software, furniture, or indeed any object, the userbase dictates its design. A \
product provides features, solutions for problems and needs, which are determined by \
its users. Therefore, it is crucial to have a clear understanding of how the userbase \
is.

The KDE developers has agreed on this definition of KDE's userbase:
KDE's userbase consists of the majority of regular users. Power users, such as KDE \
developers, are a minority of the total userbase. The definition holds true for the \
areas considered to be part of the 'desktop environment', not KDE programs in general \
- although it may apply anywhere.

For clarification, "regular user" is defined as follows:
A person who uses a computer as a tool to achieve a task but is not interested in the \
inner workings of the tool itself. The person does not know any computer languages \
such as C++ or BASH, or even what a computer language is. The person does not have an \
understanding of the components of the system, such as the distinction between KDE, \
the X Windows system or even the kernel. The person wants to achieve their task as \
fast and as efficiently as possible, and they are not interested in how the system \
goes about accomplishing it. A regular user knows nothing about how the inner \
workings of software and hardware work, just as a driver knows how to drive but \
doesn't know or understand the parts that make it up.

A "power user" is defined as follows:
A person who uses a computer as a tool but is also interested in how the tool works \
and other aspects which are irrelevant for accomplishing the task at hand. An \
advanced user may tweak and configure the system for the fun of it, but a regular \
user does not.

However, it should be noted regarding the two definitions above, that the roles are \
not always clearly defined. A regular user has no understanding of the concept of a \
regular or a power user - they simply know what they want to get done. Most of the \
time the regular user will not tweak the system or an application, but this does not \
mean that it will never happen or that tools that allow it should be ignored. When a \
user wants, or needs, to tweak a system or application depending on their \
environment, and this is made prohibitively difficult, the user cannot get the task \
they want to complete done effectively. This also, invariably, generates apathy \
towards the system.[1]

Notice that a more "advanced" user, who perhaps uses keyboard shortcuts or other \
means of working more effectively, would not fall into the "power user" category but \
be counted as a regular user. The distinction lies on what the two different types of \
users focus on. The former focuses on getting the task done (with the help of a \
computer), while the latter's goal is to "play" or use the computer. The computer is \
the goal, instead of the task. Seeing this difference is important because power \
users (a minority) submit feature requests, which when implemented are severe \
drawbacks for regular users (the majority).

It cannot be stressed enough how important it is to have a clear view of what a \
software's userbase looks. If the definition of the userbase is wrong, the wrong \
features are implemented (looking at the userbase), or are implemented badly (feature \
bloat). Some aspects of software design are only affected by how the userbase looks; \
for example, the selection of default configuration values.

Unfortunately, it can be very complicated and difficult to have a proper and \
realistic view on a software's userbase when involved in open source development. \
When surrounded by fellow programmers with deep technical backgrounds, exchanging \
views on IRC channels and the spirit found on sites such as Slashdot and the like, it \
is easy, and quite natural, to think the only people using open source/KDE software \
are power users. As this KUA points out, that is not true. Open source software is \
now least used by power users and long time Linux veterans who have a deep knowledge \
about their computer systems. Open source software, and indeed KDE, is used in \
production environments, ranging from laboratories, schools, companies to government \
agencies. These are all regular users who need pragmatic software to cut time, and \
increase productivity. That realisation needs to be made within the development \
community, and is something to be celebrated. Just one example of how KDE is being \
used in this way can be seen on the KDE Enterprise website at \
http://enterprise.kde.org/interviews/internationalhout/ - a real company using KDE to \
get everyday tasks done. This is a mark of great success, and is a measure of how far \
KDE and open source software have come in a few short years.

When it comes to decisions that depend on the userbase, for example the phrasing of a \
piece of text, a developer's instinct cannot necessarily be trusted because regular \
users are not part of the usual open source community and as such, are not always \
part of the discussion. They do not hang out on IRC, or express their needs and \
opinions on the various forums. It is a good idea to keep a healthy distance from the \
attitude found on sites such as OS News, the Dot, Slashdot and so forth. The elitist \
and cynical comments often encountered are best left ignored. For example, widely \
accepted usability principles becomes "dumbing down" and "dumb blondes". People may \
very well be right, but, taking the userbase into account,  why are they right? Why \
are they wrong?

Considering how many people all over the world use and depend on KDE, each \
contributor has a responsibility and a duty to keep this wide audience in mind. An \
attitude of "it works for me" is not a recipe for continuing the fantastic success \
that KDE has in encouraging people to use it for everyday tasks, and as such, is not \
in line with the overall mission KDE has.

Open source software is certainly not the only area suffering from the problem \
described in this KUA. The situation best described as "engineers design for \
engineers". Apple's way of describing this, and solving it, can be found in the Apple \
Human Interface Guidelines[2]. This is called the "80 percent rule":

"During the design process, you may discover problems with your product design. You \
can use the 80 percent solution to help determine how to solve those problems. The 80 \
percent solution means your design meets the needs of at least 80 percent of your \
users. If you try to design for the 20 percent of your target audience who are power \
users, your design will not be usable by the majority of your users. Even though \
those 20 percent are likely to have good ideas and probably think a lot like you, the \
majority of people may not be like the 20 percent who are elite users of your \
product. Involving a broad range of users in your design process will help you find \
the best solution for 80 percent of your users."

Within KDE, and open source software in general, designing and implementing for the \
"80 percent" of the userbase, is difficult because one is surrounded by the 20 \
percent - the power users. For example, if one developer suggests a change which is \
in favor of the 80 percent then many developers may have a personal preference \
against it, which may even stop the suggestion altogether. Therefore, an awareness \
and a considerate understanding of these issues is necessary. In other words, since \
it is impossible to please all users, the best alternative is to compromise, and \
design the software for the majority, the regular users. Hence, designing GUI \
programs is, by definition, very difficult. Since everyone cannot be pleased then \
majority-thinking must be adopted, politely discussing any exceptions along the way. \
What would be even more detrimental would be to solely design for a minority, power \
users for example, and leave the majority in the cold. This would completely ignore \
the success, and the incredible number of everday tasks, that KDE is used for all \
over the world today.

The differences between the two user types should not be exaggerated. Usability as a \
science, has its roots in how we humans work - physics, memory, eyes, and psychology, \
and those properties stay the same regardless of what interests we have. The, \
sometimes zealous, detestion for regular users that the power user community \
sometimes has is real shame, because the differences are smaller than many would \
believe. There are many common denominators, that, when improved, improves things for \
everyone. However, in those cases where the power user's interests do not equal those \
of the regular users' (the majority), action must be taken.

The power user's desire for configuration options in itself, cannot always be \
fulfilled by using configuration dialogs that are used by people for practical \
purposes. Either the power user's interest for fiddling is left out, or workaround \
technologies, such as KConfigXT, can be used. In the vast majority of cases, this \
should be totally feasible. Similarly, the power user's enthusiasm for applications \
where a fair amount of technical expertise is needed to get them working, cannot be \
equated with the applications that the vast majority will use. These needs but have \
to be taken care of elsewhere - usually in other applications. KDE software needs to \
be efficient, productive, and should be available and accessible regardless of \
whoever needs it. Of course, that goal isn't always going to be practical in every \
case, but it is certainly something that KDE should strive for. This will ensure that \
people all over the world are able to continue to use KDE for the tasks which they \
perform on daily basis 

The above may sound all very reasonable, but what it means in practical terms, and \
how it is all used within actual development is not obvious. Therefore, two KUAs \
exist that discuss two topics closely related to how diverging interests can be \
handled: KUA7 - feature bloat, and KUA10 - configuration options.

Footnotes

1. Theo Mandel: Elements of User Interface Design, page 51. Golden Rule #1: Place \
Users in Control 2. Apple Human Interface Guidelines, March 29 2004



_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]