Version 1.1: How long is that…?

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.

Project Planning

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.

12 thoughts on “Version 1.1: How long is that…?

  1. I just want to say how much I appreciate your work and how invaluable to me this tool has become. I haven’t yet used it with Scrivener very much–which is strange because I thought that I would–but I now use it before starting almost any story at all. Because I write historical fiction, it is essential for me to have everything right, and you have saved me from making many embarrassing mathematic mistakes.

  2. I have been following this product, which I found out about on a Scrivener link, with envy because I am a Windows person. To see you have a Windows edition in the offing is awesome for me. I will use it with Scrivener, but more so with my family genealogy timeline. I can hardly wait. [Actually, until I read this update, I was making plans to get a Mac for this application alone. Now I will be able to stick with Windows.]

  3. I look upon your product as an important tool but I have a basic problem. I do not understand the term “arc”. Yes I know what is commonly referred to as an arc but not in the sense of a time line. A person is born at a specific time and date and dies at a specific time and date these events are connected by a straight line not an arc. The vicissitudes of each of our lives are changeable so you can say that the two events are not connected by a straight line but an ever changing line but at the same time not really an arc. Is it possible that you can explain your point of view?

  4. Just discovered this program yesterday and already has paid for the registration fee! It is exactly the tool I was looking for as I had almost come to the conclusion I would have to do this by hand in Adobe Illustrator or the like. So glad I am not going to have to do that now! I am very excited about the visual duration bar of a event (as shown above) as I am project manager, in addition to a writer, and could use this at work too. Very much looking forward to the new release!

  5. I really like the approach to the software, especially the visualization of interactions between entities and events and the story arc concept. And the integration with Scrivener is a fantastic advantage. But for dealing with real historical data it is imperative to have the ability to adjust precision. It’s difficult to accept having to add lots of “Jan Firsts” (01-01) to events for which I only know the year, for example. It doesn’t make sense to apply full precision to all the events in a timeline – people dealing with actual data need to be able to set precision event-by-event.

    So for example, say I know an event occurred in 1634. I want my data entry to be only “1634”, or 00-00-1634. But for the calculations of times elapsed between dates, as long as you provide me with the rules you applied for making the calculation or drawing the display, I can make adjustments downstream accordingly. Or there could be an option which allows the user to choose how the imprecise date is handled (like use the first day of month, the 15th day, the last day, etc.)

    I really hope you will be able to address this issue, because otherwise it is a fine tool.

    • Thanks for the comments.

      I have made it possible to create timelines with just year information, or just month information.

      Is this sufficient for your workflow, or do you need variable precision – eg. to just specify a year for some events, but be able to specify exact dates for others?

      Regards,
      Matt

      • Yes, the ideal solution would be to mix events on the same timeline. For example, if I’m working on a corporate history I may have the *year* for the foundation of the corporation, the *month-year* for the arrival of a particular employee, and the *day-month-year hour:mins* for an industrial accident all on one timeline …

  6. re: duration control

    I think you’re trying to be too flexible. I think it would be sufficient to have a given event have either explicit start and end points or a start point and a duration, but you don’t need to mix them in an individual event. Immediately some of your inclusive/exclusive issues go away. You wouldn’t need to calculate the exact end date with a duration control, unless it was desired to be shown in some manner, in which case I think my next thought would help…

    Allow the user to do whatever they want with respect to inclusive vs. exclusive, but provide a reasonable default. I would have 3 settings globally for the default, which could be overridden on an individual event as-needed: always inclusive, always exclusive, unit-of-measure (UOM) dependent. The last one is the trickiest, but as long as the rules are known, I think it’s OK. I would think that the rules would be fairly static, but surely someone, somewhere would want to be able to edit the rules, so you may as well make them a preference, too.

    The rules themselves would probably be pretty straight-forward individually. Some examples:

    UOM: Months
    Start: first of the month
    Rule: exclusive
    Example (YYYY-MM-DD): 2012-06-01, 3 months == 2012-06-01 thru 2012-08-31

    Start: last of the month
    Rule: exclusive (adjustable)
    Example (YYYY-MM-DD): 2012-02-29, 3 months == 2012-02-29 thru 2012-05-31

    Start: any day but the first/last of the month
    Rule: inclusive
    Example (YYYY-MM-DD): 2012-06-15, 3 months == 2012-06-15 thru 2012-09-15

    Cover even just 90% of the cases and it’s good enough, because the options will exist to either switch the inclusive flag to exclusive (and vice-versa) and also the option will exist for the user to be explicit about their intentions using specific start and end points as they do now.

    I’m not sure what language this is written in — Objective-C, I guess? I’m new to Mac, so I don’t know the language at all, and whether or not it has available libraries that allow human-language date manipulation; if it does, you can use that and hopefully it will solve all of your concerns. If it doesn’t, you’ll have to write it, of course, and then I would suggest looking at something like Perl’s Date::Manip module, which has been around since 1995. The significance of that is that they’ve thought about this a LOT over the years, and probably have a decent set of rules that you can at least use as a starting base. See http://search.cpan.org/~sbeck/Date-Manip-6.34/lib/Date/Manip/Calc.pod for more info.

    If I can help at all, let me know.

  7. I’m coming back here after a very long absence. A few observations:
    1. To eliminate the stupid ambiguity between “American-style” (MM/DD/YY) and the more logical DD/MM/YY format, why not offer the ISO format YYYY-MM-DD as an option? This allows sorting in the correct chronological order, too.

    2. It seems to me the duration ambiguity could be solved by using the word “through” instead of “to”. A 3-month event goes “from January through March”. This is common enough here in the U.S., anyway.

    3. Is it true that “Foster’s” is Australian for “beer”?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s