Like UI aligned with known conventions

[rstavro]

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.

[SilviaMacovei]

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.

[lucaa]

@SilviaMacovei

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…

[lucaa]

@lucaa

So, next question after “do you like it?” is “how are we gonna make it happen?”, and I have a couple of paths:

1. 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).
2. 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.
3. 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.

Any opinions?

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 ?

[vmassol]

@SilviaMacovei

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.

I also prefer not to have any word when there are no likes. Now, for when there are likes, I’m fine with both options.

[mflorea]

@lucaa

the icon theme API of XWiki does not have 2 hearts : https://design.xwiki.org/xwiki/bin/view/Proposal/XWiki%20Icon%20Set#HXWikiicons, so this proposal is not compatible with the icon API of XWiki.

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.

+1 for your proposal otherwise.

[lucaa]

@mflorea

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).

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!

@mflorea

The hard part is to find a matching icon for Silk.

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

[mflorea]

@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

[vmassol]

@mflorea

@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

Indeed, and since it’s dead anyway, it probably doesn’t matter much if we add to it.

[lucaa]

@vmassol

@mflorea

@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

Indeed, and since it’s dead anyway, it probably doesn’t matter much if we add to it.

Indeed, I looked up the subject of colored icons yday, and there are 2 things that I noticed:

• colored icons does not seem to be a concept anymore, so Silk also looks rather dead
• I also found other silk “forks”, made to address this problem.

Looks like an easy and viable solution, for the idea, @mflorea .

[lucaa]

I made a pull request for this change here XWIKI-18545 Align Like button visuals with known conventions & XWIKI-21592 by lucaa · Pull Request #2645 · xwiki/xwiki-platform · GitHub as discussed above, awaiting feedback and merge.

[amilica]

Hey Anca! Thanks for working on this! It’s good that we can finally use the outlined heart for the Like states. I’m not sure if you’ve had the chance to see the more recent discussion on the like button revamp. The idea of my proposal was to have the like button in a container, very close in appearence to other buttons for consistency reasons, but also for making it more obvious to the user. Let me know what you think about these two proposals in relation to each other: 1 & 2 (this one has recently updated html & css). I still have to update the way I set the icon, but I’m looking to see if our visions are aligned on the look of the button

[lucaa]

@amilica I just saw your new proposal now (after I sent the pull request for issue XWIKI-18545).

However, your proposal doesn’t seem to address the folllwing items that this current proposal addresses (copy from my motivation above):

@lucaa

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

@lucaa

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).

Would it be interesting to integrate these 2 needs with your proposal?

Thanks!

[amilica]

Yes, sounds good to me!

We can add the “likes” word after the number of likes to make the meaning of the button cristal clear.

Also the list of likers can be rendered in a tooltip along with a simple explanation of the button(“click to like”/“like the page”).

We can use a simple tooltip (not great) or a fancier one if we are open to it (a tooltip with structured content in it, essentially a seperate div that becomes visible while hovering on the button, containing the list of likers with their profile pictures and names, one user below the other).

[lucaa]

We discussed orally with @amilica about this and:

• @amilica’s proposal was related to some old behaviour of some platform that used to show likers on hover and also like propose the like action, on the same icon.
• I convinced her though that it’s best to keep 2 separate buttons (for mobile which is hoverless), also looking at the like control of discourse (this forum) which is very misleading for showing likers and like action in the same control
• we worked a little more on the UI to add a background when hovering the heart icon, to make a contour around it to make sure that it’s isolated as a single item - the hover on the heart itself were not strong enough…

Here’s the result:
Before like:

After like:

The background color is computed as a color blend between the foreground color used in that place (@link-color or @text-color depending on the state) and the background (mix with 89% of the background color). The contrast is 4.51 for the blue and white of the Iceberg theme and 12 for the black & white @CharpentierLucas is this acceptable?

Everyone else, any remark about this new update to the UI?

[mflorea]

@lucaa

Everyone else, any remark about this new update to the UI?

So the button style that @amilica initially proposed was dropped. How does the “heart” button look when it is focused with the keyboard (using tab)?

Thanks,
Marius

[lucaa]

@mflorea

So the button style that @amilica initially proposed was dropped.

Yes, because:

• it kept the “one control multiple purposes” aspect of the current implementation, which may be a little hard to grasp (and we suffer for the tooltips messages trying to cram all information in)
• it was difficult to envisage a clean way to add an access to the list of likers: having a single button with 2 links inside is totally misleading, so we needed 2 separate controls.

@mflorea

How does the “heart” button look when it is focused with the keyboard (using tab)?

For now I dropped all outline on focus and active because it didn’t look great on Chrome (the outline was too big and the button is small).

We could have used a bigger button so that outline looks good but it’s awfully hard to align with the Likers link & also with the tags row which is just after. If, indeed, we revamp the whole footer, we could do a better job at this, having an explicitly bigger button (a heart with a frame around it).

We can add the same decoration as on hover on focus & active, if you wish.

Thanks,
Anca

[lucaa]

@lucaa

so we needed 2 separate controls.

we could have 2 buttons stuck together in a single button: half of it is for the like, the other half for accessing the list of likers, but that would indeed require an updated design (a follow-up on @amilica’s proposal).

However, with the current tags, it will probably still be badly aligned so we need to implement that along with the tags revamp.

[CharpentierLucas]

@lucaa

The contrast is 4.51 for the blue and white of the Iceberg theme and 12 for the black & white @CharpentierLucas is this acceptable?

Yup, 4.5 is the required treshhold to comply with WCAG standards

[lucaa]

@CharpentierLucas

Yup, 4.5 is the required treshhold to comply with WCAG standards

It will obviously not be the same for all color combinations. The background is 89% of the page background and 11% of the link color. I guess that “should be enough for everyone” but well…
I totally sacrificed the contrast between the hover background and the page background, which is almost nonexistent (and will probably be completely invisible whenever we’re on greys & bad gamma), as:

• this is not the only decoration on hover, so I considered it not critical,
• there is not much room between page background and link color, so it’s tough to fit a color in that would ensure proper contrast with both.

We also envisaged adding full button colors on this hover in order to ensure contrast, but it was very strong on hover, it was bothering that it was popping that much…

Thanks,
Anca