Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Top toolbar: Refine the icons on the right #51006

Closed
jasmussen opened this issue May 26, 2023 · 15 comments · Fixed by #51735
Closed

Top toolbar: Refine the icons on the right #51006

jasmussen opened this issue May 26, 2023 · 15 comments · Fixed by #51735
Assignees
Labels
[Type] Enhancement A suggestion for improvement.

Comments

@jasmussen
Copy link
Contributor

jasmussen commented May 26, 2023

A few recent changes happened to the top toolbar:

  • A new device icon indicator in the preview dropdown
  • Moving the "Switch to draft" button into the inspector for published posts
  • Showing the "Saved" state indicator also for published posts.
  • A new "View post" icon button

The buttons are a mix of colors and styles, and could use a little cleaning up:

Toolbar buttons, before

Here's a design iteration that accounts for both post editor and site editors:

Before After
Toolbar buttons, before Toolbar buttons, after

Main changes:

  • Same color for all icon buttons
  • Leveraging an icon-button for the device preview button
  • Can show the "View post" always, just link to the preview before publishing.

Post updated Jun 6.

@jasmussen jasmussen added the Needs Design Feedback Needs general design feedback. label May 26, 2023
@jasmussen

This comment was marked as resolved.

@jameskoster

This comment was marked as resolved.

@jasmussen

This comment was marked as resolved.

@richtabor

This comment was marked as resolved.

@jasmussen

This comment was marked as resolved.

@jameskoster
Copy link
Contributor

Could we just always show the "View post" button, and have it act as preview if unpublished?

Yep, I think that could work for the post editor. We'll need to add the equivalent button to the Site Editor, perhaps as a part of #50378?

@jasmussen jasmussen added [Type] Enhancement A suggestion for improvement. Needs Dev Ready for, and needs developer efforts and removed Needs Design Feedback Needs general design feedback. labels Jun 6, 2023
@jasmussen
Copy link
Contributor Author

Tentatively updated the post and added the dev label.

@jameskoster
Copy link
Contributor

Are the proposed changes for the post editor, site editor, or both?

The Site Editor may require a little more thought as the draft concept doesn't really exist there yet.

@jasmussen
Copy link
Contributor Author

jasmussen commented Jun 7, 2023

It was actually both site editor and post editor, but I forgot to include the site editor, and perhaps I should omit the document title as that's just distracting from the rest. Here's a clearer comparison:

Before After
Toolbar buttons, before Toolbar buttons, after

@jameskoster
Copy link
Contributor

Bingo!

@richtabor richtabor added this to Polish Jun 14, 2023
@richtabor richtabor moved this to Needs development in Polish Jun 14, 2023
@juanfra
Copy link
Member

juanfra commented Jun 15, 2023

I was taking a look at this one, and I have a doubt.

Leveraging an icon-button for the device preview button

^ Does it mean that we want to remove the dropdown for the preview/view?

@jasmussen
Copy link
Contributor Author

No, that would still drop down and show the devices plus labels, the dropdown would just be opened by an icon button.

But maybe the "Preview in new tab" option was extracted into the "View post" button instead, making the dropdown devices-only.

@juanfra
Copy link
Member

juanfra commented Jun 15, 2023

Perfect, thanks for the clarification :)

@juanfra
Copy link
Member

juanfra commented Jun 20, 2023

I had some time to work on this today, and I found a small constraint with moving the "Preview in new tab" to the "View" button.

While in the draft post-editing context it could make sense to have something like that (because eventually, the behavior of the two buttons would be the same), when a post/page is already published, the value of the "preview" is to view how the changes (not saved) could look. Whereas the "view" always opens the public content (what's saved). So we would have two functionalities competing in one button.

Screen.Recording.2023-06-20.at.13.23.07.mov

I'm unsure if it is an ideal UX to have a button behaving differently in two contexts. Plus, having the "View" button previewing can be confusing as well (It'll be next to a "Preview" dropdown). And, as these two would be competing, we would have to decide on which one to leave out. As a user, I would expect to be able to still preview changes without saving.

What I would propose is to:

  • Have the "View" button disabled (or could also be hidden, as it is now) when in draft-context.
  • Enabling the "View" button once the post/page is published.
  • Keep the "Preview in new tab" under the preview dropdown, so that we keep the functionality available.
Screen.Recording.2023-06-20.at.13.30.47.mov

The other thing I was thinking is if, in favor of consistency, we could think of having a "View site" button in the site editor. That could maybe be a different discussion (could be contextual when editing pages, or just general to view the site).

@jasmussen
Copy link
Contributor Author

when a post/page is already published, the value of the "preview" is to view how the changes (not saved) could look. Whereas the "view" always opens the public content (what's saved). So we would have two functionalities competing in one button.

That's a great clarification. Yes indeed. To me that actually suggests keeping the existing trunk behavior, which is have the preview in new tab continue to exist in the dropdown, and then add a new "View site" button once published.

Can we try that as a starting point?

Another option which I wouldn't start with, is to keep the view post button and have it be a preview until published, then a view link, but also keep the "preview in new tab" button in the dropdown. Not quite as elegant, but a potential plan B.

@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Jun 21, 2023
@juanfra juanfra moved this from Needs development to In progress in Polish Jun 21, 2023
@juanfra juanfra removed the Needs Dev Ready for, and needs developer efforts label Jun 21, 2023
@juanfra juanfra moved this from In progress to Done in Polish Jun 22, 2023
@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

5 participants