[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-11 20:11:57
Message-ID: 200407112112.17109.segedunum () actuaria ! co ! uk
[Download RAW message or body]

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

On Sun, 11 Jul 2004 00:06:00, Frans Englich wrote:
> Let's get the website up first, and some of the KUA's all other depends on
> (#1 and #2) before we go loose on the others. Otherwise we'll drown :) 

Hi Frans,

I've looked over the first KUA document (KUA1), and I've made some changes 
just to make it a bit more coherent. Let me know what you think. There are a 
couple of bits I didn't understand, so I've put these in brackets with a 
couple of question marks after them. Feel free to come back with some 
clarification.

All in all, it seems like a sound basis and a sound rational for further work.

Cheers,

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

iD8DBQFA8Z8R53OaWc7M8G0RAhmEAKCcEZp78IgKgVEIKAyLQARSiJKHaACgpLcn
T6FmVQn8EoLGJBIh11NV1Qg=
=z3of
-----END PGP SIGNATURE-----

["kua1" (text/plain)]

Name: KUA1 KDE Usability Articles

Description: Describe the Purpose of KDE Usability Articles and How They Should be \
Written

KDE Usability Articles(KUA) will exist to promote KDE's usability by filling the gaps \
usability guidelines do not. KUAs may discuss any subject, large or small, \
extensively or not, as long as it concerns KDE and usability. A KUA must describe a \
usability development approach or guideline for KDE. It is not a forum for a general \
discussion of usability issues, although the KUA may be applicable in cases outside \
KDE. Thus, a KUA is a resource of knowledge and techniques within the field of \
usability. Interface guidelines dictate designs by convention while a KUA describes \
and builds general knowledge around the subject. This will make it easier to make \
good decisions on the subject of usability, and to back them up.

The approach is similar to how knowledge in other areas is communicated within the \
open source community. Like HOWTO's and FAQ entries, a KUA deals with one subject \
thoroughly. Using such an approach, it is possible to gain and spread knowledge abou \
the field of usability on a pragmatic, ad hoc, basis. Thus, a KUA may take an \
abstract discussion, a historical perspective or reasoning behind different \
approaches. However, it must, in any case, result in easily understood, concrete \
ideas which can be directly used in development by anyone.

An oft forgotten, but still important branch of usability, is accessibility. This \
needs to be leveraged, and its importance communicated to the rest of the developer \
community. As such, a KUA should be used to discuss an accessibility perspective \
whenever possible.

A KUA may well take an educational form - its purpose is, afterall, to share \
knowledge about usability. The KUA should contain examples, discuss the problem and \
explain the rational behind the usability development approach it describes. A KUA is \
intended as a resource to spread and share knowledge in, and about, the field of \
usability.

KUAs use non-ambiguous and non-confrontational language in order for as many as \
possible to understand it and take part in the discussion [1]. (For several reasons \
it does not, to the extent possible, take for granted and either explains or refers \
to references)??. A KUA should provide adequate reasoning and concrete examples to \
remove any ambiguity. Ideally, and wherever possible, a KUA should be able to be used \
as a basis for action within KDE.

A KUA could be entertaining or "thought provoking", but not to the extent that its \
content or meaning is compromised, or the text is interpreted as being flamebait - \
i.e. too provoking. (Regardless of the form, acceptance and authority must be \
obtained.)??

Changes to existing KUAs, and the addition of new ones, should be granted and \
conducted in the KDE developer community. A KUA should never be considered done, and \
it should always be improved upon and corrected. It is of utmost importance that the \
quality is not compromised, and both care and time is spent on achieving a good \
result. If not, then the KUA under construction, and the KUA concept in general, will \
fail to achieve their goals. Quality outweighs quantity.

Each KUA must be licensed under an appropriate open source license, as per the OSI \
organization's definition[2]. This should include a correct copyright notice, as well \
as license header, as per the KDE Licensing Policy[3]. The GNU Free Documentation \
License is recommended.


Footnotes
[1]
William Strunk, Jr. The Elements of Style

[2]
OSI's definition of Open Source

[3]
KDE Licensing Policy



_______________________________________________
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]