27

I have an issue where by we have a dashboard which displays deadlines.

We just encountered a bit of a conundrum, with how to handle weekends.

You have event A, which has a deadline to be actioned in 24 hours. Event A is raised on 9:30am Thursday, there for the deadline is 9:30am Friday.

On Friday, the dashboard displays in the deadline column:

Today

Nothing happens Friday (down the pub probably), and on Monday, the dashboard displays:

3 days ago

When, for the business there's no work over the Saturday or Sunday, hence they have only missed the deadline by 1 day, not 3.

However, the issue comes, if the dashboard displays:

1 day ago

On the Monday, then people start to think the deadline was on Sunday? And the actual timestamp of the deadline is 9:30am Friday! So the two points do not match...

How best to display this?

  1. Just leave it as is, on the understanding that the deadline was in fact, actually, truthfully 3 days ago
  2. Adjust the deadline to be Sunday for the display?
  3. Have the two columns split, and have a separate calculation for the days ago, and one for the actual deadline? And then have to explain why Sunday was actually Friday.
  • 5
    I get that it's helpful to show the dates in a friendly manner, but is it not an issue that the deadline all day Friday indicates that the due date is Today when in fact, it is actually Friday at 9:30am? Wouldn't this lead to missed deadlines? – maxathousand Jul 17 '17 at 19:03
  • @maxathousand I'm being generic, as the deadline will display in 30 minutes, or an hour ago etc... But broadly, the only time when the situation of weekends occurs is when days are involved. And don't worry, deadlines are missed all the time ;) – RemarkLima Jul 17 '17 at 19:10
  • 45
    1 business day ago – Cano64 Jul 17 '17 at 21:15
  • 3
    You might have to account for public holidays as well ... – Hagen von Eitzen Jul 18 '17 at 17:29
  • 1
    This happend every years in a country or an other. Working on all the eu I can't think of a years were we didn't have to explain working day to a Customer. Because of those national Holiday, or extra holidays. So you counter will be invalid if the Customer don't have the same culture. – Drag and Drop Jul 19 '17 at 13:54
51

Let 3 days ago mean 3 days ago (not 3 business days).

It seems perfectly reasonable for a Monday-Friday company to want to schedule server maintenance to be due on Sunday morning when traffic to their web services is low. If your UI usually reflects number of business days, when they come in on Monday morning, alerting them that their event is "1 day overdue" when it actually was due on Sunday morning would be difficult to communicate.

An additional benefit: by not caring about which days are business days, your UI feedback isn't dependent on keeping company holiday data up to date. 1 day means 1 day regardless of whether or not the office was open.

However...

If you plan on:

  • Never allowing due dates to be on weekends
  • Requiring business closure data to be up to date

I'd go with tobybot's great suggestion that suggests adding the exact due date in parentheses to be explicit in this ambiguous situation.

(Additionally, if you're 24 hours overdue on a Thursday, saying "1 day ago" is likely not ambiguous, thus, you could skip adding the parentheses.)

27

Rather than saying:

The deadline was 3 days ago

How about phrasing it:

The deadline is 1 day overdue

  • 1
    This. Overdue by [duration] is a nice short phrase that can take any duration (Overdue by 2 hours, 1 day, 2 weeks, etc). – Beejamin Jul 20 '17 at 1:29
23

If "Day" means something other than "Calendar Day", be specific.

A user reading "3 days ago" will assume Friday if they are reading on Monday, and I find it hard to believe that people will know that "3 days ago" on Monday actually refers to the previous Wednesday.

You could use specific term such as "working day" or "business day" if you choose to exclude weekends from your calculations. It may help to also annotate with the specific day name (if less than a week) or date (for longer durations).

Examples

(Assume today is Tuesday 18th July 2017)

  • 1 business day ago (Monday)
  • 2 business days ago (Friday)
  • 5 business days ago (11th July)

Or

  • 1 working day ago (Monday)
  • 2 working days ago (Friday)
  • 5 working days ago (11th July)
  • I like this approach. Just don't forget those pesky public holidays on Fridays and Mondays. ;) – Bernhard Hofmann Jul 19 '17 at 14:20
  • 1
    Also be careful using "working days" as that can be confusing for team tasks when some of the team are off for a time, and has extra complications if you need to account for part time workers. "Business days" is easier to pin down to a simple definition. Just to throw another complication into the mix though: if you serve international clients their business days relative to the time an issue is raised may differ from yours, though this is a contractual issue more than a technical one (define that "business days" means your business days in any SLA arrangements).. – David Spillett Jul 21 '17 at 10:03
13

Is this for a system where "working days" can change (like this is a piece of software for use by various client businesses), or are working days always M-F?

In either case, you could change the assumption to be that it's counting working days. If that's made known to the users, then you can do the math appropriately and not have to worry about it. So if the business is closed on Sat-Sun, you just count how many weekdays have passed. On Monday, "1 day ago" means Friday.

The catch here is that the user has to do a bit of thinking to figure out what "3 days ago" means if they're seeing it on a Monday. To solve this (assuming today is Monday, July 17, 2017), here's an option:

1 Day Ago (Fri)

3 Days Ago (Wed)

10 Days Ago (6/26)

  • Working days for this are always M-F so fixed in that sense, and we'll not worry about public holidays! Yet... – RemarkLima Jul 17 '17 at 19:04
  • 1
    Great suggestion! I hope you don't mind, but I clarified the example date for people reading this in different locales. – maxathousand Jul 17 '17 at 19:10
  • 2
    Great idea. You can also say "# business days" for further clarity, if there's room to print the extra characters. – Nathan Christie Jul 17 '17 at 19:27
  • 1
    @maxathousand could've also changed "6/26" to "Jun/26". Down with ambiguities!!! ;) – msb Jul 18 '17 at 0:31
  • 1
    @RemarkLima: In German, you sometimes read “Geöffnet werktags (außer Samstag)” which means “opened on business days (except Saturday)” because at some point Saturday was a business day as well. So the working days might not be fixed to Monday to Friday everywhere. – Martin Ueding Jul 20 '17 at 10:32
11

How about if the deadline was sometime during the last week, you display:

Last [day of the week]

so your example would be:

Last Friday

Overall, your dashboard (with a mixture of deadlines), assuming it was a Wednesday, might show:

  • Yesterday
  • Today
  • Last Friday
  • 2 days ago
  • Last Tuesday

Alternatively, you could use stick with friendly descriptions and add a working day count:

  • Yesterday (1d)
  • Today
  • Last Friday (3d)
  • Monday (2d)
  • Last Tuesday (6d)

EDIT: Added a better mix of deadline examples

  • 2
    Beware - different people will interpret "last Friday" in different ways - some will always take it to mean "the most recent Friday", but some will take it to mean "the Friday before the most recent Friday". – psmears Jul 19 '17 at 13:22
  • 1
    @psmears - yes, you are correct in that this can be open to interpretation. My second example (with the day counts) should help avoid any confusion, although it won't help avoid any mental arithmetic necessary! – Raad Jul 20 '17 at 10:29
4

I think the problem is that you're mixing two different but closely related concepts.

There is the deadline for the action which is a fixed point in time. Then there is the amount that the measure has been breached by which can be affected by the business time you want to apply to the measurement.

You're currently showing the amount of time since the due date but it sounds like people expect to see the amount of business time the task was breached for. From what you've said time on the weekend doesn't count. What about outside of normal business hours? Does the time overnight when no one is there count? It may not matter depending on how granular you want to be with your display.

I think the easiest way to display this is to add another column to show the actual deadline as separate from the amount of time the task has been breached for. This will avoid any confusion and also allow you to accommodate scenarios where tasks are scheduled on the weekend and/or some future task may have a 24x7 schedule for calculating their breach threshold because it is really critical. Alternatively you just need to pick which information you want to display and clearly label your field.

example table

Normally though, for measurements involving business time, I would display the actual deadline date and the number of hours the measurement has been breached by. Row groups or colour-coding could be used to sort things into time-based buckets like "overdue", "today", "tomorrow", etc. But that is all rather subjective and users have weird requirements...

3

As an example of how to handle this issue of due dates, consider Asana project management application. Essentially, it ignores the concept of business days.

Asana editorial use case example screenshot

Asana states the assigned due date and color codes whether that's upcoming or overdue. If on Wednesday you were meant to complete a task the previous Friday, the task would have a red "Friday" in its due date place. Due the upcoming Friday, it's a green "Friday" in that same place. Due date more than 1 week before or after the present, it says a date stamp rather than a day of the week, and for upcoming due dates more than a few days away the color code is gray. Only time it does otherwise is for green or red "Tomorrow" or "Yesterday", in which case it does not differentiate business days from regular days.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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