Get Involved/Quality: Difference between revisions
(Created page with '__NOTOC__ == Becoming a KDE Tester == Testing|leftIn the early 2000's there was a specific team at KDE which was focused on finding loose ends in KDE appli...') |
Carlsymons (talk | contribs) |
||
| Line 2: | Line 2: | ||
== Becoming a KDE Tester == | == Becoming a KDE Tester == | ||
[[Image:testing.png|Testing|left]]In the early 2000's there was a specific team at KDE which was focused on finding loose ends in KDE applications and tying them together. This was a task of user case studies, writing articles, documentation, creating missing artwork for | [[Image:testing.png|Testing|left]]In the early 2000's there was a specific team at KDE which was focused on finding loose ends in KDE applications and tying them together. This was a task of user case studies, writing articles, documentation, creating missing artwork for consistency, and other miscellanea. Ultimately, this team contributed patches of code and documentation that really rounded out the KDE experience. This team is not active currently, and people that are doing this type of effort are generally working alone and are focused on specific use cases and tasks. If you are interested in an independent project like this, please continue reading for some ideas. | ||
== Communicating with the team == | == Communicating with the team == | ||
Revision as of 16:47, 7 January 2012
Becoming a KDE Tester
In the early 2000's there was a specific team at KDE which was focused on finding loose ends in KDE applications and tying them together. This was a task of user case studies, writing articles, documentation, creating missing artwork for consistency, and other miscellanea. Ultimately, this team contributed patches of code and documentation that really rounded out the KDE experience. This team is not active currently, and people that are doing this type of effort are generally working alone and are focused on specific use cases and tasks. If you are interested in an independent project like this, please continue reading for some ideas.
Communicating with the team
There is no active KDE quality team, but if you are interested in contributing improvements to KDE, you will be well received at #kde-devel on irc.freenode.net.
Context Help: Whatsthis
Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.
Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).
Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: WhatsThis Tutorial, by Aaron J. Seigo.
Application Help Or Manuals
More information is available at Getting Involved: Documentation
User Interface
User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.
It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it.
The KDE Usability Mailing List is very active and a good place for discussing your ideas, and their homepage is at http://techbase.kde.org/Projects/Usability. If you are already an usability expert, please check OpenUsability.org, a project that brings open source developers and usability experts together, and is collaborating closely with KDE.
Some documents guiding documents include the KDE User Interface Guidelines (design standards) and KDE User Interface Guidelines (design principles).
Some projects for analysis of user interfaces may include: checking that shortcut keys are coherent across KDE applications, making sure that dialogs are directly relevant to the interaction that the user would expect, and finding users of KDE software to see how they perform common workflows.