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