Extend Timeline Feature for History

[Number042]

Hi,
NovelWriter already brings the nice feature of a timeline, which is currently used to track events of the actual plot and connects those to characters and locations.
An idea I has was to extend that feature.
Let me try to explain what I had in mind. Working on a novel which is based on a plot that has quite some actual history with it. This history links to characters and locations in the actual (current) plot.
IMHO it would be very useful if this history can be sort of browsed interactively while writing on the actual plot.
Maybe the timeline feature can be extended step by step to achieve such a feature in the end. Starting with introducing an Event class that can be linked to characters and locations?

Happy to hear opinions on that.

[vkbo]

Thanks for adding this feature suggestion from our lunch chat last week.

I'm still thinking of how to better add tag navigation, and I will try a few approaches soon. I'm considering making a keyboard shortcut of Ctrl+Enter follow tags. That is, this action will open the document the tag refers to in the view pane. In addition, and since novelWriter already has an index of all the interconnections of tags, a list can appear at the bottom of the view pane, listing all other places the tag is referred to. These too will be clickable links.

Since there already is a note classification (root folder) for adding time-related notes, these can easily be used to create files describing plot events or relevant pre-plot timeline historic events. Making it easy to navigate between these should make it easy to get a quick overview of all the places a key event is referred to, and verify that they are consistent.

[vkbo]

PR #109 adds a panel at the bottom of the view window with links back to all files that refer to it. A generated preview now also shows all the @ keywords as clickable links.

I should probably also add a way to hide the panel at the bottom, as it may grow fairly large for a tag that is used many places.

But test it out anyway, and see if it is useful.

[vkbo]

I've now merged a new Outline feature, and added a description in Issue #70 with instructions on how to use it. Let me know how it works.

[vkbo]

I'm considering adding a new feature for setting a timestamp for the timeline tags. Say, for instance, you have a timeline tag @tag: history which you can reference with @time: history(1977). the additional information in parentheses can then be used to generate a timeline with nodes for all references, and show where they connect.

It's not a feature I need myself for my current projects, so you'd probably have to test how useful it is, but we've discussed this before, and I'm still thinking of ways to implement and visualise an actual timeline.

[johnblommers]

IMHO it's important that the writer be able to track time through the novel to make sure that it doesn't result in plot holes. In my case I'm working on a novel involving time travel. I want to avoid any untoward paradoxes. This is a feature so important that the Aeon Timeline product exists just to interoperate with Scrivener, which itself lacks this feature.

[vkbo]

You can already add and reference multiple timelines. One use case is if you have multiple POV characters that are really the same character on three timelines, past present and future (like Jemisin's first of the Broken Earth trilogy, Reynold's "Chasm City"). Both these cases are disconnected timelines. You then want to be able to tag the same character, but on different timelines, through the story progression.

The timeline tag feature is, however, not suitable for tracking where on those timelines you are. The above case would be tricky if these timelines overlapped. Time travel paradox stories come to mind. What I would like to do is to be able to add timestamps to the timelines, so that they can be aligned in a graphical representation. Each timeline as a horizontal line, aligned vertically by a timestamp.

You can also use this for a single timeline, if you, say, write one of those stories that count days, stardates, or whatever. You'd then want to see this all spread out so that you can make sure everything is consistent and linear.

[johnblommers]

It would be helpful if novelWriters could chime in here and share how they use the timeline feature in their writing.

Follows is how I think the feature is meant to be used. I'm thinking out loud here so bear with me ;-)

The @time tag's target is a note tag in the Timeline folder. Targets are strings and not any kind of date/time value. So we can write @tag: Monday in a document contained in the Timeline folder. Then we'd write @time: Monday in any scene that took place that day. Then we look in the Outline view and can plainly see all scenes that take place on Monday.

But there is no chronological sense to this approach. We can't double-click on the Timeline column in the Outline view and expect novelWriter to order the rest of the columns chronologically. That's not how it works. Nor do we have any sense of how much time has elapsed as the story progresses chronologically from scene to scene.

[vkbo]

The @time tag's target is a note tag in the Timeline folder. Targets are strings and not any kind of date/time value. So we can write @tag: Monday in a document contained in the Timeline folder. Then we'd write @time: Monday in any scene that took place that day. Then we look in the Outline view and can plainly see all scenes that take place on Monday.

As I explain in the previous reply, that is not what the @time tag is intended for. Chronological tags would need a different approach. Being able to add a timestamp in parentheses behind any tag may do the trick because you can anchor any reference to a chronological timeline.

I'd be happy for some direct feedback on that idea, or proposed alternatives.

[vkbo]

There are two main points to figure out:

1. How do we reference a chronological time in each scene? The parenthesis approach I suggested would work, but it strikes me as a bit inelegant. Since there's only a need for a single timestamp for each scene, it makes sense to just add a new keyword for it, like for instance @timestamp. It is also possible to just extend the keyword @time to allow for both usages. It may be sufficient for some to just tag a couple of time periods, and some may need a very fine granularity of time steps. Think the TV-show "24" for instance.
2. We need a way to visualise the information. A third tab makes sense. Exactly how to structure it visually on such a tab is a bit open at the moment. I'm considering drawing text boxes on a canvas. There needs ti ve a clear timeline and text labels with the scene titles. Whether this is organised vertically or horizontally, I don't know. Since scene titles tend to be long, vertically may make more sense.

[johnblommers]

The @timestamp keyword approach makes a lot of sense to me. I think it also makes sense to consider a @duration keyword as well.

When we want Scene 1 to begin at a certain time then @timestamp is appropriate.Suppose the scene runs for a day, so we would use the @duration keyword to say so.

When Scene 2 follows Scene 1 then Scene 2 won't need a @timestamp because we can calculate its start time from the Scene 1 using @timestamp + @duration.

As for visualizing timelines we can look to art by Aeon Timeline. Its website displays some compelling charts depicting scenes, events and time. Or look at Jutoh and its storyboard planning tool.

At a minimum I think that a Timestamp and a Duration column in the Outline view makes sense for visualizing the information.

Now what would the novelist want this kind of information for? In my case I worry about the time span of a story I'm trying to develop. One of my characters appears to be alive hundreds of years after they're first introduced. Oops! How many other temporal errors have I got on my hands?

[vkbo]

These are very good ideas. I think this is heading in a good direction. What do you think @Number042? It was your initial idea.

I'm still thinking of finding a way to combine these features with the @time keyword rather than adding more. I've thought about it since I wrote the other comments yesterday, and the @time keyword is already a bit confusing.

The downside of adding more information to the @time keyword is that it also gets confusing for new users. Especially if the syntax gets complicated. At the same time, if you have a multiple timeline story, you may want to be able to define timestamps for each timeline separately and display them separately as well. How about a syntax like this, where the brackets signify that the settings are optional:

@time: TagName[<separator>timestamp[<separator>duration]]

The TagName can still point to a note in the "Timeline" folder, and the tag will in addition correspond to a timeline in a "Timeline" view if there exist timestamps for it. Both timestamp and duration will thus be optional parameters. I'm uncertain what to use as <separator>. Comma could work as anything that isn't a tag, can be attempted parsed as a timestamp.

The @timestamp + @duration approach, on the other hand has the added benefit of being explicit such that the interpretation of what is a timestamp can be made very flexible. It doesn't have to be a date. It could also be "Monday, Week 1", "Day 5", or something like that.

I'm considering adding a simple GUI dialog to insert references to already defined tags, or some auto-complete feature to assist formatting them and looking up tags you've already defined. Even if the @time tag becomes a bit more complicated, it can be compensated for with making the editor a bit more helpful.

Just throwing more ideas at this. Let me know what you think!

[Number042]

Hi everyone, I would agree that we're heading in the right direction. As mentioned in my last reply, I think that it would be beneficial to keep them separate. Why not using the @time tag to characterise for example the day. A @timestamp could the next be used to specify further of needed. It is also more self explanatory, I guess. And with the @duration we have even more flexibility at hand. I would also vote for the autocomplete feature as this might as well help to cross check whether a tag has already been defined. Just a few more thoughts ... Am 8. April 2021 12:58:53 schrieb Veronica Berglyd Olsen ***@***.***>:

…

These are very good ideas. I think this is heading in a good direction. What do you think @Number042? It was your initial idea. I'm still thinking of finding a way to combine these features with the @time keyword rather than adding more. I've thought about it since I wrote the other comments yesterday, and the @time keyword is already a bit confusing. The downside of adding more information to the @time keyword is that it also gets confusing for new users. Especially if the syntax gets complicated. At the same time, if you have a multiple timeline story, you may want to be able to define timestamps for each timeline separately and display them separately as well. How about a syntax like this, where the brackets signify that the settings are optional: @time: TagName[<separator>timestamp[<separator>duration]] The TagName can still point to a note in the "Timeline" folder, and the tag will in addition correspond to a timeline in a "Timeline" view if there exist timestamps for it. Both timestamp and duration will thus be optional parameters. I'm uncertain what to use as <separator>. Comma could work as anything that isn't a tag, can be attempted parsed as a timestamp. The @timestamp + @duration approach, on the other hand has the added benefit of being explicit such that the interpretation of what is a timestamp can be made very flexible. It doesn't have to be a date. It could also be "Monday, Week 1", "Day 5", or something like that. I'm considering adding a simple GUI dialog to insert references to already defined tags, or some auto-complete feature to assist formatting them and looking up tags you've already defined. Even if the @time tag becomes a bit more complicated, it can be compensated for with making the editor a bit more helpful. Just throwing more ideas at this. Let me know what you think! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[vkbo]

The syntax highlighter will put a green wiggly line under any duplicate tag or a reference to an undefined tag, but auto-complete (or suggestions rather) will definitely help if you don't remember the tags you've defined.

In any case, if we add @timestamp and @duration, the @time keyword must remain unchanged as it will otherwise break people's projects. But for clarity, I could possibly add @timeline as the default keyword and just keep @time as an alias for backward compatibility.

I should have thought a bit further ahead when I came up with the keywords and picked something less ambiguous.

Edit: Also, your previous comment did not arrive in the thread. I don't use the email reply feature, but it looks like it may have gotten lost on the way?

[Number042]

Hi,

Indeed, my reply from yesterday got lost somewhere on it's way. Here is what I wrote:

As a general comment on the timeline feature: my first idea for it's use was to have a sort of overview feature on how the plots rolls out while working on the novel by (for instance) creating new scenes. It was supposed to provide a convenient overview on the whole timeline/evolution of the plot. At that point it wasn't clear to me ifi t would be possible at all.

Regarding the two points below:

1. Why not having a second type of tag, as suggested with @timestamp. This way, we could keep both types separated and avoid confusion that might pop up with the usage of two types of inputs for the same keyword.
2. A vertical layout indeed might make most sense, at least for a first trial of the feature. Horizontally would only work well if it could be sort of foldable or clickable with single points representing @time tags.

Let me add just another short thought: the @timestamp it should be able to accept strings and classic timestamps, if possible. For example my novel deals with a timeline according to the old Japanese clock with names for each hour.

[vkbo]

Let me add just another short thought: the @timestamp it should be able to accept strings and classic timestamps, if possible. For example my novel deals with a timeline according to the old Japanese clock with names for each hour.

Yes, that's the plan. Although it would be near impossible to accept all representations of time in a sortable manner. The natural options are to support alphabetical ordering, numerical ordering and a date format that Python's datetime package can understand. The latter can be extended by allowing the user to define a custom format since datetime can take this as an input. A simple validator can return some feedback to the user whether it understood the entry or not, perhaps again via the green wiggly line that's used for the other keywords.

As for duration, it should understand phrases like "1 hour", "1 day", etc. PHP has a nifty and very flexible time diff feature that understands semantic time durations, but I haven't seen anything similar for Python. The challenge is to also support projects in different languages, but the project_xx.json files in the i18n folder can probably be extended to support those.