Page MenuHomePhabricator

PointerOverlays have issues on larger screens
Closed, ResolvedPublic

Description

In an incognito window visit
http://en.m.wikipedia.beta.wmflabs.org/wiki/Headings?mobileaction=beta
OR
when logged in http://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=Headings&mobileaction=stable&article_action=signup-edit&welcome=yes

You'll notice on large screen the pointer overlays do not display 100% correctly in both.
In the first the pointer is outside the box and in the latter the pointer looks strange

Details

Related Gerrit Patches:
mediawiki/extensions/MobileFrontend : masterPost border box tweaks to pointer overlays

Event Timeline

Jdlrobson raised the priority of this task from to Needs Triage.
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task to Code Review on the Reading-Web-Sprint-52-Zoolander board.
Jdlrobson added a subscriber: Jdlrobson.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 28 2015, 12:16 AM

Change 226595 had a related patch set uploaded (by Jdlrobson):
Post border box tweaks to pointer overlays

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

I was trying to avoid this:

but I've got a better fix on the way.

@bmansurov I'm unable to replicate your issue... works fine for me

Change 226595 merged by jenkins-bot:
Post border box tweaks to pointer overlays

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

Verified on beta cluster.


@Jdlrobson Why is the width of the pointer overlay different in stable vs beta? (in stable it seems to span the full window but in beta it seems to span to the content width only)

Stable:

Beta:

For the record I think the beta behavior looks much better.

Jhernandez closed this task as Resolved.Aug 3 2015, 12:00 PM

Yeh, agreed. This should all be pushed together given that without the desktop optimisations it looks a bit strange in stable....

What's stopping us from pushing T101344 next sprint? It seems the only complicated bit on T101344 is dealing with the cache and showing that the last modified bar being at the bottom doesn't have a negative impact on user experience and is not just done out of taste...

<snip> showing that the last modified bar being at the bottom doesn't have a negative impact on user experience and is not just done out of taste...</snip>

@KHammerstein: I know the last modified bar was moved to the bottom of the page in alpha/beta some time ago but was there any qualitative/quantitative research done to suggest that it was a necessary change?

KHammerstein added a comment.EditedAug 6 2015, 1:05 AM

@phuedx
Is that snip from another conversation? This card seems to be about pointer overlays.

The last modified bar was moved to the bottom to prioritize article content over the page history and user profiles. I wrote more about it here https://www.mediawiki.org/wiki/Reading/Features/Article_lead_image#Last_edited_banner_moved_to_bottom

I'm not sure how we would research this, it does get a lot of clicks but that might be because its the very first thing on the page after search header. I think its a product decision we need to make, is the last edited bar the most important thing about an article?

phuedx added a comment.Aug 6 2015, 9:51 AM

@KHammerstein: It was from @Jdlrobson's comment above (T107118#1504485) but I, somewhat blithely, snipped what I thought was the relevant part out.

Thanks for the link!