Expected behavior of Undo/History – RC4

Beta
#1

Question. What’s the expected behavior for how granular the undo history should be?

Based on how History/Undo worked in Pro 3, I expected each individual change to be undo-able, but it looks like it’s grouping all changes together by change “type”.

For example:

  1. Duplicate a button
  2. Move the duplicate
  3. Edit the button text
  4. Edit the DC for the button URL
  5. Edit the graphic
  6. Hit undo by clicking the undo button in the Bar

My expectation was that hitting undo would undo the graphic change, and let me move granularly up the stack. However, it jumped all the way back to Move button. Looking at the History view, it seems to lump all edits to the button into a “button updated” grouping.

image

I just double checked the same behaviors, and they work as I expected in Pro 3.

image

So, just wanted to check if this was intentional? It’s surprised me a few times, and I thought it might have been some sort of keyboard shortcut related issue (like I reported in earlier betas), so I hadn’t really dove into it until now.

#2

Thanks! There is some batching happening so if you are constantly adjusting the same field it will register as one change, but it shouldn’t be grouping changes to different fields like that. We’ll look into this. Might not be fixed in 4.0.0 but we’ll see what we can do.

#3

My gut feeling tells me that I would not like this batching. If I play with the size of a button, for example, and try different sizes to see what I like, I might expect to only undo the latest change when pressing ctrl-z. More drastically: I would certainly not want my text field revert to “empty” when I worked in a code text field (e.g. CSS) and press ctrl-z after working for a couple of minutes.
So, if it is difficult for you guys to fine tune the batching properly, I would rather turn it off completely as default, instead of it being too coarse. Going forward, it can then be adjusted properly (for example in code fields, or any text field, letter-by-letter undo would probably be to fine, while word or paragraph level would likely be appropriate).
Just my two cents!

1 Like
#4

Appreciate you chiming in. Definitely get where you’re coming from. The batching functionality is needed for controls like the color picker, or unit sliders. While you’re dragging, it is sending state updates constantly to keep the live preview in sync. You really only want the last color to count instead of the action history being filled with dozens (or hundreds) of color changes. So it’s probably a matter of just making some smaller adjustments.

#5

Oh! Yes. Certainly don’t want to have hundreds of colors in your undo history :slight_smile:

#6

I was looking at this compared to Pro 3 and 4 and seeing some inconsistencies with both. We’re moving forward with the official release but will figure out a way to clean this up.

1 Like