Transitioned actions #3659

Closed
bhousel opened this Issue Dec 18, 2016 · 10 comments

Comments

Projects
None yet
2 participants
@bhousel
Member

bhousel commented Dec 18, 2016

Some actions, like the new Reflect action (#3555), could be performed in a transitioned way.. It would be cool (and actually beneficial to users not so adept at spatial reasoning) to see the feature quickly flip across its axis, rather than instantly appear in its new configuration. Circularize, Orthogonalize, and Straighten could do this too.

It could probably be implemented by allowing certain actions to have a property indicating whether or not the action is transitionable, and if so, use d3 or timer/requestAnimationFrame in history.js to difference the graph and rewrite the perform action as series of tweened replace calls followed by a final perform call.

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Dec 19, 2016

Member

some discussion in #1734

Member

bhousel commented Dec 19, 2016

some discussion in #1734

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Dec 23, 2016

Member

This turned out all right!
The gif doesn't do it justice, it looks better in a real browser.. This just me hitting the T and Y keys.

transitioned reflects2

Member

bhousel commented Dec 23, 2016

This turned out all right!
The gif doesn't do it justice, it looks better in a real browser.. This just me hitting the T and Y keys.

transitioned reflects2

@bhousel bhousel referenced this issue Dec 23, 2016

Merged

Transitioned actions #3672

10 of 11 tasks complete

@bhousel bhousel added wip and removed bluesky labels Dec 23, 2016

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Dec 23, 2016

Member

circles too 👯

transitioned circularize

Member

bhousel commented Dec 23, 2016

circles too 👯

transitioned circularize

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Dec 23, 2016

Member

The transitions look like this slowed down to 500ms. I think 150ms-ish feels better for actual editing, but this is fun too.

slow transitions

Member

bhousel commented Dec 23, 2016

The transitions look like this slowed down to 500ms. I think 150ms-ish feels better for actual editing, but this is fun too.

slow transitions

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Dec 23, 2016

Member

....

straighten transition

Member

bhousel commented Dec 23, 2016

....

straighten transition

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Dec 23, 2016

Member

📐 😏

orthogonalize transition

Member

bhousel commented Dec 23, 2016

📐 😏

orthogonalize transition

@slhh

This comment has been minimized.

Show comment
Hide comment
@slhh

slhh Dec 23, 2016

Contributor

The visual impression should also be tested with real usecases like circularizing a nearly cirlular way. Maybe the animation time can be dependent on the amount of change (e.g. moving ditance of the nodes). For example the typical slight modifications could take 150ms, which is indeed better for editing, and such misuses like circularizing a bulding as shown above could be in the 500ms range, which makes accidential use more visible.

Contributor

slhh commented Dec 23, 2016

The visual impression should also be tested with real usecases like circularizing a nearly cirlular way. Maybe the animation time can be dependent on the amount of change (e.g. moving ditance of the nodes). For example the typical slight modifications could take 150ms, which is indeed better for editing, and such misuses like circularizing a bulding as shown above could be in the 500ms range, which makes accidential use more visible.

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Dec 24, 2016

Member

Maybe the animation time can be dependent on the amount of change (e.g. moving ditance of the nodes). For example the typical slight modifications could take 150ms, which is indeed better for editing, and such misuses like circularizing a bulding as shown above could be in the 500ms range, which makes accidental use more visible.

A couple things about this:

  1. The history.perform code that schedules the transition wouldn't know how much the nodes move until after the action has moved them. So I don't see an easy way to support multiple durations. It's possible, but requires extra code that adds to the action complexity.
  2. I don't think accidental circularization is an issue anymore. Back when #1734 was opened, it used to be possible to select a thing and circularize it offscreen by accident, but iD doesn't allow this anymore. The features being operated on need to be mostly (80%) visible.

This issue about transitioned actions is primarily about helping users understand Reflect, and the other actions supported are just eye candy.

Regarding accidental changes, I do think that:

  • Sometimes a user will do something by accident and not realize how to undo it. (added #3680)
  • iD still allows certain changes to large features and we should revisit that decision. (added #3681)

So I'm going to open separate issues for those 2 things. 👍

Member

bhousel commented Dec 24, 2016

Maybe the animation time can be dependent on the amount of change (e.g. moving ditance of the nodes). For example the typical slight modifications could take 150ms, which is indeed better for editing, and such misuses like circularizing a bulding as shown above could be in the 500ms range, which makes accidental use more visible.

A couple things about this:

  1. The history.perform code that schedules the transition wouldn't know how much the nodes move until after the action has moved them. So I don't see an easy way to support multiple durations. It's possible, but requires extra code that adds to the action complexity.
  2. I don't think accidental circularization is an issue anymore. Back when #1734 was opened, it used to be possible to select a thing and circularize it offscreen by accident, but iD doesn't allow this anymore. The features being operated on need to be mostly (80%) visible.

This issue about transitioned actions is primarily about helping users understand Reflect, and the other actions supported are just eye candy.

Regarding accidental changes, I do think that:

  • Sometimes a user will do something by accident and not realize how to undo it. (added #3680)
  • iD still allows certain changes to large features and we should revisit that decision. (added #3681)

So I'm going to open separate issues for those 2 things. 👍

@slhh

This comment has been minimized.

Show comment
Hide comment
@slhh

slhh Dec 25, 2016

Contributor

The main remaining risk of such operations seems to be due to offering shortcuts in select mode, especially because of using normal character shortcuts. The user might be looking at the inspector, his memos, or any other source to intentionally fill in a field value in the inspector. In case the field didn't get focus by accident, a sequence of operations might be performed due to typing a name etc. The user might not recognise this due to not looking at the map, or might not undo all operations, because he has missed to recognize some.

In case of the building related operations like reflect, square, or circularize I don't see any requirement why we need such shortcuts. The user has to use the mouse to select or draw the feature, one additional nearby click in the radial menu doesn't matter. A shortcut might save some milliseconds, but we don't need to optimize here like iD were intended as a high performance mapping tool, while offering pure inefficience elsewhere (tagging many objects, defining a route etc.).

At least in mode select, shortcuts should not do any harmful things as a general rule. Shortcuts should be mainly reserved for selecting, navigation, or visualization purposes.

Offering shortcuts for operation like reflect, square, or circularize seem to be ok in move mode, provided that we don't use a standard charater shortcut to enter move mode, because otherwise typing a name might enter move mode and perform operations in it.
We can use the unused sidebar in move mode to visualize the shortcuts of the operations.
In case we make the operations menu available on right click, we likely don't even need the shortcuts in move mode.

Contributor

slhh commented Dec 25, 2016

The main remaining risk of such operations seems to be due to offering shortcuts in select mode, especially because of using normal character shortcuts. The user might be looking at the inspector, his memos, or any other source to intentionally fill in a field value in the inspector. In case the field didn't get focus by accident, a sequence of operations might be performed due to typing a name etc. The user might not recognise this due to not looking at the map, or might not undo all operations, because he has missed to recognize some.

In case of the building related operations like reflect, square, or circularize I don't see any requirement why we need such shortcuts. The user has to use the mouse to select or draw the feature, one additional nearby click in the radial menu doesn't matter. A shortcut might save some milliseconds, but we don't need to optimize here like iD were intended as a high performance mapping tool, while offering pure inefficience elsewhere (tagging many objects, defining a route etc.).

At least in mode select, shortcuts should not do any harmful things as a general rule. Shortcuts should be mainly reserved for selecting, navigation, or visualization purposes.

Offering shortcuts for operation like reflect, square, or circularize seem to be ok in move mode, provided that we don't use a standard charater shortcut to enter move mode, because otherwise typing a name might enter move mode and perform operations in it.
We can use the unused sidebar in move mode to visualize the shortcuts of the operations.
In case we make the operations menu available on right click, we likely don't even need the shortcuts in move mode.

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Jan 11, 2017

Member

This was done in #3672

Member

bhousel commented Jan 11, 2017

This was done in #3672

@bhousel bhousel closed this Jan 11, 2017

@bhousel bhousel removed the wip label Jan 13, 2017

@bhousel bhousel referenced this issue in openstreetmap/openstreetmap-website Feb 4, 2017

Merged

Update to iD v2.1.0 #1425

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment