-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Reconsider the usage of the WP logo / Site Icon in the editor UI #57813
Comments
Regarding the metrics, it appears there's some subtle inconsistencies besides the logo size. See screenshot below, zoomed-in.
|
See also #53148 |
Just noticed: the WP logo focus style misses an |
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 screenshots: |
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. |
I agree, it's unclear what's happening and also unclear how to get back to wp-admin. |
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. |
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. |
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. |
@mikemcalister yes that's a valid concern. I'd think the most important thing to establish first would be: separate the functionalities.
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. |
Well said, and I agree on all points! Thanks for the thoughtful response. I'm really excited to see what we can do here! |
Trying to summarize what IMHO would be nice to consider to improve users experience:
|
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 |
Thanks for your thoughtful response here, @mtias. A few thoughts:
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.
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. |
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.
Visual inconsistencies details
Post editor:
Site editor:
100%
byauto
of the container, which is 64 by 64 pixels.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.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
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.
Step-by-step reproduction instructions
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
The text was updated successfully, but these errors were encountered: