Aeon Timeline: Displaying Story-Arcs

[Don’t forget, a new version of Aeon Timeline has just been released. See the post below, and get it from the Latest Version page].

This is a rather long post (there are some pictures, at least). I say this as a warning for people who just want to check out the application, and the general direction it is taking. If you fit this category, the bullet points below list what we are trying to achieve. You probably want to read no further.

Goals of the Story-Arc View

  • Create a view that does not have the Entity lines – this allows a lot more space and freedom.
  • Events will be displayed at their exact location on the timeline, rather than pushed around to create sufficient space between each event. Combined with filtering by Entity, this will make it much easier to check that someone isn’t in two places at once, for instance. 
  • Divide events into separate story-arcs/timelines that split and merge throughout the timeline as groups of people are separated and reunited.
  • Express the temporal and causal links between events.
  • Provide an intuitive and interactive means to manipulate the additional information made available by this new view.

In the remainder of this post, I discuss the difficult task of displaying this additional information. Continue reading (click on the more link), if you want to see my current thoughts and sketches, and provide feedback and further ideas/suggestions. Feedback at this design stage is crucial, as it will become increasingly difficult to make large changes as we move towards implementation.

The ideal timeline: some notes and constraints

An ideal timeline would capture the maximum amount of data in the minimum space required (computer people call this entropy). Although this is an incomplete list, some of the constraints and properties we would want it to meet include:

  1. Events must be displayed at their correct temporal location in the timeline.
  2. Events with a duration must have that duration visible and accurate in the timeline.
  3. The division of events between story-arcs should be easily visible and understood.
  4. The relationship between the different story-arc threads should be clear at all times: at times they will split and merge, there may be events shared between different story-arcs, etc.
  5. It should be easy to work on small sections of the timeline at once, without getting swamped with details from all the other events, entities, and story-arcs.
  6. The causal chains between events should be displayed (eg. Joe was out late, which caused him to sleep in, and therefore arrive late for work the day the building was destroyed by fire).


Constraint 1 and 2: Handling collisions between events

In Aeon’s (existing) Entity View, this first constraint was intentionally broken: although we had a line marking the event’s correct location on the timeline, to avoid collisions between events, we intentionally shifted events up or down (parallel to the timeline) to avoid collisions between events.

Most timeline applications shift events perpendicular to the timeline instead (this option was not available for the existing Entity View, because it would encroach on the character space). This is why horizontal timelines are more common – it is visually better to shift events by the short height of a line of text, rather than the longer and variable width. The typical result looks something like this:

Standard Timeline

Figure 1: Standard Timeline

So that events can be displayed in their correct position on the timeline, our story-arc view must use this method to avoid collisions. An example of Constraint 2, an event with a duration, is included in this image.

Constraint 3: Dividing Events into story-arcs

If we were to consider the events included in the above timeline, the events can easily be divided into several story-arcs:

  • There is the story-arc shared by “boy and girl”, when they first meet, and when meet up again.
  • There is the story-arc that follows the boy during the war.
  • There is the story-arc that follows the girl during the war.
  • There is a set of external events (eg. the war itself) which are not part of any particular story-arc.

If we drew the timeline in more detail, there could no doubt be additional arcs and sub-arcs. If we were to draw an overview of how these story-arcs would be structured, we would see a diagram something like this (the story-arcs are labelled, but we cannot see the events that make up the story arcs):

Story Arc Overview

Figure 2: Story-Arc Overview

Constraints 1-3: combined

Aeon Timeline’s story-arc view will need to combine both of these properties, which means that the perpendicular dimension will have two separate uses: it will be used to prevent collisions between events, and it will also be used to separate the events belonging to each story-arc. This is acceptable, so long as the collision stack does not get too deep (we have some control over this, through the flexible zoom already used in Aeon’s Entity View, and by truncating event titles, if necessary).

Aa very rough sketch is shown below. Here, the vertical lines are just a visual aid to help with alignment, and would be placed at sensible date boundaries. The horizontal lines are another visual aid, dividing the events from each of the story-arcs. Note that only those events shown in the original timeline are included in this one, and so the additional sub-arc is missing.

Structured Story-Arc Timeline

Figure 3: Structured Story-Arc View

We have already lost some of the information in Figure 2. Although the events are clearly divided into the three separate story-arcs, it is not clear how those story-arcs relate to each other, or where the original story-arc divides into the two other story-arcs.

It would be possible to annotate the timeline with some of the detail, using something like Figure 4 below. If this is structured well, the gray horizontal lines dividing the story-arcs may be unnecessary.

Annotated Story-Arc View

Figure 4: Annotated Story-Arc View


Constraint 4: Detail within Context

The sketch in Figure 4 looks like a reasonable start, but as the timeline increases in complexity and volume, several important properties of the timeline are likely to change:

  1. The overall structure of the story-arcs will become more detailed, as more sub-arcs and sub-sub-arcs will be added into the timeline structure, thus increasing the amount of annotation required.
  2. The interaction of story-arcs will become more complex: A might break into B and C, and C might in turn break into D and E. E might then merge back into B, leaving B and D as the active sub-arcs. As these chains become more complex, it may not be possible for all splitting and merging chains to be adjacent to one another. 
  3. As more events are added, the timeline will need to zoom in and stretch horizontally to accommodate them, resulting in more scrolling, and much longer chains of events without annotation.

Edward Tufte (described by the New York Times as the “Da Vinci of Data”) has listed his thoughts on why Project Management GANNT Charts do not work, and provides his own sketch of how such charts should look. One of his concerns is Detail within Context, and it is this property that breaks down as we extend our Figure 4 sketch to a real-life example.

Viewing the timeline will be like looking at a wall chart through a straw. There are two possibilities to overcome this. One is to implement a physical zoom, that shrinks the text until it is so small that it looks like a fuzzy line from Figure 2. The other is to do what Tufte suggests, and what already exists in Aeon’s Character View: add a context view separate to the main view. 

The most likely implementation for the context view would be a floating panel, which can be moved around the window or hidden completely as required. Figure 5 shows an example. The light-blue highlight would show the area currently visible in the main scroll area.

Annotated Story-Arc with Context View

Figure 5: Annotated Story-Arc View with floating Context View


Constraint 5: Avoiding Information Overload

As you develop your timeline, there are probably times you want to focus on events for one particular story-arc, or one particular character. This is the same reason Hot Tags and filtering were added to Aeon’s Entity View. Similarly, in implementing the story-arc view, there must be some function to limit the events being displayed to just a few of the story-arcs so you can work on your separate threads in peace.

Importantly, you will still be able to filter events by entity, even though the entity axis has been removed. As events will be displayed in their exact location (rather than bumped parallel to the timeline to create sufficient space between event lines), you will be ensure that you do not require a character in two places at once.

Feedback Stage: That’s It, For Now

You will notice I didn’t address the last ideal, showing causal links between individual events. I have omitted it, at this point, because I am unsure how to display the additional information without making the timeline look like a spaghetti bowl of interconnecting lines. It may be that we have already reached the natural entropy of a two-dimensional sheet of paper, and these causal links may need to be omitted.

I would appreciate comments on what I have said above, whether they are suggestions for major paradigm shifts, minor adjustments, or just an agreement with what I have proposed.

Obviously, there are a lot of details still to thresh out, including:

  • An intuitive user interface design, and ensuring the user is not burdened with supplying unnecessary information.
  • Temporally linked events, and how these get displayed in both views.

I will probably post on these issues further down the track, but I welcome suggestions for these ideas at the same time. To provide feedback, comment on the topic below, send your comments from the ‘Provide Feedback’ page, or (preferably) participate in this thread on the Scrivener forums.

8 thoughts on “Aeon Timeline: Displaying Story-Arcs

  1. Hi I’ve just downloaded the beta and I’m intrigued with the idea of timeline a few quick thoughts on my super quick playing with it —
    1) Export to something, besides an image: how do I export the notes?
    It seems like a timeline should export like an outline.
    2) I think the main purpose of looking at a story/idea like this is to see relationships and spark an idea by looking at it this way —
    3) I would like to look at stories in a page number or an act structure — it might be helpful to have this instead of only dates and days.
    4) Story-arch you should actually use a spline curve to help the author visualize.

    • Hi Casey,
      Thanks for the feedback. To address your points below:
      1) Yes, exporting is the next thing that I will be working on, once the Story Arc View is completed. I expect this will begin in the next few weeks. If you get the chance, take a look at this thread that I started over in the forum: It is about integrating with Scrivener, but the same will apply to several other Mac writing programs, as well as a generic export for standard word processors.

      3) I hadn’t thought of skipping dates and having pages and acts instead. When I implement the “fantasy calendar” option, I will look to see if I can make it so that things can be setup this way as well.

      4) I’m not quite sure what you mean by this. Could you possibly elaborate on it a little further?

  2. Also look at some editing programs like final cut; after effects,etc. It seems like you’re trying to get all information at once. The user should choose what info, based on a scroll, or a second window, or pannel. Take the example of Final Cut — I can look at my time line down to the frame through a zoom — sometimes this view is helpful, but not always, sometimes I zoom out and look at the overall view. If I want to see a particular frame, or sequence, I double click and it opens in another window.
    It seems like this approach would be a unique way of looking at writing — approach it like a video/film editing program.

    • I quite like this suggestion, but I think for it to work you need to have event groups, or sub-events, etc. I haven’t used any of those editing programs, because I have no talent in that area, but looking over the multimedia guy’s shoulder, what I gather about them is that everything belongs in a heirarchical structure.

      That is something that could be applied to Aeon, and Event groups etc. is something I have on my list of possibilities, but it is down the chain a bit behind the Story Arc View and better Exporting. Once I have done those, I will have another think about your suggestion.

      I guess the idea that makes the most sense is that some events could themselves have a nested timeline of events within them – you could double click on the event to be taken to the timeline within that instead (replacing the view with the nested view), and then there would be some way to back out again to see the overall picture.

      This is something I will give a lot more thought to, further down the development track. At some point I will probably start a discussion on the forum to canvass ideas and refine the model further.

  3. There is also a “nodal” model that can work as well — look at a program like Adobe Encore… if you look at the “Flowchart” window, you have nodes that represent the info — if I click on a node, the info contained in that node will show up in an adjacent window, below those two windows is a timeline that I can scroll through. The scroll bar represents a single moment in time within that node.
    On the other hand to show multiple timelines, you can use something like After Effects — and have layers of time. Still a layer can be a “charecter” or Place, or whatever. As I move the scroll bar (representing one moment in time) I can see the relationships between the various layers. These layers can slide forward (in time) or backward (in time) — but never occupy the same layer in time — a layer exists in it’s own space — like lives of charecters, or spaces, etc. So in this way, a tool like this for writing — a way to SEE MY STORY VISUALLY in time is VERY HELPFUL. The key is that the notes of detail held within a timeline is what can get exported to whatever program. Also the whole thing can get exported in a kind of traditional outline form.
    I think the trick with timelines is that they only HOLD all the info, but The user decides what he needs to see at any given time. I doubt that any given author would want to see EVERYTHING all at once and if he did — you just export that and read through it. Personally, I think that seeing everything all at once is NOT very helpful. Overviews are good, but if I need more detail, something like double clicking on an event can provide this in a separate tab or window. I think that timelines are useful to a writer (or animator) in that it is a guide to knowing where/when things happen. It also is useful for developing structure of stories. This last part is what interests me the most — a good tool for developing structure and seeing relationships between events, characters, places, etc.

    As far as the spline thing goes, I guess I’m thinking about the program “power structure” in that it allows me to assign elements of rising tension — and being a graphic designer I think of that as a spline curve. or even a bezier curve with handles at the tangents to adjust the “tension” of the curve — it would be cool if there was a way to visually map out my stories with that sort of thing — to use as a sort of “signpost” or “goal” to reach in the writing stage — again thinking of this as a tool for writing. I was looking at your images you included in your blog and started thinking about those lines that are straight and split off to show other timelines. Mostly it was just a quick thought.

    Thanks for allowing me to pontificate — I’m glad you read these, and I glad you’re interested in developing a helpful tool. Thanks for that!

  4. I wonder if, using something like the OpenCL aspects of Snow Leopard, it would be possible to bring the third dimension into the timeline to represent both “rising tension” and individual story arcs.

    Using the story in the figures above, imagine if the split story arc of “boy during the war” and “girl during the war” had different depths on the screen (so instead of splitting up and down from the perspective of the computer user, they get split left and right from the perspective of the split point — “war begins.” The user could “zoom in” on just the boy’s story or just the girl’s story, but the user could also zoom back out to see them both at the same time.

    Also, each point in the story arc would be positioned “higher” or “lower” than the preceding point based on the tension.

    Now, as for knowing which point belongs to what arc, maybe you could use some sort of shading technique.

    Each individual story arc gets its own shade, but the shade isn’t a solid color as much as it is a kind of “light mist” surrounding each point in the arc, so that when you’re looking at on the screen, it looks like a rising or falling trail of floating colored breadcrumbs.

    Perhaps a way to visualize this is like Apple’s Time Machine visualization, except where Time Machine has you facing “downstream” the view in Aeon Timeline would have you looking at it from the side (maybe you could even give the user control of the “camera”?).

    I don’t know. But with OpenCL supposedly being such an easy thing to use now (I’m not a programmer, so I only have Apple’s PR claims to base this one), I’m wondering how you might be use to totally change the way we imagine timelines.

Leave a Reply

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

You are commenting using your 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