Polish UX when saving post metadata and create supporting data structures

[artemiomorales]

What problem does this address?

Right now, our existing data structures and logic don't support an ideal user experience when modifying post metadata:

• We are unable to easily show granular edits to the post metadata in the Save Panel (related discussion)
• We are unable to distinguish between post metadata modifications that should require an extra verification in the save panel versus ones that shouldn't (related discussion where we created a temporary workaround to prevent an extra verification when modifying footnotes)
• The "Site Updated" message shows erroneously whenever post metadata is changed, whether or not the change was related to the overall site (related discussion)

What is your proposed solution?

Let's think through the user experience of these scenarios holistically and refactor so that our use cases are easy to implement and understand in the codebase, as well as potentially extensible to future use cases.

[artemiomorales]

I'll add some images to help this discussion. We have two open questions and a proposed design to consider:

1. What indication do we show in the snackbar if the Post Meta for an entity has changed?

2. Should we add a panel in the pre-publish flow if Post Meta has changed?

3. In addition, here is the proposed design for the Save Panel when reviewing modified entities.

As mentioned, the supporting data structures to easily modify these experiences do not currently exist in the codebase, so as we think about this holistically, we'll need to consider the best way to make any new flow or UX possible.

[jasmussen]

There's a little relevant conversation happening in Slack as well. Link requires registration.

[artemiomorales]

@gziolo @SantosGuillamot Is there anyone we should ping on the code side to move this discussion forward? Maybe a PR with some data structure changes to support the granular review of post meta (as in the image below) would be good?

[SantosGuillamot]

From your previous comment, it seems there are three things we should/could work on:

1. Decide and fix which message should show when custom fields have changed.
2. Improve the pre-publish workflow to notify users the custom fields have changed, the same way we are doing when saving.
3. Improve the existing saving UX to include the list of custom fields that have changed.

If that's the case, I believe we can address each item individually. I would say that the first step would be to explore how to work on it and, if we get blocked, ask for help with more concrete questions.

[cbravobernal]

@gziolo @SantosGuillamot Is there anyone we should ping on the code side to move this discussion forward? Maybe a PR with some data structure changes to support the granular review of post meta (as in the image below) would be good?

I think we are the code side @artemiomorales 😉

We could work on several things there, as @SantosGuillamot mention. Retrieving those fields, create the sections, add the fold/unfold behavior, etc.

We also would have to check what happens when the user unselect those checks and save.

Feel free to experiment and try to get the design approach, and reach out if blocked.

[artemiomorales]

We also would have to check what happens when the user unselect those checks and save.

Feel free to experiment and try to get the design approach, and reach out if blocked.

Perfect, sounds like a plan. I'm interested in getting the save panel to work with the checkboxes — will look into that.

[SantosGuillamot]

I was checking, and we already have issues for:

1. Editing bound paragraph in post editor causes "Site Updated" message to appear
2. Add indicator for modified post meta in pre-publish flow.

The only point missing is the one to include a list of the custom fields that have been modified. We can open a pull request or issue once we work on that.

Would it make sense to close this issue and rely on those ones?

I'm interested in getting the save panel to work with the checkboxes — will look into that.

Regarding this: Which part is not working now? If we talk about having one checkbox per meta field as shown in the image, I would work first on showing the list of fields instead of "Post Meta", even without having checkboxes.

[cbravobernal]

showing the list of fields...

This would be the best start.

[artemiomorales]

I would work first on showing the list of fields instead of "Post Meta", even without having checkboxes.

Ok I've created a new issue here:

• Block Bindings: Notify users of granular post meta edits in save panel #62938

Would it make sense to close this issue and rely on those ones?

I hesitate slightly because those two issues, as well as the one above, all would rely on using the same supporting data structure. I'm happy to close this if we feel that makes project management cleaner, though. My inclination is to focus on #62938 to start, and we could move to the other two afterwards.

[artemiomorales]

I looked at this more closely and believe this issue is now better handled in the three more granular ones below. It turns out that they can largely be tackled individually, so I'll close this issue.

• Add indicator for modified post meta in pre-publish flow #62329
• Block Bindings: Notify users of granular post meta edits in save panel #62938
• Editing bound paragraph in post editor causes "Site Updated" message to appear #62236