Unified publish flow: return revisions to more prominence

[annezazu]

In testing 6.6, I noticed that revisions is now a bit more hidden and doesn't include the number of revisions available after this PR was merged: #61867

Before:

before.mov

After:

after.revisions.mov

In talking with enterprise folks, I imagine this might cause some panic and confusion. Revisions are a key part of the foundational experience of what WordPress offers and, when many folks are working on a piece, having easy access is important. Opening this issue partially to see if feedback comes up within the 6.6 cycle and to raise an initial flag.

[ntsekouras]

Thanks for raising this Anne! I just wanted to mention that the revisions number is going to be part of the label here. We're having some discussion about the API, but it will be fixed for 6.6.

--edit

The PR that adds the revisions count was merged.

[annezazu]

Oh amazing! I think that'll be important to have.

[aaronjorbin]

I don't know if displaying the number of revisions is nearly as important as the findability of revisions from within the editor.

I also don't know if dataviews is enough of a place for the revisions since 1) It's currently limited to pages out of the box 2) it's not the default experience for navigating into the post editor.

Before #61867, to know if a post has any revisions, you just needed to have the document inspector open. Now you need to click. So that process goes from zero clicks to one. If the goal is to reduce the prominence, putting it inline with the last edited timestamp might be worth exploring.

[ppolo99]

Before #61867, to know if a post has any revisions, you just needed to have the document inspector open. Now you need to click. So that process goes from zero clicks to one. If the goal is to reduce the prominence, putting it inline with the last edited timestamp might be worth exploring.

I fully agree with this. Revisions are a key part of editorial teams as Anne mentions, and hiding them behind a menu doesn't make sense to me. I like the idea of having a timestamp or even a revisions icon in place of the text (Google Docs).

[smithjw1]

The original issue says:

Revisions are now accessible from the ellipsis menu which offers more appropriate prominence.

But I don't see any data or reasoning to support the second half of that statement. Do we know how often Revisions are accessed across sites? Does that vary by the average number of revisions on a post? How are we determining appropriate prominence?

With a shared understanding, we can have a more inclusive conversation about the proposed change vs. the original vs. @aaronjorbin's suggestion that strikes a middle ground.

[hrkhal]

What is the onus for moving the revisions out of sight? As @annezazu has already noted this isn't a good move for enterprise users. Information like this should remain visible for the editors at a glance.

6.5 already brought in post url truncation in the editor, which again limits the information available for editors and users without interaction.

It now requires another click to see the full url for the post, if you add in the two clicks to see if there are any revisions and that's 3 extra clicks per editor per article per day. It adds up quick in an enterprise setting.

[annezazu]

Thanks, folks, for sharing broader context and thoughts to round out my initial instincts on the enterprise side. A PR is in progress to explore making revisions more prominent again. You can use this Playground link to test it.

[annezazu]

Thanks, Nik, for working on this and thank you everyone else for chiming in with feedback! Final state is a returned section in the sidebar like so:

[afercia]

The original #61867 says:

Revisions are now accessible from the ellipsis menu which offers more appropriate prominence.

But I don't see any data or reasoning to support the second half of that statement.

Late to the party but I'd totally agree with @smithjw1 that recent design changes in the editor have been pretty arguable. Rather than intuition or 'vision', design in a widely used software like WordPress should be based on research, data, and user testing. My point is more about process rather than personal views on design. Direct user feedback collected by @annezazu proves that users struggle with many changes the design team introduced recently. I'm not sure keeping this approach that completely ignores user testing can be sustainable and lead to any good user experience.

It's a broader discussion that I think should be made at a higher level. I'm not sure that continuous, totally untested changes to the UI are any good for this project. There's a huge cost in terms of development time, resources allocated and, more importantly, cost in terms of user experiences as users have to adapt to continuous changes of the editor UI. Reverts like this one, #65087, and the proposed revert for the Sticky setting prove that the process is less than ideal. I do realize a closed issue isn't the best place for such a discussion but I do think the design process in WordPress and the editor would greatly benefit from a radical shift towards a data-driven approach.