Re: [HIG] Naming

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]