Page MenuHomePhabricator

Spike: Re-evaluate timeago usage for the modified bar/user page
Closed, DeclinedPublic

Assigned To
None
Authored By
Jdlrobson
Mar 16 2017, 6:18 PM
Referenced Files
F6643702: Screen Shot 2017-03-16 at 14.40.38.png
Mar 16 2017, 9:41 PM
F6643704: Screen Shot 2017-03-16 at 14.41.25.png
Mar 16 2017, 9:41 PM
F6642838: zzz.gif
Mar 16 2017, 9:34 PM
F6633919: userpage.gif
Mar 16 2017, 6:18 PM
F6633918: usermod.gif
Mar 16 2017, 6:18 PM

Description

During standup it was brought up that the current approach we use for the last modified bar (and now propose to use for the user page) should be reconsidered.

There is currently a FOUC to upgrade the last modified bar and the proposed upgrade to the user page to allow translation in languages relating to gender.

These FOUC are demonstrated in the gifs below:

zzz.gif (101×605 px, 11 KB)

userpage.gif (241×733 px, 25 KB)

Currently, we rely on JS to do this, as doing this on the server side would result in a cached page which does not update over time.

For example, a page that says "Edited 1 minute ago" would not be correct 6 days later if the page has not changed.

Why is the current solution bad?
What are the design motivations here?
Do we want to re-evaluate this?
If so, what could we do instead while not causing issues to cache pages?

Event Timeline

@Jdlrobson: Why was this added to the sprint? Because it blocks/affects T150174: Registration date isn't localized on user pages?

Yes. We discussed this in standup and Max asked me to create this task to help shepherd this along. You were there!!! :)

I think human readable timestamps for the grade A browsers and simple timestamps for grade C browsers that do not run JS is an acceptable trade off. This is an enhancement after all and exactly what jQuery was designed for.

The flash of unstyled content is unfortunate, but I don't see a better way to do this, unless we limit ourselves to "Edited this month" or maybe "Edited this week" (at the risk of being incorrect some of the time). We could of course move the user page timestamp down the page a la last modified bar but I think that defeats the purpose of it.

Personally, I don't think there's much wrong with our approach here so I want to sit back and hear some reasoning and suggestions for alternative solutions.

@Nirzar could you speak to what the design motivations/constraints are?

GitHub has an interesting approach to this. Instead of reaching back into the page after it has completed loading, they use custom elements that trigger the needed logic while the page is being parsed.

https://github.com/github/time-elements

This is non-trivial to get started with, but could be adopted more widely if MobileFrontend has success with it. It has many performance benefits overall and should simplify logic considerably. Supported in Chrome, Firefox, Safari 6+, IE 9+. With graceful fallback elsewhere to plain text.

See https://github.com/wikimedia/mediawiki and https://github.com/wikimedia/mediawiki/commits/master for a live example

Screen Shot 2017-03-16 at 14.40.38.png (137×1 px, 20 KB)

Screen Shot 2017-03-16 at 14.41.25.png (818×1 px, 212 KB)

I do note though that from the captures in the task description, the style changes are a bigger problem than the text changing.

Content
The design requirement here and in any other places is to inform user about sense of time passed. Readers cannot translate timestamps easily. time stamp formats are different in different regions of the world. mm-dd-yyyy, ddmmyy, 21 march 2017 etc etc. Time passed in common units like weeks, months, and years is most understandable and can be easily translated.

Display
FOUC should be avoided as in all experiences. but if fallback requires it, maybe we can have empty space till we calculate the time passed. but no moving parts.

Yes. We discussed this in standup and Max asked me to create this task to help shepherd this along. You were there!!! :)

I was. I don't remember whether we discussed adding the task to this sprint – though we obviously did.

@ovasileva do we want to keep this task in current sprint?

ovasileva triaged this task as Medium priority.Apr 13 2017, 7:11 PM
ovasileva moved this task from 2016-17 Q3 to Triaged but Future on the Readers-Web-Backlog board.

https://phabricator.wikimedia.org/T160675#3108237 is pretty cool however it seems to suffer from the same problem that was complained about with the existing implementation - the FOUC.

I'm still not clear why the current solution is bad. I'm not sure a spike is useful here, just a conversation.
If the goal is simply to minimise the time for the FOUC this can be done by loading the JS earlier.

Can someone have a go at defining the problem - I forget who raised it during standup.

Problem statement is not clear. If it's still important we should reopen and explain, if not great, let's focus on other problems that are well defined.