[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:
- Events must be displayed at their correct temporal location in the timeline.
- Events with a duration must have that duration visible and accurate in the timeline.
- The division of events between story-arcs should be easily visible and understood.
- 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.
- 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.
- 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:
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):
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.
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.
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:
- 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.
- 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.
- 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.
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.