Raphaël wrote:

>> Let's look at the user requirements: for a _moment_
>> you want to see what you are _doing_ at high magnification,
>> while working on a _macroscopic_ scale.
> I would like to know why you state that the user requirements
> include showing for a _moment_ what you are doing at high
> magnification.

the first mail in this thread does, also the
"I really _miss_ this feature!" mail by Steve Stavropoulos does.

The macroscopic and momentarily aspects are the core of this problem.

> If the view of the zoomed-in area does not overlap the normal
> work area, some users may be equally interested in seeing at
> all times[...]

> To me, the argument that the zoomed-in area should only be
> displayed for a brief moment is far from obvious.

different use case. I already said that additional tracking views
of the same file at different magnifications will solve that.

back the the problem of this thread.

>> I add here that to be able to be of help, the magnified
>> area needs to have a strong relationship (closeness) to
>> the actual mouse position, but always needs to be out
>> of the way.
>> everything speaks for a key-triggered loupe.
> Again, this is far from obvious.  You state that it "always
> needs to be out of the way" but there is no real way to
> ensure that it is _always_ out of the way

this does it:


it is always out of the way where the mouse and the attention is
(centre of the smaller circle).

> The user
> may still be interested in some context around this area in
> order to be able to align things, repeat some pattern, etc.

my solution involves a switch (on/off of the loupe) to do that,
your solution involves a switch (user views out/in of the main
window) to do that.

the problem with your solution is the cost in screen real-estate
minimum 100x100, which force the loupe window to be small, and
not see the surrounding of the point of interest at a generous
magnification. It is also by definition farther away, being non-
overlapping with the man window, which is not what one wants when
performing finicky surgery.

The way for the future for GIMP UI is to display a lot more things
on the fly, just when one needs them, and only the truly universal
things fixed in the inspectors. Can already get used to the term HUD
(heads-up display).

>> during the moment that one is focussed on the detail
>> there is plenty screen space to put a really sizeable
>> loupe window, and it will be automatically close, but
>> also automatically out of the way.
> You assume that focusing on the detail means that the user
> lost interest in the context.

during those 1-2 seconds. It is actually physiological.
you angle of view narrows to a few degrees, when concentrating.

> This is not always the case.
> If you do not let the user position the high magnification
> area (as would be possible with an auto-tracking view), then
> the key-triggered loupe would probably have to support a
> combination of modifiers so that the user can tell GIMP: "no,
> don't pop it up somewhere above my mouse pointer, but rather
> somewhere in the lower left corner, or somewhere far to the
> right".

see the linked picture above, close and always out of the way.
very cool.

gg: I am not going to forbid anyone to pop up a loupe while
the mouse is down.


         principal user interaction architect
         man + machine interface works

         http://mmiworks.net/blog : on interaction architecture

Gimp-developer mailing list

Reply via email to