Sven wrote:

you have been working on an updated specification for the rectangle tools in GIMP 2.4. The current state is here:

http://gui.gimp.org/index.php/Specifications

under construction, btw...

First of all, could you please move this specification to its own page and link to it from the specifications page? We will want to have lots of such specs and the current page is already getting too long.

Yeah, might as well do it now... done.

Then I have some comments. These affect two things, the handles and how
they are drawn and the handling of the cursor keys. Both are aspects that already worked pretty well over the last development releases and
it is somewhat unfortunate that you suggest that they are changed again.
But my critiscm is not due to that fact but simply because the suggested
changes feel like a regression.

'Worked pretty well' is not the same as solving the problem, and achieving a result that I'd be proud to show my user interaction or usability colleagues.

Martin already implemented aspects of the new corner handles in SVN, so
one can easily try it.

I had to revert my svn to see what you are seeing. I had a sunday evening patch from Martin applied.

Once again thanks from my side for Martin, he's been 'on fire' all weekend.
It is a pleasure to work with him on getting the spec implement, and use the in-between results to fine-tune some of the handle proportions.

When the mouse is moved over a side handle, a side handle and two corner handles are drawn. If I want to reach the corner, I aim for the highlighted rectangle. But when my mouse reaches it, it turns out that what was highlighted as the target area is actually a dead area and nothing happens when I click and drag there. I
don't think this is acceptable behaviour. The highlighting of the side and corner handles before the change was much easier to predict. Perhaps
we should go back to that?

I see what you mean. I realise now that I have been looking at these highlighted side handles since the weekend and thought: 'ah, a corner-handle-and-a-half.' The problem is the 1-pixel solid line, and I have changed the spec to make them stippled. That will make them subtler and different... done.

The other aspect is not yet implemented. The spec suggests that when the
mouse is over one of the corner or side handles, and one of the cursor keys is pressed, the rectangle shall be resized by one (shift: 15) image
pixel in that direction and (new) the the canvas shall be scrolled in such a way that the position of the bounding rectangle under the sprite
shall be constant.

I don't think that scrolling the canvas is a good idea. The reason is simple. We can't currently scroll beyond the canvas. As soon as that is
changed (probably not for 2.4), we can review this part of the spec. But
currently it would just feel akward. Sometimes the canvas would scroll,
sometimes it wouldn't. For the user it is hard to predict what will happen. So I suggest that we don't do any scrolling and that a note is added to the spec that this part should be reviewed when bug #362915 is
fixed.

OK, all things considered, I am going to put on ice the goal of keeping the mouse sprite stable on the handle.

Changed the spec... done.

--ps

principal user interaction architect man + machine interface works

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

Sven Neumann writes:

http://gui.gimp.org/index.php/Specifications

[ ... ]

The other aspect is not yet implemented. The spec suggests that when the mouse is over one of the corner or side handles, and one of the cursor keys is pressed, the rectangle shall be resized by one (shift: 15) image pixel in that direction and (new) the the canvas shall be scrolled in such a way that the position of the bounding rectangle under the sprite shall be constant.

I don't think that scrolling the canvas is a good idea.

If the canvas isn't scrolled, the spec should probably mention what happens on the next keypress. Suppose I have the mouse cursor over a side handle and I press right-arrow. The side handle moves right by one image pixel. Now the side handle is no longer under the mouse. If I press right-arrow again, I hope it would move another pixel, since arrow keys aren't very useful if you can only move one step.

But that requires that the tool go into "keyboard navigation mode" where the tool remembers that one handle is active and is subject to being moved by arrow keys even if the mouse is no longer over that handle. How will the user see that it's in that mode? I'd suggest keeping the handle outline bold with the 2-pixel border described in the spec, even after it moves out from under the mouse cursor. But if the mouse moves (more than some threshold?) then un-highlight the active handle and go back to normal mouse-activated mode.

Of course you could warp the mouse cursor to follow the handle, but I doubt anyone wants to do that, especially in an app used with graphics tablets.

Sven,

On Wed, 2007-07-04 at 17:24 +0200, peter sikking wrote:

If I want to reach the
corner, I aim for the highlighted rectangle. But when my mouse reaches
it, it turns out that what was highlighted as the target area is actually a dead area and nothing happens when I click and drag there. I
don't think this is acceptable behaviour. The highlighting of the side
and corner handles before the change was much easier to predict. Perhaps
we should go back to that?

I see what you mean. I realise now that I have been looking at these highlighted side handles since the weekend and thought: 'ah, a corner-handle-and-a-half.' The problem is the 1-pixel solid line, and I have changed the spec to make them stippled. That will make them subtler and different... done.

Sorry, but how does that solve the problem?

by using different graphics (stipple) we avoid that these two lines are interpreted as showing corner handles. They don't.

They show the edges of the side handle area, giving feedback, confirming why and training where the side handle highlights.

You can see that compared to the previous 2/3rd side handle, these ones fully use the predictability the the corner handles gives us, by being in one dimension exactly the same size as the corner handles. They are shorter in the other dimension, to create a gap so one can reach the corner handles. This gap is actually bigger than in the 2/3rd situation.

The result is a side handle where it is easier to predict its boundaries,
making them slightly quicker to grab.

Not only are the new handles larger in area, they are also more 'square' in aspect ratio than the long and slender 2/3rd situation. Each of these factors make the new handles again slightly quicker to grab, on top of the one above.

That is three speed factors accumulated, and they together deliver the increase in ease of use that I envisioned when going for big handles for the select + crop tools.

--ps

principal user interaction architect man + machine interface works

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

Sven,

On Wed, 2007-07-04 at 21:04 +0200, peter sikking wrote:

by using different graphics (stipple) we avoid that these two lines are interpreted as showing corner handles. They don't.

Well, if they don't show the corner handles, what do they show then?

The exact area where the side handle is sensitive for mouse-over.

This creates a cause-and-effect relationship for the highlight and helps to stay inside, showing the edge so that you can see that you are close to the edge.

And isn't it important to show the corner handles?

Not when highlighting a side handle. The corners have nothing to do with that.

The user might be heading for the corners.

Unlikely, since the corridor to get from the centre to a corner handle is bigger than ever. So chances of unwanted flashing are lower than ever.

With the old setup, the corner handles were always present, even if the user moved over the side handles when moving towards the corners.

No. They never were. Spec and implementation up to now have been that when a a side handle highlights, no corner handles are shown. This is to show that you move the whole side, and nothing but the side.

Now quite often when I try to reach a corner handle, the side handle jumps in my way and the target area that I am heading for disappears.
This is slowing me down. A lot. I don't see how this is an improvement.

Not reproducible with svn of noon today.

May I ask if you are really doing graphics work, or trying out the new rectangle code?

The side handles are fatter, fitting exactly with the corner handles (the whole purpose in sentence). And they are easier hit, if you are heading for the side handle. But with 100% predictable new side handle size and larger go-to-corner corridors, there is no doubt that this is a real solution for what we are trying to achieve.

Like everything in GIMP I must design for what is most efficient in the long run. This goes at the cost of having to get the hang of it.

--ps

principal user interaction architect man + machine interface works

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