Re: GNOME usability test report now available

[Matthew Thomas <mpt mailandnews com>]

Calum Benson wrote:
>...
> http://developer.gnome.org/projects/gup/ut1_report/report_main.html
>...
> We're keen to hear your feedback on the report and the
> recommendations, and discuss other ideas and how best to put them into
> practice.
>...

This study is a great resource (albeit that it just scratches the
surface:-). Kudos to Calum and the rest of the people at Sun.

Before anyone runs off implementing the exact recommendations made in
the report, however, it's worth remembering that usability tests are
often excellent at finding problems but not so excellent at finding
solutions. The fact that usability studies and user interface design are
often done by the same people, currently, is probably more to do with
the small number of people involved in the field than it is to do with
any similarity between the skills required for each job.

Three simple examples from the report ...

1.  The report recommends that if the user's login fails, she should be
    presented with error text in the login dialog itself: `The username
    or password you entered in incorrect. Letters must be typed in the
    correct case. Be sure the caps lock key is not selected.'

    That's good, as far as it goes; but generally[a] the best time to
    deal with user errors is *before* they happen, not afterward. Why
    not check whether Caps Lock is on when you first put up the login
    dialog? If it is, you could show a miniature caution icon with
    explanatory text below the fields in the dialog:

    User _Name: [__________________________________________________]

     _Password: [__________________________________________________]

            /!\ Caps Lock is on. If your user name and password use
                lower case letters, try turning off Caps Lock first.

                                                        (( Log In ))

    [a] The exception is when (user's time wasted by the error
        prevention mechanisms) > (probability of error) * (average time
        taken to recover from error). This is different for different
        users; a command line has practically no error prevention built
        in, for example, whereas interfaces designed for mere mortals
        need a lot more.

2.  Test subjects were confused and annoyed that a text file being
    viewed in Nautilus could not be edited. The report suggests adding a
    gray border around the edge of the file to make it look less
    editable, and adding text `This is a read-only view.' at the top.

    That would help alleviate the confusion, certainly. (Though constant
    exposure to the sentence `This is a read-only view.' would probably
    get a bit old after a few months.:-) But it would not alleviate the
    annoyance, because people *still* wouldn't be able to edit the file
    straight away. In other words, this part of the UI would be easier
    to learn, but it wouldn't be any easier to use.

    So, why not just open text files directly in the user's chosen text
    editor, instead of viewing them in Nautilus? That way if a user
    wants to edit a file, she can do that straight away. And if she just
    wants to view it, well, text editors tend to be pretty good at that
    sort of thing too.

3.  The report comments on the dangerousness of `Halt', and recommends
    increasing the spacing between the radio button for `Halt' and the
    radio buttons for `Logout' and `Reboot'.

    However, it's generally a bad idea to use radio buttons for commands
    in the first place. (The existence of the mistake in the Shut Down
    dialogs in Microsoft Windows 95 and 98 isn't, I would hope,
    justification enough for repeating it in GNOME. Windows 2000 is even
    worse, using a popup menu so you can't see all your options at
    once.) Conceptually, radio buttons are for choosing *how* something
    happens, not for choosing *what* happens.

    And with a very basic GOMS model (assuming that each command in the
    dialog is equally likely, and that it is equally easy to find and
    click any control), it's pretty easy to work out that the current UI
    will take 75 percent longer to use than one which just used buttons
    (1.75 clicks as opposed to 1 click).

    +-------------------------------------------------------------+
    |:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
    +-------------------------------------------------------------+
    |  .                                                          |
    | /!\  Are you sure you want to log out?                      |
    | """                                                         |
    |      [ ] _Save my current session                           |
    |                                                             |
    |                                                             |
    |      ( _Halt  ) (_Reboot )          ( Cancel ) (( Logout )) |
    +-------------------------------------------------------------+

    Or, if we substitute more human-readable terminology:

    |                                                             |
    |      (_Shut Down ) (_Restart )     ( Cancel ) (( Log Out )) |
    +-------------------------------------------------------------+

    As always, though, it's better if you can design a UI which doesn't
    require an alert at all. In this case, that would mean finding space
    to provide separate menu items for each of the commands, and making
    them sufficiently difficult to get to that you're sure that the user
    really means it without having to ask for confirmation.

-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/> -- And yes, I'm posting from Mac OS. Sorry.