-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
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? |
Tentatively updated the post and added the dev label. |
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. |
Bingo! |
I was taking a look at this one, and I have a doubt.
^ Does it mean that we want to remove the dropdown for the preview/view? |
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. |
Perfect, thanks for the clarification :) |
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.movI'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:
Screen.Recording.2023-06-20.at.13.30.47.movThe 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). |
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. |
A few recent changes happened to the top toolbar:
The buttons are a mix of colors and styles, and could use a little cleaning up:
Here's a design iteration that accounts for both post editor and site editors:
Main changes:
Post updated Jun 6.
The text was updated successfully, but these errors were encountered: