Icons: Add different mail statuses

[crisbusquets]

What?

Add four different icons representing various mail statuses: a standard envelope, an envelope with a + sign for subscribing, an envelope with a - sign for unsubscribing, and an envelope with an X sign for deleting.

Why?

This icon is widely recognized and helps users quickly identify email-related functions, such as accessing and managing newsletters and interacting with mail interfaces. Its inclusion provides a clear visual representation of these types of communication, which is currently lacking in WordPress.

Screenshots

References

Figma link

[jameskoster]

Tagging @WordPress/gutenberg-design for feedback :)

[jameskoster]

Envelope looks good to me and seems a worthy addition.

There can be exceptions, but generally speaking I'm not the biggest fan of repeating details across related icons this way. In this case I'm not sure how much value the envelope is adding to the already-familiar ✗, ✓, + shapes.

To demonstrate the point; I find the menu on the right in the screenshot below a bit clearer than the one on the left, where the two icons kind of blur together and don't add much meaning.

I acknowledge there are already icons in the set that are guilty of violating this principle :)

[crisbusquets]

I totally see your point, @jameskoster. As mentioned, the ✗, ✓, and + symbols can definitely appear too small in certain contexts.

While I agree that the envelope might feel unnecessary or repetitive in some interfaces, how else could we effectively represent subscribed (the envelope with a ✓)or unsubscribe (the envelope with a ✗)actions?
It's not quite the same as delete, which is universally represented by the trash icon. Using something different might lead to confusion, particularly if the icon doesn't have a label.

[jameskoster]

I suppose it would depend on the UI in which the icons appear. Is it a toolbar without text, a menu, or something else?

[mtias]

The envelope is a good addition to the library but the other combinations seem highly domain specific and should probably be handled in plugin territory.

[crisbusquets]

Thanks for the feedback, @mtias!

While I understand that some icons may not seem highly domain-specific, I believe Core should have a broad enough library to address both current and future needs. Relying solely on the envelope icon could introduce inconsistencies, as different use cases may require other states as well.

@jameskoster, consider an interface where users need to choose between subscribing, unsubscribing, or managing a subscription, or one that's more focused on mail or messaging, or even the "subscribe to comments" feature itself. In such cases, limiting the options would reduce clarity.

[keoshi]

@mtias Curious to know where you see the line being drawn between what should be in the icon library vs what should be handled by plugins.

From my perspective, and especially considering the admin redesign, plugins will have less and less need for adding their own customization. A clear sign of WordPress’s success will be when you can navigate from plugin to plugin without having to relearn patterns.

A more complete icon library — and therefore more detailed and semantic — should always be better than an incomplete or sparse one. More options adds more diversity to the library, which will mean better contextual use of those icons.

By contrast, making the library exceedingly streamlined, so much so that plugins will have to add their own tiny variations, doesn't seem to serve the purpose of creating a unified design system. In fact, losing the curation aspect of adding icons to the core library and having them reviewed, would be enough to very easily and quickly lead to inconsistencies.

In this case I'm convinced the proposed icons follow the style of the existing library, are consistent with the metaphors already introduced, and don't seem to be product specific, meaning the larger community could benefit from them.

[crisbusquets]

Building on what @keoshi and I mentioned above: Have we ever considered creating an icon library that others, even those outside the WordPress ecosystem, could use?

I realize this conversation might belong elsewhere, but I wanted to mention it here for context.

[simison]

It might help with consistency across the ecosystem as well just overall be convenient if +, -, ✔︎ etc. symbols could be modifiers applied with the <Icon> component:

<Icon icon={ envelope } modifier="plus" />

That would allow plugins to use any icons with familiar-looking modifiers/additions/overlays.

It might still be helpful to have the pure SVGs available with plusses/minuses for some of the most common cases, like images. Currently, there looks to be very few modifiers in the core library :

Adding modifiers to different icons, such as "bug," "calendar," "comment," "colour," "payment," etc., might feel like too much for core library, but plugins might have real use cases for these.

[jameskoster]

@crisbusquets for managing subscriptions would you need to add another envelope-based icon with a mini cog detail? How about exporting, sharing, downloading? These feel like examples of how this convention (base icon + mini context icon) does not scale well in practise and leads to an overall lack of clarity / consistency.

You may consider this a bit unrelated, but as an example here is the toolbar from the Apple Mail app:

Following the convention outlined in this issue many of the actions here would include a repeated envelope detail which wouldn't work as well, imo. Generally speaking the context for the action should come from the broader UI rather than the specific icon.

It goes without saying that ultimately this decision is up to y'all! For now I'd suggest opening a PR to add the envelope icon as that one seems fine to me. I believe the Icon component accepts custom svg, so you should be able to use the proposed designs in your plugin.

[mattrwalker]

My 2¢:

I find it would be cleaner and clearer for consumers if the email icon and the variants of the email icon were added together. A consumer shouldn't have to guess which library an icon is in. I think @keoshi makes some strong points to the benefit of organizing these icons in one library.

I like @simison's idea of a modifier as well, but that seems like it could be a larger and separate effort.

It might be helpful to see proposals like these that show the contextual examples of where and how exactly the icons show up in context of the app.

[mtias]

Another way of thinking about this is that we want to add symbols with names that describe the symbol, not a function. So "envelope" or "mail" would fit well, but these "subscribe" and "unsubscribe" are very action oriented and domain specific. The more natural way of reading them would be "add mail" or "remove mail", and those would be the names they'd have. More is not necessarily better if the description is not apparent.