Replies: 4 comments 6 replies
-
|
Great issue, would love input from @fcoveram as well. I have a preference for the star with the number, the design we have for patterns, and applying that across everything. On permalinks that star can have a border around it, but in case we choose to show it also on list views, it can be borderless, like this:
So that's icon on the left, text on the right, and that text could show the number. This recently came up for Patterns, it'll likely come up for Themes as well. If we go with the heart we need a new heart icon, that's the same foot print and 1.5px stroke. Here are new icons.
Filled: Outline: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for creating this discussion. Very much needed. Based another comment I shared a few days ago, I started working on a proposal for all the sections pointed out in the initial comment, and the idea that convinces me most is the following one. Star for rating, Ribbon for savingThe star is commonly used for rating content, so no change is needed here. But on the other hand, Instagram, Twitter, TikTok, and Facebook (in a customized way) use the heart to mark user’s preferences, and when the case exists, to feed the recommendation algorithm. Here is a summary of the sites mentioned.
Because of this, the ribbon icon seems more common for saving content. Replacing the icon on the three sections in discussion might look like this. Patterns Themes Plugins This change might also require to replace the "favorited" word with "saved". So instead of "My favorites" in Patterns, it could be something like "Saved patterns". I also considered the “+” icon, as Spotify does. But it risks conflicting with the visual language used for blocks in WordPress as a whole. Keeping the heartI don’t fully reject the idea of using the heart, but if there are plans for integrating liking actions, it seems better to use a different icon. Counter in PatternsGiven all the above, I don’t see much value in showing the counter in Patterns. It mixes the language of rating, saving and liking. And on the socials mentioned above, the counter shows how much people liked the content. Therefore, I would remove it completely. What do you think of this idea? MockupsFigma: Rate and Save |
Beta Was this translation helpful? Give feedback.
-
|
While some users may use the favorite feature to save collections for themselves, we should not lean into that being its primary use case. The favorite feature should help us surface themes/plugins/patterns for other users. Users should be able to "like" something, easily, and we should be using that to order the interface. We do this with patterns and we should be looking to add the sorting to themes and plugins soon. We don't do a great job allowing users to vote with their feet, save for writing reviews which are more valuable but harder to elicit from users. |
Beta Was this translation helpful? Give feedback.
-
I don't understand this point. Why do you think this idea sets the action as primary? The visual tweaks applied only involve icons.
This idea is worth discussing, but it sounds like adding a new feature: Like. The feature was in my mind while designing these mockups, but I put it aside as it doesn't relate to the discussion topic. |
Beta Was this translation helpful? Give feedback.
-
As you note Ribbons are for saving things for myself. I don't always save things I think are good. I save things that have specific utility. We need to provide interfaces that encourage users to elevate content for others. I don't recommend that we focus on giving users features that are designed specifically for saving things for themselves. If we start switching to a Ribbon, I believe we are walking down that path. Icons are very important in what they convey. The experience should be closer to:
We can use "this is cool/good" information for users to inform what we show to other users. For me, the heart communicates this idea the best. Ribbons are selfish :) |
Beta Was this translation helpful? Give feedback.
-
I think we've already established this behavior with favorites, especially with being able to load your favorite plugins & themes in any WordPress site: 
As an aside, this might be another consideration for the "saved" name change idea — we already call this favorites in WP core, so we should stay consistent with our labels too.
Even if we magically switched to something users would see as "good", that's too subjective for the diversity of wporg users to all agree on— "useful" is also "good", and people are pretty bad at distinguishing "useful to me" vs "useful for others".
We will probably see a little negative feedback around removing this (we've already got an issue to add it back to author pages on patterns), do you see a case where we could keep it only on Patterns? Just thinking that because Plugins and Themes already have visible metrics with "X star ratings" values, if we remove this from Patterns there will be no visible feedback metric. |
Beta Was this translation helpful? Give feedback.
-
That is what it does now. "My patterns" and "My favorites" in themes and plugins show the content marked as favorite. It saved the content.
I disagree. Mainly because of how Heart and Ribbon are used on social media; Like for the former, Save for the latter. Surfacing content to users based on their faves also contradicts this statement because now the difference between things liked and things saved needs to be clear. Again, saving content is what the site currently does. Regarding the name, I agree with @ryelle on being consistent with the label as in the WP core example. So +1 to keep the "favorite" word. If the Ribbon icon brings more friction than agreement, I'm fine using the heart. Although, I would avoid using the star icon for rate and favorite as both actions not necessarily relate to each other and can lead to confusion.
The only case that comes to me is showing public preference, just like "thumb up" a video on YouTube or tap on the heart on any post on social media. I was avoiding bringing this case to the discussion because it introduces a new feature: Like. If you envision some push back, then it sounds safer to keep it as is and just replace the start with a heart, if we decide to go with that icon. |
Beta Was this translation helpful? Give feedback.
-
|
This is one of those cases where we can go either way. What's most important is the need to unify across the directories and site as a whole, and use the 24x24+1.5px stroke width style for the icons. If that means star for rating, heart for favorites, star for ratings and favorites, or star for ratings and ribbon for favoriting, I've no strong opinion. If anything, I lean towards keeping the star across, but very happy to defer to a consensus otherwise. |
Beta Was this translation helpful? Give feedback.
-
|
As noted, "favorites" and "saved" can't be interchanged, as they have different expectations, which seems to be recognized here but the intention behind our purpose in this regard is perhaps not unanimous.
One critical aspect is that "saved" or "bookmarked" has an expectation of privacy (which appears consistent across social services). Users may be able to see the aggregate count of saves on a resource, and the saves may be used for algorithms, but you can't see what someone else saved/bookmarked. Favorites are generally a publicly viewable listing. In the WP directories, there is no expectation of privacy with what has always been referred to as "favorites". There are archives of a given user's favorites (e.g. mine for plugins, soon to be for photos, and probably should be the case for themes and patterns if not already). And as Ryelle noted, favorited plugins and themes can be searched for from within any WP admin. Additionally, favorites are listed in user profiles (currently plugins and themes, soon photos and patterns). In short, I'm in general agreement with StevenDufresne. I'm against using "saved" or "bookmarked" as the terminology for "favorites" as we've generally been treating this sort of thing, and I'm against using the ribbon as the associated icon. Favoriting is a public signal by the user saying this thing has merit in their eyes (what that merit means won't be consistent, but it doesn't have to be). We can certainly consider the feature of privately saved/bookmarked items, but that is a new paradigm that is of less importance and not something we've sought to do thus far. (Patterns seems to not expose a user's favorites natively in any fashion, but it is proposed to be added to Profiles via meta#6911 and I see no reason why a view/archive/endpoint shouldn't be added.) Matt is very much in favor of using favorites as a way of surfacing better liked resources in general, and I believe also in favor of exposing the counts as well. The heart icon is consistent with expectations (a public like/favorite), and more universal. A star would be fine, but gets confusing when the resource also has ratings, which can be the case.
As I argued, there should be no concept of "saving", only liking. If we intended "saving", then a count is definitely of less use (only Twitter shows such a count). But we should be intending like/favorite, and a count is appropriate and shouldn't be confusing. |
Beta Was this translation helpful? Give feedback.
-
|
Reading this comment after publishing mine. Sorry for missing it. Very good points. Thanks @coffee2code for clarifying the content approach.
I wasn't aware of this feature. I would keep it in mind.
+1. I'm now convinced to keep using the heart for like and move away from the "saving" logic. Regarding the counter in Patterns, let's keep it and replace the start with the heart. |
Beta Was this translation helpful? Give feedback.
-
Currently, different sites across the network use different favorite buttons, built into the child themes. For consistency, these should be the same across all sites. Here's an overview of the current landscape.
Patterns — ⭐
Plugins — ⭐ for ratings/reviews, ❤️ for favorites
Themes — ⭐ for ratings/reviews, ❤️ for favorites
Edit: Updated to add that themes also uses stars for ratings. Neither appear on the archive layout though.
Other details
Each site uses a different API endpoint for managing favorites, unifying the block will either need to change that or leave that open for the child sites. Or maybe just style updates to the current blocks (and creating a block for plugins)? Easier approach, but duplicates code in the child themes.
Only some sites (just patterns?) track the number of favorites, I'm not sure if that's a limitation or just hasn't been necessary.
Favorite status: Plugins uses color (light grey default, dark hover, red favorited), the other sites use filled/empty icons (though this is because Plugins still uses dashicons).
Beta Was this translation helpful? Give feedback.
All reactions