Last modified: 2014-08-13 18:39:29 UTC
Created attachment 9052 [details] How Facebook shows time and date When I'm looking at edit histories, I often find myself wanting to know roughly how long ago someone made an edit. Mostly because I am wondering if the person is still around to talk with. But, it takes me a split second to do the mental processing, because MediaWiki just shows time and date. By contrast, when I'm on Facebook or Twitter or many other sites, that processing is automated for me, and I see human-friendly language like "7 minutes ago," "about an hour ago" or "17 days ago." It probably makes sense for us to continue to show time and date, but I think it would be helpful to add a notation on the changes that have taken place within the past say eight hours, noting in human-friendly language how long ago the edit was made. The purpose of this feature request is to eliminate a little mental processing on the part of editors, by automating it.
Note that it can be helpful for such relative timestamps to also 'live update'; if the page is left open for some time, recent times should be able to recede from 'just now' to '5 minutes ago' to 'an hour ago' etc. This will especially be important if this sort of thing gets implemented on future more ajax-y interfaces. Adding bug 19992 as a dependency -- similar machine-readable markup for the timestamps would be needed to update them this way. Visual clutter is also an issue -- short & sweet '3 years ago' is often handy, but checking exact times can be necessary for many wiki maintenance needs... but having both will just eat up more and more visual space. I might suggest something like having a lot of markers default to showing the 'short' style, but allowing the user to switch the format live ... which of course brings its own new UI. :P :) At least providing 'raw' times in a hover title would be super useful in many cases.
Now that moment.js has been implemented, this could be easier to do (for JS). I think a PHP solution already exists. We could identify areas where we should start doing this and go one by one?
Change 113960 had a related patch set uploaded by Yuvipanda: Show relative 'last modified at' at bottom of each page https://gerrit.wikimedia.org/r/113960
Hmm, this might actually be terrible performance wise everywhere, since this renders pages uncacheable for anon users. I don't know how that would be fixed...
(In reply to Yuvi Panda from comment #4) > Hmm, this might actually be terrible performance wise everywhere, since this > renders pages uncacheable for anon users. I don't know how that would be > fixed... CC'ing Ori, just in case he can comment performance-wise.
A more cache friendly solution would be to mark such timestamps with a class or other attribute and do the replacement in JS. While workable, this also has a (small?) performance penalty, and might also cause ugly 'flash'ing as things re-layout when a timestamp is changed for the first time.
FYI, https://gerrit.wikimedia.org/r/95555 was merged last night PST, and is now ready for use in core and extensions. PHP date/time may not be as easy, but at least JavaScript applications can be a little better about this now.
S informs me that CLDR supports this on the PHP side! All that's left is integrating it where necessary. Maybe this should become a tracking bug for different instances of the issue, now that the grander architectural questions seem to be dealt with.
Sorry for missing the issue in comment 4. Maybe we could ignore cache invalidation, or maybe we could only ever return values that will last an hour, else return "less than 1 hour ago"? Ugly, but cacheable. How does Reddit do this?
If I recall correctly, anon HTML is cached for 30 days. Perhaps it could just use the relative version for logged in users?
Yeah, was talking about this on IRC. Anon HTML is cached for 30 days unless explicitly invalidated, so even if we invalidate them only every day that's a 30x increase in invalidates and I don't think Ops will like us very much :) We could show it only for logged in users, yes. Although that does feel a bit weird :) The JS solution would work better if we top loaded the JS, of course :D We can also easily make it dynamic - updating it as time goes on, rather easily.
Change 113960 abandoned by Yuvipanda: Show relative 'last modified at' at bottom of each page Reason: See discussion on bug https://gerrit.wikimedia.org/r/113960
Alright, so current 'consensus' seems to be: 1. Have PHP emit what it currently does, but add a data attribute with a machine readable timestamp and also a class or some such 2. Have JS (top loaded?) look for any element with the class added in (1), and then replace it with an appropriate relative time 3. Depending on how long ago the time is, we can use a setTimeout to make sure we keep updating it as time goes on, so that relative times are always correct Open questions: 1. Can we top-load this JS? 2. Can we top-load JS if we don't use jQuery? 3. Can we top-load JS if we just supported not-too-old browsers and did not use jQuery?
Also since this could potentially be top-loaded, is delivered to *all* anon users, and also modifies the DOM in place after it has loaded, I'd like a +1 from Ori for this approach before proceeding.
Keep in mind that some people might have usecases requiring absolute timestamps (e.g. copy and pasting a timestamp to a talk page). [Not saying dont do this, just saying to keep in mind that absolute ts is nice for some things too, when evaluating the solution] Ideally i think it would be nice if this was somehow introduced as the (perhaps default) date preference, so people could choose.
Could, possibly. We could also have a title attribute show the absolute timestamp. I'd rather not have a separate date preference, but there's no reason we can't have one if a use case arises.
Also anons have no preferences :)
I meant use the existing date preference.
(In reply to Yuvi Panda from comment #13) > Open questions: > > 1. Can we top-load this JS? It certainly won't cause a problem to do this. However, bear in mind this code can not run before ready, so even though it's top-loaded, it will run after all HTML has been delivered and parsed (and probably a few entries into the ready queue). > 2. Can we top-load JS if we don't use jQuery? Currently, absolutely all MediaWiki JavaScript requires jQuery. The client-side part of ResourceLoader uses jQuery, which makes it a hard requirement. Thus, there is an isCompatible function in the startup module; it's all or nothing. Certain browsers are blacklisted from all ResourceLoader JS, but everything else gets both jQuery and the main MediaWiki module (which in turn loads other modules). Can you explain the question a little further?
I hate to butt in like this, but do we have anything concrete to support that this is indeed more user-friendly, or necessarily even appropriate to mediawiki use cases?
(In reply to Matthew Flaschen from comment #19) > It certainly won't cause a problem to do this. However, bear in mind this > code can not run before ready, so even though it's top-loaded, it will run > after all HTML has been delivered and parsed (and probably a few entries > into the ready queue). Right, so there will still be a 'flash' > > 2. Can we top-load JS if we don't use jQuery? Oh, then it is just me being dumb :) Nevermind this question then. THanks!
(In reply to Isarra from comment #20) > I hate to butt in like this, but do we have anything concrete to support > that this is indeed more user-friendly, or necessarily even appropriate to > mediawiki use cases? What sort of evidence would qualify?
Let me just note that we should keep the timestamp in the UI somewhere in addition to the relative date if we do this – this would be very relevant during, say, debugging with end-users or checkuser investigations. I know of at least two sites that show timestamps on hover on the relative date (using the 'title' attribute) – Reddit and StackOverflow, we should probably do the same.
Indeed. Using title should be good enough, methinks.
(In reply to Ori Livneh from comment #22) > (In reply to Isarra from comment #20) > > I hate to butt in like this, but do we have anything concrete to support > > that this is indeed more user-friendly, or necessarily even appropriate to > > mediawiki use cases? > > What sort of evidence would qualify? Consideration of merits/drawbacks of each given common use cases, any relevant research (if it even exists), etc.
(In reply to Yuvi Panda from comment #13) > 2. Have JS (top loaded?) look for any element with the class added in (1), > and then replace it with an appropriate relative time A JavaScript library for generating such a relative time string in a consistent way would already be useful. (GettingStarted has a need for it for one of our experiments, for example). MobileFrontend has custom code for displaying relative times. momentjs is in core, and has fromNow (http://momentjs.com/docs/#/displaying/fromnow/). If that suits our needs, we could standardize on that. (If you follow that link, there is a table showing how it works). Otherwise, I think we should pick an algorithm, put it in core, and use it consistently, including MobileFrontend.
