Hi Leonard,
Leonard Mada wrote:
Hello,
1. I will firstly comment some of your previous comments.
2. I have looked onto your suggestions.
- I would prefer the non-merged methods.
With many objects (as i already wrote) there will be a problem with
normally only having 256 alpha steps and being not able to use them all.
This is a good argument for the merged method.
- there are some problems with some of the methods, see new Test Case
Yes, that's why i still presented all possibilities. I said i prefer the
'fat transparent outline, merged'. Do You see problems there? Please
argument.
- all these methods are inferior for *non-filled objects*
Why? The examples work well without filling, too. It's not enough to say
'inferior'. Arguments, please?
What about comments for my other points? I repeat them here:
>- it's uniform for all selections (filled and non-filled)
>- it solves the problem of hidden objects
>- it does as much WYSIWIG as possible (filling is not disturbed, line
still visible. Line fill mode is less important as area fill, anyways)
>- it can be created deterministically
>- it supports different selection colors -> high contrast support,
system selection color support
>- supports big and very small objects
>- the selection generates attention and a good overview on the first
look (this point is opinion-based :-))
Without comments and argumentation, i take this as consent.
3. I will write an expanded comment when I get some free time, detailing
a severe limitation of all selection methods (except the method using
arrows), and will draw a flow diagram, how to implement the arrows
selection
1. COMMENTS
Armin Le Grand wrote:
... 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.
Up until now, all selections involved 2-3 objects from 3 objects. Real
life work may involve substantially more, like 10-20 objects from 10-100
objects. Here it does make a difference and a big one.
I do not want to draw an exaple for that, but 10-20 fat arrows will not
give a good first-sight overview in my opinion.
There is one *BIG LIMITATION* of all current selection modes and I will
detail it in a new post. The arrows selections will offer a very elegant
solution, so I will have to expand that when I get a little bit more
free time.
However, as I pointed out previously, I may want to accurately move and
place a selection near some other object based on some colour
characteristics. A border or an overlay, will hinder me in doing this
accurately. If I just wanted to copy the selection into a writer
document, than probably any method is right.
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.
SHIFT or CTRL+MOUSE CLICK+MOVE (works best in some other programs)
Nothing Joe-user will like, as i already argumented. I see no real new
arguments against my last ones here, repeating Your statements is not
sufficient.
Actually, everything is quite simple. ...
guessing :-)
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.
Really, no guessing. *ANY arbitrary* point will do it OK. When I will
have a little free time, I will draw a flow diagram how the code should
look like. And it does not involve any guessing. IF arbitrary sound like
guessing, than rename it: take point most close to the upper left
corner. If that point overlaps/ is overlapped by something else (I will
detail it in flow diagram), move a little bit away, until NO overlap
anymore. This is no guessing.
In Your examples, there is a 'default' visualisation and a user-edited
one which is seen as optimal. This involves the initial one not being
optimal (else editing would not be necessary) and being one of many
possibilities. Choosing one from many possibilities is not deterministic
-> i call this guessing.
BTW: Which point do You choose in Your own example for the non-visible
circle? There is no 'NO overlap anymore' situation as You describe here.
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?
YES. Consider working with > 10 objects. They are usually overlapping,
that's my experience.
I want now to select some objects.
What is the most *easy and fast* method of selecting the objects?
Draw one big rectangle around them. But usually this selects
*non-wanted* objects, too.
Definitely agreeing here.
*How do you deselect these unwanted objects?* This is a problem.
Yes. Problem goes into two parts:
(1) reception of which objects are selected
(2) changing that.
Until now we discuss (1). I would like to clarify (1) before starting
point (2) to not mix things up.
Having such a method will make things *much, much, much* more easier for
Joe-user. [As a hint to my next post, it will deal specifically with
this problem and with arrows.]
No new arguments either. Joe-user is lost nowadays with using a
master-page mode. He will be more lost with three selection modes.
Kind regards,
Leonard Mada
Leonard, thanks for Your comments.
I am sure with a lot of exceptions and special handling something like
the arrow-method is possible and can be handled. I am also sure that for
each argument i give You, You can find another 'work-around' which
solves it more or less.
The point is not that - with enough exceptions - the arrow method can
not be made working, but that it already showed up that it will be very
complex (and not deterministic) when handling all that cases. More
complex than alternative, existing methods. More complex than necessary.
Please consider the interaction criterias from software ergonomy:
- being intuitive
- keeping things simple
Now compare the discussed possibilities and follow the argumentations.
Count the arguments (not the repeats) and make a conclusion.
I invite all co-readers doing the same and add their comments.
I already stated my conclusion and repeat it here: The arrow method is
too complicated. Editable selections and multiple selection modes are
too complex for a mass application (for Joe-user).
I still hope for completely different ways to handle things. I am sure
there must be alternatives some people think about. Please write them
here for discussion!
------------------------------------------------------------------------
---------------------------------------------------------------------
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]
