UI Demonstration: Undo History as Actions, not Waypoints #117096

Harley Acheson · 2024-01-13T18:27:18+01:00

Harley Acheson commented

2024-01-13 18:27:18 +01:00

Working demonstration of the Undo History list working as a series of
actions that can be undone and redone, instead of (confusing) waypoints

I don't actually think we could make this change as we are so used to how the current Undo History list works. But this can also make it difficult to see that the current behavior is a bit odd...

Under the hood our "Undos" are like snapshots of the scene taken just before many actions are taken. But we expose it to users in a way that is confusing and awkward. We show the list as an "Undo History" and each item can "Redo specific action in history". But these items are not actions that can be undone/redone, but are instead waypoints to restore to. These two concepts don't mesh well.

To help illustrate lets use a specific set of actions. Start Blender fresh, then select the cube, move it, then delete it. The current list looks like this:

The tooltip hint for each item says "Redo specific action in history", but is this the case? How do you undo the deletion? You can't click on "Delete" to undo that because it is greyed out. Instead you have to click on the item below that says "Move" because we know we are actually selecting a snapshot taken before the deletion. But once you do so you can click on "Delete" to redo that. So the redo works but the undo does not? And my current position is an item I cannot select called "Move", that I now just consider to be the time before I deleted the cube.

This PR alters these behaviors so the Undo History list contains a series of actions that can be undone and redone. Just like the tooltip hints describe. You load a fresh scene, run the same actions as above and get:

This looks roughly the same except the first item is not disabled. This is because you can now select the "Delete" and it will undo the delete just like you might assume it does. Do so and the history now looks like this:

There is now also a line showing your current position. This should be much more clear that you are now between the deletion and move. Crucially, items below your current position can be undone, while the items above the line can be redone. So you click on the "delete" and it will redo and your cube will delete once again. And if you continue to think of these as actions that can be undone and redone it seems to make a lot more sense.

In case it is not obvious why Undo is different from Redo. With undo you want to move to before the action, while with redo you want to be after the action, so these deal with different snapshots. This is why the items on the current list will do different things depending on whether they are in the past or future. This PR deals with them separately and consistently, in that all items in the past should undo while items in the future will always redo.

Working demonstration of the Undo History list working as a series of actions that can be undone and redone, instead of (confusing) waypoints --- I don't actually think we could make this change as we are so used to how the current Undo History list works. But this can also make it difficult to see that the current behavior is a bit odd... Under the hood our "Undos" are like snapshots of the scene taken just before many actions are taken. But we expose it to users in a way that is confusing and awkward. We show the list as an "Undo History" and each item can "Redo specific action in history". But these items **are not actions that can be undone/redone**, but are instead **waypoints to restore to**. These two concepts don't mesh well. To help illustrate lets use a specific set of actions. Start Blender fresh, then select the cube, move it, then delete it. The current list looks like this: ![image](/attachments/ec80f3d0-4029-44e4-90dc-ae9b6907222e) The tooltip hint for each item says "Redo specific action in history", but is this the case? How do you undo the deletion? You can't click on "Delete" to undo that because it is greyed out. Instead you have to click on the item below that says "Move" because we know we are actually selecting a snapshot taken before the deletion. But once you do so you **can** click on "Delete" to redo that. So the redo works but the undo does not? And my current position is an item I cannot select called "Move", that I now just consider to be the time before I deleted the cube. ![image](/attachments/dd4a5b32-2541-4035-86b6-ac8984212520) This PR alters these behaviors so the Undo History list contains a series of actions that can be undone and redone. Just like the tooltip hints describe. You load a fresh scene, run the same actions as above and get: ![image](/attachments/38dc3310-f68f-4edc-a2fa-39b9cc1af21b) This looks roughly the same except the first item is not disabled. This is because you can now **select the "Delete" and it will undo the delete** just like you might assume it does. Do so and the history now looks like this: ![image](/attachments/9581a9b6-2ff3-4e2e-9bb4-0ba044883bf7) There is now also a line showing your current position. This should be much more clear that you are now between the deletion and move. Crucially, items below your current position can be undone, while the items above the line can be redone. So you click on the "delete" and it will redo and your cube will delete once again. And if you continue to think of these as actions that can be undone and redone it seems to make a lot more sense. In case it is not obvious why Undo is different from Redo. With undo you want to move to before the action, while with redo you want to be after the action, so these deal with different snapshots. This is why the items on the current list will do different things depending on whether they are in the past or future. This PR deals with them separately and consistently, in that all items in the past should undo while items in the future will always redo.

image.png

7.1 KiB

image.png

13 KiB

image.png

7.6 KiB

image.png

13 KiB

👍 1 👀 3

Harley Acheson added 1 commit 2024-01-13 18:27:27 +01:00

buildbot/vexp-code-patch-darwin-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-arm64 Build done. Details

buildbot/vexp-code-patch-linux-x86_64 Build done. Details

buildbot/vexp-code-patch-lint Build done. Details

buildbot/vexp-code-patch-windows-amd64 Build done. Details

buildbot/vexp-code-patch-coordinator Build done. Details

d034505f2b UI Demonstration: Undo History as Actions, not Waypoints

Working demonstration of the Undo History list working as a series of
actions that can be undone and redone, instead of (confusing) waypoints

Harley Acheson added this to the User Interface project 2024-01-13 19:11:07 +01:00

Hadrien commented

2024-01-13 21:12:47 +01:00

First-time contributor

That makes sense ! I can never tell, when opening that list, whether I should click on the action itself or the one before it... to me that's because it's not obvious that the dot represents "the last action taken" as opposed to "the current scene state".
Conceptually all actions listed are either in the past or in the future, and showing the dot besides an action is ambiguous. In addition to your proposal, I'd like to propose either

showing the dot in-between list entries, or
create a dedicated list entry for "current scene state" and show the dot besides it

That makes sense ! I can never tell, when opening that list, whether I should click on the action itself or the one before it... to me that's because it's not obvious that the dot represents "the last action taken" as opposed to "the current scene state". Conceptually all actions listed are either in the past or in the future, and showing the dot besides an action is ambiguous. In addition to your proposal, I'd like to propose either 1. showing the dot in-between list entries, or 2. create a dedicated list entry for "current scene state" and show the dot besides it

Harley Acheson commented

2024-01-14 00:12:03 +01:00

@HadrienBrissaud

That makes sense ! I can never tell, when opening that list, whether I should click on the action itself or the one before it... to me that's because it's not obvious that the dot represents "the last action taken" as opposed to "the current scene state".

The items (in the current list) will also move to different places in the stack depending on whether they are in the future or past. I updated my first comment to better explain that.

showing the dot in-between list entries, or

create a dedicated list entry for "current scene state" and show the dot besides it

I started with this idea, with an item for "Current". But it ended up being an always-disabled item that didn't add much. It was especially awkward when the list is small, just an item or two. No matter what is done with these things you still have to click on an entry, not the gaps, to navigate.

But mockups are certainly welcome. Have you actually applied this patch and tried it? If you don't compile I can make a build for you to try.

@HadrienBrissaud > That makes sense ! I can never tell, when opening that list, whether I should click on the action itself or the one before it... to me that's because it's not obvious that the dot represents "the last action taken" as opposed to "the current scene state". The items (in the current list) will also move to _different places in the stack_ depending on whether they are in the future or past. I updated my first comment to better explain that. > 1. showing the dot in-between list entries, or > 2. create a dedicated list entry for "current scene state" and show the dot besides it I started with this idea, with an item for "Current". But it ended up being an always-disabled item that didn't add much. It was especially awkward when the list is small, just an item or two. No matter what is done with these things you still have to click on an entry, not the gaps, to navigate. But mockups are certainly welcome. Have you actually applied this patch and tried it? If you don't compile I can make a build for you to try.

Hadrien commented

2024-01-14 00:21:16 +01:00

First-time contributor

But mockups are certainly welcome. Have you actually applied this patch and tried it? If you don't compile I can make a build for you to try.

No, I don't have a build environment setup. I've never done this before but I am starting to think it would be a wise investment of my time. If it's not too much hassle for you, please, make a Windows build and I will test this.

> But mockups are certainly welcome. Have you actually applied this patch and tried it? If you don't compile I can make a build for you to try. No, I don't have a build environment setup. I've never done this before but I am starting to think it would be a wise investment of my time. If it's not too much hassle for you, please, make a Windows build and I will test this.

Harley Acheson commented

2024-01-14 00:24:54 +01:00

@blender-bot package windows

Blender Bot commented

2024-01-14 00:24:57 +01:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR117096) when ready.

Harley Acheson commented

2024-01-14 00:36:05 +01:00

I've never done this before but I am starting to think it would be a wise investment of my time.

You always give great feedback, being able to test PRs would be great for us.

make a Windows build and I will test this.

The build package is here: https://builder.blender.org/download/patch/PR117096/
The link to the Windows build specifically is here: https://builder.blender.org/download/patch/blender-4.1.0-alpha+main-PR117096.d034505f2b80-windows.amd64-release.zip

Why I want you to actually try it is because although it looks so similar to the current list it is quite different. So the inconsistency you felt should just go away, if you try to not think about how it is now. Even the line next to the item with a dot. You are just before or after that thing that happened.

> I've never done this before but I am starting to think it would be a wise investment of my time. You always give great feedback, being able to test PRs would be great for us. > make a Windows build and I will test this. The build package is here: https://builder.blender.org/download/patch/PR117096/ The link to the Windows build specifically is here: https://builder.blender.org/download/patch/blender-4.1.0-alpha+main-PR117096.d034505f2b80-windows.amd64-release.zip Why I want you to actually try it is because although it looks so similar to the current list it is quite different. So the inconsistency you felt should just go away, if you try to not think about how it is now. Even the line next to the item with a dot. You are just before or after that thing that happened.

Hadrien commented

2024-01-14 13:55:29 +01:00

First-time contributor

It's terrific to know I'm being helpful, I can be insecure about giving feedback. ✌ My download speeds are capped to 7kbps right now (undersea cable is mangled) so let's see if I can snatch the build during nighttime. Nothing is less certain

Hadrien commented

2024-01-15 03:59:57 +01:00

First-time contributor

If I try to clear out my preconceptions, it feels pretty natural. You actually included a separator between past and future actions, and that makes things considerably clearer. I still think the dot is misplaced, or completely superfluous even. I can't find a good reason to justify its existence, especially with this new paradigm. I think I understand now why : it is reminiscent of an active radio button, which usually indicates state. I see it, and I think "that's where I am".

In any case, clicking an action to undo it makes sense to me conceptually. Although I'm not entirely certain it is worth changing, my brain did not find this new approach difficult to wrap around at all.

There's also the possibility to rename the entire menu to "state history" or something to that effect, solving the discrepancy from the other end.

If I try to clear out my preconceptions, it feels pretty natural. You actually included a separator between past and future actions, and that makes things considerably clearer. I still think the dot is misplaced, or completely superfluous even. I can't find a good reason to justify its existence, especially with this new paradigm. I think I understand now why : it is reminiscent of an active radio button, which usually indicates state. I see it, and I think "that's where I am". In any case, clicking an action to undo it makes sense to me conceptually. Although I'm not entirely certain it is worth changing, my brain did not find this new approach difficult to wrap around at all. ![undomenu01.png](/attachments/5916982d-aa2d-419d-8eb1-d3d3e02cb227) ![undomenu02.png](/attachments/77756755-603b-4d78-9373-9258b17b3851) ![undomenu03.png](/attachments/8ff616fa-e35b-4982-b9e2-967f1b46406a) There's also the possibility to rename the entire menu to "state history" or something to that effect, solving the discrepancy from the other end.

undomenu01.png

104 KiB

undomenu02.png

103 KiB

undomenu03.png

102 KiB

Brecht Van Lommel commented

2024-01-15 14:02:57 +01:00

I assumed the way the undo history works currently is the standard behavior, and that history stacks in other applications work similarly? That is you go to the state where you just performed that action, you don't select which action to undo.

I would more think of communicating that more clearly than changing the behavior of what happens when you click a certain item.

I assumed the way the undo history works currently is the standard behavior, and that history stacks in other applications work similarly? That is you go to the state where you just performed that action, you don't select which action to undo. I would more think of communicating that more clearly than changing the behavior of what happens when you click a certain item.

Harley Acheson added 2 commits 2024-01-15 17:32:03 +01:00

64fcc8a8f0 Merge branch 'main' of projects.blender.org:blender/blender into UndoHistory

311988c9e5 Add descriptions to Undo & Redo for illustrative purposes

Harley Acheson commented

2024-01-15 17:51:40 +01:00

@HadrienBrissaud - I still think the dot is misplaced, or completely superfluous even

Yes, you are right. It is more clear without that dot.

@brecht - assumed the way the undo history works currently

We are just out by one for undo and correct for redo. But yes, we could communicate how this works better. But you are still stuck with some mental gymnastics since undoing an action in the past means selecting one after the action, while redoing an action in the future is selecting that action name. Of course we are used the current behavior; this PR is just an exploration of doing it differently, which gives some benefits described later in this comment.

@brecht - I would more think of communicating that more clearly than changing the behavior of what happens...
@HadrienBrissaud - the possibility to rename the entire menu to "state history" or something to that effect...

It is true we could communicate better that this is a list of state snapshots with a waypoint name corresponding to the action taken just after it. This becomes a History list of history states or such.

But... we get a very nice synergy between this and "Undo", "Redo, "Repeat" if we treat these all as actions.

A simpler illustration by just adding descriptive labels to Undo and Redo (now in this PR). At the point we are illustrating above we now see the following:

It is now clear that "Undo" will do so on the move, and that "Redo" will repeat the deletion. And the Undo History directly indicates your current position in the stack, between the move and delete.

Ideally the "Repeat Last" would say "Repeat Move". But note that we can't actually have these description for this and undo and redo because they mess with our "menu search". If you now did a menu search for "undo" it would show you "Undo Move".

> @HadrienBrissaud - I still think the dot is misplaced, or completely superfluous even Yes, you are right. It is more clear without that dot. > @brecht - assumed the way the undo history works currently We are just out by one for undo and correct for redo. But yes, we could communicate how this works better. But you are still stuck with some mental gymnastics since undoing an action in the past means selecting one after the action, while redoing an action in the future is selecting that action name. Of course we are used the current behavior; this PR is just an exploration of doing it differently, which gives some benefits described later in this comment. > @brecht - I would more think of communicating that more clearly than changing the behavior of what happens... > @HadrienBrissaud - the possibility to rename the entire menu to "state history" or something to that effect... It is true we could communicate better that this is a list of state snapshots with a waypoint name corresponding to the action taken just after it. This becomes a History list of history states or such. But... we get a very nice synergy between this and "Undo", "Redo, "Repeat" if we treat these all as actions. A simpler illustration by just adding descriptive labels to Undo and Redo (now in this PR). At the point we are illustrating above we now see the following: ![image](/attachments/aa33f29b-38ad-4f3b-adee-d820a98041b8) It is now clear that "Undo" will do so on the move, and that "Redo" will repeat the deletion. And the Undo History directly indicates your current position in the stack, between the move and delete. Ideally the "Repeat Last" would say "Repeat Move". But note that we can't actually have these description for this and undo and redo because they mess with our "menu search". If you now did a menu search for "undo" it would show you "Undo Move".

image.png

46 KiB

Brecht Van Lommel commented

2024-01-15 19:35:54 +01:00

But you are still stuck with some mental gymnastics since undoing an action in the past means selecting one after the action, while redoing an action in the future is selecting that action name.

For me, I'm not thinking about picking an action to undo or redo, changing the labels does not change that for me.

For example if I have this and I want to go back to before I deleted a bunch of stuff:

Delete
Delete
Delete
Delete
Transform
Transform

I would not guess to click the first Delete rather than the last Transform. I'm thinking of going back to the state before the deletes, not selecting a range of operations to undo.

> But you are still stuck with some mental gymnastics since undoing an action in the past means selecting one after the action, while redoing an action in the future is selecting that action name. For me, I'm not thinking about picking an action to undo or redo, changing the labels does not change that for me. For example if I have this and I want to go back to before I deleted a bunch of stuff: ``` Delete Delete Delete Delete Transform Transform ``` I would not guess to click the first Delete rather than the last Transform. I'm thinking of going back to the state before the deletes, not selecting a range of operations to undo.

Harley Acheson commented

2024-01-15 20:19:41 +01:00

@brecht - For me, I'm not thinking about picking an action to undo or redo, changing the labels does not change that for me.

That's fair. I'll give it a think and see if there are ways of making these seem more like snapshots in time.

> @brecht - For me, I'm not thinking about picking an action to undo or redo, changing the labels does not change that for me. That's fair. I'll give it a think and see if there are ways of making these seem more like snapshots in time.

Harley Acheson closed this pull request

2024-01-21 19:29:16 +01:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UI Demonstration: Undo History as Actions, not Waypoints #117096

Pull request closed