A New Digital Ecology

There is a particular kind of cognitive dissonance that comes with having a website that only shows one face of you. For a few years, crisly.nl was essentially a publications list with a blog attached — useful, but flat. My clinical and research identity was there in outline, but the connections between projects were invisible, the design felt inherited rather than chosen, and the private side of the site (photography, animation, the occasional detour through astrophotography or cycling) sat in a separate aesthetic universe from the work pages, as if the two halves were embarrassed to be seen together.

What I wanted was something closer to an ecosystem: a site where a visitor could arrive at a research write-up about Usher syndrome genetics and, without feeling they had wandered off-map, end up looking at storm photographs from Gelderland. Not because those things are the same, but because they come from the same person, made with the same disposition towards attention and detail. A digital ecology, to use a term I’ve been turning over — a space where different kinds of output coexist in a shared environment, shaped by consistent design rather than rigid category walls.

This post documents what changed in the latest round of work.

Research as narrative, not inventory

The biggest structural addition is a Projects section — five pages, one per research theme, each building a coherent story out of what would otherwise be a scatter of publications:

• Hereditary Hearing Loss & Rare Genetic Disorders
• Genotype–Phenotype Correlations & Natural History
• Cochlear Implantation & Auditory Outcomes
• Remote Care & Digital Audiology
• Clinical Trials & Inner-Ear Therapeutics

Each project page has a findings table (gene, phenotype, key result, reference), a narrative summary, a linked list of related blog write-ups, and a per-page bibliography rendered by jekyll-scholar from the same .bib file that feeds the publications page. The result is something that reads more like a research dossier than a filtered publication list.

What I find interesting about this structure is that it makes the connections visible. The natural history work on DFNA9 and Usher syndrome type 2A isn’t just a set of papers — it’s the explicit scientific prerequisite for the AON therapies that colleagues Erwin van Wijk and Erik de Vrieze are now moving into clinical application. A publications list can’t show that. A project page can.

The projects are also wired into the navigation as a dropdown, and linked bidirectionally from the resume’s focus areas — so the same information is reachable from multiple entry points depending on what the visitor is looking for.

The design layer: runtime flexibility

The visual redesign was driven by one core idea: separate what the compiler knows from what the browser decides.

Jekyll compiles Sass to CSS at build time. The traditional Feeling Responsive approach bakes a palette (a set of hex colours) into the compiled stylesheet, and that’s what users see. Changing the palette means rebuilding the site. That’s fine for production, but it makes experimentation slow and it means every visitor gets the same colour experience regardless of context or preference.

The new approach adds a second layer on top of the compiled styles: CSS custom properties (var(--primary), var(--secondary), etc.) that the browser evaluates at paint time. Dark mode works by switching html[data-theme="dark"] — the browser re-evaluates all the custom properties instantly, no recompilation. The same mechanism drives a palette switcher in the navigation bar: four small coloured dots (Moonlight, Verdant, Claret, Meridian) that swap the full colour scheme at runtime, with the choice persisted to localStorage so it survives page reloads.

The practical consequence is that the site can have four complete colour identities without four builds. The compiled stylesheet contains all of them as html[data-palette="X"] override blocks; only the active one wins on any given page load.

Colour palettes

Four palettes are available via the dot switcher in the navigation bar. The dark-mode values are derived at runtime using the same lightness-scaling formula as the Sass compiler.

Palette	Light primary	Light secondary	Light accent	Dark primary	Dark secondary	Dark accent
D · Moonlight
E · Verdant
F · Claret
G · Meridian

A small but meaningful downstream effect: any component that uses color-mix(in srgb, var(--secondary) 12%, white 88%) rather than a hardcoded hex automatically responds to both the palette switcher and dark mode. The project page TOC pills, the resume focus area pills, the navigation gradient stripe — all theme-aware, all zero-maintenance as new palettes are added.

The smaller things

A few changes that don’t warrant their own section but add up:

Navigation order was adjusted to reflect how I actually think about the site: Start → Blog → Photos → Projects → Publications → Resume. The research-heavy end is to the right; the more personal and recent content is to the left.

The projects index now displays entries in the same visual format as the blog listing — subheadline, title, thumbnail image, description blurb, read-more link — rather than a flat card list. The TOC jump-to pills above the listing use the same token-driven styling as the resume focus pills, so they track whatever palette and light/dark mode is active.

The hero name on the front page was cleaned up — weight reduced, gradient removed, and the font size aligned to match the widget headers below it. The negative letter-spacing that was clipping the right edge of long descenders is gone.

Why Jekyll

The question I get most often about the site is some version of: “why not just use WordPress?” Or Substack, or Ghost, or Webflow, or one of the many platforms designed to make publishing easy. The honest answer is that easy and controllable are not the same thing, and for a site that needs to hold a bibliography engine, a custom runtime colour system, a structured research collection, and a photography archive all without feeling like it’s straining at its seams — control matters more than ease.

Jekyll is fast in two senses. The generated site is entirely static: no PHP, no database queries, no server-side rendering on request. Every page is pre-built HTML served directly from a CDN. On a standard connection, pages load in under a second; on mobile on a flaky network, the difference between a static site and a CMS-backed one is the difference between “readable” and “I’ll come back later”. The build step itself — Sass compilation, Liquid templating, bibliography rendering — takes about five seconds for this site. That’s an acceptable price for having a fully automated system that produces optimised output every time.

Jekyll is flexible in the sense that matters for an academic personal site: it gets out of the way when you know what you want. The bibliography integration runs through jekyll-scholar, which processes .bib files and renders per-page reference lists with <a class="citation" href="#"></a> tags that work exactly like LaTeX — familiar territory. Jekyll Collections handle the structured project pages with typed front matter and clean URLs. Liquid templating is limited by design (no arbitrary code execution), which sounds like a constraint but mostly means that the templates stay readable and the site stays auditable. YAML front matter means every page carries its own metadata: title, projects membership, image, category, tags — and Liquid can filter and sort on any of it without a database.

The aesthetics are entirely mine. This is probably the real reason. A platform like Webflow or Squarespace imposes visual opinions through its component system; fighting those opinions is where most of the effort goes. With Jekyll and SCSS, the design is built from the bottom up: every spacing value, every colour token, every responsive breakpoint is something I chose. The runtime palette switcher described above — CSS custom properties overridden by html[data-palette] attribute selectors — would be awkward or impossible to implement inside a managed CMS. Here it’s just SCSS and fifteen lines of JavaScript. The constraint is having to write it; the freedom is that it then does exactly what I wanted.

The tradeoff is real: there is no admin panel, no drag-and-drop, no autosave. New content goes through a text editor and a jekyll build. For someone who writes everything in Markdown anyway and uses a bibliography manager (Zotero) that exports .bib, this is not a hardship — it’s just the existing workflow, with one more step at the end.

What this is, eventually

None of this is finished. The remote care and clinical trials project pages are still placeholder content. Several blog posts about ongoing work (RIPOR2 follow-up, TMPRSS3 CI outcomes, the AC102 programme) exist only as drafts. The photography section deserves more curatorial attention than a reverse-chronological dump.

But the structure is right, and the design feels genuinely mine. That’s enough to work from.