How to display duration (HH:MM) so it isn't confused with clock time

Question

I have a table in my application that shows dates along its x-axis, and different statuses along its y-axis. The table keeps track of how much time an employee spent in a given work status (on duty, off duty, etc) for the given day in hours:minutes. I've included a rough sketch below:

My worry is that some users may get confused and think that this time represents something different, such as the time at which this state occurred (i.e. went on duty at 6:00, went off-duty at 18:00). Is there a better way to represent this time to be more clear of what it is representing, or is this just something that users will have to learn on their own using my software over time?

Answer 1

You are right to ask this question. It really depends on who your users are.

In labor-intensive environments, users are often very familiar with the HH:MM notation for duration, so it's OK to use that format. But, I agree that even for those environments easy to get it confused with time.

Is there a better way?

Let's start with the existing solution. The benefits of HH:MM are:

• It's universally recognized as a time format
• It's scannable, i.e. when you have lots of data in a grid, the HH:MM aligns nicely so it's easy to scan.

With this in mind, here are two approaches. You could label the existing table to remind users that it's showing duration rather than time. Or you could adopt a different notation to indicate that it's duration:

The notation on the left is popular these days, and preserves some (but not all) the scannability while denoting duration more clearly. The approach on the right keeps the cleanliness of the HH:MM notation, and sets user context elegantly by utilizing the top-left corner (which is the visual entry-point to the table anyway).

Answer 2

A plus sign is sometimes prefixed to the time format indicate offset. It can also imply duration. For example:

 +4:00  +10:00  +4:00
 +6:00   +0:00  +6:00

Answer 3

Another possibility would be to add a "prime" mark at the end, as is sometimes (often in race times) used. Minutes and seconds would look like 4′33″, so a single prime is minutes, so use 1:30′ for an hour and a half.

Answer 4

You can also show the minutes with a smaller font.
On stopwatches, this is done for the seconds or milliseconds.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 5

The international standard ISO 8601 would suggest P04:00 or P4H. Its part on periods, durations or time spans and repetitions, though, is hardly ever followed – and you aren’t using its date format in the first place. JFTR

Please note that 4h00 is not unambiguous, since some people tend to write clock times that way. 4h00m or 4h00min would be better.

There‘s also icons: a stop watch ⏱ (with big buttons) often designates durations (less often an hour glass ⏳) where a clock face 🕒 (with big hands) shows times.

Answer 6

You could use decimals. So for example:

90 minutes would be 1.5 hours instead of 1:30

3 hours and 45 minutes would be 3.75 instead of 3:45

This format is highly scannable and makes it easier to sum the values in your head.

Answer 7

ISO 8601 Duration

As mentioned in the answer by Crissov, the ISO 8601 standard defines a textual representation of a span of time in this format: PnYnMnDTnHnMnS, called Durations.

In this format, the P marks the beginning. The T separates the days portion from the time (fractional day) portion, and is omitted for whole days.

Examples:

• P1D = One whole day.
• PT5M = 5 minutes.
• PT4H30M means "four and a half hours".
• P3Y6M4DT12H30M5S represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds".

Even Briefer: 4H 30M

You could truncate the PT for presentation to the user. So four and a half hours would be: 4H30M.

Perhaps add a space for readability: 4H 30M.

Pros

The upside is that this format is unambiguous, and won't be confused for some other meaning. Another benefit is the fact it is a standard. And the values are somewhat intuitive and easy to read and understand.

Cons

One downside is that users may not be familiar. So a moment of explanation or training may be needed.

Programming

Some programming libraries can parse and generate such strings. For Java, the Joda-Time library does so handily with its Period class. Similarly, the new java.time package built into Java 8 also offers a Period class.

Example using Joda-Time 2.7.

DateTime now = DateTime.now();
Period period = new Period( now , now.plusHours( 7 ) );
System.out.println( "period: " + period.toString() );

Output:

period: PT7H

Answer 8

maybe is out of scope, but scanning a table to detect patrons is not very user-friendly. If resources are available, i would go with an horizontal stacked chart:

It offers a better perspective of the percentage of time on each status, and is more easy to scan for out-of-patterns days.

Answer 9

JIRA uses the '3h 15m' style notation which works for me.

Oh the other hand, I used a timesheet system in which time was entered in 15 minute blocks. I found having to enter times as a decimal values like 3.25 was non-intutive way of expressing a duration of 3h 15m.

On the example given, couple of things are not clear:

What is the granularity? Minutes?, 5 minutes or 30 minutes? If showing something like 24 hour days split into several states, I would be thinking along the lines of percentages or segmented bar graphs rather than hours/minutes which might be too precise for a view. Also remember that twice a year you get 23 or 25 hours.

Answer 10

One other solution could be to show the seconds as well. Since seconds will be changing quickly it will be clear that the times are continually changing. I don't recommend this solution but from the perspective of clarity, it works.

Answer 11

It seems to me that confusion occurs because there are 2 low-order places with both methods. You could take all the data to fixed 3 decimal places (or 1 decimal place) of an hour, using a decimal point, and rounded before display. Remember to keep the data accurate by doing the maths in integer minutes internally, so minor floating-point errors can't occur when totalling. Another idea is to report everything in minutes.

If you test some alternatives on some users you might be able to get to the best solution, possibly something that hasn't come up yet. Some might think it's your job to resolve the ambiguity.