Re: [Usability] Re: Proposal + RFC: Improving the Bugzilla layout

["Jonathan Vaughan" <vaughan xandmail com>]

I was interested to read the comments on the GNOME Bugzilla interface. I can't
comment on the specific case, but I believe there is a valid lesson here in
terms of the relation between terminology and usability.

In general terms, the problem consists of how to handle the case where an
average person encounters a particular group/tradition that has an existing
vocabulary of commonly-used terms. The meaning of terms is often not obvious
to the outsider. What is the easiest way of helping the outsider to interact
with the group?

Before answering this question it's worth considering a few things:

1. In some cases, the language of the group is intentionally opaque, i.e. its
main function is to prevent outsiders from understanding what is being
discussed, and reinforce the exclusivity of belonging to the group. You see
this all the time with teenagers and the slang they invent. Hopefully this
attitude is rare in the open source community.

2. In all other cases, the vocabulary exists because it serves some purpose,
i.e. it is useful to the members of the group. The terms relate to specific
concepts and enable the group to communicate efficiently without risk of being
misunderstood.

3. If the group and the vocabulary are well-established, a newcomer trying to
introduce a new set of terms for existing concepts is unlikely to meet with
success. The benefits of the new vocabulary are highly unlikely to offset the
considerable hassle involved in moving everyone over to it.

As a child learning music, I remember wondering why it was necessary to
memorise so many arbitrary terms for note-lengths (minim, crotchet, quaver)
and Italian words like adagio, crescendo, forte, etc. Why couldn't they just
use plain English? I could have spent my whole life trying to overturn the
musical status quo, but given the huge amount of printed music, books written
on the subject, and existing musicians, it would have been futile. Instead, I
learned the terms like everyone else, a negligible investment of effort which
was more than worth it in the long run.

Another example: the recent phenomenon of weblogging has brought with it a set
of commonly-used terms which have specific meanings: weblog, blogging, post
(or entry), archive, permalink, timestamp. Suppose I am writing a new
weblogging tool for people with no experience of the medium; should the UI
include these terms, or should I substitute them with more "intuitive"
alternatives?

I believe that the latter is ultimately doing the user a disservice. If they
are interested in blogs, at some point they are going to need to know the
standard terms, so they can understand articles people have written about the
subject, and communicate with other bloggers. Far better to give them clear
definitions of these important words at the beginning, than to pollute their
vocabulary pool with duplicate terms which won't be understood by the outside
world.

The same can be said for someone entering a bug for the first time. The word
"bug" is so widely-used in the software community that the best thing we can
do is to introduce them to the word with a clear definition. People can't
always agree on one, but my personal favourite is

"bug: Anything in a piece of software which deviates from high quality."
(see http://www.kaner.com/pdfs/bugadvoc.pdf)

[I like this one because it's not limited to coding errors; it includes bad
design (however well implemented) and poor UI.]

Simplify the UI by all means, but don't change well-established terms unless
you have an overwhelming reason to - it will only make it harder for the user
in the long run.

Jonathan