Site Architecture and Design Language
A working design-language note for a site that now has enough moving parts to deserve one.
Working System
One site, several modes, one visual grammar.
Chips’nCode should feel coherent across writing, utilities, documentation, education, projects, and astrophotography without forcing them into one generic shell. The design language needs to hold the whole site together while still letting each section behave like the thing it actually is.
design://site-state
- sections
- 6
- header modes
- 2
- index model
- editorial
- rule
- cohesive, not cloned
one visual language, several page archetypes, and no obligation to force writing, utilities, and image-led work into the same shell.
Shared
What should stay consistent
- type scale and spacing rhythm
- surface, border, and shadow tokens
- metadata, link, and code styling
- the general mood of calm technical material
Variable
What is allowed to change
- header treatment
- archive structure
- media priority
- interaction model and information density
Bad rule
Every page should use the same shell.
Better rule
Every page should feel like it belongs to the same site.
Actual rule
Keep one visual grammar, then let each section earn its own pacing.
Current structure
The homepage is the switchboard. The section indexes are the shelves. The individual entries are where the real work happens. The site gets clearer once those layers stop pretending to have the same job.
Header modes
Use when the page wants title-first reading, less chrome, and a quieter technical tone.
Use when the page benefits from framed metadata, early media, or a stronger artifact-led opening.
Plain is not automatically better. It is simply better for some kinds of content. Showcase-style material can still need a stronger frame.
Section archetypes
inspect specimen
- wide lead story
- support rail
- denser archive below
Lead story, support rail, denser archive below, plain headers by default.
inspect specimen
- framed hero
- artifact-first body
- field log pacing
Artifact-friendly entries, stronger hero framing, and a more material-first index tone.
inspect specimen
- small utility marker
- light metadata
- text-first card deck
Text-first when images do not exist, with reduced metadata clutter and faster scanning.
inspect specimen
- plain engraved header
- reference callout
- dense technical body
Plain headers by default, heavier use of callouts and denser technical pacing when needed.
inspect specimen
- context-setting hero
- supporting fact panel
- guided task flow
Still benefits from a stronger hero and supporting fact panels because the teaching context needs them.
inspect specimen
- large image field
- caption and session notes
- kept separate on purpose
Should be changed carefully and in isolation. It has earned its own stronger treatment.
Patterns in use
Lead story, support rail, then a denser archive below.
terminal reference moduleUse terminal framing where the content is plain-text by nature and copyable.
inspector layoutUse selector-driven inspection when dense technical comparisons would be worse as a stack.
text-first utility indexDo not fake image cards when the content has no images. Let utility pages stay useful.
Current rules
Do
- let layouts react to the content, not just the viewport
- use text-first variants when entries have no media
- treat indexes as editorial surfaces rather than uniform grids
- choose
headerStyleon editorial grounds - keep image-led sections image-led
Do not
- force every section into the same post shell
- replace one repetitive card system with another repetitive card system
- add terminal styling where it serves no purpose
- assume plain headers are universally better
- change astrophotography casually because another section changed well
Practical authoring note
If a new entry is mostly writing, reference, or explanation, start with:
headerStyle: plainIf it is mostly artifact, media, or structured showcase material, start with:
headerStyle: panelThen let the page argue its case.
Design history
The first version focused on section archetypes, shared tokens, and the idea that the site should feel cohesive rather than cloned.
The live system now includes editorial indexes, terminal status headers, text-first utility/archive handling, the WIA band inspector, and the headerStyle option.