On Wed, 10 Dec 2003, Nathan Hurst wrote:

Please run it and tell us if the behaviour feels right - it is easier to try variations whilst the code is python, rather than C++ (although it is easier to know whether the behaviour feels right once we implement it in Inkscape proper)

If you are labelling these guidelines as `placement aids' then I think the behaviour feels wrong in that they have too much power. Namely the power to resize objects that are attached to them, which moves beyond `placement.' This is a really minor criticism and I see the current behaviour being very useful for doing things like resizing multiple shapes togther.

My suggestion would be for you guys to (in the next prototype iteration) offer at least a couple of shapes in the example window. These types of guidelines are most useful for aligning shapes, and without a couple of shapes it is hard to simulate some of the situations that will likely arise in true editing. Thus, this may enable you to get some more useful feedback.

Feel free to ask questions about our intentions, and suggest extensions that would be helpful. Clearly the prototype is but a taste of what can be done with this new approach (We have several whiteboards worth of ideas to implement :), but it is important to work out the basic interface now.

In particular, what do people think about the two tools behaviour?

I personally found the two tools to be confusing and subtle in their differences. I do understand the differences between them and suspect that the problem my lie in the way they're described (the icons, tooltips and cursors used). The second tool mode is really "Manipulate control points while keeping attached control points constrained (where possible)."

Should this be folded into a modifier key on the selection tool?

Yes, but there needs to be a good visual indicator when this modifier is active, i.e. moving over the control points results in two different cursors, depending on the modifier state. Preferably the user should be able to tell what will happen when they drag the control point before they actually begin moving it.

Is the breaking of constraint behaviour (which control point disconnects when you move something) reasonable, or can you suggest a better heuristic? (Currently the rule that is broken is chosen arbitrarily, perhaps it would be better to break the oldest created relationship, or perhaps the least recently moved?)

This is where you start to get into problems. Breaking things arbitrarily is very bad and will frustrate users, *unless* they can clearly determine the heuristic and predict its results. Additionally, any behaviour that is inconsistent from use to use is terrible from a usability perspective. It may be better to break the oldest created relationship, but if this is not immediately obvious to the user (as the cause of the breakage) then this is just as bad as the current situation. `Least recently moved' suffers a similar problem in that different constraints get broken depending on the order of previous actions. This is also bad because the user is probably likely to think in terms of tasks they are completing and may use two different orders of steps to complete the task without realising themselves, each time leading to a different constraint breakage. Also, what if the diagram has just been opened, how is the decision made then? Perhaps you should be thinking about not breaking the guideline constraint, i.e. have the control point do nothing by instead breaking the mouse constraint. I notice this is what happens if the center and left-middle points are each attached to a seperate vertical guideline and you try and drag the right-top control point. Though there ought to be some feedback to the user here explaining why the control point doesn't have any effect (in one direction) when dragged.

I'm not sure there is a `perfect' solution to this question. But I'll have a bit more of a think about desirable behaviours.

What do people think of the indicators for how control points are connected to guide lines and guide points? Suggestions?

This works for me on one level--I like the way they look when connected. I don't like the way they lose the look of control points. After manipulating them further it is clear they are still control points, though when it first occurs you feel like you've lost the `handle.' My feel is it is a little unnatural to click on and manipulate the `railway tracks' when wanting to break a control point from a guideline.

I also don't quite understand how this is going to work in Inkscape itself either. As Bulia pointed out, the control points in Inkscape are away from the edges of shapes. Also, I notice when a selection contains multiple shapes then these control points represent the edges of the bounding box of the selection. It doesn't make sense for these control points to be attached to guidelines. It needs to somehow be shown that the control point of the shape sharing that edge of the bounding box has become attached. Given this behaviour, you may need to have a seperate second tool to deal with objects themselves rather than the bounding box of the selection.

In any case, I suggest there also needs to be some discussion about how exactly these tools will fit into general Inkscape editing. I know that you were looking mainly for critism of the model rather than implementation details, but such things may need to be considered by your model.

Cheers, Michael