Hi Leonard,
Leonard Mada wrote:
Armin Le Grand wrote:
You can simplify this to one case: The User makes a selection to
transform object properties. This may be geometrically (move, scale,
transform somehow) or graphically (line, fill, shadow, transparence,
all...). Since simple things are always better (to understand and to
handle) i would prefer to not handle selection for different cases
(and have to guess what the user wants to do next) but in a single
case. I would only make an exception if it is really unavoidable.
This discussion was intended to justify, why I am certain that one
selection type won't suffice. Implement at least 2, better 3. Do NOT try
to guess what is best. Give the end user the choice and let him select
the method he prefers best (and is most suitable for his usage).
I have seen no good arguments up to now for multiple selection views,
especially when we have suggestions which do not need it.
But I am happy that we agree that guessing is bad, but it's not me and
my suggestions which include 'guessing'.
drawing only a portion of the border, NOT on the whole length.
So which part to leave off? If i understand You right here, it's again
something to 'guess', here which 60-30% to leave out. This is not a
deterministic approach and will need some KI ('guessing code') again?
NO guessing code. Give user the option to change % of border drawn (let
it even be 0% - 100%) and give him the option to move it around the object.
So You want an extra interaction to move the selection? Normally, a
klick and move on the selection is the start of the object manipulation.
Users will not remember (believe me) in which mode they are and be
unable to manipulate objects.
What happens when the user changes from 100% to 50% visibility, which
part of the selection do You not paint initially? I call this guessing.
Arrows pointing to object
Question to II: Why is it possible here to 'place selection point' ? I
thought, the selection point is the common point in a multi-selection
and lies in the center of gravity? If this is the case, You cannot
'place' it here as needed.
This leads to another problem: In single object selection, the center
of gravity and the selection point (arrow head) would be the same
point -> only a point to visualize a single selected object?
Question to IV: How is the position for the circle on the rectangle
'guessed' ? How is it positioned? This also seems not deterministic to
me.
Actually, everything is quite simple. I choose some particular positions
so that everything looks perfect. ;-)
guessing :-)
*But this is NOT needed*, and especially it is not needed to compute
beforehand. IF center of gravity overlaps the arrow (as in the one
object example), put it slightly away from center of gravity. This is
the only requirement for the code.
This is one of many exceptions required for the code when doing what all
the stuff You intend. The visualisation of the selection is a single
exception handling.
For non-filled objects, select the middle of the line/curve (for open
objects) or some arbitrary point on a closed-object. And let the user
*move* these points. That would be great.
'some arbitrary point' -> initial guessing again.
Most important: let user be able to move "the point" (with e.g. shift +
left mouse button + mouse move) and adjust everything automatically (the
arrows), so that the most visually appealing selection is produced. (As
you mentioned, implement also to move the whole selection when moving
the point without pressing shift, ..., and there are many other advanced
possibilities.)
Do You really think there are users out there who make a selection, see
it's not showing what they want (they will not be pleased, maybe it was
their last usage of OOo) and are willing to 'edit' the selection before
being able to use it?
The users want to get work done (-> edit objects), not edit nice selections.
BTW: The qualifiers are already used, there is no free one for another
extra editing stuff. More qualifiers make things again more complicated.
The normal Joe-User does not work with qualifiers, he does not even use
the context menu, barely double-click. All bust be offered as simple as
possible.
C'mon!
Let's talk about stuff where all this is not necessary and also solved.
There are possibilities. Your suggestion is getting just too complicated.
Maybe You should take a look at some software ergonomic papers, they
clearly show that being intuitive and keeping things simple are the key
factors for good user interactions.
The goal is to make handling easier as it is now, Your model is no
candidate for this from my point of view.
I will look over the weekend to your suggestions.
Kind regards,
Leonard Mada
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Greetings, Armin Le Grand
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
