[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: Updates to KUA
From: Frans Englich <frans.englich () telia ! com>
Date: 2004-08-25 17:06:56
Message-ID: 200408251706.56541.frans.englich () telia ! com
[Download RAW message or body]
I've done some changes to the KUA project. I know it's going slow, I've been
busy with getting the UIG finished for aKademy.
* The index page was improved:
http://usability.kde.org/kua/current
* The directory layout was changed to be identical to the one the UIG uses;
better and consistent
* I've added a new article; number two: "KDE's Userbase". My plan was to
announce it and bring it to discussion, but with the announcement of the
aKademy people's work, we'll have to sort that out first. I added it to give
a sense of where KUA is heading.
* I lifted the draft status of kua1 -- it's been up for a long time now.
* I did some changes to kua8. I think most people agree so I applied it; the
attached patch is what was changed. Comments are welcome. I also consider
lifting the draft state of that one pretty soon.
What's interesting, and the most important, is where all these documentation
efforts are heading and if/how they conflict-- let's try to solve that in the
documentation thread.
Frans
["kua8_changes.diff" (text/x-diff)]
--- kua8.xml 2004-08-02 02:24:20.000000000 +0000
+++ src/kua8.xml 2004-08-23 23:03:13.000000000 +0000
@@ -1,7 +1,6 @@
<?xml version="1.0" ?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" >
-<?xml-stylesheet type="text/xsl" href="web.xsl" ?>
<sect1 id="kua8" status="draft">
<sect1info>
<authorgroup>
@@ -13,8 +12,8 @@
</authorgroup>
</sect1info>
<title>Discussing Usability Issues</title>
- <subtitle>Usability problems are often hard and
- unproductive to discuss. This article discusses why and gives practical
+ <subtitle>Usability problems are often hard discuss. This article
+ discusses why and gives practical
advices to achieving sane discussions.
</subtitle>
@@ -36,16 +35,16 @@
Simply, if the communication fails, the overall goal will
fail. This is especially noticeble in open source projects
because the social rules usually contains an implicit requirement of
- absolute consensus - if one person objects, the change can not
+ absolute consensus -- if one person objects, the change can not
be done.
</para>
<para>A misconception around usability is it's not scientific but
- "artistic" and vague. This myth needs to be counteracted -
+ <quote>artistic</quote> and vague. This myth needs to be counteracted -
usability is engineering.
</para>
- <para>As a help to keep discussions sane, here is a couple of advices:</para>
+ <para>To help keep the discussions sane here is some advice:</para>
<itemizedlist mark="bullet">
<listitem>
<para>Do not write anecdotes and novells. If you need to
@@ -56,6 +55,13 @@
</listitem>
<listitem>
+ <para>Read the <ulink url="usability.kde.org/hig/">KDE User Interface \
Guidelines</ulink>. + Read twice those sections which concerns your issues. Also
+ read any relevant <ulink url="http://usability.kde.org/kua/">KDE Usability \
Articles</ulink>. + </para>
+ </listitem>
+
+ <listitem>
<para>Don't write long texts. Be short, concise and
straight to the point. What you write must be
meaningfull -- what does a long, rattling and abstract
@@ -68,18 +74,18 @@
<listitem>
<para>Avoid superlatives and subjective adjectives. What do you
exactly mean with
- "very", "much", "honestly", "actually" and so forth?
+ <quote>very</quote>, <quote>much</quote>, <quote>honestly</quote>, \
<quote>actually</quote>" and so forth? Your point should speak for itself and not \
need any
- exagguration. If it does, you should perhaps reconsider
+ exagguration. If it need exagguration, you should perhaps reconsider
its value, and especially why you at all lobby for it.
</para>
</listitem>
<listitem>
<para>
- Be concrete. Saying "contrary what many might have
- you believe, KDE does not have serious usability problems" or
- "I don't see anything which needs to be chopped away from KDE"
+ Be concrete. Saying <quote>contrary what many might have
+ you believe, KDE does not have serious usability problems</quote> or
+ <quote>I don't see anything which needs to be chopped away from KDE</quote>
says nothing because its too general, simple assertions with no
argumentation
or proof(and will hence be replied on a similar primitive
@@ -90,18 +96,19 @@
</listitem>
<listitem>
- <para>Opinions and suggestions such as "my list of things which
- needs improvement in KDE" are of no help and usually looked
+ <para>Opinions and suggestions such as <quote>my list of things which
+ needs improvement in KDE</quote> are of no help and usually looked
upon as dull. No matter how sensible the suggestions are, they
won't be implemented unless you do it yourself. Unfortunately,
- this is how open source usually works -- "Where's the patch?".
+ this is how open source usually works -- <quote>Where's the patch?</quote>.
Regardless of how much time it takes you to do even the
smallest part of your suggestions, it will be more valuable
than the mail <emphasis>discussing</emphasis> what needs to be
done -- actual changes done instead of yet another empty mail.
There is nothing more respectful and appreciated when
a problem is outlined, and a patch
- is attached which fixes the problem.<phrase/>
+ is attached which fixes the problem.</para>
+ <para>
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 -- then you will be one of those
@@ -113,10 +120,10 @@
<para>
However, when suggestions are created and represented in the
correct way, their usefulness is indescribable. Objective
- usability reports is of high interest. Going through the
+ usability reports are useful. Going through the
process of reading and studying how
useful reports are written is admirable, and the result -- an
- objective report -- is one of the most appreciated
+ objective report -- is one of the most valuable
contributions.
The <ulink url="http://www.openusability.org">Open Usability
project
@@ -125,48 +132,110 @@
of course KDE's own <ulink \
url="http://usability.kde.org/activity/usabilityreports/"> Usability Reports
</ulink>
- project is of value too.
+ project is useful too.
</para>
</listitem>
+ <listitem>
+ <para>
+ Avoid the <quote>let's make it configurable</quote> <quote>solution</quote> \
for a problem. + In open
+ source development a practice of adding configuration options
+ to solve a problem is quite common, which often occurs in
+ situations where:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>Users wants something configurable</para>
+ </listitem>
+ <listitem>
+ <para>Developers cannot agree how something should be
+ designed
+ </para>
+ </listitem>
+ <listitem>
+ <para>Developers lacks the motivation to do the extra
+ coding which would render an option unnecessary.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Have a zero tolerance for the "make it configurable" solution.
+ Configuration options which are not needed, adds bloat,
+ hinders simpleness and affects the interface negatively. When a
+ discussion is heating up and the alternatives are narrowing down,
+ or a set of users gets more and more zealous, and "let's make
+ it configurable" comes closer and closer, state explicitly that
+ is what's happening and that is not an option to solve the
+ problem you are dealing with.<!--There's an <xref \
TODOtargetptr="kua10" targetdoc="kua10">article</olink> which specifically deals with \
configuration options.--> + </para>
+ </listitem>
<listitem>
<para>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,
+ For example <quote>On all office landscapes I have seen,
+ they have used ...</quote> or <quote>I know a lot of people who
+ likes ...</quote> since they are anecdotal and subjective,
they will only cause counter arguments of similar
type. Instead, give an example and clearly outline 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
+ 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.
</para>
</listitem>
+ <listitem>
+ <para>
+
+ KDE's usability development is filled by ideas
+ but actual implementation -- code and documentation --
+ is sparse. If you haven't planned to implement the ideas
+ you are about to suggest youself, or literally know someone who will, you
+ should not post your ideas on the usability list because it will
+ be vaporware. Empty words which only are noise and hinders
+ work that will lead to actual result. It is statistically proven.
+ </para>
+ </listitem>
<listitem>
<para>Backup your arguments with references and get
- facts into the discussion. For example, in a
- discussion concerning what types of menu entries
- which should end with "...", the author of this article
- thought his reasoning made
- sense. Ian Geiser, linked
- relevant sections from various guidelines and it
- become clear several sources had a different, unified
- view and the article's author's reasoning had to have some kind
- of flaw.
- Since Ian's references had made it clear who was wrong, the
- discussion
- ended and implementatuib started.<phrase/>
- Perhaps google, or a book at the library can help
+ facts into the discussion. Perhaps google, or a book at
+ the library can help
support or deny your idea? Can how other environments and
programs are designed be a source of inspiration or
be a new viewpoint on the problem?
</para>
</listitem>
-
+ <listitem>
+ <para>
+ Are you user orientated? Do you have the whole range of KDE's users in mind?
+ For example, you can't step onto the usability list and ask <quote>If you \
agree + with bug report X, then vote for it,</quote> because all lists \
surrounding + open source development are filled with people possessing
+ deep technical backgrounds. The majority of users, regular users, are not
+ represented. Help keep KDE's
+ development focused on the Real Users.
+ <!-- TODO link to kua3 once it's up -->
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Don't use the <quote>Company X supports my idea</quote> argument. It is of
+ course valid to argue that a certain design should be used in
+ order to meet user expectations(a matter of consistency towards
+ a user's previous computer experiences), but not because the
+ company is big or <quote>probably is right since they usually do
+ good things</quote>. The idea should stand by itself and be supported
+ by theorethical arguments and user studies -- if that's not
+ possible, the idea should be discarded. In the end, the
+ argument usually bites oneself in the tail anyway, since next
+ time, the favorite company does something radically
+ different(which surely will be pointed out).
+
+ </para>
+ </listitem>
<listitem>
<para>Be aware of the absolute-consensus rule: If a
single person objects to a proposal it will most
@@ -179,7 +248,8 @@
participation be a redundant flamebait contribution? Help
keeping the communication overhead down.
Don't voice your
- opinion for the sake of it.<phrase/>
+ opinion for the sake of it.</para>
+ <para>
Perhaps it would be best if the proposal got accepted
at all, although it has its small quirks - anything
is better than nothing.
@@ -191,7 +261,9 @@
discussions are cumbersome is people react
emotionally. Humans are a creature of habit and become
accustomized to certain behaviors, and when someone
- changes our environment, we naturally get upset.<phrase/>
+ changes our environment, we naturally get upset.
+ </para>
+ <para>
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
@@ -203,12 +275,36 @@
<listitem>
<para>
+ Avoid buzzwords. We are trying to do work here and
+ communicate ideas, it is hard
+ enough as it is. Here's some examples
+ of words with vague meaning:
+
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>Intuitive</para>
+ </listitem>
+ <listitem>
+ <para>Essentially</para>
+ </listitem>
+ <listitem>
+ <para>Natural</para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Be concrete. For example, when you argue for consistency, is it consistency
+ against other desktop environments, the internals of KDE or some user
+ experience? (software or not)</para>
+ </listitem>
+ <listitem>
+ <para>
Don't let your belly button talk but act professionally. KDE
development is not a chance to customize software to ones own
- opinions -- we are developing a <emphasis>product</emphasis>
+ opinions -- we are developing an end result
for a wide range of users, where each feature must fit in KDE's
- overall picture. When you open your mouth, think twice if it is
- of gain for KDE at large.
+ overall picture. Think twice before you send that mail -- does it
+ only gain you, or does it gain KDE's users at large?
</para>
</listitem>
@@ -222,10 +318,8 @@
picture. Practically, if a change disliked by you is
proposed, don't only state what you find negative about it, but
put it in the broader picture and argue how your issue of
- concern is<emphasis>
- more important
- </emphasis>
- than those you find negative. Complete your reasoning, and put
+ concern is<emphasis>more important</emphasis> than those you
+ find negative. Complete your reasoning, and put
all the various aspect in relation to each other.
</para>
</listitem>
@@ -240,9 +334,8 @@
may upset developers and users following
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:
+ who are less fortunate. Perhaps the power user's preference
+ can be pleased by:
</para>
<itemizedlist>
<listitem>
@@ -323,8 +416,8 @@
<surname>Raymond</surname>
</author>
<subtitle>
- This paper contains good advices to being
- tactical in mail interaction with the community.
+ This paper contains advices to being
+ tactical in interaction with the community.
</subtitle>
</biblioentry>
</bibliography>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic