Maniphest T205321

[Bug] Search icon has no visual indication that it's a button on small screens
Closed, ResolvedPublic0.5 Estimated Story Points
Actions

Assigned To

Authored By

	• Niedzielski
	Sep 24 2018, 6:42 PM

Description

Steps to Reproduce

Visit https://en.m.wikipedia.org/wiki/Barack_Obama
Shrink the screen width to less than 720px.
Move the mouse over the search icon.

Expected Results

The mouse cursor is a hand indicating that the button is clickable

Actual Results

The mouse cursor is a pointer and the search icon does not look like a button

Peek 2018-09-24 12-37.gif (206×865 px, 284 KB)

Environments Observed

Minerva prod enwiki

Browser Version

Chromium v69.0.3497.81

OS Version

Ubuntu v18.04 64b

Device Model

Desktop

Device Language

English

QA Instructions

Environment: staging
Browser & device: desktop, all browsers
Skin: Minerva
Steps:

Go to any page on staging
Make your screen less than 720px wide
Mouse over the search icon and make sure that the cursor changes to the click hand, rather than the black pointer

Details

	Subject	Repo	Branch	Lines +/-
	Buttons should be cursor pointer by default	mediawiki/skins/MinervaNeue	master	+1 -0

Customize query in gerrit

Related Objects

Mentioned Here: T205575: Our icons should have hover states
T126387: Special:Nearby refresh button does not change cursor
T145493: Some buttons in mobile interface don't indicate clickable target with pointer
T197105: [Bug] Gallery next / previous buttons use default arrow instead of pointer (hand) cursor

Event Timeline

• Niedzielski created this task.Sep 24 2018, 6:42 PM

Restricted Application changed the subtype of this task from "Deadline" to "Task". · View Herald TranscriptSep 24 2018, 6:42 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 462559 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Buttons should be cursor pointer by default

https://gerrit.wikimedia.org/r/462559

gerritbot added a project: Patch-For-Review.Sep 24 2018, 7:09 PM

It's because we optimised this for touch devices. This keeps coming up in some form (T197105, T126387, T145493, T197105#4283320). This is easy enough to fix it's just never been prioritised and likely never will be. I'm just going to be bold and submit a patch to fix these issues.

In future, please also feel empowered to post patches for this kind of thing I will happily review!

Change 462559 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Buttons should be cursor pointer by default

https://gerrit.wikimedia.org/r/462559

This was such a trivial task, I just did it (and @Volker_E merged).

@alexhollender I've loaded the code on https://reading-web-staging.wmflabs.org - can you check the behaviour there and resolve if you're satisfied?

ReleaseTaggerBot added a project: MW-1.32-notes (WMF-deploy-2018-09-25 (1.32.0-wmf.23)).Sep 24 2018, 10:00 PM

• alexhollender_WMF edited projects, added Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q1); removed Web-Team-Backlog (Design).Sep 25 2018, 1:54 PM

• alexhollender_WMF moved this task from To Do to Needs Design Review on the Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q1) board.

ovasileva set the point value for this task to 0.5.Sep 25 2018, 4:08 PM

Jdlrobson assigned this task to • alexhollender_WMF.Sep 25 2018, 8:49 PM

hmm, so there is no gap between the buttons, and the buttons don't have hover states (aside from the cursor) so there is no feedback when you transition between the click-zone of one to the other. Not a big deal at all, but while we're doing touch-ups I wonder if we should address that? I think the easiest, unsystematic, way to solve this would be to add some kind of hover-state for these buttons (which is something we have for OOUI buttons), as in:

hover-states.mov259 KBDownload

In T205321#4620105, @alexhollender wrote:

hmm, so there is no gap between the buttons, and the buttons don't have hover states (aside from the cursor) so there is no feedback when you transition between the click-zone of one to the other. Not a big deal at all, but while we're doing touch-ups I wonder if we should address that? I think the easiest, unsystematic, way to solve this would be to add some kind of hover-state for these buttons (which is something we have for OOUI buttons), as in:

hover-states.mov259 KBDownload

Sounds good. I've opened T205575 to capture that as it's a little more complicated than this one. Is this card good to resolve?

👍

• alexhollender_WMF updated the task description. (Show Details)Sep 26 2018, 9:29 PM

ovasileva moved this task from Readers-Web-Kanbanana-Board-2018-19-Q1 to Readers-Web-Kanbanana-Board-2018-19-Q2 on the Web-Team-Backlog board.Oct 2 2018, 5:29 PM

ovasileva edited projects, added Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q2); removed Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q1).

ovasileva moved this task from To Do to Needs QA on the Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q2) board.

Ryasmeen added a project: Verified.Oct 4 2018, 9:45 PM

Ryasmeen moved this task from Needs QA to Ready for Signoff on the Web-Team-Backlog (Readers-Web-Kanbanana-Board-2018-19-Q2) board.

Jdlrobson reassigned this task from Ryasmeen to ovasileva.Oct 5 2018, 6:13 PM

Jdlrobson added a subscriber: Ryasmeen.

looks good!

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptOct 8 2018, 8:31 PM

	F26213824: hover-states.mov
	Sep 26 2018, 6:44 PM

[Bug] Search icon has no visual indication that it's a button on small screensClosed, ResolvedPublic0.5 Estimated Story PointsActions