This is a ridiculous argument - relative dates are an enormous usability improvement for actual users, who don't care about machine-readable timestamps or the incredible mess that is timezones.
Twitter also doesn't give a fuck about archival via screenshots. I'm pretty hard-pressed to imagine who would, actually.
Whenever I use relative dates, I usually draw the line at either one week or one month, after which I go to absolute dates. It can be cognitively challenging to see a date from two days ago and work out whether it was two days or one day, hey, today's Thursday right so that was Tuesday etc., whereas from 2012 a timestamp from 2009 isn't cognitively challenging to read as "years ago", and if you want the precision, it's there.
Personally when I've done it I often also simply always have the absolute time: "Wednesday, August 22nd at 8:22PM (a day ago)", with the order of the two elements chosen depending on which makes more sense.
That'd be an improvement in HN, imo. Times like "12 minutes ago" or "3 hours ago" or even "9 days ago" are fine, but "1612 days ago" requires me to mentally convert to figure out when that actually was.
The problem you are describing isn't a problem with relative dates. It is simply imprecision. You can make relative dates that are precise (e.g. 783 days and 4 hours ago), and you can make absolute dates that are imprecise (e.g. 2010).
Now you're just being pedantic - displaying the number of days since a picture was taken is not worse than not being able to differentiate past 12 moths.
No, he isn't being pedantic. It's a real, valid usability issue.
"783 days and 4 hours ago" really is worse. If I am browsing a photo and look at that, my first reaction is "That photo was taken a long time ago". If my buddy asks when that happened, I'll have to start doing some simple math in my head. "Uhh, around two years ago? So what, that's 2010?"
Simply putting the date would have been a much friendly solution. You know immediately that it was "a long time ago" because everyone knows what the current year is. And you know what year immediately.
Conversely, on short scales it's opposite. I don't really care if a post was on Monday or Tuesday (usually). I care that it was recent. Providing the exact timestamp doesn't help.
Think about the task of correlating online events with events from your memory.
Suppose you see a quote from you, saying something rude that seems out of character. Knowing that it was however many hundreds of days ago is useless; see that it was July 27, 2011, at 4am, and you'll say "oh, yeah, somewhere in late July we had X and Y over drinking into the wee hours... those #%#$%s must have been futzing with my computer after I fell asleep, and somehow I never noticed".
Most importantly -- you have to predict the reasons people will be looking at dates, and this varies. Gmail shows both because they can't guess; email can carry so much different stuff.
HN post/comment timestamps beyond a few days ago can be notated in number of days as far as I'm concerned; I don't need to know what year, even -- just "this is old".
The timestamp on a blood sugar reading should include time of day (and possibly day of week even) -- a full timestamp, minimum -- to be useful.
Well, see, I would just print the date that's there in the database in the first place. How is "864 days ago" useful information? Doesn't everyone at least convert it to the number of years it stands for?
Relative dates are effective up to a point. People think relatively about events for perhaps a month or two. Past that it probably becomes more effective to use absolute dates.
+1. I'm not a fan of relative dates as a user (although I maybe a too "scientific" mind) but I can't see any other way to display dates if timezone matters.
When timezone no longer matters, e.g. after a few days, then I would switch back to absolute dates exactly to avoid such incomparable expressions.
I'm an actual user who doesn't really care about machine-readable timestamps and I would prefer absolute dates. The gmail solution in post works for me too.
I totally agree. UX should not be based on some engineer's idea of what might be useful but on what might be useful to the actual user. Seeing August 22 doesn't mean much to me because I don't constantly look at my calender, but seeing 1 day ago or "yesterday" lets me know when something happened without me trying to remember what today's date is.
However, that being say, I thing relative dates do have a point of diminishing returns. For me, past a week is when I'd prefer to see actual dates.
I do agree that "over a year ago" is pretty vague at not as useful to the user as "August 2011." The word "about" gets ambiguous when dealing with longer spans of time. Obviously "about" is ambiguous by definition, but the degree of ambiguity increases as one goes further away from the event.
The best part: Twitter actually already does something very similar what he suggests, with their relative dates having a data-time attribute containing the Unix timestamp for each tweet. If he wants to throw away source information and store pixels representing how a particular browser rendered it, well, that's not Twitter's problem.
His microdata example is also only write if you having upgraded to HTML5, in which case <time> is obviously better.
It's much more sensationalist and page hit attracting to make absolute black or white claims rather than something nuanced. How many hits would "When to use relative versus absolute time" get?
It's on the HN front page. Look at this thread. The joke's on us.
I disagree. I think the date should be there so I know exactly when it happened. This is especially critical in realtime systems. I have seen some horrid relative date instances. On Pinterest, for example, I have seen "about a year ago". Really?
If you can recognize cases where timestamps are important, you should be able to recognize cases where they aren't, too. Why does it matter exactly when a Pinterest item was pinned? Answer: for the vast majority of cases, it simply doesn't.
But the stupidity is that you are taking away something for no good reason. You already know the date of the pin. You figure it's important to show this, but then you make it completely useless instead of providing the already useful piece of information you actually had.
Providing perfect information isn't always as important as providing information that's quick and easy for people to process.
Take a piece of information like '12 Apr 2012 10:09 AM PST'--there's a fair bit of mental arithmetic required to work out how long ago that was, if 'how long ago' is important to you. And it's different arithmetic depending on whether you're looking at it on the 12th of April (time zone adjustments, crossing noon)or the 14th of June (how many days in April and March). Multiply this by the number of dates on a screen, and you might end up with a lot of information noise.
A lot of the time, a quick, rough idea of 'how long ago it was' is really helpful. I wouldn't be so quick to label relative dates as stupid. Information overload is a real problem for humans, not so much for computers. It really depends on the circumstances, but for most UIs designed to be read by people, relative dates can work really well.
It really does matter because "a year ago" is VAGUE. Is that 1.5 years ago? 1.1 years ago? 1.6 years ago? And depending on the content, it is even more critical. Let's say it is a sporting event of Usain Bolt. Did that amazing shot of him running happen in the Olympics or at a meet? No. Idea.
If you can make a case for why you need an absolute date at that level for a Pinterest item, then I'd be all ears. But for now these use cases demanding absolute dates for ephemeral social media content seem ephemeral.
Absolutely agree about realtime. Just ran into this issue. Relative timestamps on content that is live updated gets stale immediately. The user has to refresh the page to get an accurate timestamp, which sort of defeats the purpose of the realtime content. So we switched to absolute.
I don't think they care about screenshots specifically, but they certainly do intend Twitter.com/.app to be the primary or only method that tweets are displayed, ever. To this end, relative dates are great.
You do have a good point that touches on the dilemma of the internet archivist, but this is certainly a problem easier to solve than the ones faced by people attempting to preserve software or video games, for example.
How is the relative timestamp not machine-readable? Can the computer not be programmed to parse If (4_characters_after_timestamp == " ago") {$timeoftweet = $now+$timestamp} ?
One of the author's points is that relative dates discard information. 10:37 and 10:36 are both encoded as "9 hours ago," and therefore you can't map back to absolute dates without potentially losing order.
I dunno, I find the GMail inbox less usable for pretty much the exact reason he gives in the article. When I see an unread mail with "yesterday" or "one day ago", I'd like to know whether this mail--that I apparently overlooked--was sent yesterday morning or evening, so I can know whether the person expected me to reply yesterday or today when I see it.
The problem isn't a technical one related to timezones. The problem is that full date/timestamps are less useful for a reader to see than relative dates in many cases.
if the date is less than a couple of days old (or whatever threshold works for you) display a relative date. This is useful because in the short term relative dates are more useful to the user. If it's older than the threshold display a YYYY-MM-DD H:m:s or whatever format floats your boat.
Here's what I do. First, the markup:
<time datetime="2011-08-27T19:15:38Z" pubdate>27 Aug, 2011</time>
So, time in [ISO 8601][0] format. Run JS to transform '27 Aug, 2011' into a relative date.
If the relative date is >1 month (or, whatever you'd like), then just display the full date.
Ding ding ding. Machine readable and user-friendly.
If you're making your users' experience worse out of a fear of breaking the relative value of screenshots you might need to re-examine your priorities.
This would even let users change the date back with a user script.
A browser/extensions could add a tooltip or context menu item to time elements, showing relative and absolute dates regardless of the way it's authored.
a) Who cares about screenshots? "I'm going to the pub on Thursday" suffers from exactly the same issue.
b) Nonsense. Of course relative dates are machine readable. But anyway, web rendering != API.
c) These examples are not ambiguous, they are merely less precise
And less precision is, indeed, often what a user wants. That's why we don't print "posted 124568080nanoseconds ago". Simplifying to a reasonable unit, appropriate to the application, reduces cognitive load on the user. Most people struggle to tell you today's date, let alone knowing how long ago an arbitary timestamp was.
I like twitter (who maintain a relative date on the top-right of the feed entry) and gmail exactly the way they are.
"I'm going to the pub on Thursday" isn't likely to be archived and referenced at some future date.
Unless you Tweet it. In which case, your statement (and the relative, human-parsable time) and the timestamp (absolute, machine readable) are both present.
Repetition and redundancy can increase robustness and strength.
This would be a valid argument for not persisting dates as relative values.
It isn't an valid argument against presenting dates this way.
The OP's POV seems, to my eye, driven by the fact that primitive screen-scrapers can't just run a simple "toDate" function to provide it, API style, to some back-end. But it doesn't mean that it's not possible to convert them - it's not even that hard.
Fortunately, UI designers care more about their actual users than satisfying 3rd party leeches.
Equally frustrating is when dates are displayed without the weekday, especially when trying to schedule an event. "August 30 2012? Wait, is that a Tuesday or a Wednesday?"
Hopefully the <time> element catches on, so I can make my browser display dates however I like.
That's a good example about why there's no one-size-fits-all approach to displaying dates and/or date intervals. I care what day of the week I fly. I care if someone commented on my picture 2 minutes or two hours ago. I don't care about the local timezone of someone else's server.
Lot's of love for relative dates, but personally, I agree with the poster. Here's an example from HN:
user: run4yourlives
created: 2012 days ago
Got any idea how long I've had an account for? I sure as hell don't, because 2000 days is a completely irrelevant measurement to me.
It would be a lot cleaner just to say that I've been around here since 19 Feb, 2007.
I think this is a bigger point than just the dichotomy between dates. If you are trying to make them mean something, make them mean something. 2 hours ago is fine, but 23 days ago is most certainly not. Was that a weekend? A morning? Last Tuesday after work? Who knows.
Actual dates work for longer periods of time, relative much better for shorter frames. Stick to this, for the love of God please.
Okay, but how is Feb 19, 2007 relevant information to you? If you were trying to schedule something based on your HN Join date, then i suppose you want the actual date. In the general case though, the date on your profile is only used by other members (or maybe moderators) to get a rough idea of how long you've been a member for. I can look at your profile, see 2012 days, and understand immediately that you've been an HN member for a long time. I've learned everything i need to know, and i've learned it quicker than i would have by reading a full date and subtracting it from today's date.
sometimes you need a relative date. sometimes you need an absolute date. saying one is always bad and the other is always good is stupid, it all depends on the context.
Why are you worrying about how it's relative to me? That's not your problem to solve.
We have a system for understanding time that is universal around the world. Instead of presenting me with information that is in that format, you're making up a new one for no good reason.
saying one is always bad and the other is always good is stupid,
Well, yes, which is why I didn't say anything like that.
The "2012 days ago" is just a sub-optimal implementation of relative dates. It could be expressed as the more comprehensible but less precise "over 5 years ago" with the actual date either nearby or in the title=""
"2 hours ago" is actually more informative than "1:08 PM 23 Aug". The latter requires a location to be exact (1pm where? Is this being localized? Do you guys use daylight savings?) and the former does not.
How is "2 hours" computed? Android does this by checking if the >120 minutes has passed. Which is mindboggingly incompetent.
Especially when it comes to days. So, I had a call to me that was made 1 day and 23 hours ago. I look in my call history and it says that it was "1 day ago", and I'm like. Wait? That can't be right, I didn't make that call yesterday.
One hour later android changes it to "2 days ago", no sentinent being in the history of the universe has ever, or will ever, think about in that way. And just by seeing "x days/hours" ago I have no idea what is actually meant.
I think the best way to display date/time is to have the text in relative date/time and title in actual date/time.
For example:
This post was made <span title="2012-08-23 2 PM EDT"> 2 hours ago </span>
This solves the problem of both clutter and practicality. Now whenever you need to know the absolute time, just hover over the relative time and it will also show up in screenshots!!
Doesn't help for multiple <span>s (actually <abbr>s from the post) in a single screenshot, but a bookmarklet or userscript that replaces all <abbr>s with their title attributes would help.
I concur. I do think the "5 minutes ago" type of message should be shown first, with the detailed date/time in brackets afterward. What the users want/need is probably the key driver in this kind of UX decision though.
As a sometimes developer of web applications, relative dates nicely (for me) solve the problem of timezones. "10:42 PM - 15 Aug 12" means nothing without the relevant timezone information. "30 minutes ago" is timezone agnostic.
For non-commercial apps, lately I've been displaying relative time, but embedding the actual datetime (in UTC) as a title attribute.
I think the point of showing relative dates is that the web is International and cross border. and if you display a date time. You need to define next to it Which Timezone !
Then it would be complicated for the users living in USA to read the status of His Japanese friend that is stamped with a future date while it was actually posted a minute ago.
Another Scenario:
Which Time-stamp you want to use. the Client or the Server ?
Imagine a user in London using a server in Singapore, which time stamp you want to display, the Java-script generated Time-stamp for the Client's browser in London, or the Server time-stamp in Japan ?
Relative dates are awesome. They're easier to understand, and save us a lot of space.
We use the timeago [1] jQuery library. It shows relative dates in an abbr tag and keeps the microformat in the title attribute, which shows in a tooltip on hover. We use the en-short [2] locale, so it formats times like '1y ago', '1mo ago', '3m ago', etc.
I think Gmail's format is the best of both worlds, but we don't have the space for it in our sidebar gadget.
Finally, the screenshot argument isn't very convincing, and neither is machine readability or ambiguity. They're formatted for humans, and they're ambiguous on purpose.
I find relative dates to be the most useful, most of the time. The scenarios where needing the exact date or time come less frequently.
The argument for screenshots is valid, however, sites like failbook where you see the post progression as X minutes ago still provide you the quick glance benefit of relative dates.
The problem is not relative dates in context. Relative dates in context are extremely useful! Would I rather have to parse "4:50pm January 10th, 2012" or "5 minutes ago".
---
The real problems:
1. Old relative dates aren't useful.
- Instead of "1 year ago" give me a real date. I can figure that out for myself. OR give me the option of getting a real date easily (hover, or click, or something).
2. Relative dates are shared statically.
- Listen for print-screen commands and swap things to relative dates. (I have no idea if this is possible. I actually would bet that it isn't, but maybe it should be.)
- Make embedding real HTML much easier so when people think about embedding tweets they don't choose images just because they are easier.
- Make embedding real HTML much more advantageous (real retweet button, view conversation button, etc.) so that people want to use it instead of static (read: lame) images.
>- Listen for print-screen commands and swap things to relative dates. (I have no idea if this is possible. I actually would be that it isn't, but maybe it should be.)
If it were, a lot of people would immediately (ab)use it to make screenshots impossible. You might consider that a positive or a negative, depending on your perspective.
Edit: although, on a Mac if you listened for `Cmd` or `Shift` you'd catch the print screen command. And I don't think anyone would complain that the dates changed on Ctrl press.
Of course you might still be screwed on other OSes.
This sounds like more of an argument for why you shouldn't be distributing stuff in the form of screenshots (although the horrendous entropy of the web is a compelling argument in favour of that, I realise).
Neither of those two solutions are correct. They only work in a some cases. You need a more advanced detection algorithm for this. Preferably one based on the Olson database, since time zones have changed over the years and you want to be able to display past dates correctly.
This solution linked from your second link looks more correct.
ridiculous argument and bad misinformation. relative dates are better for users in any context involving event freshness/recency, and they are machine readable by using many well-known markup techniques, including the microformat he mentions.
If you're looking at an email and it says "2 hours ago," how are you supposed to know if it's rounding the number or giving you an exact value? If it's currently 11:15am, was the email sent before or after your 9:00am phone call?
I actually find this pretty convenient. I don't remember days numbers. 5 days ago gives me a perspective. If I want the exact time, I'll just unfold the email tab. (I'm talking about the Gmail example he picked)
Speaking of crappy user interfaces, his blog breaks the Alt+Left keystroke to go back. It takes me to previous blog entries, rather than back to HN. Grrr.
The archival quality of something displayed on the screen is not as small of a factor as some people are making it out to be. I can't count the number of times a poor user has pasted the output of "hg log" into an email without stripping the sequence number out of the changeset line, only to confuse another mailing list reader when they look for the patch using the sequence number.
This totally depends on context. For example, on HN, relative dates are great, it is much easier to see how old posts are at a glance. However, anything where date is important, use the full representation.
The more interesting question is, what is the best (easiest to read) way to format a full date? I believe it is: 8/1/2012 10:10:48 PM. I find twitters format slower to read: 10:10 PM - 1 Aug 12.
I dislike when an author titles and formats their post in this way. The title is an overstatement about why something that is common practice is wrong ("hey! i use relative dates, what am i doing wrong?"), leading to an article with a couple interesting points, ending with a concession that common practice is actually OK but could be better.
I agree with others that the argument is pretty weak considering twitter screenshots are one of three reasons why we should avoid relative dates. But i would have felt it genuine if the thesis was his last sentence: "Avoid displaying relative dates, but if you feel like you absolutely need to, follow these best practices: ..."
One interesting solution would be to have the html contain/display the exact date, so any scrapers etc. have access to the precise date BUT use a Javascript/CSS overlay the relative date on top of that exact date.
I work on a product for software developers and speaking to our customers there are two camps: those who like relative dates and those who like absolute dates. What does HN prefer?
And also, doesn't Twitter's extreme attention on embedded tweets lately underscore how little they care about screenshots? Not to mention the fact that while they have, as the post suggests, resorted to timestamps on individual pages, they are still using relative timestamps in the main stream.
As a user, I prefer relative time. And since relative time views are almost always displayed in sequence, most of the arguments laid out in the post fail to matter.
I'm the PM for a horoscopes app, and I much prefer to use relative dates (e.g. yesterday, today, tomorrow) instead of absolute ones (e.g. wednesday, thursday, friday).
The problem is that the app serves a worldwide audience, and I don't always know the locale of the user. By showing relative dates, everyone feels happy that they are seeing today's horoscope today. With absolute dates I'd get a lot complaints that they were seeing yesterday's horoscope for instance.
I've always hated relative dates. Glad people are finally coming to their senses. The only case I see for relative dates are that they are more user friendly. But is it really that hard to parse "Wednesday, August 22nd at 8:22PM"? While I believe in easy to use interfaces, we don't have to act like our users are total bafoons either.
In the long run relative dates are more confusing for screenshots, leaving a page open, etc as stated in the post.
The reason why relative dates are used is that you don't have to worry about timezones. You either have to get client's timezone and reformat dates, or use static timezone and let users do the conversions in their heads.
Personally I prefer relative dates, because that's the information I'm looking for. I don't care if some screenshots break; there shouldn't even be any reason to take screenshots of tweets etc.
> Twitter has since stopped using relative dates on their tweet pages, and instead just shows the full date now.
This part made me feel the argument is suffering from confirmation bias. Twitter has only removed the relative date from the page where a tweet is accessed directly, not in the timeline where the relative timestamp is absolutely relevant.
I totally agree, this is another case of software thinking it's smarter than me. This is really a problem on blogs, where you'll have 5 comments in a row that say "posted 1 hour ago" and you have no idea the order you're supposed to read them. Common sense nullified by "smart" apps yet again...
If you push this argument further, missing time zones are a problem as well. I recently moved between continents, and the time zone difference sometimes results in gmail conversation threads showing send times ("On Aug 15 9:00 PM Someone wrote: ...") that appear to time travel.
I think there's room for both relative and absolute. Encode the absolute in the metadata for machine readability and display relative to the people for as long as it makes sense. We can go beyond 'it must be 0 or 1' when it comes to the presentation layer!
So you don't prefer them and that's why I shouldn't do something?
I'd also prefer that your website not high jack the back key-command so that I could go back to Hacker news without clicking the back button in my browser.
If you are worried about not knowing when the screenshot was taken couldn't you include in the actual file name the date the screenshot was taken in a "machine readable" format?
Twitter also doesn't give a fuck about archival via screenshots. I'm pretty hard-pressed to imagine who would, actually.