Re: levels of compliance



>  back then, several people wanted to turn the style guide into a list of
>  features whose creators refused to produce code. the levels of
>  compliance made sense in that context, but now i puzzle at them: can
>  someone give me an example of how a _rule_ for human interface would
>  meet, say, level 3 compliance or level 4 compliance but not level 1 or
>  2? good human interface design is not limited to whether a feature is in
>  or out; it involves determining _where_ and _how_ the features (_any_
>  features really) are implemented.
>  
>  anybody have some input to clarify this, especially with examples? say,
>  for instance, a simple rule like "a dialog box must have at least two
>  buttons and at most four": ignoring the silliness or usefulness of this
>  rule, how would one determine what "level" it fit into?

There are more or less two kinds of stipulations in the UI Guidelines,
the rules and the suggestions.  Low-numbered compliancy levels were
intended for rules, and high-numbered ones were intended for
suggestions, kind of.  I agree that the distinction is murky, and
maybe we could do away with them and just base things on the wording:

"If your application has a menu, it MUST be like this and this and that"

"If you use a dialog box, you MUST provide a way to close it"

"If you write an application, it SHOULD have complete online
documentation, and if it does, it MUST use the GNOME documentation
framework"

This is pretty much the same wording that is used by RFCs, and we may
as well use it.  I certainly hope that the UI Guidelines will not be
as dry reading as most RFCs, though :-)

  Federico



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