Information Technology Reference
In-Depth Information
Table 5.
Today's Checklist: Configuration Dialogs
Today's checklist is about Configuration Dialogs - we plan to announce more lists every three or four days, for example toolbars, menus,
context menus, color settings, keyboard access, feedback dialogs, and more.
The procedure for reviewers is pretty simple:
1. You pick an application that is already in trunk, but not yet reviewed by another person. See the Wiki page for reference.
2. You open a checklist - today's focus is Configuration Dialogs - and go through the checklist items.
3. For each infringement you find, post a bug. In the title, write “HIG” and the number of the checklist item that is not met (e.g.
CL1/1.1).
4. On the Wiki page of checklists, add a section for the application you reviewed and link all bugs you have created.
For developers, this will probably mean a lot of work. However, many of the “HIG” bugs can be fixed easily by referring to the checklist,
others will be harder. Regarding configuration dialogs, bugs that concern the dialog navigation or size of dialogs can be fixed easily;
problems concerning the categorization or grouping require further analysis.
from interface guidelines help reach a consensus
among project stakeholders.
ally neglected, or requirements are only partly
and simply identified. Moreover, many projects
lack the distinction between functional and non-
functional requirements.
Participatory design is the most prevalent part
of the open usability lifecycle. However, most
distributed projects start with little or no end users.
Therefore, projects initially lack user aid during
the predesign and design stage, hence developers
provide marketing requirements, derive product
usability features and build user interfaces with
the help of their previous own experiences, with-
out access to a group of knowledgeable users.
This results in a continuous re-design during the
development phase, and even after the project
maturity stage. However, the inclusion of end
users does not mean that usability engineers
should be omitted, and the UE processes are left
to end users providing half understood checklists,
unfinished usability tests and unclear results. As
in institutionalized usability process, distributed
projects should deploy HCI experts with a back-
ground in open source software processes, and
preferably, knowledge in open source tools and
applications.
Since not all software engineers have a
knowledge about usability processes and rather
they tend to stick with SE models, our diagram
does not radically modify the SE lifecycle but
rather extends it, so that usability processes are
immersed within the SE processes. This is done
in a way that, if a particular usability activity is
A distributed
usAbility ProCess
Requirements gathering is the first and foremost
step in usability design. Scacchi (2002) claims
that requirements for open source projects seem
to be asserted, rather than elicited. In his paper,
Scacchi examines features of a major release of the
Firefox web browser an attempt to understand how
prevalent this phenomenon is. Using archives of
mailing lists and issue tracking databases, features
of Firefox were tracked from first mentioning to
the release date, to determine how requirements
are proposed, adopted and implemented. In open
source projects, requirements are normally not
aligned with usability requirements, but they are
rather separate, and most of the time usability
requirements (i.e. acceptable levels of user perfor-
mance, effectiveness and satisfaction) are ignored,
giving a higher priority to extracting functional
requirements and data requirements, i.e. structure
of the system or the necessary database model.
Field experts in software requirements engi-
neering propose a set of activities (i.e. process
items) which (Davis, 1990) do not necessarily
characterize an order. A software development
starts with identifying requirements analysis. In
open source world, requirements analysis is usu-
Search WWH ::
Custom Search