[HIG] REVIEW: Introduction & Usability Principles



Introduction
------------
This is a good introduction, the wording just needs to be tightened 
up a bit. It is a bit repetitive. My comments are aimed at tightening
up the text.

First paragraph, first sentence:

"This document tells you how to create applications that look 
_right_..."

The word "right" here seems risky and might be interpreted by
some readers as pretntious. It also seems rather undefined. 
What do you mean by right? What is not right? This word doesn't
convey very much useful information. I would consider rewriting
the first sentence to something along the lines of:

"This document tells you how to create applications that are
usable, behave properly and consistently, and fit into the GNOME
environment as a whole."

I have the same comment for the use of the phrase "to look right"
in the fourth bullet.

First paragraph, last sentence:

"Both specific advice on making effective use of interface elements,
and the philosophy and general design principles behind *the GNOME
interface* are covered."

I think this would be more accurate and sound better if you said,
"...the philosophy and general design principles behind successful
user interface design are covered" instead of "behind the GNOME 
interface." The truth is that the philosophy behind the GNOME 
interface we started with is/was scattered at best...we are not 
documenting everyone's pet interpretations of how to do things; 
what we are pulling together is good design principles.

To simplify this altogether, you could just say, "Both specific 
advice on making effective use of interface elements and general 
design principles are covered." 

To make it even better, and remove some of the redundancy in the
Introduction, combine this sentence with the sentence in the third 
paragraph, removing the third paragraph.The end of the first paragraph
would now read, "Guidelines on basic interface elements, how to combine 
them effectively, and how to integrate your application with the desktop 
are covered along with general design principles and philosophy."

Second paragraph, second sentence:

Spelling error: "thse" > "these"

First bullet:

This bullet has awkward grammar. I suggest changing it to read: 
"Because interface elements will look and behave consistently, users
can learn your application more quickly."

Second bullet:

I'm not fond of "(even advanced users)", I think it plays too much
to the assumption that the reader will be biased against usability
because it "dumbs things down". I think it would suffice to say instead:
"Users, from novice to advanced, will be able to accomplish tasks..."

Also, spelling error, "making" > "make"

Third bullet:

This bullet seems a little redundant with the first bullet. If you
leave it in, I'd change "fits in" to "is consistent".

Fourth bullet:

I have the same issue with "to look right" as mentioned in the first
paragraph. I would suggest changing this here as well.

Fourth paragraph, first sentence:

Minor editing: I would rewrite the beginning of the sentence so it
reads better, "These recommendations build on design approaches..."


Usability Principles
--------------------
I don't know how the end document will appear, but I think something
more noticeable needs to be added to indicate that these 9 pages are
all part of "Usability Principles". Currently, the only indication
is the tiny and easy to miss "Usability Principles" in the header. 
If each principle will appear on its own page in the end document, 
find a better way to indicate that each is a principle.

First paragraph: 

I'd rewrite this, to tighten it up a little, so that it reads: "This
section summarizes some of the basic principles which underlie the 
recommendations in this document. We believe that these principles are
important for all types of application development."

Design for People:

I'd recommend changing the name of this principle to "Design for You
Users". 

First paragraph, first sentence:

The wording "some group of people" is awkward, I think it would be
fine to just say "users".

Second paragraph:

I like the direction the examples in this paragraph are heading
but I think they stop short. They left me intrigued but thinking, 
"okay...so what I have these applications for these types of
users. I probably knew that much already...What else are you trying
to get me to think about?" I think an example would be more helpful
if you simplified it to just one example application and user base
and then provided sample types of questions a developer could ask to 
learn more about that user base. For example, "...you may be designing
an application which will enable engineers to create diagrams. What
types of diagrams will they need to create? What will they want to 
do with these diagrams? Will they want to use these diagrams in other
applications? Share them with other engineers?" See how this makes
the importance of 'Designing for Users' a little more clear?

Third paragraph:

Again, I think the last paragraph is a little vague and doesn't provide
much to the reader as far as next steps to take. I realize this isn't
the place to get detailed, but I would hope we would at least provide
a link to a bibliography or recommended reading list, or provide actual
names for the books and courses we mention off-hand in this paragraph.
If the reader doesn't know how to find the more specific references,
then this paragraph is pretty much fluff.

Don't Limit Your User Base:

First paragraph:

I think the first sentence might read a little smoother as, "Whether
you are designing an application for engineers, children, or system 
administrators,...."

Accessibility:

I would reword the first sentence as follows: "Designing with 
accessibility in mind enables people with disabilities to use your
software." I would stay away from the part about us allowing people
with disabilities to participate in life's activities. That makes it 
sound like they haven't been able to do anything meaningful until we 
came along with 'accessibility', which could offend some people.

I would reword the third sentence as follows: "For example, your
software should support color-blind users by not relying on color 
alone to display critical information. It should support deaf users
by not relying on sound alone to indicate critical information.
Likewise, enabling keyboard equivalents will support users with 
limited movement."

At the end of this paragraph you could also mention that designing 
with accessibility in mind improves usability for all users, not just
those with disabilities, by supprting multiple ways to communicate 
the information in the application.

Will we make specific recommendations geared towards accessibility?
If so, might it be helpful to come up with a symbol to put next to
these guidelines as they do in the JLF guide?

Internationalization and Localization:

Minor nits and edits for the first paragraph: "Internationalization
is the design of software so that it can support different languages. 
Localization is the process of actually translating messages, labels, 
and other interface elements of an application in other languages.

Create a Match Between Your Application and the Real World:

First paragraph:

I like the example used alot, the grammar just needs to be 
tightened up, I would reword it as follows: 
"Your application should always use words, phrases, and concepts 
which are familiar to your user rather than terms from the underlying 
system. The terms you use should be related to the user's concept 
of the tasks your application supports. For example, in medical fields, 
the real-world folder which contains all information about 
a patient is called a "chart". A medical application would be more 
usable for the intended user base if a patient record were referred to 
as a "patient chart" rather than a "patient database record".

Same sorts fo grammar comments for the second paragraph: 
"You can frequently leverage your users' existing knowledge base
by using real-world metaphors. Familiar concepts from the real world
can usefully represent elements within your application. Successful 
metaphors include an image of a folder..."

Make Your Application Consistent:

First paragraph, first sentence: 

One small nit, add "GNOME" to clarify: "Your application should be
consistent with itself and with other _GNOME_ applications..."

First paragraph, last sentence:

I would edit the sentence the following way: "The recommendations
in the GNOME HI Guidelines are designed to help your create..."
Remove the "most of" bit.

Also, if someone is keeping a list of items to track over the whole
document, add "GNOME HI Guidelines" and ensure that all the chapters
refer to the document in a consistent way.

Second paragraph:

Excessive use of commas! Remove the comma after "misapplied" and
"incomplete" in the first sentence. I'm not sure if I agree that 
a misapplied or incomplete consistency is "actually worse" than 
inconsistency. I'd just say, "...a misapplied or incomplete attempt
at consistency can create additional problems."

Second paragraph, second sentence: 

I'd at "with other applications" to the end of the sentence to clarify
why the developer added an "Undo" menu item in this example.

Let User's Know What's Going On:

I might recommend renaming this principle to something along the
lines of "Provide Feedback to the User."

First paragraph:

This is pretty much word for word from the usability report, which
is fine, but I like the wording of the first sentence in the report 
better and would recommend small tweaks so it reads:
"The system should always keep the user informed about what is going 
on, through appropriate feedback presented in reasonable time."

Second paragraph:

This paragraph refers to "determinate" progress indicators, however,
the Feedback chapter, in the Progress Bar section, refers to 
"measured-progress" indicators. We need to agree on terms here and
use them consistently throughout the doc. If a list is drawn up to
track document-wide issues, make sure this and other terminology
issues are added.

Second paragraph, second sentence: 

The word "display" is used too many times and sounds funny; change the
second one to "communicate" or "convey". It is also a bit run-on; I'd 
edit the whole thing so it reads:
"If you display a determinate progress indicator to communicate/convey 
the state of completion of a task and it is inaccurate, the user will
lose faith in progress indicators. They will find the environment...."

Keep It Simple and Pretty: 

I'm not a fan of the word "Pretty" here, it sounds too casual. In the
usability report this principle was called "Aesthetic and Minimal 
Design." Perhaps we could rename this principle to "Keep It Simple 
and Aesthetic"?

First paragraph, second sentence: 

There's an extra "extra" ;) that sounds repetitive. Remove the "extra"
before "interface element competes with..."

First paragraph, last sentence:

"progressive disclosure"...I wonder if this will be clear what you mean 
in UI design terms?

Second paragraph, first sentence:

I'm not sure how an interface can be cluttered-looking if it only has
a few elements? I understand what you are trying to say here...in 
addition to not overloading a UI, pay attention to how the elements
are laid out in the window, whether there are lots of elements or only 
a few. Perhaps it would be more clear to say, "Finally, it is also
important to present your information and interface elements in an 
aesthetically pleasing manner. A disorganized interface can be 
confusing and impede progress, just as a cluttered interface with too 
many elements is often unusable."

Forgive The User:

Second paragraph, last sentence: 

This sentence is a little awkward. I'd change the ending to, 
"...users tend to ignore them or get frustrated."

Enable Direct Manipulation:

I think this principle is misinterpreted from the usability report?
If you read what is in the report it talks about manipulation in a 
different light. I think it is more accurately on the level of a 
usability principle. Here is the Direct Manipulation principle from
the report, it might be worthwhile to consider re-examining what is
currently in the HIG version and replacing it with the text from 
the report:

"Make objects, action, and options readily visible to the user. Users 
should not have to remember information from one part of the dialog to 
another in order to complete a task. How to manipulate the system should 
be readily visible and intuitive at all times. The user should not have 
to guess what to do next."

  

`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°'

                             		s u z a n n a  s m i t h
                         	    v i s u a l  d e s i g n e r         
                       		           sun microsystems, inc 
                                    		     
`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°`°º¤oo¤º°'




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