Re: [HIG] Naming

[Adam Elman <aelman users sourceforge net>]

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 
context.

> 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.

Adam