As I have mentioned briefly, I am currently working on Aeon Timeline version 1.1 for Mac, which will bring Aeon Timeline up to the level I want it to reach before I write a feature-parity version for Windows. Version 1.1 will be out before the end of the year, with a Windows version to hopefully follow some time next year.
Aeon Timeline is intended to aid creativity and data analysis, and to achieve this aim, it is important that users spend their time thinking about their content rather than the application they use to create it. This means Aeon Timeline needs a clean, easy, intuitive user interface.
There are many decisions made in designing a user interface that take a long time to get right, but when done correctly, go completely unnoticed by the end user.
It seems a shame to say it given the amount of time I have spent thinking about the problem I discuss below, but I hope this is destined to become one of those decisions. If the final decision goes unnoticed, it means the interface has done its job and got out of the way. What most users notice are the design decisions that have gone wrong.
Below is a sneak peek of a couple of new features coming to Aeon Timeline version 1.1.
This particular problem is subtle, but also difficult. I don’t yet have a complete answer to the problem, but the shape of one is forming in my mind.
Time will tell if I make the right decision. Suggestions, as always, are welcome.
Version 1.0: Room for improvement
One of the new features I am adding for version 1.1 is the ability to explicitly set event durations as an alternative to an explicit end date. For users of the existing version 1.0.x, the reasons may be fairly apparent.
In the old version, the Inspector allowed you to set a start and end date only. Internally, this was stored as a duration in minutes, which meant you could shift the start date and the end date would follow. Of course, this was a problem if you wanted something to last for a month. You specified a start date of 01/01/2005 00:00:00 (I am Australian, so that’s dd/mm/yyyy) and an end date of 01/02/2005 00:00:00 (that’s February).
But then, if you decided to shift the event one month later, it would adjust the end date accordingly.
This preserves the 31 day duration – but may not be what you want if you wanted it to remain as a clean 1 month duration instead.
Version 1.1: Duration Control
With the added duration controls in Version 1.1, this is addressed. You can now specify a start date and either end date or duration. As the GUI indicates, these last two fields are tied together, so changing one will change the other.
We can now specify a duration of 2 hours, or 2 days, or 2 months, and wherever we shift the start date, that neat duration will remain. Easy, right?
Actually, no, not really. Take a look at the dates and times shown in that last screenshot. It is perfectly accurate. If we switch the duration to 2 days instead of 2 months, we get something like this:
So far, so good. It’s hard to argue with basic maths (Australian… we add the ‘s’ to math).
But lots of users don’t like having to specify or even see times when they just don’t care, so we include the option to turn the time off. Keeping all of the dates the same, this now looks like this:
And based on a straw poll of a few family and friends, I expect about half of you will now think there is an error.
If an event starts on Monday and lasts for two days, that means it covers Monday and Tuesday, right? But the end date says Wednesday – is that really three days instead? Even though the dates are exactly the same, without the time putting the dates in context, the line begins to blur.
Welcome to the opening of the rabbit hole.
Inclusive or Exclusive?
It all depends whether you consider the end point to be inclusive or not. There is a lot of ambiguity in the way we talk about dates and times. The mathematically correct answer does not always match up with this:
- If something begins at 3pm, and lasts for 3 hours, we say it runs from 3pm-6pm.
- But if something begins on the 3rd of the month, and lasts for three days, we say it is the 3rd-5th.
- For shorter durations, months work the same as days: we might say that an event beginning in January and lasting for three months is January to March.
- But as the duration gets longer, the intuitive answer seems more ambiguous. Does a 12 month event starting in August 2011 run to August 2012, or July 2012? If we polled more people, I expect this would go close to an even split.
- Likewise, does an event starting in 1960 and running for 30 years end in 1990, or 1989?
There are many more examples you could find, each with their own subtle differences. I expect there are many border cases without clear agreement.
Although this ambiguity may seem trivial to some users and some projects, in other cases it can be quite important.
Although Aeon Timeline was initially conceived for writers, it can be used for much more. I use Aeon Timeline for a lot of my project planning, both for Aeon Timeline, and in my day job. I don’t usually plan down to the level of specific dates and times, so I configure the timeline to display only Month and Year in the event label.
Consequently, an event configured like this in the Inspector (the dates are chosen randomly for the example):
Gets displayed like this in the timeline itself:
The duration is longer than I can easily judge at a glance, so I tend to rely on the labels a little more. And here, when I read that a task is June-November, that seems to imply development continues throughout November. Visually, I can line it up and see where it ends against the timeline at the top, but that required extra thinking to avoid making an error.
Making the Timeline and Inspector Match
So in this case, I want the event label to say June 2012 – October 2012. But what about the dates in the Inspector with its tidy duration control?
If the timeline says June to October, do I want the Inspector to show:
- 01/06/2012 to 01/11/2012, giving us that nice, clean, mathematically accurate 5 month duration, but seemingly contradicting the display on the timeline; or
- 01/06/2012 to 31/10/2012, which matches the timeline event label, but makes the 5 month duration seem untidy.
Of course, I can fudge the end date a little if someone sets a 5 month duration, and automatically make the end date to 31/10. But if 01/06 to 31/10 is considered a 5 month duration, what if the user goes the other way, and enters a specific end date instead of a duration. When the user types in 01/06 to 01/11, shouldn’t this be interpreted as “5 months + 1 day”, and thus be represented as “154 days” instead?
Version 1.1: Month-only Calendars
To give away one more upcoming feature of version 1.1, the available calendars are being expanded to include many more representations of dates and times.
One example is a month-only calendar, which removes the date and time component altogether. This has been a common request, particularly for history projects spanning centuries, where the exact date of the spread of plague tend to be either unknown or irrelevant.
Using this calendar, the inspector for the event discussed above would be shown like this instead:
The same ambiguity is now magnified by the lack of precision, in much the same way removing the time component did in the first example.
As I said at the beginning, I have some ideas for how I might address this, but no clear solutions yet that will solve every case. But I will keep thinking about it and drawing out sketches and running straw polls until I find an answer.
Hopefully, when the first beta rolls out, no one will notice it happened.