Sample project
Reading history books used to be a problem for me because I could never remember the years. A timeline of events pulled out of a history book gives me a reference line to follow, which turns out to be genuinely useful.
Taking Wikipedia as a starting point, I built a timeline on the Hundred Years' War as a reference project for learning Timeline JS. Some translated names turned out to be awkward, so I worked in English instead. That project turned out to be bigger than I expected and remains a work in progress.
The project data lives in a GitHub repository: data-vis-timeline-100-years-war.
Odds and ends
The Timeline JS JSON can contain an array of eras objects. As the name suggests, an era is useful for describing a span of time, but the only descriptive property an era object carries is its headline. For that reason the events array is the more flexible choice.
Slide objects inside the events array can take a group property. The order in which groups appear depends on the earliest time within each group; when times are equal, the order follows the sequence of slides in the JSON file.
| Element | Use it for | Note |
|---|---|---|
eras | Describing a span of time | Only a headline property is descriptive |
events | Individual slides | More flexible; supports group |
group | Grouping slides | Group order follows the earliest time in the group |
| Slide count | Overall size | Official guidance suggests keeping a timeline under 20 slides |
Official guidance suggests that a timeline should not exceed 20 slides, though that number is easy to go past. When it does grow, keeping the data organized becomes the harder problem.
JSON editing
Writing JSON by hand for a long timeline is tedious. A tool with side-by-side validation makes the work much easier, for example Smart JSON Editor. When the source data already lives in a database, a converter saves a lot of manual work: the Timeline JS Sqlite to JSON converter turns SQLite output into the JSON structure the library expects, and DB Browser for SQLite is useful for inspecting and preparing the data first.
Local debugging
During development it helps to serve the page locally rather than opening the file directly. live-server is a convenient way to do that, refreshing the browser as JSON changes.
The companion piece covers the basics — the v3 rewrite and its incompatibility with older JSON, the spreadsheet wizard, and loading the library from a CDN or from local files.
Related
- Timeline JS The earlier introduction: setup, the spreadsheet wizard, and JSON format basics.
- Blog Archive Technical articles and personal reflections by Frederick D, spanning 2008 to 2021.
Notes on using a timeline library in the browser often reveal more about the developer's workflow than about the tool itself. Building a small reference project from a history book turns out to be an effective way to learn how data is structured, how entries are grouped, and how a finished timeline reads to someone who has never seen the source material. The exercise doubles as a personal study aid, since a visual sequence of events gives memory a spine to hang dates on. Treating the sample as a genuine reference rather than a throwaway demo encourages attention to clarity, ordering, and pacing.
Working with JSON data for timeline entries teaches the value of keeping information in a separate, readable file rather than embedding it in markup. Editing sources by hand makes it obvious which fields matter and which are decorative. It also surfaces questions about consistency: should every entry have the same shape, how should missing dates be handled, and how much descriptive text fits comfortably before a row becomes unreadable. Small decisions like these tend to matter more in practice than the syntax of the library itself, and they are much easier to correct in a plain text file.
Debugging locally is where confidence in a timeline project is actually earned. Serving the page on a development machine, watching the browser console, and checking the network panel turns silent failures into visible ones. A malformed data file, a mismatched selector, or a missing script can each look identical on screen, yet each announces itself distinctly once you inspect what the page is really loading. Getting into the habit of verifying locally before publishing avoids the frustrating pattern of a finished page that simply renders nothing.
Beyond the technical side, building a timeline about a historical subject is a quiet reminder that software can be personal and unhurried. A reference timeline built for your own use has different priorities than a polished product: it values clarity, plain language, and the absence of distraction over decorative effects. The result can sit quietly on a personal site as a working tool rather than a showcase piece, which is often the more rewarding outcome. Small, focused projects like this sharpen judgment about data, structure, and restraint.
Writing about the process afterwards is useful in its own right, because notes age faster than memory. A short follow-up to an earlier introduction can record what turned out to be awkward, which approach simplified the work, and which habits are worth keeping for the next project. Such writing also gives a blog something honest to publish: not a tutorial written for an audience, but a reflection on learning in public. The tone matches a gentle, editorial style, where a modest personal project is described plainly and the emphasis stays on the craft rather than on any claim of novelty.