> > When the anchor is shown next to the mouse pointer, it must always
> > be possible to anchor the selection.
> I haven't been able to reproduce that problem. Of course the cursor
> feedback needs to match what happens. Can you give details on how to
> reproduce this brokeness?

Maybe it's also a SuSE problem? It usually happens after
scaling/transforming a selection. If the user selects the rectangular
selection tool after having finished the transformation, there is an
anchor displayed next to the mouse pointer. However, anchoring does only
work by selecting the corresponding menu item.

> > Move the 'Fill' and 'Stroke' functions to the 'Selection' menu.
> I don't think these belong there since they do not manipulate the
> Selection. Where do other apps put "Fill"? IMHO it belongs into the
> "Edit" menu and I am surprised that the users didn't look for it
> there.

The problem about menu structures is that it is hardly possible to meet
all the users' ideas and conceptions. Also, there is an important
theorem in usability: 'You are not your user'. This concerns both,
developers and usability stuff. Just as you, I was also surprised that
the users did not look for stroke in the 'edit' menu - which shows once
more that the theorem is correct. Nevertheless, a small usability test
as the one conducted is not representative, especially to make decisions
about such important (and sensitive) things like the menu structure. 

To identify the most fitting menu structure, 'card sorting' with about
100 users is the best method. My colleague should set up a tool to do
this online, which I wanted to use for the GIMP. But unfortunately, the
tool is not yet finished.... 



Ellen Reitmayr          email: [EMAIL PROTECTED]
Usability Engineer      mobil: +49.177.3325867
relevantive AG          fon:   +49.30.23455630
Zehdenicker Str. 21     fax:   +49.30.23455639
10119 Berlin            web:   www.relevantive.de

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply via email to