Style Revisions: Provide more details on what changed in each style revision

[pablohoneyhoney]

I can take a pass at it design wise, but it'd be great to iterate on the revisions list component, so it provides more valuable context.

Specifically:

• Hide the user if site only has one author.
• Perhaps add granular timestamp.
• Present the author differently, without needing the sentence Changes saved by to be redundant in the list.
• Specify a little more input into what changed, without listing all changes; perhaps more at category level (Typography, Color, Layout, Block).

cc @apeatling

[annezazu]

Love it! As we dig into this, let's also think about what we can reuse to provide more information in the saving flow as well as per this issue #29388

[pablohoneyhoney]

Would something like this work?

I haven't gone into spacing details yet, and can definitely keep exploring, but worth sharing the direction.

Changelog:

• Added more granular timestamp.
• Present the author differently, without needing the sentence Changes saved by to be redundant in the list.
• Specify a little more input into what changed at category level (Typography, Color, Layout, Block).
• Align beginning and end of the timeline with the dot or mark.
• Added some styles and hierarchies to information for better parsing.

[jasmussen]

Yes, that would work. 👍 👍

[annezazu]

Love the iteration, especially the more exact timing and increased specificity in what's being saved 🌟. I'm curious how we might present changing to a different style variation. We emphasize switching style variations in the UI and changing to one results typically in numerous changes across the site. Being able to quickly go back and forth based on a prior style variation selection is an important use case to cover.

[apeatling]

This looks like a great iteration and significantly more useful with the details of what changed. My personal preference is the line intersections over dots, it seems easier to scan.

Agree with Anne, we probably want to have variation changes as a single entry that can be navigated.

[apeatling]

We also talked about removing the user being displayed if the site has only one user. I'd imagine this can remain the same just with the user and avatar removed?

[apeatling]

Updated the title to provide more details at a glance from the tracking issue

[annezazu]

Reopening this after testing #55913 with Gutenberg.run. I don't currently see more information about the style revision. In particular, I changed style variations and added lightbox + duotone functionality for all images but nothing shows up to indicate that:

This doesn't fulfill the heart of the problem here, unless I'm missing something! Let's keep it open until we iterate closer to what's shared above design wise.

[ramonjd]

This doesn't fulfill the heart of the problem here, unless I'm missing something! Let's keep it open until we iterate closer to what's shared above design wise.

Thanks @annezazu Yes, good idea.

We decided to separate that piece of functionality from the redesign piece as it's a bit murkier and larger than first thought.

This issue auto-closed, so thanks for reopening.

[ramonjd]

I've been exploring options here, and trying to work out a reliable (and acceptable) way to go about it. Just jotting down some findings so far...

• In a single change set there could be 100s of specific styles and settings. To get an accurate summary of what's changed we need to do a recursive comparison of every value. This is a potentially expensive operation.
• Considering the above, there are, therefore, multiple strings to be translated with various combinations of "block/element" + style type (spacing, border etc) and then specific style property, e.g., letter spacing, padding top, margin bottom...
• Maintenance burden is tied to the vagaries of theme.json and could hence be high.
• Though the exploration has yielded lessons, I'm not yet convinced that this feature represents a justifiable balance between design/development time and user value.

To limit the impact of the comparison calculation, I've rejigged the revisions buttons to only calculate them when a revision item has been clicked on and is "active". Once calculated, I cache them so we don't have to recalculate.

I've also limited the depth of the summary copy to 3 levels. So, for example, instead of reporting that a slug name has been added/updated for n individual font size presets, where n could be unlimited, we'll just print something like "Font size settings" no matter how many have been updated.

2023-11-28.12.40.37.mp4

(Ignore the 'Apply' button in each item for now, I'm testing something else related to pagination 😄 )

Here's the experimental PR:

• Global style revisions: show change summary on selected item #56577

Related links

• Global Styles: Add link to compare revisions #52829 (comment)

[jasmussen]

Coming along nicely. Can we make it so for whatever revision matches what you have, there's a black dot and more emphasis on that particular revision? Ideally I can see at a glance which revision is "selected" or "active".

[apeatling]

I think the PR is looking quite good, it's certainly an improvement.

In a single change set there could be 100s of specific styles and settings. To get an accurate summary of what's changed we need to do a recursive comparison of every value. This is a potentially expensive operation.

I do wonder if it's still valuable to be less fine-grained here. Stick to higher level groups like "Colors, Typography, Spacing" etc etc. Looking at your PR code, it's going to be a big load of translations to maintain which does worry me.

[ramonjd]

Looking at your PR code, it's going to be a big load of translations to maintain which does worry me.

True, it could get ugly very quickly. 😆

I do wonder if it's still valuable to be less fine-grained here. Stick to higher level groups like "Colors, Typography, Spacing" etc etc.

The risk in making things too high-level is repetitiveness. E.g., if a sequence of revisions changes typography > font size, then typography > letter spacing and so on, then we'll see "Typography" repeated.

Not a bad thing really. Anyway, I'll try it out and update the PR.

Coming along nicely. Can we make it so for whatever revision matches what you have, there's a black dot and more emphasis on that particular revision? Ideally I can see at a glance which revision is "selected" or "active".

Good one! I'll have a play around.

Thanks for the feedback, folks!

[ramonjd]

The risk in making things too high-level is repetitiveness. E.g., if a sequence of revisions changes typography > font size, then typography > letter spacing and so on, then we'll see "Typography" repeated.

I've updated the PR and reduced the depth to 2 levels and removed a bunch of translation. Seem ok 🤷🏻

2023-11-30.14.07.13.mp4

Coming along nicely. Can we make it so for whatever revision matches what you have, there's a black dot and more emphasis on that particular revision? Ideally I can see at a glance which revision is "selected" or "active".

I might hang on to this idea until after we look at pagination. At the moment there can be up to 100 revisions in the list. To achieve an "active in the editor" marker for each rendered item we'd need to do an object comparison for every one, which slows down rendering a bit.

If we limit paginated results to say, 10 or 20 items at a item that performance hit is reduced.

However, as you can see in the screencast above, I've used your idea for the currently-selected element. Do you think we need the text as well to explain that the revision matches what's in the editor?

[ramonjd]

Hi folks,

I think I have something workable over at:

• Global style revisions: show change summary on selected item #56577

Just need some opinions on how the summary should look.

Thank you!