I'm not sure about hard research, but there's a good article from UX Movement:
Absolute vs. Relative Timestamps
When to use absolute timestamps:
There are times when users need to look back on past content to retrieve information. Without absolute timestamps, users can’t target a specific period to find the information.
Sites that host photos, ...
Format distinction needed
08:15 is typically identified as clock format, not duration.
You could just write (8h) or (8¼h) for duration (see list of fraction unicode chars).
Here is how Google do it:
Duration or endtime?
Another question you should ask is:
Which is more important for users - duration or end time?
If a meeting starts at 06:00 and ...
I have seen the following visualization used to represent down time and it has been effective:
The illustration in the question requires too much thinking.
The linear time line works well for a 24 hour timespan.
Possible redesign below:
Color should not be used as the only indicator to accommodate those with color blindness (Red-Green being very common). I've used different icons as well as different colors for indication.
Red has a "finality" to it and might make the user think further action is required to solve the problem. I've made the icon yellow ...
Your first solution is the classic one. The most of the timelines on the web are made with this solution. Just google "timeline" and take a look to the pictures. But you said, you only have a small area to use your timeline, so this could be tightly. I would use a version, where you have the line at the bottom of the page and just show up the events upwards. ...
This is the way Pingdom chose to visualize it in their Public Status Pages:
(Disclosure: I was the front-end web developer who implemented this graph back in 2010, but not the designer or originator of the concept.)
Forward chronological order lends itself well to finite amount of data that tells a story. Reverse chronological order lends itself well to (potentially) infinite amount of data that loses usefulness over time.
For example, in Facebook, each post is listed in reverse chronological order, so you scroll back through history, but within each post the comments ...
When you use absolute timestamps, you need to find out which timezone the user is in. This can be a guess based on IP address (which may be wrong) or a setting in the user profile (which needs to be filled out during user signup, adding another field), or a mix between both.
It is confusing to the user when you get it wrong. When I travel abroad, some ...
I see there a debate whether the finish time or duration should be displayed and in fact it's not what the OP is asking for. They decided to go for the duration.
So first of all I suggest making it disambiguous by explicitly stating that the bracketed value is time span:
06:00 - Meeting (for 8:15)
It still looks weird, I'll come back to it later on.
6:00 - 14:15 (8hs) - Meeting. (Starts in 2 hours).
The user can easily infer the duration of the meeting from the give time, but you can also display it after the hours. Try not to put descriptions or labels, they will only distract.
An aside: COTS stands for Commercial Off The Shelf.
Per the chart - it tells me nothing. Both the X and Y axis are so deep I have to following an enormous gulf in order to guess that the server was down roughly in the timeframe of 20:24-20:28.
Why are there 4 lines in-between the hour lines when they only jump by 2 hours?
My eye also has to wander a great ...
UptimeRobot is a tool for monitoring server downtimes (I'm just a user, no other connection whatsoever). They're showing a small graph on the left side for the up-/downtimes for every watched server in the last 24 hours (I edited the image because none of my watched servers had a downtime in this period). If you click on one of the bars, you see details on ...
I do not recommend the highlighting of 'contained' choices. It is an interesting idea, but the edge cases (where previous day, week or whatever are partially or ambiguously contained in the selected choice) would make it confusing, not clarifying. If the effect does not tell anyone something they can't easily know then it doesn't really serve a purpose.
The emphasis is all wrong - the chart needs to tell just one story - the fact that you have downtime on one or more servers
I would take the following steps:
highlight the fact that there is downtime, not the fact that you have different servers. When you have no downtime, the display should appear bland, not full of colour.
remove colour coding completely ...
I think I would not opt to put data on both sides of the line for any of the variants. At least, not the same kind of data. You could consider putting something like significant changes in the environment on the left side, while the right side has all the events that you're trying to interpret.
(Vertical) direction is dependent on the use case: are you ...
For a timeline to be more than a "sort by date" option, it needs to have another facet to it.
What other useful information will displayed by the timeline other than just the order in which events happened?
For example, if I was making filterable timeline of WWII events, I could use the space between events to give an indication of how far apart they were ...
You could just draw a box on the first chart that signifies what area is highlighted in the second like so:
Alot of games use this to signify which part of the map you are seeing on your screen out of the whole map.
Or if you don't want to impede the viewing of the first chart with the overlay you can have a mini-map type view above the second chart ...
The choice between absolute (13:35) and relative (2 hours ago) is made depending on the type of content you're browsing. Absolute timestamps are used when your user needs to reference something; sites that host photos, documents, messages, tasks and events all need absolute timestamps. You need to know the exact date something was published, it's not ...
Your priority metric should be chronological significance - this depends greatly your context. Is it more important for the user to see the oldest items or newest first. Timelines on social media sites place significance upon what is happening 'now': 'What are my friends doing? Is my sister online? Are we partying tonight?'
Units of work are generally ...
You don't mention which is the aspect of the family tree you are having trouble with. Horizontal trees can use time or be represented as a timeline, the problem is that the data usually increases on each generation, so you end up with something that looks like this:
But it sounds like you might be following only a few branches, not the whole tree, so in ...
What you're describing is a Kanban board. The concept started at Toyota and has been co-opted by the software industry. But the roots in manufacturing makes it a perfect metaphor for a dashboard for manufacturing processes.
It starts with value stream mapping: identifying the activities that add value to your manufacturing process. They get represented as ...
I agree with a previous comment that formatting would make the distinction clear.
08:00 - reads as 8 o'clock (time)
8hrs - reads as 8 hours (duration)
I would, by all means, NOT follow ISO 8601's guidelines because "P3Y6M4DT12H30M5S" is one of the most confusing strings I've ever seen! As UX designers, we HAVE to come up with a better way to present ...
A few additional ideas to address your zooming differentiation question:
Instead of an overlay, you could try a preview window with a much simpler version of the chart.
Here is an interactive
This gives users
their bearings quite effectively without obscuring the chart area
and using ...
You're on the right path. If each colored graph represents server load then blacking out the periods of time when the server has been down is a great way to show that info.
The clutter in your design comes from the vertical lines at the start/end times of outages. It's better to show all of that in a tool-tip when users hovers their cursors over an outage ...
I've a bit of experience designing timelines, here's the end result of one of them that solves your multi event problem you've noted - Industrial-Heritage or Operation Dynomo.
What happens here is that a stacking order is set as and when needed, it recalculated at the different zoom levels to where possible remove the stack if more precise dates are ...
If the items are independent of each other - place newer first. This way the user will see first what is new.
If the items depends on each other and all together form some single content - place older first.
For example, the posts in a forum topic are connected together by one subject - they form one single content that can grow in time. So, place older ...
I think there could be usability issues with your current design.
Dates duplicating clutters the interface. The dates are both on the timeline and within text blocks.
Too narrow text blocks lead to bad readability.
Bad reading pattern could lead to error in data perception:
Uncomfortable "jumping" reading pattern.
The entire graphics is too heavy (line ...