Site Navigation — Beyond the Menu

Thu, 04 Jun 2026 00:00:00 +0000

A menu works when the content is shallow and the audience knows what they want. It breaks down when the content grows into something more like a knowledge base — when you have 80 notes across 12 sections and the useful thing is not finding a specific page but discovering that two ideas are connected.

There are a few distinct problems here and they need different tools.

Retrieval vs exploration

Retrieval is when you know what you want: “where did I write about Terragrunt?” A search box solves this. Fuzzy matching, title weighting, done.

Exploration is when you do not know what you want, or want to rediscover something you wrote a while ago. A menu does not help. Search does not help — you cannot search for something you have forgotten exists.

The menu is for retrieval by navigation. Search is for retrieval by keyword. Neither is for exploration.

What does not work

Most recently used / most popular — this feels like someone keeps moving your things. The notes that surface are the ones you or others have looked at lately, not the ones that are useful to you now. Navigation should not have memory that works against you.

Alphabetical listing — fine as a fallback, not useful as a primary navigation mode. Proximity means nothing.

Two experiments

Mindmap

Every note as a node. Edges connect notes that share tags or belong to the same section. Lay it out with a force-directed simulation and you get a visual map of the knowledge base — clusters emerge naturally, isolated notes stand out, and you can trace paths between related ideas.

The interesting property: clicking on one note shows which other notes it is connected to. This is not search — you are not looking for something specific, you are seeing the neighbourhood of an idea.

Try it →

Word cloud

Sections and tags, sized by how many notes carry them. The big words are the areas where there is the most material. Click a word and it feeds directly into the search.

This is an overview of the shape of the knowledge base. Good for answering “what is actually in here?” in a few seconds.

Try it →

The shared data model

Both visualisations run off the same JSON index that powers search — a build-time output from Hugo listing every note with its title, URL, section, tags, and summary. One data source, three interfaces.

The technical implementation is in Notes: Site Navigation.

What is still missing

Tags are sparse — most notes do not have them, so the mindmap edges are mostly section-based rather than cross-section. Adding tags to notes as they are written would make the mindmap significantly more interesting over time.

The word cloud currently surfaces sections more than tags for the same reason. As tags accumulate, it will shift toward showing the actual concepts rather than just the categories.

Both are experiments. The interesting question is whether they change how notes get written — if knowing that a note will appear in a connected graph encourages tagging, or whether tagging feels like overhead.

Elasticsearch & Kibana

Mon, 01 Jan 2024 00:00:00 +0000

Elasticsearch is a distributed search and analytics engine built on Apache Lucene. Kibana is its web UI for querying, visualising, and exploring the data stored in Elasticsearch. Together they form the search and analysis layer of the ELK stack — typically with Logstash or Beats collecting and shipping data into Elasticsearch, and Kibana on top for humans to interact with it.

Elasticsearch

A document store where every document is JSON and every field is indexed by default. Queries are also JSON, using a rich query DSL that supports full-text search, structured filters, aggregations, and geospatial queries. Elasticsearch is horizontally scalable — an index is split into shards, shards are distributed across nodes, and replicas provide redundancy. Adding nodes increases both capacity and query throughput.

# Index a document
POST /logs/_doc
{
 "timestamp": "2026-06-04T12:00:00Z",
 "level": "error",
 "service": "api",
 "message": "connection refused"
}

# Search with filter
GET /logs/_search
{
 "query": {
 "bool": {
 "filter": [
 { "term": { "level": "error" } },
 { "term": { "service": "api" } }
 ]
 }
 }
}

At scale, index lifecycle management (ILM) policies handle the hot-warm-cold tiering automatically — recent indices stay on fast nodes, older indices roll to cheaper storage, and expired indices are deleted.

Kibana

The interface to Elasticsearch. Kibana’s core is Discover — a time-series log explorer with free-text search and field filtering — and Dashboards — composable visualisations (time series, bar charts, pie charts, data tables, maps) that query Elasticsearch directly. For log aggregation and observability use cases, a typical workflow is: ship logs into Elasticsearch via Filebeat or Logstash, explore them in Discover, build dashboards for the signals that matter, set up alerting rules on those patterns.

Kibana also hosts the Elastic APM UI (application performance monitoring), the SIEM app (security event correlation), and the Lens visual editor for building dashboards without writing aggregation queries by hand.

ELK vs the Grafana stack

The Grafana stack (Loki + Prometheus + Grafana) has become the common alternative for cloud-native environments. The key difference: Loki indexes only log metadata (labels), not the full log content — it is cheaper to run and query at scale, but full-text search across log bodies is slower. Elasticsearch indexes everything and full-text search is fast, but the storage and memory cost is significantly higher. For log volumes in the hundreds of GB/day and above, the operational cost of Elasticsearch becomes the dominant factor. For environments that need fast full-text search across structured and unstructured data — logs, documents, events — Elasticsearch earns its cost.

Search on Backend Engineering Strategy Tools