[ADMIN] Moving on.

[Frans Englich]

On Saturday 10 July 2004 06:12, Thomas Zander wrote:
> On Friday 09 July 2004 21:35, Frans Englich wrote:
> > I think the line
> > between the two is vague(for example: is it only experts who's allowed
> > to preach on usability-devel? )
>
> The answer is still the same as last time you asked:
> https://mail.kde.org/pipermail/kde-usability-devel/2004-February/000009.htm
>l
>
> kde-usability itself gets to keep the users and semi-experts discussions
> since cutting those off is counter productive. You still want input, and
> users can have good ideas as well :)

That approach won't work. There is no Usability Experts -- how would you 
distinguish "them"? By education? What if we did the same on the lists that 
concerns programming/c++? I'm sorry, but this sounds medieval, elitistic and 
practically impossible.
I wrote about this Expert Myth:
http://programming.newsforge.com/programming/04/07/07/1640244.shtml?tid=25&tid=26&tid=2&tid=31

Regarding Cornelius' "You got it. I was subscribed to kde-usability several 
times. I will not do it again." :
Problems does not get solved by ignoring them. Those who find them belonging 
to the upper-class and suitable for kde-usability-devel, can simply use their 
Expert Knowledge and tell us others what we are doing wrong.
If we can't handle users and wrong statements in one place, we won't be able 
to do it in another - you are not correcting the false statements but locking 
out voices(which is dangerous in itself) in a way which will not practically 
work.

I don't see myself as an expert(anyone who does should be shot, of course) but 
my plan is to take kde-usability to a level where we can reach substantial 
achievements. For example, the attached "kua8" is one tool which can help us 
with that, once the KUA concept is up and rolling, more about that here:

http://lists.kde.org/?l=kde-usability&m=108939865814380&w=2


Cheers,

		Frans






-------------- next part --------------

Name: KUA8 Discussing usability problems

Description: Usability problems are sometimes hard and unproductive to discuss. This KUA discusses why and what possible could be done to easen.


Discussing usability issues in the sense open source projects such as KDE do, is difficult. Compared to other subjects such as solving programming tasks or other of technical art, usability discussions have a much heavier communication overhead, noticed by the harsh words, the overall frustration, their sheer size and that proposals stalls; it resulting in no changes, despite their good start. For example, usability changes which are directly committed tends to be accepted while ideas of the same magnitude brought up to discussion ends in such a way it would not be acceptable to commit.

This is a major problem because at the heart of any problem solving lies the discussion, and cultivation of the problem. Simply, if the communication fails, the overall goal will fail. This is especially noticeble in open source projects because the social rules usually contains a requirement of absolute consensus - if anyone disagrees, the change can not be done.

Since there is extensive knowledge in computer science related topics, those are easy to discuss. The open source movement have during its long existence, always pondered those issues and thus there is strong resources - knowledge, online books, HOWTOs and so forth. Hence, it is easy to have an exact and rational discussion since people can be told to RTFM[1] and especially, the discussion is deterministic - it behaves like science.

A misconception around usability is it's not scientific but "artistic" and vague. This myth needs to be counteracted - usability is engineering. This faulty view, combined with the lack of resources and knowledge in the field, is most likely heavy contributors to why discussions tends to be emotional, opinions instead of reasoning, and thus the inproductivity.

The best way to solve this communication problem is to spread knowledge in the usability area, write HOWTOs, guides, books and similar so discussions and decisions are based on facts. While the pool of common knowledge in the usability field grows, the discussions will gradually become more sensible, and reach the same level the technical discussions have now.

While the open source community's pool of knowledge will gradually grow, there is many things one can keep in mind about the actual discussion.

* Do not write anecdotes and novells. If you need to explain a certain way something is used - give a short example, not a story, and explain why it applies to the common case. How a program is designed usability wise, is heavily affected by the userbase - KUA2 discusses this in detail.

* Don't write long texts. Be short, concise and straight to the point. What you write must be meaningfull and help development. 

* Avoid superlatives. What do you exaclty mean with "very", "much", "honestly", "actually" and so forth? You should not be subjective and vague, but exact with a scientific approach.

* Opinions is not of interest. KDE has thousands of supporters which each one has a personal opinion. Suggesting changes and motivating it with your own opinion won't work and is a wrong way of solving problems. Instead, reason why the current interface is wrong and suggest a solution which is correct. For example, opinions like "contrary what many might have you believe, KDE does not have serious usability" is of no use and flamebait for that matter too.

* The last thing KDE needs is vapourware - empty promises. If you have a this Brilliant Idea it will only happen if you write yourself. We all have our own Super Duper Ideas we are occupied with and anyone who talks/whines about how certain improvements and additions needs to be done without doing something about it, will simply be ignored. There is nothing more respectful and appreciated when a problem is outlined, and then in addition an attached patch fixing the problem.
Start small. Find a text which can be phrased better, locate it in CVS(that's the  hard part), change it, and send the patch to the list(which will result in an actual improvement, instead of yet another opinion on what needs to be fixed). Learn to edit Designer files and a small portion of C++, and you can do miracles.

* Do not use arguments based on personal experience. For example "On all office landscapes I have seen, they have used ..." or "I know a lot of people who likes ..." since they are anecdotal and subjective, they will only cause counter arguments of similar type. Instead, give an example and clearly show how it applies to the general case. The only case where arguments are allowed to be backed up by user statistics is when they are created properly - clean and objective usability reports. Build theoretical arguments, it's needed anyway and is usually the easiest way to reach a non arguable conclusion.

* Backup your arguments with good references and get facts into the discussion. For example, in a discussion concerning what types of menu entries which should end with "...", my reasoning made sense(I, of course, thought so). Ian TODO, linked relevant sections from various guidelines and it become clear several sources had a different, unified view and my reasoning had to have some kind of flaw. Since it was unarguable I was wrong, and Ian triumphing with his strong support, the discussion ended and we started implementing and continued with other things.
Perhaps google, or a book at the library can help back up your idea? Can how other environments and programs are designed be a source of inspiration or be a new viewpoint on the problem?

* Be aware of the absolute-consensus rule. If a single person objects to a proposal it will most likely be stalled. In other words, be absolute sure your opinion/objection is of value before airing it. Perhaps it would be best if the proposal got accepted at all, although it has its small quirks - anything is better than nothing. In general, it is good to be concise and straight to the point because then people find it worthwhile to read your mail.

* Probably the largest contributor to why usability discussions are cumbersome is people react emotionally. Humans are a creature of habit, become accustomized to certain behavior and when someone changes our environment, we naturally get upset.
If someone propose to change a default behavior or remove a configuration option, why do you react as you do? Perhaps your customization with the old behavior prevents you from seeing alternatives? Is the way you want it representative for the whole userbase, and not only the usergroup you belong to?

* Sometimes users and developers feel upset by a change against their viewpoint or personal preference. For example, a change in favor for regular users, but not as profitable for power users, may upset developers and users following the development, and they will try to hinder the change. Then it can useful to provide alternatives to those who are less fortunate. To continue the previous example, perhaps the power user's preference can be pleased by:
-) Suggest implementing the functionality in a plugin, and place it in a module not shipped to regular users
-) If it concerns an option, make it available via the Configuration Editor. If the code is not yet converted to using KConfigXT, the parties interested can scratch their itches
-) If it is heavy configuration functionality not suitable for KConfigXT, implement it in a KCModule, and place the library in another module not shipped to regular users
-) If detailed information is to be removed, print it to standard out instead
-) How a program is designed is subjective with respect to the userbase, as discussed in KUA2. If a user group's interest is not compatible with KDE's, it can be pleased by writing a program specifically for that usergroup - there is plenty of place in the repository.

TODO
ESR how to ask questions

Footnotes

1.
RTFM, short form for Read The Fine Manual. There are variants of the F-word, though. More abbrevations are covered in the Linux Kernel Mailinglist FAQ:
TODO