Culture Atlas · Build Journal / 08

BUILDING THE SYSTEM · CODE & DATA

When the Database Outgrew the Interface

I found a strange problem: sometimes information was not missing. The website just could not show it properly yet.

Ahaan Deshmukh · Grade 7 · Nita Mukesh Ambani Junior School

Builder's note: I am building Culture Atlas while learning to code with AI. These are my ideas, research and build notes, lightly edited for clarity.

I found a strange kind of missing information

Sometimes the information was not actually missing.

It was in the database. The website just did not know how to show it properly yet.

A visitor cannot explore knowledge just because it exists somewhere behind the screen.

Two search boxes should not know different things

One example was search. Culture Atlas had an older way of searching and a newer one. The newer search understood more kinds of records, while another search box still used the older version.

Imagine if the index at the back of a book knew about only the first six chapters. The other chapters would still be there, but the index would make them harder to discover.

I learned what “one source of truth” means

People building software often talk about a single source of truth.

I understand it like this: if two parts of Culture Atlas need to answer the same question, they should not each invent their own answer.

So the project moved toward one main search system that different parts of the website can use.

A database table is not a finished feature

The database could understand some newer kinds of cultural records before every part of the website had caught up.

A record might need a page, a way to appear in search, a way to connect to other records and a safe way to edit it. “I added it to the database” is not the same as “people can use it.”

Empty and broken can look exactly the same

Suppose I open a tradition and Culture Atlas shows no related stories. There are at least two possibilities.

Possibility one: we genuinely have not connected any stories yet.

Possibility two: the website tried to load the connections and something failed.

Those are completely different facts, but the screen used to be able to make them look the same.

We changed important parts of the system so a loading problem can be shown as a problem instead of pretending there is no research.

The screen has to be honest too

I used to think accuracy was mostly about getting the facts in the database right.

Now I think the interface has a responsibility as well. It should not make something look certain when it is uncertain, or empty when it actually failed to load.

More database knowledge does not automatically mean a better website

I could solve every missing route and still make a confusing product. The interface does not need to expose every table just because the database contains it.

The harder job is choosing what a learner needs now, what can appear later, and what should stay behind the scenes.

English gives me a useful test

A piece of writing can contain lots of information and still be difficult to understand if the order is wrong. The interface has the same problem. The database may know twenty things, but the learner needs a clear beginning, a sensible sequence and a reason to continue. That makes interface design partly an audience-and-structure problem, not only a coding problem.

Knowing more is not the same as explaining more

Building Culture Atlas is not only about collecting knowledge. I also have to make sure there is a clear path from that knowledge to the person exploring it.

What I'm figuring out next

Then I discovered a more basic problem. Before worrying about whether every page could find every record, I needed to know whether the whole project could still be built properly.

For a while, it could not.


Follow the build

← Previous entry Next: What broke →