--Boundary-00=_N8Z8AorMLVbz3dS
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=2D----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 :)=20

Hi Frans,

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

All in all, it seems like a sound basis and a sound rational for further wo=
rk.

Cheers,

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

iD8DBQFA8Z8R53OaWc7M8G0RAhmEAKCcEZp78IgKgVEIKAyLQARSiJKHaACgpLcn
T6FmVQn8EoLGJBIh11NV1Qg=3D
=3Dz3of
=2D----END PGP SIGNATURE-----

--Boundary-00=_N8Z8AorMLVbz3dS
Content-Type: text/plain;
  charset="iso-8859-1";
  name="kua1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="kua1"


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

--Boundary-00=_N8Z8AorMLVbz3dS
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=_N8Z8AorMLVbz3dS--