Design Language Archive

Archive note: this is the earlier version of the design-language document, kept as a record of the design journey. The current working version lives in the main design-language page.

Archived version

Short version: the site should share one visual grammar, but not one identical page shell. Cohesive, not cloned.

What this site is

Chips’nCode is not one thing pretending to be many things. It is a small constellation of related modes:

writing
projects
tools
documentation
education
astrophotography

Those are all part of the same brain, but they are not the same kind of page. That matters.

The site should therefore feel cohesive, but not uniform.

That is the core rule.

What stays shared

typography
spacing rhythm
colour tokens
link and code styles
reusable UI pieces

What changes by section

page framing
information density
media treatment
reading flow
interaction priority

Structural overview

At the content level, the site is organised into collections:

blog: narrative posts, essays, field notes, technical rambles
projects: build logs, systems, experiments, activations, outcomes
tools: small utilities, references, converters, interactive helpers
docs: structured how-tos, technical notes, references, internal manuals
education: scaffolded resources, lesson-adjacent material, embedded teaching content
astrophotography: image-driven session logs and processing notes

At the route level, that becomes:

/
/blog
/projects
/tools
/docs
/education
/astrophotography
/tags/[tag]

The homepage is the switchboard. The section pages are the shelves. The individual entries are where the real work happens.

The design problem

If every page type uses the exact same “title, date, paragraph blob” wrapper, the site becomes visually honest but emotionally flat.

That is fine for one post.

It is not fine for page after page after page.

At the same time, going too hard on visual novelty creates another problem: the site starts feeling like six unrelated microsites wearing the same domain name.

So the answer is not “make everything fancy” and it is also not “leave everything plain forever”.

The answer is:

one visual grammar
several page archetypes

Problem	Bad fix	Better fix
Everything feels flat	Add random visual noise everywhere	Keep body copy calm, improve page framing
Sections feel unrelated	Make every page use the same shell	Share tokens and components, vary archetypes
Long docs feel dense	Use more paragraphs	Use cards, callouts, tables, and clearer hierarchy

Shared design language

These things should stay consistent across the whole site:

typography
spacing rhythm
border radius
elevation and shadow rules
link behaviour
colour tokens
code block styling
metadata patterns
reusable UI pieces like pills, callouts, dividers, and image frames

This is the connective tissue. It is what makes the site feel like one place.

Visual principles

The shared language should aim for:

calm reading surfaces
slightly tactile panels rather than flat white voids
restrained accent colour
enough personality to feel human
enough discipline to still read like technical material

In plain English: not sterile, not noisy.

Page archetypes

This is where the variety comes from.

1. Narrative pages

Used for: blog posts and some longer project write-ups.

Should feel like: essay-like, readable, and slightly atmospheric.

stronger header block
clearer metadata
optional hero treatment
controlled reading width

2. Reference pages

Used for: docs and some education resources.

Should feel like: cleaner and utility-first.

strong hierarchy
obvious sectioning
callouts and warnings
optional table of contents

3. Showcase pages

Used for: projects and astrophotography.

Should feel like: artifact-driven and more visual.

media early on
structured metadata
gear or outcome panels
image-led pacing

4. Utility pages

Used for: tools.

Should feel like: compact, quick, and interaction-first.

controls above the fold
outputs before explanation
lighter prose footprint
fast scanning

Important: a tool page that behaves like a blog post has its priorities upside down.

Section-by-section intent

Blog

Purpose: Longer-form thinking, technical posts, stories from experiments, and things that deserve a voice.

Should feel like: A good notebook entry cleaned up just enough for public consumption.

Needs:

stronger post headers
optional hero imagery or motif blocks
reading aids like pull-quotes, callouts, or side notes

Docs

Purpose: Answers, references, procedures, and “how do I do this again?” material.

Should feel like: A practical manual written by a person, not a support portal.

Needs:

better section grouping
consistent note/warning styles
optional table of contents for long pages

Projects

Purpose: Show what got built, why, how, and what happened when reality had opinions.

Should feel like: A field log crossed with a lab notebook.

Needs:

more visible artifacts
metadata blocks for gear, links, dates, status, and outcomes
richer page framing than plain prose

Education

Purpose: Material that guides someone from “what is this?” to “I can use this.”

Should feel like: Structured, clear, encouraging, and step-aware.

Needs:

strong hierarchy
scaffold blocks
explicit sequence markers
embedded resources that look intentional rather than bolted on

Astrophotography

Purpose: Session logs, processing notes, image outcomes, and technical capture detail.

Should feel like: Quiet, image-led, and slightly more atmospheric than the rest of the site.

Needs:

careful image presentation
session metadata
processing summaries