Following some usage of the new Like feature, I experienced some counter intuitive visuals:
the color of the UI control is an active color (primary button color) when the current user hasn’t liked the page and the inactive color (default button color) when the current user has already liked the page. While this makes sense from a “highlighting the most interesting action” point of view, it’s completely counter-intuitive on usage, from all the other like usages in other apps, a user expects the heart to “light up” when they like a page
there is too much information crammed in a single button: the like action as well as the number of current likes: thus, we need to have a tooltip with 2 information in the tooltip. This is really puzzling, it would be easier if the 2 purposes would be served by 2 different controls, each with its own tooltip
the access to the list of likers is inexplicably far away from this UI and thus rather “hidden”, although the actual number of likes is displayed - one needs to know that the list of likers is linked from the page content menu and go click there
displaying the number of likes without giving an almost equally easy access to the actual likers is pushing too much for quantity over quality (it shows the number of likes and making it too hard to see whether the likers are trustworthy).
I propose the following new UI, using visuals inspired by similar features in other software:
en empty heart that fills when people like a page as the main control to like content
followed by the number of likes that is a link to the likers
My question to you is how would you feel about such a UI, if anyone finds it worse than the current implementation or would be against implementing it. I am equally interested in adjustments of this proposal that would make it even better!
It’s all described in Loading... , that can be implemented.
the color of the link to number of likes is the standard link color
the color of the empty heart (when not liked) would be the text color, I would say
the color of he full heart would be the primary button color
This should ensure proper contrast whichever is the color theme and it should equally ensure a certain highlight of the liked state (the full heart) compared to the regular text / heart.
I really like your proposal ! I would go with text color for the “nb Likes” text and the active color (blue in this case) only for the heart on hover / click (liked).
I thought about that, and indeed it would be more elegant, but this would make this the almost only link that doesn’t have a link color and I wasn’t sure that was a good idea…
Is there another link like that anywhere?
The link would take to the list of likers, functionality that is today only available in the page’s content menu.
The rationale for the number of likes to be a link to the actual likers is the following limitation of the current UI (as explained in the initial post):
the access to the list of likers is inexplicably far away from this UI and thus rather “hidden”, although the actual number of likes is displayed - one needs to know that the list of likers is linked from the page content menu and go click there
displaying the number of likes without giving an almost equally easy access to the actual likers is pushing too much for quantity over quality (it shows the number of likes and making it too hard to see whether the likers are trustworthy).
I think I’d use “0 like” and “1 like” instead of “0 likes” and “1 likes” but that’s a detail.
Now since you talk about consistency, I wonder if we shouldn’t also change the “Tags: [+]” visual to use an icon in addition or instead of “Tags:”, use a text input with auto suggest to add/remove tags (replacing the [+]), as in:
Of course the tags could be improved as well and I have some ideas about that as well, but maybe we should have that as a separate task / thread. I’m not sure exactly what kind of consistency you refer to (with known conventions?). To me, there is less of a pattern of tags management than the one for likes, but this doesn’t mean there is nothing to improve in our current UI…
If it would be my decision of the process, I would chose to start with listing the “problems” of the current UI, so that we know what we’re trying to improve, but let’s collect that in a separate thread, maybe?
Now, there is one major and fundamental quality of all those proposals that my current proposal doesn’t have (I kept the best for the end ): all those proposals are compatible with all icon themes (since all they do is use a single heart icon that doesn’t change color), while this proposal is rather specific to font awesome, because it uses 2 heart icons (an empty / inactive one and a full / active one).
So, next question after “do you like it?” is “how are we gonna make it happen?”, and I have a couple of paths:
Drop it and produce another proposal that uses a single heart icon, which would make it compatible with the icon API.
The problem here is that it would really be a pity to drop it and the alternative we find may really be suboptimal and not interesting, given that less than 20% of the existing XWiki instances use another icon theme than FontAwesome (20% is a personal feeling, I don’t have numbers to defend it).
Make the code icon theme aware and use this implementation for when the icon theme is FontAwesome and a “degraded” version for when the icon theme is something else.
TODO: We need to produce the degraded version that is comparable to this one.
Hardcode this UI to always use the FontAwesome icons, regardless of the current icon theme set on the wiki and consider that the heart is not an icon per se, but a “button in the shape of a heart” so we can draw it however we want, regardless of the icon theme.
Yes sure. The consistency I was referring was between the Like and the Tags. One (the Like) is using an icon with some link afterwards and the other (the Tags) is using a text followed by a colon and then some textual “[+]”. They look quite different in style (and thus in consistency) to me. Note that this was true before your new proposal too. I just thought it would be good to mention it since this thread was started about consistency.
Ok, it makes sense. Thanks for the explanations, Anca !
I know that the color of the link should be in line with the general UI, but in XWiki there are some exceptions and if the tags were mentions, we can take the example of the [+] link. What I had in mind when I asked you about the link was that if it has to be a link and as I understood, it does, then it should be in line with the tags design, meaning that IMO the Likes link and the Add tags link should have the same color.
Hi! I’m really glad to see this proposal. While using the like feature I always had the impression I had already liked pages, when in fact I hadn’t. I have grown accustomed to the opposite behaviour from other apps and couldn’t shake this feeling off, although I knew how the feature was supposed to work in XWiki. So +1 for the above proposal (all three aspects).
Minor detail: Wondering whether we should have the word “like” / “likes” at all. The number itself could be clicked by users to see the list of likers. When there are no likes, only the heart would be displayed, no number next to it.
You mean like on this discourse that we’re using just now .
That can be an option, indeed, in here they’re putting the number of likes before the heart and it’s actually a 3-state heart - see my previous comment about the implementation. I personally like it with the words, like on Instagram and I think we have some room to put the words on the bottom of the page, but it’s indeed a detail…
I’m also really interested of how everyone that liked the initial proposal would see this being handled on other Icon Themes, or if anyone even cares about other icon themes (because if no one does, then that confirms my supposition and helps answer the question…): @rstavro@vmassol@SilviaMacovei ?
The XWiki Icon Set is not final. We extend it whenever we detect a missing icon. So you need to add the mapping for the empty heart to the supported icon themes (Silk and FontAwesome). For FontAwesome is easy. The hard part is to find a matching icon for Silk.
Thanks for the reminder, @mflorea! Actually I also had this in mind but by the time I wrote this proposal I forgot about it , thanks for reminding!
Indeed. Actually, it’s rather easy to make a “deactivated” icon from an image icon by using a grayscale image filter (with some compatibility work), but this cannot be implemented as part of the icon theme API
As you said, the problem is that there is nothing that may look like an empty heart in Silk. My solution to that may turn towards dropping the support for the Silk icon set , I’ll keep you posted.
I’m gonna give it some more thought, to see whether I have some other idea, but if there are other ideas, I am taking
@lucaa note that we control the Silk icon set because we have it in our source tree. So we could also add a new image (e.g. heart_empty.png) for the empty hart to the Silk icon set
, I’ll keep you posted.