A portfolio can make complicated work look simpler and less credible at the same time.
Put every project into the same card, give each one a confident paragraph and a neat outcome, and several important distinctions disappear: a live system looks like a prototype; a proposal looks like a commission; a long publishing relationship looks like a single deliverable; a failed route vanishes; a piece of collaborative work loses the question of who actually did what.
The result is easier to scan, but it can also be less true.
Pages are containers, not models
Websites flatten things very easily. They are good at pages, posts, menus and categories. A surprising amount of professional work is not naturally shaped like any of those.
Trigger SMARTS‘s event signage can be presented as a list of screens, but the real model is rooms, bookings, clients, event times and physical directions through a building.
IMLPO could have pages explaining membership, events and payment, while the operational reality was a set of relationships between people, status, subscriptions, money, communication and access.
The Lettings Compliance Checker could publish guidance pages, while the useful product needs to know which requirements apply to a particular property and why.
In each case, the page still works as a presentation surface, but the real value sits in the relationships behind it. If those relationships exist only as prose repeated across individual pages, the website has represented the material but not really structured it.
Flattening creates maintenance problems
When relationships are represented only through prose or duplicated fields, they drift.
The same fact gets written in three places and corrected in two. A renamed room still appears under its old name somewhere. A character description conflicts across book pages. An event title differs between the website and the recording platform.
This is not always a reason to build a database. But it is a reason to ask whether the content model reflects the work.
The right structure might be very small: one canonical event record, a handful of relationships, one controlled vocabulary, a clear ownership rule.
Complexity in the subject does not require maximal complexity in the software.
Flattening can also erase uncertainty
There is another, subtler kind of flattening.
Systems like definite fields. A record wants one date. One status. One name. One version.
Reality may not be so obliging.
Historical evidence can support a year but not a month. A project can have a live predecessor and an experimental successor at the same time. An AI extraction may be plausible but not yet reviewed. A person may genuinely answer “not sure” to a compliance question.
If the system has nowhere to put those distinctions, it creates false certainty.
One of the reasons Interactive Professional Portfolio became more elaborate is precisely because a simple CV-style model was not enough. It needed date precision, project maturity, evidence class, source boundaries and the ability to preserve unresolved states.
A cleaner-looking record can be less true.
The danger of generic service architecture
This problem applies to professional websites too.
The old Niche Clever site was organised around Support, Publishing, Web and Marketing.
Those are perfectly understandable service categories. They are also a poor description of much of the strongest work.
Where does a structured literary corpus belong? Is it publishing, web or AI?
Where does IMLPO belong if the value is simultaneously operations, institutional knowledge, membership systems and handover?
Is Trigger SMARTS a WordPress project, a digital-signage project, an operational system or product stewardship?
Forcing the work into service boxes makes the site easier to categorise and the practice harder to understand.
That is why the current site keeps Work, How I Help and Method as connected but different views of the same practice, rather than a single service menu.
No single taxonomy has to carry the entire truth.
Structure should reveal, not imprison
There is a risk of over-correcting.
Once you become interested in entities and relationships, it is possible to model everything.
That can be another form of flattening, because the model starts treating only what fits its schema as real.
Human editorial judgement, local convention and narrative context often resist clean formalisation for good reasons.
A useful system therefore needs escape routes:
- free text where nuance matters;
- explicit unknown/uncertain states;
- evidence links;
- human review;
- version history;
- the ability to revise the model when reality disproves it.
The structure is a tool for understanding, not a claim to have exhausted the subject.
What this means for the web
The web is capable of much richer representations than the page/post model suggests.
A site can let people browse by relationships, chronology, evidence, project maturity, location, people or theme. A publication can have a companion system that extends rather than merely advertises the printed object. A portfolio can be interrogated by question. A workflow can use WordPress as the canonical record while coordinating external services around it.
But the point is not novelty.
The point is to give the material a form proportionate to what people actually need to understand and do.
Sometimes an ordinary page is exactly right. Sometimes it is the thing doing the flattening. Complexity should be structured and progressively disclosed, not dumped on the reader or erased.
Related
The Work timeline keeps these maturity distinctions visible rather than collapsing them into one story. Interactive Professional Portfolio is the clearest example of building provenance into the structure itself.