4

I'm writing a mobile app, in which users can record a date for something that happened in the past. On the main screen, they can see the date they saved, and next to it, the number of days since this date.

It looks like this: 6days

This is fine, but if the number of days becomes larger, the elapsed time becomes less clear: 118days

I can have access to:

  • the number of days since the date recorded (406)
  • the number of weeks & days since the date recorded (16 & 6)
  • the number of months, weeks & days since the date recorded (3, 3 & 5)

It's fairly easy to imagine switching to the upper unit when it's non-null. For example, 0-6 days, 1-4 weeks, 1-12 months. The issue with this basic approach is that 1 month and 26 days would show up as "1 month" when it's closer to 2.

I could combine 2 units (weeks & days, months & weeks, etc.) but I don't really like this option, given the space it requires (it's a mobile app so I'd like to keep it short).

I understand there's no "rule" regarding this, but how would you handle such a situation ?

Improve this question

3 Answers 3

Reset to default
7

Week is a bit tricky here. Also month counting is not consistent with month length between 28 and 31 days (average 30.4).

But you need some human-readable numbers here. Provided you are not opting for rounding, what about the following schema?

  • less than 8 days -> display the number of days

    4 days => 4 days

  • less than 1 month -> display the number of weeks and days

    20 days => 2 weeks and 6 days

  • less than 1 year -> display the number of months and days (if the remaining days not divisible by 7)

    42 days => 1 month and 12 days

  • less than 1 year -> display the number of months and weeks (if the remaining days divisible by 7)

    44 days => 1 month and 2 weeks

  • more than 1 year -> display the number of years and perform the above schema with the remainder of the days

    400 days => 1 year, 1 month and 5 days

  • more than 1 year -> if the remainder of months is a quarter, display the number of years and perform the above schema for less than a month with the remainder of the days

    470 days => 1¼ years and 15 days

However the latest is not that clear, in my opinion.

Bottom line - use no more than two units at the same time.

Improve this answer
6
  • Thanks for your answer. This is a potential solution I talk about in my post, where I state that it may end up taking too much space. Nevertheless, I also think it's the only comprehensible option available.
    – rdurand
    Mar 7, 2018 at 13:33
  • @rdurand, if lack of space is your problem try either abbreviations like "d" for days, "w" for weeks, "m" for months, etc. or rotate the unit counterclockwise by 90 degrees.
    – Mike
    Mar 7, 2018 at 13:53
  • rotating the units is interesting (although maybe painful to code, but that's another subject), thanks ! :)
    – rdurand
    Mar 7, 2018 at 14:29
  • @rdurand - if it is Android, wouldn't Canvas.drawTextOnPath be a solution for you?
    – Mike
    Mar 7, 2018 at 14:39
  • probably, but it's iOS :)
    – rdurand
    Mar 7, 2018 at 14:42
5

You don't mention a requirement for precision. If exactly when the thing was recorded isn't as important as about how long ago you could do something like:

4 Days

and then (although not accounting for February, leap years etc:

35 days would be (Imagining as a round)

About 1 Month

80 Days

About 3 Months

And for 360 Days:

About 1 Year

If you want a little more precision without it being critical, you could leave the decimal places to 1 digit:

196 days:

About 6.4 Months

And it's always possible to add the functionality to click the control and get more details such as the exact date or time span.

Improve this answer
2
  • Thank you for your insights on this. Although it wasn't mentioned, I think in this case using "about" would cause more confusion than anything. I also ruled out the decimal option as the values (weeks, months) are not base ten, which makes the decimals sometimes unclear for the user. But now that I'm thinking about it, using only .5 decimals could improve the precision while keeping the readability (on can figure 3.5 months easily). With this comes the issue @Mike noted that months can be 28-31 days and 4-5 weeks.
    – rdurand
    Mar 7, 2018 at 14:39
  • @rdurand I agree 100%, you could easily get away with just the easy round decimals. Also, I did consider the 28-31 days problem, and ~1 month is even fuzzy for people. Jan 30 - Feb 28th is "1 month" by most counts, but so would be Feb 28th to March 28th OR March 31st to most people who aren't worried about say accounting or edge cases. In a comment system for example I doubt 99% of your users would notice the lack of precision PLUS you'd have the disclaimer of "about". End of explaining how this could theoretically work, even if not for you
    – Austin French
    Mar 7, 2018 at 23:41
2

Visually it would be superior to simply display the number of days. The key question that must be answered is " What is the usefulness of this information?" and secondly "How will this information influence the action of the user?"

Assuming the user will not act differently if he sees 89 days or 91 days then simply listing the days ought to be fine. If he knows he must do "x" every quarter then more information is needed.

However there comes a point where listing the number of days becomes silly: example 1723 and certainly something like 11,234 days.

Based upon the information given I would display 1-365 days and then go to "More than 1 Year", "More than 2 Years", etc...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.