Collaboration in Open Source Domains - Collaborative Technologies and Applications for Interactive Information Design - page 175

Table 4.

Kmail
New Print | *Check Mail^ | *Reply^ *Forward^ | Previous Next | Trash | Spam Ham | [User-defined Tags]
Konqueror Web
Previous^ Next^ Refresh Stop | Home Bookmark [URL]

Open source development process is transpar-
ent. Developers work on the Internet, mostly in
an asynchronous manner, in order to collaborate,
communicate and cooperate with the help of
a variety of tools with a basic complexity (i.e.
instant messenger) to a greater complexity (i.e. a
comprehensive document sharing system). These
tools help projects define and enforce some rules
as required in order to ensure a seamless team-
work. Likewise, much of the usability work is
transparent to users, hence everyone is invited
and encouraged to provide feedback to the HIG
(Human Interface Guidelines) developed, which
in turn will be populated in a Wiki like page for
review process. For example, the following excerpt
is from the weblog of a KDE (an open source
desktop environment) developer.

to his proposal, and upon debating on the new
interface design using a collaborative approach,
mentioned improvements to the user interface are
expected to be merged in the new human interface
guidelines.
Another usability activity seen in distributed
projects is bug-hunting seasons. For example, in
the scope of KDE 4 usability review cycle, KDE
HCI working group announced the HIG hunting
season, which is an experiment to include the
community into the search for obvious infringe-
ments of the KDE HIG. This procedure is also
backed by the projects, and end users analyze
applications, by reporting user interface and
interaction issues that can be stated like bugs.
Users are asked to find points which disturb a
seamless use experience, such as inconsistencies
among applications, incomplete keyboard access,
missing feedback, or overloaded configuration
dialogs, toolbars or menus. This way, applica-
tions can be transparently analyzed and tested by
anyone using a given checklist early before the
UI becomes mature. Usability bugs are reported
directly in the bug tracking system tagged with
the attribute “HIG”, so that it could later be easy
for developers to search and fix a list of tagged
bugs during the review cycle. Table 5 shows a
checklist from a bug-hunting season.
Nichols and Twidale (2002) give a comprehen-
sive outlook on how usability experts and open
source developers work in a distributed manner.
In their paper, authors explain how design-by-blog
works in a way to leverage the design the UI and
wait for comments in order to let the design evolve
by time using pure end user participatory design
methods. Alternating screenshots, textual com-
mentaries and rationales, often giving examples

This is obso1337.org's weblog. She posts toolbar
guidelines for generic KDE4 applications. Rather
than using graphical rich explanation of how to
describe the toolbar contents, she uses text based
rendering of Kmail (a web client for KDE) tool-
bar, giving examples from different distributions
and focusing on less cluttered and less confusing
configuration. Among 19 responses to her blog,
there are questions and comments from develop-
ers of different applications, end users and other
usability experts. The main debate focuses on the
use and aim of Back and Up buttons.

In another blog, a developer gives a proposal
regarding the toolbar icon organization of an
open source e-mail client (Table 4). In her text
base diagram, split buttons are denoted by ^, icon
separators are denoted by | and notes are denoted
by * . There have been more than 18 responses