Thinning out of Impress: New Spec for Object Selection Positioning and Modification

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Frank Loehmann
Hi,

A new specification about the selection and positioning behavior in Impress/Draw is online:

http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt

Specification is work in progress and describes changes from the current implemented behavior.

Feedback welcome!

Best regards,

Frank

P.S. Thinning out Impress homepage can be found here: http://wiki.services.openoffice.org/wiki/Renaissance:Impress

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Jaron Kuppers
Hi Frank,

I have some questions/comments in no particular order:

1.1.2.4 Multi-selection behavior
I am not sure if this behavior will be natural to the user, especially for
object sizing.  It is not clear to me how many users make use of groups so
limiting their ability to rotate or size a multi-selection of objects may
not be a good idea.  I personally would benefit from that change since I
make use of groups often but I am unsure about what is in the best interest
of all users.

Multi-selection behavior: "special" (yellow) handles
In Multi-selection behavior how do you propose the "special" (aka the
yellow) handles behave?  a) Special handles are not accessible, b) A change
in one handle changes all the other handles by the percentage change in the
original, ie if two smileys are selected and one is changed to a frown, then
both become frowns, c) only the object of the special handle being changed
is affected.  I would vote for option "a".

Multi-selection behavior: guides?
How will "guides" be affected when moving a multi-selection? - If you turn
on "Guides when moving" under Options>OOo Draw>View, how will the guides be
drawn, a) each selected object will have its guides drawn, or b) guides will
be drawn as though the objects were a group?  Obviously, if option "a" is
chosen, guides will appear as though option "b" was chosen (since naturally,
the selected shapes define the bounding box for a multi-selection).

Object handle colors:
It seems green handles are for curves and groups, and teal handles are for
complex shapes.  It may make more sense to give groups a unique handle
color, especially since it is possible to have a group with only one object
(in which case the bounding box will not indicate to the user that the
object is a group since it is the same size as the bounding box for the
object alone).
Slightly off-topic:   Why do we have two different rectangle shapes, the
"rectangle" in the drawing toolbar, and the "rectangle" under "Basic Shapes"
which do by the way function differently? (Perhaps the second is a "rounded
rectangle" with no rounding)?

Group selection cursor:
I am not sure whether this is a good idea (it may be too much information
for the user) but perhaps there could be a unique selection cursor for
groups.  (I am thinking perhaps a color change of the white cursor, instead
of an additional icon; a color that matches the object handle colors for
groups).  Since double-left-click behavior changes depending on the object
the mouse is over, it makes sense to indicate to the user what they are
mousing over.  Also, this would prevent confusion if a user forgets which
objects are in a group when trying to make a multi-selection (aka they tried
to select one object in a group but instead selected the group).

Rotation point snap positions:
Setting the rotation point to the exact feature of an object can be
prohibitively difficult (ie, setting the rotation point to a corner).
Perhaps there could be a way that when users have on "snap to grid" that the
locations of the handles be automatic snap points for the rotation point.
Likewise if the new proposed modifier key is pressed (alt, although it used
to be ctrl) to toggle "snap to grid" that the handles no longer be snaps for
the rotation point.

1.2.3.2 Snap Guides
Are you proposing a snap system similar to alignments in Apple's iWork?  I
would be a big fan of that feature, as it lets the vast majority of users
efficiently align and size shapes.

Middle resizing handles drawn incorrectly:
Currently, when the middle handles are drawn on shapes (generally the top
and bottom middle) they are not drawn correctly.  Often after a shape has
been re-sized they will be off-center.  It is particularly apparent with the
"diamond."  It sometimes makes it appear as though the shape is skew.
Perhaps this could be fixed as a component of the spec?

Minor detail:
The cursor crosshairs in the cursor selection icons should probably have a
white border (which may be unnecessary for those diagrams in the spec; it
has never been clear to me how "exact" the spec diagrams need to be).

The spec looks really good thus far!  This will be a humongous improvement
to the user experience with shapes.

Cheers,
Jaron



On Mon, Jan 11, 2010 at 1:30 PM, Frank Loehmann <[hidden email]>wrote:

> Hi,
>
> A new specification about the selection and positioning behavior in
> Impress/Draw is online:
>
>
> http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt
>
> Specification is work in progress and describes changes from the current
> implemented behavior.
>
> Feedback welcome!
>
> Best regards,
>
> Frank
>
> P.S. Thinning out Impress homepage can be found here:
> http://wiki.services.openoffice.org/wiki/Renaissance:Impress
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Frank Loehmann
Hi Jaron,

Good to have you on our project mailing list again!

Jaron Kuppers wrote:

> Hi Frank,
>
> I have some questions/comments in no particular order:
>
> 1.1.2.4 Multi-selection behavior
> I am not sure if this behavior will be natural to the user, especially for
> object sizing.  It is not clear to me how many users make use of groups so
> limiting their ability to rotate or size a multi-selection of objects may
> not be a good idea.  I personally would benefit from that change since I
> make use of groups often but I am unsure about what is in the best interest
> of all users.
>  
The multi selection proposal seems to questionable. The proposal wants t
addresses issues we have that users expect to see which objects belong
to the current selection. The question is if this currently proposed
change is to radical. We will further discussed this in our Impress
Renaissance meeting today.
> Multi-selection behavior: "special" (yellow) handles
> In Multi-selection behavior how do you propose the "special" (aka the
> yellow) handles behave?  a) Special handles are not accessible, b) A change
> in one handle changes all the other handles by the percentage change in the
> original, ie if two smileys are selected and one is changed to a frown, then
> both become frowns, c) only the object of the special handle being changed
> is affected.  I would vote for option "a".
>  
Good point! a) seems an option, but let us see where the discussion
about the multi selection behavior will end.
> Multi-selection behavior: guides?
> How will "guides" be affected when moving a multi-selection? - If you turn
> on "Guides when moving" under Options>OOo Draw>View, how will the guides be
> drawn, a) each selected object will have its guides drawn, or b) guides will
> be drawn as though the objects were a group?  Obviously, if option "a" is
> chosen, guides will appear as though option "b" was chosen (since naturally,
> the selected shapes define the bounding box for a multi-selection).
>  
Another point that speaks for the current behavior to handle a group
like a non-persistent group.
> Object handle colors:
> It seems green handles are for curves and groups, and teal handles are for
> complex shapes.  It may make more sense to give groups a unique handle
> color, especially since it is possible to have a group with only one object
> (in which case the bounding box will not indicate to the user that the
> object is a group since it is the same size as the bounding box for the
> object alone).
>  
I like the different color thing for grouped objects.
> Slightly off-topic:   Why do we have two different rectangle shapes, the
> "rectangle" in the drawing toolbar, and the "rectangle" under "Basic Shapes"
> which do by the way function differently? (Perhaps the second is a "rounded
> rectangle" with no rounding)?
>  
Do not know why we use different objects here.

> Group selection cursor:
> I am not sure whether this is a good idea (it may be too much information
> for the user) but perhaps there could be a unique selection cursor for
> groups.  (I am thinking perhaps a color change of the white cursor, instead
> of an additional icon; a color that matches the object handle colors for
> groups).  Since double-left-click behavior changes depending on the object
> the mouse is over, it makes sense to indicate to the user what they are
> mousing over.  Also, this would prevent confusion if a user forgets which
> objects are in a group when trying to make a multi-selection (aka they tried
> to select one object in a group but instead selected the group).
>  
Currently the cursor indicates the single click behavior for the current
position. Color codes or colored cursors are not used in OOo today.
If single click to edit text is active, the selection cursor should show
an I-beam sub cursor. I have added a not to the spec to cover this.
> Rotation point snap positions:
> Setting the rotation point to the exact feature of an object can be
> prohibitively difficult (ie, setting the rotation point to a corner).
> Perhaps there could be a way that when users have on "snap to grid" that the
> locations of the handles be automatic snap points for the rotation point.
> Likewise if the new proposed modifier key is pressed (alt, although it used
> to be ctrl) to toggle "snap to grid" that the handles no longer be snaps for
> the rotation point.
>  
I am not a big fan of the rotation point at all. I assume most users
will not use/miss it, but if we keep the default to the center it will
not harm anybody if we reset it to the center on deselecting the object.
The Ctrl  key is needed for Drag & Copy which is disabled by default.
> 1.2.3.2 Snap Guides
> Are you proposing a snap system similar to alignments in Apple's iWork?  I
> would be a big fan of that feature, as it lets the vast majority of users
> efficiently align and size shapes.
>  
Snapping guides while moving an object would be really great, but I do
not know if this is realistic for 3.3. Snapping on resizing an object is
already supported by Draw/Impress, but well hidden :-). If snapping to
objects is enabled (currently this option is not the default) you can
use the cursor to snap to an horizontal/vertical edge of another object.
> Middle resizing handles drawn incorrectly:
> Currently, when the middle handles are drawn on shapes (generally the top
> and bottom middle) they are not drawn correctly.  Often after a shape has
> been re-sized they will be off-center.  It is particularly apparent with the
> "diamond."  It sometimes makes it appear as though the shape is skew.
> Perhaps this could be fixed as a component of the spec?
>  
Hmm, seems to be a pixel. Maybe Christian Lippka could have a look on that.
> Minor detail:
> The cursor crosshairs in the cursor selection icons should probably have a
> white border (which may be unnecessary for those diagrams in the spec; it
> has never been clear to me how "exact" the spec diagrams need to be).
>  
That one got lost by using the magic selection tool from Photoshop :-)
Cursors will keep the same if already present and if not they will be
added using the same design rules.
> The spec looks really good thus far!  This will be a humongous improvement
> to the user experience with shapes.
>  
It's a way to go. Seem this spec. will cost me much more time than expected.
> Cheers,
> Jaron
>  
Thank you very much for your feedback and all the best for your doctoral
work!

Best regards,

Frank

>
>
> On Mon, Jan 11, 2010 at 1:30 PM, Frank Loehmann <[hidden email]>wrote:
>
>  
>> Hi,
>>
>> A new specification about the selection and positioning behavior in
>> Impress/Draw is online:
>>
>>
>> http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt
>>
>> Specification is work in progress and describes changes from the current
>> implemented behavior.
>>
>> Feedback welcome!
>>
>> Best regards,
>>
>> Frank
>>
>> P.S. Thinning out Impress homepage can be found here:
>> http://wiki.services.openoffice.org/wiki/Renaissance:Impress
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>    
>
>  

--
Sun Microsystems GmbH                Frank Loehmann
Nagelsweg 55                         User Experience StarOffice
20097 Hamburg                        Phone: (+49 40)23646 882
Germany                              Fax:   (+49 40)23646 550
http://www.sun.de                    mailto:[hidden email]

OpenOffice.org User Experience Team
http://ux.openoffice.org

Sitz der Gesellschaft:
Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Frank Loehmann
Hi,

Frank Loehmann wrote:

> Hi Jaron,
>
> Good to have you on our project mailing list again!
>
> Jaron Kuppers wrote:
>> Hi Frank,
>>
>> I have some questions/comments in no particular order:
>>
>> 1.1.2.4 Multi-selection behavior
>> I am not sure if this behavior will be natural to the user,
>> especially for
>> object sizing.  It is not clear to me how many users make use of
>> groups so
>> limiting their ability to rotate or size a multi-selection of objects
>> may
>> not be a good idea.  I personally would benefit from that change since I
>> make use of groups often but I am unsure about what is in the best
>> interest
>> of all users.
>>  
> The multi selection proposal seems to questionable. The proposal wants
> t addresses issues we have that users expect to see which objects
> belong to the current selection. The question is if this currently
> proposed change is to radical. We will further discussed this in our
> Impress Renaissance meeting today.
We have discussed this issue within the iTeam and we came to the
conclusion, that we want to stay with the current multi selection
behavior. But we want to add a visual feedback about what objects belong
to the current selection. I have added some new proposals (A/B) to the
spec: (page 6/7)

http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt

Please note that handles and colors shown in these mock-ups are not final.

[...]

>> Group selection cursor:
>> I am not sure whether this is a good idea (it may be too much
>> information
>> for the user) but perhaps there could be a unique selection cursor for
>> groups.  (I am thinking perhaps a color change of the white cursor,
>> instead
>> of an additional icon; a color that matches the object handle colors for
>> groups).  Since double-left-click behavior changes depending on the
>> object
>> the mouse is over, it makes sense to indicate to the user what they are
>> mousing over.  Also, this would prevent confusion if a user forgets
>> which
>> objects are in a group when trying to make a multi-selection (aka
>> they tried
>> to select one object in a group but instead selected the group).
>>  
> Currently the cursor indicates the single click behavior for the
> current position. Color codes or colored cursors are not used in OOo
> today.
> If single click to edit text is active, the selection cursor should
> show an I-beam sub cursor. I have added a not to the spec to cover this.
I have added a new proposal for the select/move cursor to the spec.
(page 4/5) Showing such a cursor will also help to handle read-only
documents and protected shapes.

[...]

Feedback welcome!

Best regards,

Frank

--
Sun Microsystems GmbH                Frank Loehmann
Nagelsweg 55                         User Experience StarOffice
20097 Hamburg                        Phone: (+49 40)23646 882
Germany                              Fax:   (+49 40)23646 550
http://www.sun.de                    mailto:[hidden email]

OpenOffice.org User Experience Team
http://ux.openoffice.org

Sitz der Gesellschaft:
Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Jaron Kuppers
Hi Frank,

The spec changes look good.

Cheers,
Jaron

On Thu, Jan 14, 2010 at 5:16 AM, Frank Loehmann <[hidden email]>wrote:

> Hi,
>
>
> Frank Loehmann wrote:
>
>> Hi Jaron,
>>
>> Good to have you on our project mailing list again!
>>
>> Jaron Kuppers wrote:
>>
>>> Hi Frank,
>>>
>>> I have some questions/comments in no particular order:
>>>
>>> 1.1.2.4 Multi-selection behavior
>>> I am not sure if this behavior will be natural to the user, especially
>>> for
>>> object sizing.  It is not clear to me how many users make use of groups
>>> so
>>> limiting their ability to rotate or size a multi-selection of objects may
>>> not be a good idea.  I personally would benefit from that change since I
>>> make use of groups often but I am unsure about what is in the best
>>> interest
>>> of all users.
>>>
>>>
>> The multi selection proposal seems to questionable. The proposal wants t
>> addresses issues we have that users expect to see which objects belong to
>> the current selection. The question is if this currently proposed change is
>> to radical. We will further discussed this in our Impress Renaissance
>> meeting today.
>>
> We have discussed this issue within the iTeam and we came to the
> conclusion, that we want to stay with the current multi selection behavior.
> But we want to add a visual feedback about what objects belong to the
> current selection. I have added some new proposals (A/B) to the spec: (page
> 6/7)
>
>
>
> http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt
>
> Please note that handles and colors shown in these mock-ups are not final.
>
> [...]
>
>  Group selection cursor:
>>> I am not sure whether this is a good idea (it may be too much information
>>> for the user) but perhaps there could be a unique selection cursor for
>>> groups.  (I am thinking perhaps a color change of the white cursor,
>>> instead
>>> of an additional icon; a color that matches the object handle colors for
>>> groups).  Since double-left-click behavior changes depending on the
>>> object
>>> the mouse is over, it makes sense to indicate to the user what they are
>>> mousing over.  Also, this would prevent confusion if a user forgets which
>>> objects are in a group when trying to make a multi-selection (aka they
>>> tried
>>> to select one object in a group but instead selected the group).
>>>
>>>
>> Currently the cursor indicates the single click behavior for the current
>> position. Color codes or colored cursors are not used in OOo today.
>> If single click to edit text is active, the selection cursor should show
>> an I-beam sub cursor. I have added a not to the spec to cover this.
>>
> I have added a new proposal for the select/move cursor to the spec. (page
> 4/5) Showing such a cursor will also help to handle read-only documents and
> protected shapes.
>
> [...]
>
>
> Feedback welcome!
>
> Best regards,
>
> Frank
>
> --
> Sun Microsystems GmbH                Frank Loehmann
> Nagelsweg 55                         User Experience StarOffice
> 20097 Hamburg                        Phone: (+49 40)23646 882
> Germany                              Fax:   (+49 40)23646 550
> http://www.sun.de                    mailto:[hidden email]
>
> OpenOffice.org User Experience Team
> http://ux.openoffice.org
>
> Sitz der Gesellschaft:
> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Haering
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Uwe Fischer
In reply to this post by Frank Loehmann
Hi,


>
> http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt 
>
>
> Please note that handles and colors shown in these mock-ups are not final.
> [...]
>
> Feedback welcome!

currently, when you drag-and-drop an object in Impress the original
stays in its colors while the dragged copy is shown ghosted or with
dimmed colors.

In my opinion it should be the other way: once an object is moved, the
object should show all its colors, and the original can be shown
ghosted. (if that is necessary at all: see comment ** below)

This would make it more easy to drag an object to a position where it
matches the color and brightness of the background when there is a color
gradient.

** (the original can still show all its colors if we just copy, while
being ghosted when we move. But that would imply that we know whether to
move or copy in advance. Currently we know because we must decide
before, but in a perfect world we would press a modifier key just before
releasing the mouse button to decide, as we are used from file copy and
move operations).

Uwe
--
   [hidden email]  -  Technical Writer
   StarOffice - Sun Microsystems, Inc. - Hamburg, Germany
   http://documentation.openoffice.org/
   http://wiki.services.openoffice.org/wiki/Documentation
   http://blogs.sun.com/oootnt
   http://user.services.openoffice.org/en/forum

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Christoph Noack-4
In reply to this post by Frank Loehmann
Hi Frank,

I've only had a brief look at the spec, but as far as I can see, many
people have been very helpful so far :-)

New rotation handle (1.1.3.1.b):
      * Is it planned to provide a new mouse pointer to visualize the
        rotating (mouse over)?
      * It is a bit ambigious to me whether the rotation handle line
        will be drawn to the center or to the center point.

Duplicate objects (1.2.2.1): Today, duplicated objects are placed above
the original object. The user may not know that some action has take
place. MS solves this by adding some offset to the newly added objects -
but this is problematic for people wo want to keep the reference
position. What about adding a small visual effect to make clear that
something has been added (fade to 50% white, fade back)?

Multi-Selection Behavior (1.1.2.4):
      * Is it planned to update the "selection of multiple shapes"
        during the selection is being made? (Example: Selecting objects
        which have transparent parts and are larger than expected by the
        user.) Currently it seems that the selection is highlighted
        after the user finished the selection with the selection frame.
      * Illustration 9 shows quite nicely how non-regular shaped objects
        (triangle, circle) may mess up the visualization for the
        individual objects (here, 3 more circles would make it
        impossible to indentify the objects). Woudn't it make more sense
        to indicate the boundary box (also for usual selections)?
      * To me, the change of the basic behavior (no group behavior) is a
        drawback :-( As far as I understand it. I would like to know
        more what the reason is - issue 50209 does only cover the
        visualization.

Text Edit Mode (1.1.3.3): Personally (!), I don't like the dashed text
object outline since it adds much visual noise during editing. Are there
any ideas for alternatives? Maybe re-use some of the ideas for page
borders (discussion with the IBM guys)?

Generally:
      * As indicated above, I don't have an overview what visual
        elements are used to indicate different states. For example, why
        do we use dashed lines for selection frames (1.1.2.5)? Isn't
        that different to Writer or Calc?
      * Is it planned to improve the handles itself? Currently the
        handles (e.g. for changing the object size) do only indicate
        "here is something", but wo don't communicate that it is about
        (e.g.) resizing the width.

Frank, Jaron and Uwe - thank you for your help! Have a nice day!

Christoph

Am Donnerstag, den 14.01.2010, 11:16 +0100 schrieb Frank Loehmann:

> Hi,
>
> Frank Loehmann wrote:
> > Hi Jaron,
> >
> > Good to have you on our project mailing list again!
> >
> > Jaron Kuppers wrote:
> >> Hi Frank,
> >>
> >> I have some questions/comments in no particular order:
> >>
> >> 1.1.2.4 Multi-selection behavior
> >> I am not sure if this behavior will be natural to the user,
> >> especially for
> >> object sizing.  It is not clear to me how many users make use of
> >> groups so
> >> limiting their ability to rotate or size a multi-selection of objects
> >> may
> >> not be a good idea.  I personally would benefit from that change since I
> >> make use of groups often but I am unsure about what is in the best
> >> interest
> >> of all users.
> >>  
> > The multi selection proposal seems to questionable. The proposal wants
> > t addresses issues we have that users expect to see which objects
> > belong to the current selection. The question is if this currently
> > proposed change is to radical. We will further discussed this in our
> > Impress Renaissance meeting today.
> We have discussed this issue within the iTeam and we came to the
> conclusion, that we want to stay with the current multi selection
> behavior. But we want to add a visual feedback about what objects belong
> to the current selection. I have added some new proposals (A/B) to the
> spec: (page 6/7)
>
> http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt
>
> Please note that handles and colors shown in these mock-ups are not final.
>
> [...]
> >> Group selection cursor:
> >> I am not sure whether this is a good idea (it may be too much
> >> information
> >> for the user) but perhaps there could be a unique selection cursor for
> >> groups.  (I am thinking perhaps a color change of the white cursor,
> >> instead
> >> of an additional icon; a color that matches the object handle colors for
> >> groups).  Since double-left-click behavior changes depending on the
> >> object
> >> the mouse is over, it makes sense to indicate to the user what they are
> >> mousing over.  Also, this would prevent confusion if a user forgets
> >> which
> >> objects are in a group when trying to make a multi-selection (aka
> >> they tried
> >> to select one object in a group but instead selected the group).
> >>  
> > Currently the cursor indicates the single click behavior for the
> > current position. Color codes or colored cursors are not used in OOo
> > today.
> > If single click to edit text is active, the selection cursor should
> > show an I-beam sub cursor. I have added a not to the spec to cover this.
> I have added a new proposal for the select/move cursor to the spec.
> (page 4/5) Showing such a cursor will also help to handle read-only
> documents and protected shapes.
>
> [...]
>
> Feedback welcome!
>
> Best regards,
>
> Frank
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ux-user interface] Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Frank Loehmann
In reply to this post by Uwe Fischer
Hi Uwe,

Uwe Fischer wrote:

> Hi,
>
>
>>
>> http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt 
>>
>>
>> Please note that handles and colors shown in these mock-ups are not
>> final.
>> [...]
>>
>> Feedback welcome!
>
> currently, when you drag-and-drop an object in Impress the original
> stays in its colors while the dragged copy is shown ghosted or with
> dimmed colors.
>
> In my opinion it should be the other way: once an object is moved, the
> object should show all its colors, and the original can be shown
> ghosted. (if that is necessary at all: see comment ** below)

We have already used this behavior in our Java based prototype. It feels
more 'natural' than the current implementation that was designed years
ago without the full drag feature.

http://tools.services.openoffice.org/impressprototype/impressprototype.jnlp

Most impressive if you move the picture on the title slide. Move & Copy
(Ctrl key pressed) should leave the original to give additional feedback.

We have discussed to implement this for Impress 3.3, but we have
discovered technical issues that will be hard to solve for 3.3. We will
keep an eye on this!

> This would make it more easy to drag an object to a position where it
> matches the color and brightness of the background when there is a color
> gradient.
>
> ** (the original can still show all its colors if we just copy, while
> being ghosted when we move. But that would imply that we know whether to
> move or copy in advance. Currently we know because we must decide
> before, but in a perfect world we would press a modifier key just before
> releasing the mouse button to decide, as we are used from file copy and
> move operations).
>
> Uwe

Best regards,

Frank


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Thinning out of Impress: New Spec for Object Selection Positioning and Modification

Cor Nouws
In reply to this post by Frank Loehmann
Hi Frank,

Frank Loehmann wrote (11-01-10 19:30)

> A new specification about the selection and positioning behavior in Impress/Draw is online:
>
> http://specs.openoffice.org/renaissance/object_selection_positioning_and_modification.odt
>
> Specification is work in progress and describes changes from the current implemented behavior.
>
> Feedback welcome!

I've seen this yesterday, and as far as I really thought about it, most
seams OK.
But while moving some objects, I just realise: when I move an object,
and it is shown transparent, it is easier to put it at the desired
location, than when it is shown non transparent.

Has that been taken into consideration?

Ciao - Cor


--
  >> Your office 2010 software: the new OpenOffice.org <<

Cor Nouws
   - ideas/remarks for the community council?
   - http://wiki.services.openoffice.org/wiki/Community_Council


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]