On Mon, Jun 07, 2004 at 06:15:15PM +0200, Ellen Reitmayr wrote:
> Hi Simon,
> > Visually pressing down CTRL or ALT is immediately visible in the tool
> > options: The mode switch will switch accordingly. What else would you
> > suggest to communicate this more clearly?
> When users are concentrated on drawing a path (and at the same time are
> exploring different keyboard shortcuts) they will pay few attention to
> changes in the tool options. Instead, they will give their attention to
> the image area, here especially to cursor feedback (and hopefully the
> status line!). 
> The major problem I see here is that when pressing CTRL (Design mode)
> while the mouse is not located over the path, there is no interaction
> possible (which is shown by the concerning icon). But there is no hint
> in the status bar WHY interaction is not possible. I'm not sure about
> the actual text, but maybe something like 'Move the mouse pointer over
> the path to edit it'(?) would be helpful and support exploration.
i am a long time gimp user.  this new path tool confused me when it
first arrived into the app, and i had watched the development and the
formation of the logic.  i also was never much into using gimp with the
keys as the point that i started back up with computers, the gimp had
buttons for most things.  i learned the key changes back then for the
few things that absolutely needed them.

it took me about two or three times making actual paths (actually using
the app, not testing it).  the logic is there and i actually grew to
like the function.  perhaps i am not in as much need of editing the
points i place as others, but the simple tool option change makes sense
very quickly with actual use.  especially when you understand how the
gimp used <ctrl> and <alt>.

you might be surprised yourself if you were to work with gimp on an
actual project rather than with "usability tests" how quickly this will
make sense.  there is a point in software development where you might
need to give it up and give the new logic a try -- especially when the
concerns might cause de-evolution in a well thought out plan like simon
accomplished here.

the points are not a problem, the crappy libart2 backing is a problem.
this is the sort of opinion you get from actual use of the program.

also, i might add that if you were a piece of software and the gimp
developers were testing you for usability, you might be failing them
right now.

good thing that humans are not software and do not get treated or tested
this way, dont you think?

( /me <ctrl>edits this opinion to prove her point)

> > Basically it is impossible to really compare the path tool in 1.2 and
> > the path tool in 2.0. I have rewritten the Path tool from scratch,
> > removing arbitrary limitations and implementing some new ideas.
> Yes, I know it's completely built from the scratch - and I think it's
> really very good! I tried the 1.2 path tool, and was not happy with it.
> Nevertheless, on the first look, four modes seem to be more intuitive
> than three, as they hide les information from the users. Four buttons,
> combined with simple keyboard shortcuts for a quick navigation, are very
> easy to learn. But when I read this mail, I just realised that the tool
> is way more complex than it seemed to be on the first look, and that
> simple keyboard shortcuts are not realisable. 
it is a difficult balance to have full functionality available to
professional image manipulation and yet be simple enough for new users.

i would like it if there was a way to have everyone with an opinion give
as much thought to the logic of the pathtool design as the author.  even
one tenth of the time thinking through it as simon did.

(it would also be nice if simon thought about his opinions as much as he
did the path tool, but the path tool parts that he wrote are excellent
and the best place to apply logic if you only have so much to spare)

> > Given the prerequisite, that the whole tool should be usable without
> > having to move the mouse back and forth to a buttonbar (jimmac already
> > wrote about this) and the need for a modifier (SHIFT) we have two
> > modifiers left, which lead to the three modes of the existing tool. In
> > theory we could use CTRL+ALT for a fourth mode, but this would require
> > the user of the tool to be quite a finger acrobat and is probably not
> > really a good idea.
> That's true. I just didn't realise that there is such a lot of
> functionality. Further below, you said that the path tool is not for
> newbies, but for people who will use it on a regular basis and willing
> to invest some effort to study it. I know it's a bit sobering, but
> studies on help/manual usage showed that only very very few people
> actually read manuals. That's why an intuitive and easy to learn
> interaction design is so important! 
> I admit that my suggestions were short-sighted, I just did not know
> about the whole complexity! but still I think that especially users who
> are not image manipulation experts need a bit more support with respect
> to the path tool. Especially, a hint on how to remove path segments and
> points is missing. Maybe at least provide a tooltip text for the three
> modes (Design: 'Create new anchors and shape the path', Edit: 'Add
> [Ctrl] and remove [Ctrl-shift] elements' - rough wording).
see here, you are slowly and logically being rewritten the way they
rewrote the gimp.

eventually you might pass their usability tests.

> > So, if you propose to add a fourth mode please also propose a way to get
> > out of the dilemma explained above. I hope you can understand, why I am
> > a bit skeptical about your suggestion.
> Yes, I understand now - really complicated stuff.... 8-) 
> But nevertheless, I hope you don't mind if I think of it some more, talk
> to some colleagues... not to change the conception of the tool, but
> maybe to find some very small and simple solutions to facilitate the
> learning.
thanks for spending the time testing gimp for usability.  i am curious
to know if you have any personal things you used gimp for and if you
could share them with this community.


Gimp-developer mailing list

Reply via email to