--Boundary-00=_VA6ABPt/0rWS4fM Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Frans, I went through KUA 2 and made some additions and improvements (attached). I= 've=20 slightly toned down some of the language, but the overall message is still= =20 very much there. I really felt your pain in that document. I am a power use= r=20 and I totally agree. Let me know what you think. Cheers, David =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBA6Al53OaWc7M8G0RAoDLAKCfU27FMx7EqBPFaGLgOOUsIZArGgCgnKm+ U3VenZ3g2N3hVJXEi8nnyM8=3D =3DHn5R =2D----END PGP SIGNATURE----- --Boundary-00=_VA6ABPt/0rWS4fM Content-Type: text/plain; charset="iso-8859-15"; name="kua2" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="kua2" Name: KUA2 KDE's userbase Description: Defines KDE's userbase and discusses how it should be consider= ed 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, whic= h are determined by its users. Therefore, it is crucial to have a clear und= erstanding 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 ho= lds true for the areas considered to be part of the 'desktop environment', = not KDE programs in general - although it may apply anywhere. =46or clarification, "regular user" is defined as follows: A person who uses a computer as a tool to achieve a task but is not interes= ted 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= =2E The person does not have an understanding of the components of the syst= em, such as the distinction between KDE, the X Windows system or even the k= ernel. 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 accompl= ishing it. A regular user knows nothing about how the inner workings of sof= tware and hardware work, just as a driver knows how to drive but doesn't kn= ow 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 to= ol 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 r= oles 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 o= r 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 twea= k 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 syst= em.[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 use= r" 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 th= e task done (with the help of a computer), while the latter's goal is to "p= lay" or use the computer. The computer is the goal, instead of the task. Se= eing this difference is important because power users (a minority) submit f= eature requests, which when implemented are severe drawbacks for regular us= ers (the majority). It cannot be stressed enough how important it is to have a clear view of wh= at a software's userbase looks. If the definition of the userbase is wrong,= the wrong features are implemented (looking at the userbase), or are imple= mented badly (feature bloat). Some aspects of software design are only affe= cted by how the userbase looks; for example, the selection of default confi= guration values. Unfortunately, it can be very complicated and difficult to have a proper an= d realistic view on a software's userbase when involved in open source deve= lopment. When surrounded by fellow programmers with deep technical backgrou= nds, 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 pe= ople 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 a= nd long time Linux veterans who have a deep knowledge about their computer = systems. Open source software, and indeed KDE, is used in production enviro= nments, ranging from laboratories, schools, companies to government agencie= s. These are all regular users who need pragmatic software to cut time, and= increase productivity. That realisation needs to be made within the develo= pment 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 u= sing KDE to get everyday tasks done. This is a mark of great success, and i= s a measure of how far KDE and open source software have come in a few shor= t years. When it comes to decisions that depend on the userbase, for example the phr= asing of a piece of text, a developer's instinct cannot necessarily be trus= ted because regular users are not part of the usual open source community a= nd 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 goo= d 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 o= ften encountered are best left ignored. For example, widely accepted usabil= ity principles becomes "dumbing down" and "dumb blondes". People may very w= ell be right, but, taking the userbase into account, why are they right? W= hy 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 m= ind. An attitude of "it works for me" is not a recipe for continuing the fa= ntastic success that KDE has in encouraging people to use it for everyday t= asks, 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 prob= lem described in this KUA. The situation best described as "engineers desig= n for engineers". Apple's way of describing this, and solving it, can be fo= und in the Apple Human Interface Guidelines[2]. This is called the "80 perc= ent rule": "During the design process, you may discover problems with your product des= ign. You can use the 80 percent solution to help determine how to solve tho= se problems. The 80 percent solution means your design meets the needs of a= t least 80 percent of your users. If you try to design for the 20 percent o= f 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 h= ave good ideas and probably think a lot like you, the majority of people ma= y 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 surround= ed by the 20 percent - the power users. For example, if one developer sugge= sts a change which is in favor of the 80 percent then many developers may h= ave a personal preference against it, which may even stop the suggestion al= together. Therefore, an awareness and a considerate understanding of these = issues is necessary. In other words, since it is impossible to please all u= sers, the best alternative is to compromise, and design the software for th= e majority, the regular users. Hence, designing GUI programs is, by definit= ion, very difficult. Since everyone cannot be pleased then majority-thinkin= g must be adopted, politely discussing any exceptions along the way. What w= ould be even more detrimental would be to solely design for a minority, pow= er users for example, and leave the majority in the cold. This would comple= tely ignore the success, and the incredible number of everday tasks, that K= DE is used for all over the world today. The differences between the two user types should not be exaggerated. Usabi= lity as a science, has its roots in how we humans work - physics, memory, e= yes, 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 differen= ces are smaller than many would believe. There are many common denominators= , that, when improved, improves things for everyone. However, in those case= s 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 pra= ctical purposes. Either the power user's interest for fiddling is left out,= or workaround technologies, such as KConfigXT, can be used. In the vast ma= jority of cases, this should be totally feasible. Similarly, the power user= 's enthusiasm for applications where a fair amount of technical expertise i= s 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 elsewh= ere - usually in other applications. KDE software needs to be efficient, pr= oductive, and should be available and accessible regardless of whoever need= s 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 ensur= e that people all over the world are able to continue to use KDE for the ta= sks which they perform on daily basis=20 The above may sound all very reasonable, but what it means in practical ter= ms, and how it is all used within actual development is not obvious. Theref= ore, two KUAs exist that discuss two topics closely related to how divergin= g interests can be handled: KUA7 - feature bloat, and KUA10 - configuration= options. =46ootnotes 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 --Boundary-00=_VA6ABPt/0rWS4fM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kde-usability mailing list kde-usability@kde.org https://mail.kde.org/mailman/listinfo/kde-usability --Boundary-00=_VA6ABPt/0rWS4fM--