Add outline to star (unstarred state) for selected source

[ninavizz]

EDIT: Issue has significantly evolved. Scroll down to last comment, to see.

---

Addendum to #873

---

Problem

When a user goes to click on a star to star or un-star a Source, the hover is triggered first—yay! Unfortunately, when the user then clicks to star or un-star a Source, they do not receive immediate feedback on that action—as they continue to see the over state via their cursor still hovering over the star.

To not be confusing, I feel immediate and visually demonstrable feedback should happen, when a user clicks on anything—even when the cursor is still hovering over that item.

Solution

The GMail team has solved for this nicely. They also user-test the hell out of everything, so I trust their implemented solutions as going over with users, well. In the GIF below, the following pattern is demonstrated (using language we've coined for our own project, to speak to the GMail UI):

1. When a user hovers over the entire Source widget, that full-widget hover state is demonstrated by a thickened/darkened outline on the Star, a thickened/darkened outline on the Checkbox, and grabber dots to the far left.
2. On hover the star shows both the darker/thickened outline, and a gray circle behind it.
3. On click... 3a. When the mouse button is released from the click action, the grey circle flashes away, then animates in size from small to large, all in a half-second. The GIF shows a solid circle outline appear, but that's my screencap software demonstrating the mouse click. 3b. The star immediately reflects the state-change, despite the user's cursor still being over the star. To reflect this maintained hover, the circle also remains behind the star.
4. When the user mouses away/off from the star, the circle goes away and the on/off toggle remains in the state the user just acted upon.
5. Tooltips are also shown for "starred" and "unstarred" upon hover-over. Eventually these would be great, but feel very optional considering other priorities and resource limitations.

I do not wish to act upon item #1, in part because we have neither a grabber affordance nor checkboxes. 3a also feels too fancy. For this ticket, however, I would like to act on items 2, 3b, and 4. IGNORE the numbers on the below mockup, they correspond to a different issue.

Artwork to do this, will be pasted below as SVG code.

[ninavizz]

Outline Star

<svg width="17" height="16" viewBox="0 0 17 16" xmlns="http://www.w3.org/2000/svg"><title>  Starre</title><desc>  Created with Sketch.</desc><g fill="none"><g style="fill:#FFF;stroke:#2A319D"><path d="M8.5 1.2L6.3 5.8 1.1 6.5 4.9 10 3.9 15 8.5 12.5 13.1 15 12.1 10 15.9 6.5 10.7 5.8 8.5 1.2Z"/></g></g></svg>`

[ninavizz]

Background Circle

<?xml version="1.0" encoding="UTF-8"?>
<svg width="27px" height="27px" viewBox="0 0 27 27" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
    <!-- Generator: Sketch 63.1 (92452) - https://sketch.com -->
    <title>Oval</title>
    <desc>Created with Sketch.</desc>
    <defs>
        <radialGradient cx="50%" cy="50%" fx="50%" fy="50%" r="50%" id="radialGradient-1">
            <stop stop-color="#FFFFFF" offset="0%"></stop>
            <stop stop-color="#C5FCFF" offset="100%"></stop>
        </radialGradient>
    </defs>
    <g id="•••-Current-Screens-To-Zeplin" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
        <g id="AllWidgets-—-Hover" transform="translate(-340.000000, -617.000000)" fill="url(#radialGradient-1)">
            <g id="persnickity-doodler-+-10-Aug-+-Hello:-I’m-a-nurse-a-+-Starre-+-paperclip-+-Line2-Mask" transform="translate(336.000000, 612.000000)">
                <circle id="Oval" cx="17.5" cy="18.5" r="13.5"></circle>
            </g>
        </g>
    </g>
</svg>`

[eloquence]

I agree ideally the user shouldn't have to mouse away to see the effect of their action.

As a first iteration, I think changing the state of the star from hover to the click result (selected or de-selected) immediately after the click would help to more clearly indicate to the user that the action they took had an effect. I do like the circle highlight as a potential follow-up iteration.

[ntoll]

So this is basically going back to the way things were before (I seem to remember removing a grey background on hover over star and replacing it with making sure hover was ensured by the star colour)...?

I'll work to @eloquence's suggestion for the time being.

[ninavizz]

@ntoll Honestly, I hadn't noticed that subtlety in how you'd previously implemented the starring feature. I also really thought my initial design would be great, until I saw it in action.

GMail also has what appears to be a white dropshadow behind the star, which I fudged with a radial gradient in the SVG above—as dropshadows you noted to be a PITA to do, yet they help a bunch with elements standing-out in state changes, and with elements not being muddled.

I love your thoughtfulness and insight into how things behave, and wish we both had more time together to work on things. For now tho, I will credit a token on your end of the fence for owning my call on this one. Wish I had more time to learn from you in our collaborations!

[ninavizz]

@creviera commented on PR#1006

just a thought for a future improvement: if the star is already checked, then don't show the hover state when you mouse over it, otherwise it looks like a star that is unchecked about to be checked

I'm not sure if @ntoll had this in the first iteration (and if you did, Nick, then I really owe you a drink!) but upon seeing Allie leave this comment I did want to quickly leave a response on this ticket.

If you look at the GMail pattern (in the above GIF) Allie, I think the rationale you cite is why the background-circle is there... and why the "hover" state is kind of a 2-fold deal. (insert Nick giggling and shaking his head with an eyeroll).

When the star is ON and the user hovers over it, the hover-state is just the background circle appearing. When the star is OFF however, the hover-state is an outlined-star in addition to the background circle. I do feel the affordance is necessary, to indicate to a user that they're hovered over something... but as you point out Allie, it would suck if that affordance obfuscated the on/off state of the star. Enter the GMail pattern, or what Nick initially implemented (and Nina failed to notice the awesome attention to detail, with).

[ntoll]

With all this discussion of stars, it feels like we need someone with a PhD in Astrophysics to work out what the hell is going on... oh wait... cc/ @redshiftzero (Jen, that was the long promised astrophysics "dad" joke). :star2:

[ntoll]

@ninavizz you're the wonderful UX person, and it's my task to work with you to get the UI you want. You just tell me what you want and I'll try to make it work as best I can given the limitations and UI-"vernacular" that Qt uses. Honestly, if we're still writing UI's like this in 20 years time I think we've made a big mistake. :+1: Come back HyperCard -- all is forgiven (I loved that program).

[ninavizz]

@creviera This is the issue I was Slacking you about, yesterday after our meeting. TL;DR, when a Source is selected, the background color of the selected state is of too-low contrast with the unselected star, for accessibility and general legibility. I can't login atm, to see what happens when I actively star, tho. HMU to chat when u back and it's sunny outside?

[ninavizz]

2021 Apr, update

Last year Nicholas updated the star's hover state, to the bright cyan I'd specified some time ago. That's what the comments above, are all about. Outstanding as a need, however, is the outline artwork to replace the current SVG, when a source is both not-stared and selected.

If you look at the client today, the contrast-ratio of the unselected star on the tinted background when a source is selected, is much too low. The outline, will rectify that—which will help general usability and accessibility interests.

With #587 the background colors may need to be darkened, as well. Should that happen, the contrast ratio will narrow even more. Regardless, though, the outline star should be implemented for the source item's selected state. Once that happens, this issue can be closed. :)

[eloquence]

though, the outline star should be implemented for the source item's selected state

Can you add a simplified before/after mock for the one change you want to see here?

[sssoleileraaa]

@ninavizz could you confirm how it should look when there is:

1. a selected starred source with the mouse hovering over the star
2. a selected unstarred source with the mouse hovering over the star
3. an unselected starred source with the mouse hovering over the star
4. an unselected unstarred source with the mouse hovering over the star

[ninavizz]

@eloquence Below is a screenshot of my wireframe with the outlined star in Surreal Yo-Yo. The client currently has the same spec'd value as I'm using in my wireframes/mockups, but it renders far lighter on the qubes laptop. Allie and I will be addressing that, in the round of changes she's making this sprint.

@creviera No matter any of the other states, the hover should always be the same bright cyan.

What matters to the user on hover, is that they see a visible change. Contrast ratios matter most, when elements are static. If it's important for a user to be reading text or to decipher semiotics of a form, then the contrast ratio would still matter on hover—but otherwise (our case) it does not.

[sssoleileraaa]

Ah, ok. So we'll just be updating the star for an unstarred selected source -- nothing to do with hovering.

[eloquence]

SGTM. Retitled issue accordingly.

[ntoll]

:wave: I appear linked to this ticket so was absolutely delighted to get a bunch of emails from GitHub and see you folks at work. Just wanted to remind you all that FPF is wonderful and amazing, hope that COVID isn't disrupting things too much for folks, and big hugs from the UK. :gb: :tada:

[ninavizz]

See UXPin prototype, here, for starring how-to-behave. Zep-lin, here, because I created it anyway. :)

...and our new design system in Figma, because we're moving to it!

Note: When Surreal YoYo is the selected source, the above will accurately reflect starring/unstarring on both selected and un-selected sources. When any other source is selected, it will still show Surreal YoYo's star functionality assuming it is selected, and all the other Sources with stars for unselected states. Because while UXPin is mighty fancy, my conditional-logic skills are not (yet!) that fancy.

[ninavizz]

@creviera My client isn't showing outlined stars; did the above PR get merged?