Grouping Items into Hierarchies
What Are Hierarchical Groups?
Aeon Timeline allows you to organise items into hierarchical groups or structures. These groups can be used in a number of ways, depending on your industry and data, such as:
- Events nested within larger parent events, such as a particular battle nested within a war.
- Locations nested within other locations, such as cities within countries.
- Project management tasks broken down into smaller units (e.g. tasks broken into sub-tasks, or in an Agile environment, Epics, Stories and Tasks).
- Dividing characters in a novel into different groups, such as Protagonists and Antagonist.
When referring to items within the structure, we refer to parent and child items: where Item A contains a number of sub-items grouped within it, those sub-items are child items of Item A; equally, Item A is the parent item of those sub-items. As this hierarchy can extend across many levels, it is possible for an item to be both the child of one item and the parent of another at the same time.
Grouping events within these parent/child structures provides several benefits:
- The structure can be expanded and collapsed within several views including Entity Lists and Timeline, Spreadsheet, and Relationship Views, allowing you to limit or increase the amount of detail visible on the screen as required;
- Item dates will be extended to include the date range of their children;
- Item properties can be configured to be calculated from their children: for instance, a country’s population could be calculated as the sum of the child state’s populations; or the percentage complete of a task could be calculated from the percentage complete of the child tasks
Not all item types can be grouped under all other item types. Your chosen template will define which groupings are logical and allowed (e.g. you cannot group a Location under an Event), but this can be changed in Advanced Settings.
Each item can only be grouped under a single Parent item. You can use Relationships instead to model more complex relationships, such as assigning a Task to multiple Projects.
Note: The parent/child terminology should not be confused with actual parent/child (i.e. father/mother and daughter/son) relationships between two people. Aeon Timeline can also represent those as Relationships, but they are not created using the same hierarchical structure.
How to group items
There are several other methods to group an item underneath a parent:
- With one or more items selected, you can select the item’s Parent from the dropdown list in the Inspector.
- In Spreadsheet View, Relationship View, and Entity Lists, drag an item and hover over the parent you wish to drop it on. When the entire parent is highlighted, the item will be added as a child under that group. You can drag an item out of a parent as well to remove its parent association.
- In Timeline View, hold down the command (Mac) or control (Windows) key while dragging items to move them in and out of parent items;
- To group one or more items under a brand new parent item, select the items and then choose Embed in New Parent under the Item menu.
Subway, Mindmap and Narrative views do not directly represent parent/child hierarchies.
Date Ranges for Parent Items
In general, items within Aeon Timeline have a start date, duration, and end date.
This is also true for parent items: they can be given specific start and end dates, which remain independent of any dates given to their child items. This allows longer events such as “World War 2” to track their own start and end dates (e.g. 1939 - 1945); child items grouped under “World War 2” will then have their own start and end dates (e.g. July - October 1940), but the parent item does not need to have child items that span the entire duration of the child.
This works well in most situations, as the range of child events will usually be contained within the parent event (the usual case).
However, in some circumstances, you may create a child with dates that fall outside the range of the parent event. When this occurs, the dates set for the parent will be interpreted as preferred dates, but will be extended to include the range of the child dates for purposes such as calculating dependencies.
This will usually represent an error or intermediate state that will need to be resolved in the future (e.g. by moving the child back within the range of the parent, or by extending the parent’s dates to accommodate the child), so when this occurs, the discrepancy will be highlighted to you in a number of ways:
Timeline View
In the Timeline View, child dates exceeding the parents’ dates will be indicated with error bars attached to the parent item:
Inspector
In the Inspector, an additional field will show the calculated date range (the maximum range of the parent and child dates):
Spreadsheet View
In Spreadsheet View, any date that is exceeded by child dates will be highlighted in red. The user can also choose to turn on an optional column to show the child range:
Note: The way parent and child date ranges are handled is a departure from version 2, where parent events dates were always calculated solely from the dates of their children, and placeholder child events could be used to be added to mark the start or end of a parent event if required).
Moving Parent and Child Dates
By default, when you change the date of a parent item, all of that item’s children will be adjusted by the same amount, keeping them within the same relative offset from each other. This makes it easy to move around groups of events (e.g. delay the start of a task, which should therefore delay any sub-tasks contained within the task), but may not be preferable in all cases.
To prevent a child from moving with its parent, you have two options:
- If it is a small number of child items you want to remain fixed, you can lock that child using the Inspector so that its dates cannot be changed;
- You can change the default behaviour in Timeline Settings;
Note that some templates (such as Historical templates) reverse the default behaviour so that children do not move with parents. This is because in these fields, where exact dates are known or have been entered, you are unlikely to want any dates to be automatically adjusted.