[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Usability Certification (Was -- Re: Usability Strategy Discussion)
From:       Robert Watkins <robert_maria () yahoo ! com>
Date:       2002-07-09 11:04:31
[Download RAW message or body]

>If we
>assemble checklists of proven facts done by .>
>other
>usability researchers, >then 
>we can help developers look critically at their
>applications and identify> 
>their problems.
I think this is where we get stuck. There is no
research by Usabilty people that come up with any
hard and fast rules. The answer is 'It depends'.
A perfect example is presenting options to users.

You could use menu options, buttons, hotkeys,
etc. menu options work well when there are lots
of options that get used infrequently (but don't
get me started on the importance of organizing
menus...) Buttons work well for options that are
used frequently and hotkeys work well when
efficiency is important. Individually, each is a
good solution to a particular problem, but if you
take the MS Office approach and use all of these,
you can end up with a mess that's hard to sift
through as a user. I don't expect the checklist
to have much value from a Usability standpoint.

Similarly, suppose a programmer creates a
checklist for new developers that addresses which
sorting algorithm to use. The answer is 'it
depends'. Are you trying for low overhead? Are
you working for speed? What is the nature of the
data you're working with? Does the whole list
need to be sorted or can a sample do? With so
many options, you decide that you won't talk
about sorting algorithms on the checklist and you
end up with a checklist that says check your
spelling and indention variable naming
conventions and don't use public variables unless
you absolutely have to. This type of checklist
doesn't seem to have much value.

>If we provide 
>documentation, then the developers have an
>opportunity to help themselvesI think this is a good idea. A list of resources
would be helpful. I'll post some below.

>There can also be a
>companion to a checklist that 
>explains WHY these things promote usability for
>those who want to read mo>re.
I'd rather reference books on the subject. The
WHYs can get pretty lengthy.

>As for the process (paper prototypes, etc.), we
>can also post that as a ">How 
>to develop with usability in mind" (damn that
>phrase sounds familiar....)>.  
>so we do things like:
This list is a great list. I've included a link
below to help out with this.

RESOURCE LIST
-----------------------------------------
WEBSITES
http://www.useit.com
http://mail.asis.org/pipermail/sigia-l/2002-May/000950.html
http://www.infodesign.com.au/usability/paperprototypinggraphics.html

BOOKS
Usability Engineering - Nielsen
Information Architecture - Rosenfeld and Morville

AUTHORS
Jakob Nielsen
Don Norman


====--------------------------------------------------

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]