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

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

Open
afercia opened this issue Jan 12, 2024 · 16 comments
Open

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

afercia opened this issue Jan 12, 2024 · 16 comments
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Package] Edit Post /packages/edit-post [Package] Edit Site /packages/edit-site [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Jan 12, 2024

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:

Screenshot 2024-01-12 at 12 02 37

Site editor > Edit mode:

Screenshot 2024-01-12 at 12 04 58

Site Editor > View mode:

Screenshot 2024-01-12 at 12 05 38

Post editor: Custom Site Icon (squared):

Screenshot 2024-01-12 at 12 34 11

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

Screenshot 2024-01-12 at 12 34 29

Post editor: Custom Site Icon (non squared):

Screenshot 2024-01-12 at 16 08 13

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

Screenshot 2024-01-12 at 16 08 01

== 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:

Screenshot 2024-01-12 at 16 40 58

For posts of type page:

Screenshot 2024-01-12 at 17 34 52

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: Screenshot 2024-01-12 at 16 41 18
    • 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 afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Edit Post /packages/edit-post [Package] Edit Site /packages/edit-site labels Jan 12, 2024
@afercia
Copy link
Contributor Author

afercia commented Jan 15, 2024

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.

Screenshot 2024-01-15 at 16 57 38

@afercia
Copy link
Contributor Author

afercia commented Jan 16, 2024

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 afercia self-assigned this Jan 16, 2024
@afercia
Copy link
Contributor Author

afercia commented Jan 16, 2024

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:

Screenshot 2024-01-16 at 15 32 21

Site editor hover:

Screenshot 2024-01-16 at 15 32 45

@afercia
Copy link
Contributor Author

afercia commented Jan 16, 2024

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

@afercia afercia added the Needs Design Feedback Needs general design feedback. label Jan 17, 2024
@afercia
Copy link
Contributor Author

afercia commented Jan 17, 2024

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:

github

github open menu

github path

gmail 01

gmail 02

google calendar 01

google calendar 02

outlook 01

outlook 02

whatsapp web 02

whatsapp web 01

wix

@afercia
Copy link
Contributor Author

afercia commented Jan 17, 2024

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:

post

@mikemcalister
Copy link

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
Copy link

m commented Jan 17, 2024

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

@patric-boehner
Copy link
Contributor

patric-boehner commented Jan 18, 2024

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
Copy link
Contributor Author

afercia commented Jan 18, 2024

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
Copy link

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
Copy link
Contributor Author

afercia commented Jan 19, 2024

@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
Copy link

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
Copy link
Contributor Author

afercia commented Feb 16, 2024

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
Copy link
Member

mtias commented Feb 17, 2024

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

image (79)

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:

image

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Design Feedback Needs general design feedback. [Package] Edit Post /packages/edit-post [Package] Edit Site /packages/edit-site [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

5 participants