Reconsider the usage of the WP logo / Site Icon in the editor UI

[afercia]

Description

This issue doesn't aim to focus on the behavior and functionality of the WP logo / Site icon link and button used in the editors. Rather, it aims to only focus on the visual metrics and meaning of the images used for those functionalities.

Both the Post editor and the Site editor use the WP logo (or the Site icon if set) for the link to exit the editor / button to toggle the navigation panel. There's a few visual inconsistencies across the two editors. Alos, I'm not sure the meaning of the images is the most appropriate for a link and button that basically mean 'go back to the classic admin' or 'toggle the navigation panel'.

Visual inconsistencies contribute to make the user interface be perceived as unpolished and confusing. The visual meaning of the images doesn't really represent the underlying functionality. Both things are confusing for users and add cognitive load. As such, I'm marking this issue with the Accessibility label.

• The images default sizes are different between the two editors. I'm not sure what is the reasoning behind this but there doesn't seem to be a good reason to introduces such an inconsistency.
• When setting a custom site icon, that will be used in place of the WP logo. Depending on the image aspect ratio, the visual difference is even more noticeable.
• The transition on hover is different. In the Post editor, the image scales up. Instead, in the Site editor the image scales down. I'm not sure whether this is intentional but if a transition effect is really necessary, I'd say it should be consistent. Personally, I'm not sure the transition adss any value for users and I'd rather remove it entirely.
• The meaning of hte images doesn't seem to be the most appropriate for the functionality.
  • The WP logo: Historically, the WP logo has been used in the admin menu for the link to the About page (and its related dropdown menu). While it's probably the less used link in the admin interface, it's very prominent. It's there in the left top corner of the user interface: all users are familiar with it and they learned it means 'WordPress About page' or links to wp.org pages. Instead, in the editor the WP is supposed to have another meaning, which is unexpeced and confusing for users. To me, the WP logo certainly doesn't mean 'go back'.
  • The Site icon: as a used, when I see the Site icon I mentally associate it to the front end. To me, it means 'go to the front end'. I'm not sure I understand what the added value is for users by showingt the Site icon in the editor user interface, for controls that have a different meaning than 'go to the front end'.

Visual inconsistencies details

Post editor:

• Image default size: 36 by 36 pixels.
• If the image is larger, it is constrained to 36 by 36 pixels anyways.
• On hover: it scales up to 1.25 which makes it 45 by 45 pixels.

Site editor:

• The CSS size is: 100% by auto of the container, which is 64 by 64 pixels.
• As such, regardless whether the image is smaller or larger than 64 by 64, it will take all the available container space.
• If it's smaller, it will be blurred because the browsers scales it up.
• In view mode:
  • The image scales down to 0.5 which makes it 32 by 32 pixels
  • On hover: it's still scaled down to 0.5 so there's no visible transition effect.
• In edit mode:
  • By default it's not scaled down so it's 64 by 64 puxels.
  • On hover: it scales down to 0.96 which makes it 61.44 by 61.44 pixels.
  • Besides the 0.96 scale value seems to me a 'magic number' that produces a computed value that doesn't male much sense, I'm not sure I understand why on hover the site editor image scales down while the post editor the image scales up.
  • Lastly, when the site icon image is not a square image, it will fit very inconsistently within the two editors.

Some screenshots:

Poist editor:

Site editor > Edit mode:

Site Editor > View mode:

Post editor: Custom Site Icon (squared):

Site editor > Edit mode: Custom Site Icon (squared):

Post editor: Custom Site Icon (non squared):

Site editor > Edit mode: Custom Site Icon (non squared):

== Proposal

• Remove any transition effect. Transitions don't add great value for users. They only add unnecessary code and maintenance cost.
• Don't use the Site Icon.
• Don't use the WP logo. The WP logo could be used separately for brandin purposes but not for the link and button as it has a different meaning.
• Post Editor: as long as the link brings back to the post type list, the image should represent the post type. For example for posts of type post WordPress already has an icon in use for this purpose since ages:

For posts of type page:

And for Custom post types, the related icon should be used.

• Site editor: The image should represent the underlying functionality.
  • When it's a link to go back to the Dashboard, just use the icon that WordPress uses for the dashboard since ages:
  • When it's a button to toggle the navigation panel, use an icon that represents a menu.

Step-by-step reproduction instructions

• Compare the Post Editor and Site editor.
• Observe the WP logo (or Site icon if set) have different sizes and transition effects.
• Observe the images meaning doesn't communicate the underlying functionality.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Regarding the metrics, it appears there's some subtle inconsistencies besides the logo size. See screenshot below, zoomed-in.

• In the post editor, the logo is not perfectly vertically centered within the black box. It's more evident when the focus style is shown. As such, it's not alivned with the other buttons as well.
• The bottom bordeer is clearly different in the two editors. In the post editor, the black box is visually on top of the light gray border while in the site editor the border is fully visible.

[afercia]

See also #53148
Reported at from #53148 (comment)
a large site icon image is cut-off by a few pixels because the container size is smaller than the image size.

[afercia]

One. more inconsistency: the post editor WP logo (not the custom site icon) does have a hover style, which shows a gray outline. The post editor doesn't (it only sales down the logo by a little).

Post editor hover:

Site editor hover:

[afercia]

Just noticed: the WP logo focus style misses an outline to support Windows High Contrast mode.

[afercia]

After some admittedly non-scientific research through some of the main web applications around I think a few clear, well established, patterns emerge.

I went through: GitHub, Gmail, Google Calendar, Google Sheets, Microsoft Outlook web, WhatsApp, Wix.

• Some of these applications don't even use a brand icon.
• The ones that use a brand icon always use it as a control to go back to the application 'home'. For example in Gmail it points to the Inbox, in Google spreadsheets it points to the Sheets Home, in GitHub it points to the GitHub home page, in Wix it points to the hoem dashboard, etc.
• The icon to open the menu is genereally a hamburger menu, separated by the branding icon.
• The control to open the menu doesn't unexpectedly switch to another function e.g. 'Go back'.
• When the menu opens and the control that opened it stays visible, there are no other duplicated controls to toggle the menu.
• When the menu opens and the control that opened it gets hidden, a 'Go back' arrow is used to close the menu.

Some screenshots:

[afercia]

One more subtle visual glitch: in the Post editor, switching to 'Distraction free mode' makes the top bar height smaller. Sdee the animated GIF below, leeping the top bar visible by hovering it. Focus on the top bar bottom border that clearly shifts vertically by 1 pixel:

[mikemcalister]

Thank you for opening this, @afercia! I came here to open this very issue.

First and foremost, I think we're missing a key opportunity to more clearly communicate what this "Open Navigation" button does in the site editor. As users continue to struggle with navigating the new editor, we should lean into obvious and predictable iconography.

As it stands, this icon changes based on whether the user does or doesn't have a logo/site icon set up. That alone is kind of confusing for folks. On top of that, I've built dozens and dozens of sites with the site editor, and the site icon virtually never looks great here. It's often sized oddly and even looks broken in many cases. We can't assume users are going to have great logos/site icons as seen in some of the marketing materials.

To ensure this button is as clear as possible, we should stick to a common design pattern here, as seen in the many screenshots that @afercia posted. A menu/sidebar icon to open it, and a back button to return back to the dash when the sidebar is open. Or stick with the (W) icon. Either would be more predictable and easier to understand than the current implementation.

[m]

I agree, it's unclear what's happening and also unclear how to get back to wp-admin.

[patric-boehner]

It would be great to stop having the conversation with every client that goes: "the back button is the logo icon in the upper right, I don't know why it's that way, and I know it doesn't make sense."

In terms of design, I would imagine either a back button or an 'x' close button, but I realize that doesn't make sense in the context of the editor not being in full-screen mode.

[afercia]

Thank you all for your feedback and comments.

Personally, I'm not against using the WP logo as a link to the admin dashboard but then it should be a very well established convention across all the user interface, including the classic admin. I'm thinking to create a related Trac ticket for consideration.

[mikemcalister]

Although I did offer the (W) logo as an alternative to the site icon, the more I think about it, the more I'd like to just make it super obvious. We know from user testing that users don't even identify that (W) button as a button, and it's a critically important button!

I know it will be easier to use the WordPress logo than have a nuanced discussion about what other icons we could use, but I feel it would be a missed opportunity to make a big improvement here.

[afercia]

@mikemcalister yes that's a valid concern.
I started this issue aiming to focus only on the visual metrics and meaning of the icons but yes, it inevitably involves functionality as well.

I'd think the most important thing to establish first would be: separate the functionalities.

• A link to the admin dashboard must do just that: always point to the dashboard and never change.
• A link to the post type list must be just that and never change.
• A button to open and close the editor menu must be just that and never change.

If we all agree on the above, I'm sure we can find together the most appropriate iconography to use across the whole WordPress interface, including the classic admin pages.

Aside: As an accessibility specialist, I should say that visible text instead of icons is always preferable but yes, a logo can be a pretty accetable exception.

[mikemcalister]

Well said, and I agree on all points! Thanks for the thoughtful response. I'm really excited to see what we can do here!

[afercia]

Trying to summarize what IMHO would be nice to consider to improve users experience:

• Entirely remove the Site Icon preview, instead of spending time with trying to improve it as done in Improve SiteIcon display and transition #58472. An user interface control that serves the purpose to 'go back' or toggle a menu isn't the right place for the site icon preview and that's source of confusion for users.
• In the Site editor: don't use the same design and visual placement for two controls that serve two different purposes. These controls should be clearly separated:
  • A link to 'go back' to the classic admin
  • A toggle to open / close the navigation menu.
• Make a decision on the icon to use for the 'go back'. Considering that the left arrow is already used in the Site editor navigation menu, that leaves us with two alternative options:
  • Use the WP logo. In this case, I'd recommend to establish a new convention throughout the whole WordPress interface: in the classic admin, in the customizer and anywhere else, the WP logo should be used as a link to the home of the application, which in WordPress is the Dashboard admin page.
  • Use the X icon. This is pattern already used in the Customizer and users are already familiar with it. It clearly means 'Close this view and go back to the classic admin'.

[mtias]

Some history and context can be useful here. For reference, the "go back" button used to look like this on the full screen editor:

It had some problems of its own. At the time, when making the full screen experience the default, there was feedback from users that it wasn't clear what site you were posting on, which carried general concerns about publishing on the wrong site, unintended privacy leaks (uploading media, saving drafts, etc). That lead to design explorations leveraging more of the site identity as primary navigation on full screen views. I disagree the use of the site icon is inherently confusing, I think it can work with some adjustments, though I acknowledge it's not quite there yet. Actively looking at some options for achieving both clarity of action and identity.

Leaving the W icon as a fallback has probably contributed to some of the confusion and is worth revisiting a different fallback altogether for where the icon is used. For example, it's also used in the pre-publish flow, where the W fallback can also add to the confusion:

Another practical challenge—as pointed out—is that the post editor and the site editor currently behave a bit differently. This is not the final state, but a current reality nonetheless. The intention behind the site icon as home button was to be a permanent fixture of the experience that always allows users to navigate up the dashboard hierarchy, consistently. One simile was home buttons in mobile devices that used to take you out of apps and subsequently back to home screen if you were on secondary screen and pressed again. It's hard to establish such a pattern coherently until we expand the new admin experience. Users that don't have the site editor, for example, are only experiencing the "site icon as a link to dashboard" or "W icon as link to dashboard". This leads to a similarly looking interface working differently, which we should probably address interim.

Finally, there's also a problem with how obscure the setting for changing the site icon is. It's either buried in the customizer or buried in the logo block, even though this is not just about the frontend appearance. The fact it's fairly buried means it's not often customized by users and most would naturally assume the W is the way the software is supposed to work. This related ticket aims to address this part of the problem: https://core.trac.wordpress.org/ticket/54370

[mikemcalister]

Thanks for your thoughtful response here, @mtias. A few thoughts:

I disagree the use of the site icon is inherently confusing, I think it can work with some adjustments, though I acknowledge it's not quite there yet.

As someone interfacing with many different kinds of users everyday, this site icon nav is something that comes up very often as a point of confusion. It's not just beginners, even long-time WP users are being tripped up by this. If you're looking around the interface, and can't find your way out, whether it's a WordPress W or your site icon, it's just not good enough.

That lead to design explorations leveraging more of the site identity as primary navigation on full screen views.

I can appreciate the thoughtfulness behind bringing in the site identity to personalize the experience a bit and I'm glad we tried it. In a perfect world, this can work well. Ultimately though, this particular navigation element is far too critical for ambiguity and inconsistency.

Many people don't even know what a site icon is. I volunteer with about a dozen non-profits and help them with their WP websites. I don't think there's one person in any of those organizations that knows what a site icon is or how to create one, let alone one that looks great.

Furthermore, even if someone can create a site icon (and we add a setting to add one), we can't assume it also works well in a navigational context, even if we can contort it to fit. I'm seeing a lot of best-case-scenarios in the marketing images for the editor, but there are many different variables like the design, size, text in the graphic, etc. that ensure it rarely looks great in practice. We're asking users to go out of their way to ensure a part of their interface looks presentable.

As a product-minded creator, I'm always asking myself, "Does this help the user achieve what they need?" Users seem to be having trouble with it. Does it look cool? Sometimes. Can it work in the best circumstances? Sometimes. But is it actually helping the user? So far, I don't see many answers about how this actually helps the user.

[rectang]

I disagree the use of the site icon is inherently confusing, I think it can work with some adjustments, though I acknowledge it's not quite there yet.

Anecdotally, as someone having difficulty figuring out how to get around the Site Editor, I found the "what looks like a home button is actually a back button" design choice baffling enough that I decided to hunt down the issue (which I was certain would exist) so I could upvote it.

[afercia]

I'd agree with all the points from @mikemcalister last comment.

This design proved to be confusing for users, at least for a group of users. I find myself tripped up by this design several times even if I know how it works. I would greatly appreciate the design team in this project to take way more into consideration direct feedback from users. It just happens that some ideas, sometimes, may seem smart at first. But, at the end, sometimes they just don't work well.

[mikemcalister]

Since my last comment 4 months ago, I've had to help dozens of users figure out how to return to the site editor menu or exit the editor with this nav item.

As @afercia mentions, this may not cause widespread confusion, but it's clear that this is not intuitive to many (often new users).

[colorful-tones]

After reviewing #57813 and the changes introduced in #58472 and #61579, it seems that much effort is being put into this piece of UI and UX.

While #62675 aims to address a critical regression (yes, visible and adequate focus is critical) it is not a simple solution given the complexity that the unnecessary animation introduced in #61579.

I would encourage us to de-prioritize focus on the full-site editing (Distraction Free) and prioritize the Site Editor (non-Distraction Free). We should aim to have a proper :focus for WP 6.6 stable, which is due in a few days. As it stands, #62675 offers this, and we should merge ASAP. (Again, with little regard for the Distraction Free.)

As far as the overall discussion in #57813 on the usage of the WP logo / Site Icon in the editor UI - I agree that it is a confusing interaction and most folks I've observed interacting with the site editor are confused by its purpose.

Ultimately, I agree with @afercia that the animation is superfluous and should be removed, and the Site Icon preview is far more confusing than useful.

I understand that we want to offer a delightful, playful, and custom experience to end users, but as it stands, it is more of a hindrance in this implementation. Animation should be introduced only when we're confident that the UI is stable with user studies. Animation is critical to offering the edge of delight but should be scaffolded on top of a sound and stable solution.

[mtias]

@mikemcalister certainly, I wouldn't call this part of the UI "solved" by any means and I agree it's important to get it right. I was trying to bring the perspective that what lead to this design was direct user feedback, particularly confusions around what site you were in when on full screen. The editor used to have a simple "back arrow" for a few releases and it wasn't working for users. Writing, publishing, or uploading media to the wrong site is not great. So it's something we need to keep thinking through. The W probably needs to go since it doesn't accomplish either of the pieces (identifying what site you are in, nor communicate the exit action well enough).

[afercia]

Update:
Adter #63986, #64161, and #64172 in the site editor there's now an animation that shows what is supposed ot be a 'home' icon on hover. It only works on hover. It doesn't work with keyboard focus.

I'm not sure this change makes things better in any way. The first time I saw it I just thought there was something broken e.g. an image didn't load properly. I still think the entire mechanism to exit the editors / show the navigation would need more redical design changes and I'd encourage to explore alternative solutions.

[stokesman]

Speaking to the concern for communicating the site’s identity in the editor’s interface, it seems of very low importance because the browser’s address bar or the app header should suffice. If someone is using a browser that allows hiding the address bar then it can largely be said that they are choosing to have the problem. That’s not intended to invalidate it or squash any effort to address it.

I’m thinking that this is important only to a small portion of users and so any UI accommodation might be best as an opt in preference. It seems like using the Site Icon in the "back button" could be immediately made that way to unblock the return of a more clear symbol (that’s not hover/focus dependent).

A final note is that this seems of even less concern in the Site editor because many views will include the full template thus also the easily identifiable bits like the site title/icon.

[afercia]

Update: #65497 is going to replace the square 'home' icon with an hamburger icon. Still, the fundamental issues raised here aren't addressed.