Re: [HIG] Naming
- From: Adam Elman <aelman users sourceforge net>
- To: hig gnome org
- Subject: Re: [HIG] Naming
- Date: Wed, 7 Nov 2001 10:43:38 -0800
On Wednesday, November 7, 2001, at 08:31 AM, Kathy Fernandes wrote:
While I agree that design decisions should be based on user testing,
are there design conventions such as action names, order of menu
contents, shortcuts that we want to "strongly encourage" (require?)
developers to use (to ensure consistency across applications within a
system)? Are there some guidelines that need to be stated as "shall"
rather than "should" so that this happens?
I mentioned in my general comments on the must-fix changes that I
believe that stronger language in general is necessary in the HIG, and
that there _are_ cases where I would add "shall" and "must." For
instance, "Radio button groups must have a default selection." Others
have commented that there are always exceptions to any rule; I think
that given that this is a policy document which is subject to change and
not some immutable document of law, it's perfectly reasonable to use
"shall" and "must" in some places. So I'd vote for including this kind
of language frequently in the policy doc.
Adam indicated that the document is "more of a guideline/policy doc
than a how-to manual." Will there be a policy statement on what it
means for an application to be "GNOME-compliant" with regard to its
user interface? Is a "compliant" application one that "must" follow
the guidelines? Or can a "compliant" application diverge from the
guidelines if the divergence is justified by usability testing?
Well, unfortunately, software design is not an exact science; there are
plenty of cases of applications on Mac, Windows, and every other
platform which are technically compliant with the appropriate set of
usability guidelines, but are still totally unusable. "Compliance" with
any set of design guidelines does not guarantee usability.
That said, I think that some decisions have to be made on a
platform-wide basis, and some can be made on an app-by-app basis. User
testing should not, for instance, justify a change in the shortcut keys
used for cut, copy, and paste, or the name of the Quit command; it
might, however, justify a change in the standard menu structure -- an
additional item, or the removal of an item that doesn't make sense in
As someone who provides UI direction to a diverse group of application
developers, I find it difficult to make policy pronouncements related
to "doing the right thing" with regard to usability when the guidelines
contain "should's" rather than "shall's." When time and funds are
limited, developers tend to "defer" addressing usability considerations
if they are not stated as application requirements. I'm not advocating
that the content of the HIG change, only that these questions be
discussed at some point (if they haven't been already).
I think there has been plenty of thought in the overall GNOME Usability
Project on how to get GNOME developers to think more frequently about
usability; the HIG is one aspect of that, but it is definitely not the
only one. The problems are, unfortunately, more complicated in an
open-source project than they would be in a more business-oriented
environment (it's slightly more difficult to make the "you need usable
software so people will buy it" argument :), but that's definitely an
issue that Seth, among others, has been trying to address.
] [Thread Prev