Brand 2026: Conduction brand guide, design rationale and DTCG tokens#21
Open
rubenvdlinde wants to merge 29 commits intomainfrom
Open
Brand 2026: Conduction brand guide, design rationale and DTCG tokens#21rubenvdlinde wants to merge 29 commits intomainfrom
rubenvdlinde wants to merge 29 commits intomainfrom
Conversation
…TCG tokens Introduces the theme-conduction-2026 brand system in the .github repo so all Conduction apps can consume a single source of truth for colour and typography. - BRAND.md: values, logo usage, colour palette, typography, do's & don'ts - DESIGN.md: rationale (why cobalt, why windmill orange, why Figtree, why a Conduction-owned theme that aligns with NLDS rather than extending it) - brand/tokens.json: W3C DTCG format, primitive + semantic layers (scope A: colours + typography; spacing/radii/components follow later) - brand/README.md: how to consume tokens (CSS vars, Tailwind, JS) + NLDS mapping - brand/assets/: Conduction avatar SVGs recoloured to cobalt #21468B — on-white (default), on-blue (inverse), transparent (flexible) - profile/README.md: link to the new brand guide from the org landing page Colours: cobalt #21468B (primary), windmill orange #FF7F00 (secondary), vermillion #AE1C28 (tertiary), white #FFFFFF (background) — all sourced from the official Dutch flag palette, signalling Conduction's Dutch identity without colliding with the Rijkshuisstijl. Hexagon logo wrapper preserved. Typography: Figtree (body + headings) and IBM Plex Mono (code), both OFL.
Clarifies which surfaces (www.conduction.nl marketing site, docs.conduction.nl Docusaurus site, individual app-UIs) adopt the theme in which order and why. Marketing-first on merit of brand impact, with docs as parallel technical testbed. Defines what counts as "migrated" per surface.
Replaces wimpel-oranje #FF7F00 with KNVB-oranje #F36C21 as the brand secondary. Motivation (full version in DESIGN.md): - Softer, warmer pairing with cobalt (less buzz from a pure-complement 100%-saturation orange) - KNVB is the most universally recognisable "Nederlands oranje" — accessible patriotism via the national football team, without the Rijkshuisstijl (government) association - Better fit with the "innovative / trade-driven / human" side of the brief than wimpel's formal ceremonial feel Adds two new sections to DESIGN.md: - "Wat oranje betekent voor Conduction" — the accent color stands for warmth, accessibility, Dutch identity at mass-appeal level, and attention focus. Cobalt carries trust; orange carries movement. - "Overwogen kleurcombinaties" — comparison table placing our cobalt+KNVB pairing against Rabobank, ING, Rijkshuisstijl, KNVB itself, and the Dutch flag. Shows we sit in the gap between "too-dark banking navy" and "too-brown government orange". Adds a "Subtiel gebruik: de 8%-regel" section that spells out where orange belongs (focus rings, hover states, badges, icon accents, highlights) and where it does not (large fills, primary buttons, body text, multiple accents per screen). Token rename: color.primitive.orange.windmill -> color.primitive.orange.knvb. All semantic tokens updated to reference the new primitive.
…parison tables Three improvements based on feedback that the colour section was asymmetric: 1. Blue had rationale but no side-by-side comparison table. Added one. Candidates compared: legacy #4376FC, cobalt #21468B (chosen), NLDS utrecht-blauw #154273, rijks-lint #01689B, midnight #0C2D48. Table shows HSL, contrast-on-white, body-text viability, cultural reference, and reason for selection or rejection. 2. Orange comparison table omitted Rijkshuisstijl (#E17000). Added it as a third column alongside wimpel and KNVB. Shows Rijks fails on three fronts simultaneously: worst contrast on cobalt (2.82:1, below WCAG 3:1), highest positioning risk (direct government signal), and darkest luminance (sinks into cobalt rather than popping). 3. The Dutch-brand comparison table (Rabobank, ING, Rijkshuisstijl, KNVB, flag) was buried as a subsection inside the KNVB-orange rationale. Promoted it to a standalone subsection "Positie tegenover andere Nederlandse merken" at the bottom of the colour section, after all individual colour rationales. Now discoverable as its own topic. Also added a note about the differentiation risk: no single brand matches our exact pair, but the combination can read as Rabobank/ING/government at a glance. Our differentiation therefore leans on proportion and application (the 8% rule, hexagon wrapper, Figtree, white dominance), not hex values alone.
…BRAND/DESIGN Three coupled changes to PR #21, all serving the www.conduction.nl overhaul. 1. BRAND.md — three new company-wide sections: - "Wat we bouwen — een app-ecosysteem, geen consultancy" — Conduction is reframed as a product company. The ecosystem of Nextcloud apps is the primary business; projects, training and advisory services are supporting, not leading. Customers can use us without talking to us. - "Voor wie we bouwen" — audience shift codified. Primary: MKB (target). Secondary: overheid (current majority, in wind-down). Tertiary: OSS developers/integrators. Honest about the transition rather than pretending it's already complete. - "Apps & Solutions" — terminology standard for ALL Conduction communication. Apps are software products (OpenCatalogi); solutions are what you achieve with them (WOO compliance). One app serves many solutions; one solution needs a stack of apps. Bans phrases like "our WOO app" across all channels. 2. DESIGN.md — new section "Tone & visuele richting — implicaties van de positioneringsshift" — translates the BRAND.md positioning shifts into design implications valid company-wide, not website-specific: - Tone table: overheid-formal "u"/3e persoon/jargon → MKB-direct "je"/resultaat-centraal/scanbaar - Visual table: stockfoto/team/vergaderzaal → app-screenshots/hexagon/ UI-as-hero. Team photos retreat to About pages; apps take over hero slots. - Apps-vs-Solutions language rules for visual contexts (stack-diagrams, don't name apps after solutions). 3. briefs/website.md (new) — the actual website design brief, ~18 sections: purpose, strategic context, audiences, CTA hierarchy (primary task = install from Nextcloud app store), information architecture, page types, content types, tone, visual direction, i18n (bilingual NL/EN with NL default), accessibility, SEO (solution landing pages as SEO anchors), success metrics, out of scope, and a two-phase implementation approach (design-first in HTML+CSS mocks, Docusaurus implementation second). Launch scope: 11 core apps, 5 initial solutions. briefs/README.md establishes the per-surface brief convention (briefs/ dir for future drukwerk/presentation/app-UI briefs). Everything in the brief links back to BRAND.md, DESIGN.md and tokens.json rather than duplicating foundation content. Surface-specific insights that emerged during scoping (e.g. product-company tone) are lifted to the foundation docs so future surfaces can consume them.
…#20) Closes gap #20 from the one-shot readiness review: designer needs concrete anchor points for tone and sfeer, without which a one-shot produces a generic average-of-everything design. Selection comes from our competitive-intelligence DB (1,088 catalogued competitors in a broader pool of ~32K GitHub repos / ~17K organisations). Curated down to: - 5 positive references, each representing a different aspect we want to approach: Nextcloud (tonal + app-store model), Decidim (civic-OSS + solution landing pattern), Supabase (modern OSS productbedrijf + catalog), Backstage (ecosystem/plugin framing), PostHog (personality without corporate-dryness). - 2 anti-references showing the classic NL-gov-vendor archetype we're moving away from: PinkRoccade Local Government and BCT Corsa. Both are in the DB as proprietary / subscription competitors in the same Dutch government market we're repositioning against. Each entry includes the DB-relationship (ally / initiative / competitor) so it's clear how we framed them in our intelligence pipeline, not just cherry- picked from the web. Also adds a "Gebruiksinstructie voor de designer" subsection with concrete heuristics: "if a mock sits between PinkRoccade and Supabase, go further toward Supabase"; "if it reads too developer-heavy, back toward Nextcloud/PostHog"; etc. This is data-grounded rather than speculative — a step that can't be skipped for a real one-shot attempt.
…ce DB Addresses gaps #12, #16, #17, #18 from the one-shot-review, using real data from concurrentie-analyse/intelligence.db (Postgres) — not placeholder copy. Adds four content appendices under briefs/website/ plus a README index: 1. app-taglines.md (gap #17) — Tagline library for all 11 core apps, bilingual (NL + EN). Each tagline calibrated against the top canonical_ features per app by demand_score from the DB. Ranges from 2,112 features for OpenCatalogi to 32 for ZaakAfhandelApp (flagged as thin pending more data). Includes review-checklist and banned-word list so future tagline edits stay on-tone. 2. solution-woo.md (gap #18) — A complete WOO-compliance solution page usable as the TEMPLATE for all future solution pages. Mined from 1,031 Dutch tenders and 5,992 Woo-related requirements. Real stakeholder quotes from Gemeente Tilburg, De Connectie, Gemeente Dordrecht, and multiple authentic requirement sentences. Covers hero, problem framing, Conduction's "publish from source" approach, 4-app stack table, FAQ (7 questions), SEO metadata (NL + EN), and explicit "template sections" note so other solutions can follow the same structure. 3. tone-samples.md (gap #16, NL part) — NL tone-calibration set. Three registers identified with real DB samples: A) Overheid-inkoop-taal ("De Oplossing..."), B) Systeem-moet-zinnen ("Het systeem moet..."), C) User-story-taal ("Als gebruiker..."). Plus three rewrite recipes (tender-language → Conduction-language), seven golden rules, and a banned-word list confirmed from the source material. 4. icon-library.md (gap #12) — Decision framework comparing 9 icon libraries (Lucide, Phosphor, Heroicons, Feather, MDI, Fluent UI, Bootstrap Icons, Ant Design, Carbon). Recommends Lucide based on style-fit, licensing (ISC), peer-group adoption (Supabase/PostHog reference sites), and tree-shakeability. Documents the Phosphor switch-criterion for if multi-weight icons become necessary. Also adds briefs/website/README.md as the index for this appendix and links all four files into the relevant sections of the main brief: app-taglines into §7 (Content types), solution-woo into §7, tone-samples into §8 (Tone & voice), icon-library into §9 (Visuele richting). This closes 4 of the 20 identified gaps with actual grounded data. The remaining 14+ gaps (spacing scale, component specs, etc.) are pure design decisions where the intelligence DB has nothing to add.
Adds Font Awesome Free to the icon-library candidates table (it was the most notable omission) plus a full "Waarom niet Font Awesome?" subsection with three substantive reasons for preferring Lucide: 1. Visual register — FA signals "2010s web / Bootstrap-era / WordPress- ecosystem", overlapping with the enterprise-SaaS look our positioning shift (see DESIGN.md) explicitly moves away from. All our positive reference sites (Supabase, PostHog, Linear, Nextcloud) use Lucide/Phosphor-family; our anti-references skew FA or FA-adjacent. 2. CC-BY 4.0 attribution requirement on FA-Free icons (code is MIT, but the icons themselves require visible credit). Strictly speaking a compliance item; Lucide ISC and Phosphor MIT require nothing. 3. Pro-upgrade pressure — FA Free's ~2k icons cover a marketing site on paper, but in practice you hit "that icon is Pro" walls that push you to a $99+/yr subscription. For a company that's explicitly anti-SaaS- lock-in, that's a values conflict. Plus three smaller points (bundle default, Docusaurus integration ergonomics, peer-group trajectory) and three scenarios under which we'd revisit the decision (brand-icon coverage, apps adopting FA, domain- specific iconography gap). Keeps Lucide as the recommendation — this commit only makes the comparison and reasoning visible so the choice isn't tacit.
Adds briefs/website/platform-benchmarks.md: extensive analysis of two
mature app-platform websites that match our "extensive catalogue"
structural pattern. Both were explicitly requested as references.
Structure:
- Context section up front: our "always free + optional SLA" model vs
their freemium / paid-extension models, with a table of the key
differences. This framing runs through the whole document — we adopt
structural patterns (IA, catalogue UX, detail-page templates) but
NOT commerce mechanics (cart, checkout, subscription management,
in-site accounts, upgrade pressure).
- Odoo deep-dive (~50K GitHub stars, 30K+ apps in marketplace):
homepage teardown by section, apps catalogue UX (/apps + apps.odoo.com
split), individual app page structure, Community-vs-Enterprise split
as visual pattern on pricing, services/partners directory. Eight
patterns to adopt (mega-menu, stats-strip, multi-facet filter, sticky
intra-page nav, alternating feature blocks, integration strip,
extensive footer, Community/Enterprise-kolom pattern adapted to
Self-host/SLA), seven to avoid (separate catalogues, add-to-cart,
review system, trial flow, upgrade pressure, scroll-marathon, full
partner directory).
- WooCommerce deep-dive (core free + paid extensions on Automattic
platform): navigation, homepage patterns, extensions store with
filter-sidebar + grid, detail pages with tabbed content (description/
reviews/docs/FAQ), metadata sidebar, themes gallery, WooExperts
directory, developer hub. Six patterns to adopt (values-as-hero-
teasers, extensions-teaser as second section, filter-sidebar + grid,
tabbed detail content, metadata sidebar, compact homepage), five to
avoid (cart/pricing, review tab, themes gallery, experts directory,
subscription/one-time pricing UI).
- Side-by-side synthesis: seven core patterns both platforms share that
we adopt one-to-one (mega menu, apps grid post-hero, filter+grid,
detail-page template with hero + screenshots + tabs + metadata
sidebar, stats-strip, community/OSS block, extensive footer).
- Dedicated section on how our free + SLA model reshapes the IA
fundamentally: no Enterprise/Pro badges, no pricing page as central
element (replaced by discrete SLA page), no Try-it-free CTAs, no
Contact-sales as funnel endpoint, proof via usage (installs,
municipalities, forks) rather than revenue.
- Seven concrete design decisions as output:
1. Homepage in 7 sections
2. Apps catalogue: filter-sidebar + grid, four facets
3. App-detail page: hero + sticky intra-page nav + 4-6 alternating
feature blocks + integration strip + metadata sidebar + CTA
repeat, no reviews tab
4. Solution pages: reuse the existing solution-woo.md template
pattern (matches Odoo's industry-page pattern)
5. SLA page: one page, footer-linked, no price list
6. Services page: discrete in footer
7. Navigation split (primary in header, secondary in footer)
Also updates briefs/website.md and briefs/website/README.md to link
the new file from the appendix index.
…essure
Three coupled changes in response to clarification that our SLA model
is genuinely unique (two paths, not one) and that the CTA psychology of
a free-always-download-pressure site differs fundamentally from a
paid/trial upgrade-pressure site.
1. briefs/website/sla-model.md (new) — full documentation of the
Conduction SLA model as foundation for the SLA-page design.
- What SLA includes (explicit scope): reactive helpdesk support +
proactive support via telemetry (we see problems before the
customer calls). Explicit exclusions: no 24/7, no custom dev,
no implementation help (that's Services), no hosting, no training.
- Path 1 (most common): SLA via the customer's existing Nextcloud
reseller. One contract, one invoice, one point of contact — we
settle via Nextcloud with the reseller behind the scenes.
- Path 2: SLA direct with Conduction for self-managed Nextcloud.
Request form lives IN THE APP under admin settings, not on our
website. Deliberate choice: you need the app before you need
the SLA.
- SLA-page structure (7 sections) explicitly specified, plus list
of what the page should NOT contain (no pricing comparison, no
cart, no urgency, no scare tactics, no feature-gated comparison).
- Relation to Services clarified: SLA = ongoing support, Services =
projects (implementation, training, custom dev).
- 5 open decisions noted (reseller list, minimum contract size,
Nextcloud revenue-share mechanics, in-app form automation,
SLA-status widget).
2. briefs/website/platform-benchmarks.md (update) — replaces the single
SLA positioning section with:
- New section "Van upgrade-druk naar download-druk" that crystallises
the CTA-psychology difference. Odoo/Woo's primary verbs are
Try/Buy/Start/Upgrade; ours is always Install/Download. Adds
side-by-side table contrasting friction, urgency signals, pricing
communication, social proof, and endpoint of flows. Explicit
layout implications (no sticky CTA bars with urgency, no
exit-intent popups, no pricing in main nav).
- Expanded SLA section now covers both paths and what's in the SLA
(not just the positioning copy). Links to sla-model.md for full
detail.
3. briefs/website.md (update) —
- §4 CTA hierarchy adds a "download-pressure" framing paragraph up
front, adds SLA to the CTA ladder at rank 5, clarifies SLA is NOT
a conversion point on the website (it's requested via reseller
or via in-app form).
- §6.7 becomes "SLA (/sla)" (new page type, structure referenced to
sla-model.md). Services moves to §6.8, Contact to §6.9, 404 to
§6.10. Footer and sitemap updated to include /sla.
- §17 Open vragen adds the OpenCatalogi-eat-our-own-dog-food
consideration: since we have a federated-data-catalogue product
(OpenCatalogi), the apps-catalogus page could literally be an
OpenCatalogi deployment. Noted as a later-phase decision, after
the HTML+CSS mock.
- Also adds "SLA in-app form UX is a separate app-UI brief" and
"Nextcloud resellers supporting our SLA — list to be compiled"
as open questions.
4. BRAND.md (update) — the "Wat we bouwen" section now explicitly
distinguishes the two revenue-supporting layers (SLA and Services)
around the always-free ecosystem, including the two SLA paths in
brief. Clarifies that both are secondary and neither applies
upgrade-pressure.
5. briefs/website/README.md (update) — index now reflects
platform-benchmarks' expanded scope and links the new sla-model.md.
Three coupled changes triggered by the clarification that (a) SLA should be
renamed to Support for accessibility, (b) pricing is acceptable in main nav
as long as the page is clear about software staying free, (c) a concrete
pricing table per app/user/year is needed, mirroring how Nextcloud does it.
Also confirms Services scope = custom development + training (+ optional
implementation help).
1. Rename SLA → Support globally (user-facing)
- git mv briefs/website/sla-model.md → briefs/website/support-model.md
(preserves history)
- URL /sla → /support
- All user-facing "SLA" references now say "Support"; "SLA" is retained
as the technical contract term ("Support, technisch een SLA-contract")
- Nav item moves from footer into main nav: Apps / Solutions /
**Support** / About / Docs / GitHub. Mitigation lives in the page
content (prominent disclaimer that software is free, Support optional)
rather than in hiding the page.
2. Add Nextcloud pricing benchmark and pricing table
- New section in briefs/website/platform-benchmarks.md: "Nextcloud —
derde benchmark (free core + paid support)". Researched via WebFetch
against nextcloud.com/pricing. Documents the exact structure:
tiers Standard/Premium/Ultimate, €71-205/user/year for Files (Talk
separate), 100-user minimum with volume discounts at 200+, "contact
us" for larger orgs, 3-column comparison layout.
- Analysis of what we adopt structurally (per user × per year billing,
tiered response times, volume discounts, "contact us for quotes") vs
where we deviate (we only charge for support not software; lower
minimums for MKB accessibility; 2 tiers instead of 3; per-app
granularity instead of per-stack; explicit bundle discount for
ecosystem adoption).
- New pricing table in briefs/website/support-model.md with all 11
core apps grouped into Foundation / Core / Ondersteunend categories,
two tiers (Standard/Premium), with placeholder €TBD values that
leadership must confirm. Indicative ranges included as starting
points for that discussion. Worked calculation example showing how
bundle discount applies.
3. Confirm Services scope and reorganise
- briefs/website.md §6.8 Services now explicitly lists: maatwerk-
ontwikkeling, training, implementatie-begeleiding (was: "implementatie-
ondersteuning, training, maatwerkadvies, integratie-projecten" —
consolidated to match user's stated scope).
- §6.7 becomes Support (/support) in main nav with pricing table;
reverses the earlier "SLA in footer only" decision per user input
that Pricing in main nav is fine as long as the page is honest.
- BRAND.md revenue-model section updated to use "Support" as the label,
keep "SLA" as the technical term, and document the per-app × per-
user × per-year tier structure + Services = maatwerk + training +
implementatie.
4. Housekeeping
- briefs/website/README.md index updated to reflect the rename and
expanded scope (support-model.md now covers pricing too).
- Platform-benchmarks "Seven patterns" stays but title reflects the
three-platform synthesis (Odoo + Woo + Nextcloud) instead of two.
- Open questions expanded: actual pricing values TBD, Nextcloud-
reseller list TBD, revenue-share mechanics TBD, minimum-user-
counts TBD, maatwerk-tier pricing TBD, in-app form CRM integration
TBD.
All placeholder pricing values are flagged for leadership confirmation
before publication.
Documents the full Services pricing structure so the Services page has concrete numbers instead of "contact for quote" placeholders. Also resolves the maatwerk-tier Support open question (priced via Services rates on per-offer basis). New: briefs/website/services-model.md Rate card: - Development: €125/hour - Consultancy: €150/hour - Strippenkaart: €15,000 prepaid → 10% discount → effective €112.50 (dev) or €135 (consultancy) per hour; valid 12 months; transparent usage reporting - Physical training: 8 hours billed per 4-hour dagdeel (the 4 extra hours cover preparation and processing — explicitly justified in the doc so clients understand they're not being overcharged). At €125/hr that's €1,000/dagdeel for dev-training, €1,200 for consultancy- training. Example formats: halve dag, volle dag, meerdaags. - Online training: FREE. Positioned as congruent with our open-source/ penny-wise values — kennisdeling should not sit behind a paywall. Self-paced content on docs.conduction.nl plus scheduled webinars. Quality trade-off: no 1-on-1 guidance (that's what physical training or consultancy hours are for). - Certification: variable per certificate (indicative €150-500 range based on Linux Foundation / Red Hat patterns). Free training + paid certification is the industry-standard OSS pattern. Three candidate certificates noted (App User / Integrator / Solution Architect) for later certification rollout. All prices ex. VAT, travel/accommodation separate. Plus a reproducible comparison matrix (Apps / Support / Services-dev / Services-consultancy / Services-physical-training / Services-online-training / Services-cert / Partnerschap) showing target customer, billing model, and example use case per line. Updated: - briefs/website.md §6.8: replaces placeholder Services section with summarised rate card + link to services-model.md - briefs/website.md foundation links: adds services-model.md entry - BRAND.md "Wat we bouwen": Services entry now includes the rate-card specifics (€125/€150 per hour, €1,000-1,200 per training dagdeel, strippenkaart, free online training) rather than vague "project-based" wording - briefs/website/README.md: index row for services-model.md - briefs/website/support-model.md: maatwerk-tier open question resolved (priced via Services rates, case-by-case offer) Six open questions in services-model.md (certification prices, certificate portfolio, larger strippenkaarten, international pricing, travel expense policy, pro-bono framework) kept for leadership to resolve before publication.
…ments, illustration-style candidates
Three coupled visual decisions that together determine the site's feel
more than colour/typography alone. Captured in a new
briefs/website/visual-motifs.md and promoted company-wide where appropriate.
1. Hexagon as systematic motif (company-wide — DESIGN.md updated)
Previously the hexagon was only the logo wrapper. This commit elevates
it to a recurring UI shape that appears across: list bullets,
pagination, step-indicators, progress-bars, status-badges, avatars,
app-logos, category-tags, ratings, section-dividers, timeline-beads,
empty-states, loading-spinners.
Load-bearing rule: hex for ACCENTS, not functional containers.
Elements where a shape carries meaning (indicator, accent, icon,
badge) get hex. Elements where a human does something with them
(inputs, buttons, modals, tables, cards) stay rectangular — click,
tap, read and fill behave better. Rectangular containers with hex
accents is the deliberate combo: function and brand both defended.
Two orientations: flat-top for formal brand moments (logo wrappers,
avatars, app-icons, hero-constellations); pointy-top for UI
elements (bullets, badges, step-indicators). Functional
differentiation, not inconsistency.
DESIGN.md now reflects this as company-wide direction (applies to
apps, drukwerk, presentations, not just the website) while
visual-motifs.md holds the detailed catalogue.
2. Per-section treatments (website-specific)
Each homepage section (plus app-detail, solution-landing, Support,
Services, About, 404) gets 2-4 options and a recommendation with
rationale. No section just defaults to "hero + text + screenshot".
Notable recommendations:
- Hero: "Ecosystem constellation" — central hex with satellite-app-
hexes, quiet animation. One-image communication of the ecosystem.
- Values teasers: honeycomb row — 4 touching hexagons with values.
- Apps-grid: the user's proposal — offset honeycomb on desktop with
icon tiles, hover reveals tagline from app-taglines.md. Vertical
list fallback < 768px. Touch/keyboard accessible. 200ms cross-fade.
Micro-interaction: honeycomb-build-in entrance (50ms stagger).
- Solutions: stack-diagram teaser — each solution card shows its
app-stack as a mini hex-composition, communicating our
differentiator (solutions are compositions of apps).
- Stats: hex-framed numbers with count-up-on-scroll.
- Support teaser: deliberately quiet — one understated sentence
with a single hex accent, matching our "not upselling" tone.
- Footer: subtle hex-pattern background at 5-8% opacity.
3. Illustration style — named candidates awaiting confirmation
Flagged that I couldn't see conduction.nl's actual illustrations via
WebFetch (tool only processes HTML text, not images). Listed 7
candidate named styles with descriptions, licensing and URLs:
Open Peeps (CC0, thick-outline line-art characters),
Humaaans (CC BY 4.0, mix-and-match), Blush (mixed, scene collection),
Storyset Line (free-with-attribution complete scenes),
Drawkit Line (paid-tier, cleaner rounded), Icons8 Ouch! Lineal (mixed
massive library), Streamline Line (paid enterprise-grade). My
recommendation: Open Peeps + Storyset Line hybrid — Open Peeps for
characters, Storyset Line for concept scenes.
Also included a "master briefing text" for use with AI tools
(Midjourney, etc.) or freelance illustrators, describing the style
reproducibly: "Vector-based line illustrations. Thick uniform outline
weight (2-3px). Rounded friendly shapes. Minimal facial features.
Cobalt outline, KNVB orange accents on white. Reference: Open Peeps
and Storyset Line hybrid. Dutch-inflected feel: unpretentious,
competent, warm."
Explicit anti-references: Corporate Memphis / Alegria-style (too
bland), isometric (too enterprise), 3D Lottie-type (clashes with
flat+hex direction), cartoon/caricature (too informal for MKB
decision-makers), photo-realistic stock illustrations.
Awaits user to confirm which candidate matches the current
conduction.nl style, or to describe their preferred direction.
Also updates briefs/website.md §9 Visuele richting to point at
visual-motifs.md for the hexagon catalogue and illustration-style
candidates. Updates briefs/website/README.md index with a row for the
new file.
Two corrections from user input:
1. Hexagon orientation — ALWAYS POINTY-TOP
My earlier flat-top-for-logo/pointy-top-for-UI split was wrong. The
existing Conduction logo and existing hex-portrait frames are all
pointy-top, so everything stays pointy-top. One orientation across
all surfaces.
Why: maximum brand recognition (same shape everywhere loads "Conduction"
immediately), visual rest (mixed orientations create busy honeycomb
patterns), cross-surface consistency (logo → bullet → avatar →
pagination all share the silhouette).
Honeycomb patterns of pointy-top hexes still work fine — they stack
in offset horizontal rows.
Updated: DESIGN.md, BRAND.md (app-logo wrapper rule), visual-motifs.md
(implementation section).
2. Illustration direction — explicit break from current style
User provided 6 reference images of the current conduction.nl
illustration style. I was wrong about it being line-based. The
current style is actually:
- Filled-shape flat vector characters (Freepik/Vectorjuice/
Upklyak-family stock illustration style)
- Detailed faces (pupils, teeth, shaded eyebrows)
- Shading within colors (hair highlights, clothing folds)
- Tilted colored background rectangles (light blue, yellow, orange)
- Hex-portrait variants already on-brand (cobalt hex frames with
the character inside, pointy-top — confirming orientation rule)
User explicitly rejects continuing this style. Three reasons I
articulated for why we move on:
(a) feels too stock — the band, the people-with-folders, the
man-pointing-at-himself could sit on any SaaS/consultancy site
(b) too-detailed faces pull attention to the people, away from the
apps (product-first positioning mismatch)
(c) not reproducible without Freepik-marketplace dependency —
every new illustration becomes a hunt-for-matching-asset
which guarantees inconsistency over time
Four fresh directions proposed with pros/cons/risks/reference:
- A. Hex-first geometric (RECOMMENDED) — illustrations built
from hexagons and primitives, no humans, cobalt-dominant with
KNVB orange accents. Max brand consistency, zero stock risk,
infinitely reproducible by AI or human, distinctive (nobody
else builds illustration language from hexagons). Risk: can
feel cool — mitigated by warm typography and orange accents.
- B. Minimal line-art characters (RECOMMENDED AS SECONDARY) —
outline-only human figures, Open Peeps family. For About/
testimonials/team moments where humans are essential. CC0
licensed via Open Peeps.
- C. Editorial / paper-cut — sophisticated, NYTimes-cover feel.
Distinctive but may read too highbrow for MKB audience.
Requires illustrator.
- D. Riso / two-color print — indie-craft feel. Fits OSS community
vibe. Risk: trendy, may age. Requires tooling.
My recommendation: A primary + B secondary (for human-specific
moments only). Rejected C and D as primary because they limit
reproducibility.
Added two master-briefing-texts (one per direction) suitable for
Midjourney/DALL-E prompts or freelance illustrator briefings. Also
documented licensing for each direction.
The hex-portrait concept from the current images (hexagonal frame
with character inside, cobalt background) is KEPT — it's on-brand
and pointy-top. Only the character-style inside is reworked
to the new direction.
Three open questions for user to resolve before first mock:
- Confirm A+B as the direction (or pick different)
- AI vs illustrator for first batch
- Estimate of MVP illustration count (~8-12)
User asked for concrete examples of each of the four illustration directions. Since I can't generate images, this adds a new appendix section to visual-motifs.md with: - 4-6 real websites/brands per direction whose illustration style matches (with direct links), so the user can click and visually inspect each direction - Pinterest/Dribbble tag links per direction for broader exploration - 4-6 concrete Conduction-specific scenes described for each direction, showing what "our" illustrations would look like - A ready-to-paste Midjourney/DALL-E prompt per direction, so first-batch generation can happen immediately without further prompt engineering Per direction: - A. Hex-first geometric: honeycomb.io, supabase.com, hashicorp.com, fly.io, cloudflare.com, plausible.io, prisma.io. Scenes: homepage ecosystem constellation, WOO-compliance fragmentation-to-consolidation, About values grid, Support tier-stacks, 404 "lost in grid", footer background pattern. - B. Minimal line-art characters: openpeeps.com, Icons8 outline, Storyset Line Color, linear.app. Scenes: About team portraits in hex-frames, testimonial avatars, Support two-paths illustration, Contact welcome figure. - C. Editorial/paper-cut: newyorker.com, Tom Froese, Malika Favre, Owen Davey, Charlie Davis. Scenes: homepage paper-cut hero with layered hex shapes and orange sun, abstract Nederland paper-cut, Zaakafhandeling abstract office scene, blog post editorial headers. - D. Riso/two-color print: risotto.studio, riso.party, People of Print, obsidian.md, drawdown.org. Scenes: two-color hex constellation hero with misregistration, riso-tinted solution icons, riso blog character illustrations, OSS-community merchandise. Also adds a "Hoe deze voorbeelden te gebruiken" subsection explaining three workflows: (1) direct-to-execution if A+B confirmed, (2) moodboard comparison if still deciding, (3) external illustrator briefing with the master prompts.
…omb platform-overview pattern
Uses Playwright to capture real reference screenshots from each
direction's exemplar sites, saved locally so the brief is self-
contained (no broken image links if external sites change).
Six screenshots added to briefs/website/references/:
- ref-a-honeycomb-3d-platform.png — Honeycomb.io's 3D-isometric hexagon-
prism platform overview. This is THE reference for our homepage hero
(the user specifically called it out as "extreem sterk").
- ref-a1-honeycomb-section-3400.png — Honeycomb's flat horizontal
variant of the same data-flow. Reusable for app-detail and
solution-landing pages.
- ref-a-supabase-hero.png — Supabase typography-led hero (richting A
alternative).
- ref-b-openpeeps.png — Open Peeps showcase of line-art characters
(richting B).
- ref-c-tomfroese-work.png — Tom Froese's editorial portfolio grid
showing variation within editorial illustration (richting C).
- ref-d-risotto.png — Risotto Studio riso prints and stationery
(richting D).
Major additions to visual-motifs.md:
1. Upgraded homepage hero recommendation from "Ecosystem constellation
(B)" to "Isometric platform overview (C, Honeycomb-style)" —
stronger because it communicates how all apps interconnect in one
visual, which is our primary differentiator.
2. New major section "Platform overview pattern — Honeycomb-stijl als
hero" with:
- Embedded screenshot of Honeycomb's 3D platform
- Analysis of what makes it work (data-flow left-to-right,
prismatic extrusion, pastel category colors, feature-labels
inside hexes, external boxes for sources/integrations)
- Concrete Conduction-translation: 6 category-hexes (Data
Foundation / Integration / Documents / Case & Process /
Insights & Dashboards / Design & Theming) with our 11 core apps
grouped inside; external "Your systems" box on left (Nextcloud,
BAG, BRK, PDOK, Common Ground components), "Integrations" box on
right (Nextcloud app store, gov portals, LLMs); dashed data-flow
lines between categories
- Implementation options (SVG interactive, Lottie, pure HTML+CSS
with SVG hex components — recommends HTML+CSS SVG for
simplicity, a11y, progressive enhancement)
- Flat sub-variant reuse for app-detail, solution-landing, About
3. New richting A sub-variants:
- A1 — Flat (2D hex compositions for solution illustrations, icons,
404, empty-states)
- A2 — Flat-isometric (extruded prisms for platform/architecture
diagrams). Explicitly called out as "technisch nog steeds flat"
— no photorealistic 3D, no lighting, no gradients. That keeps us
consistent with our anti-lijst (no 3D).
4. "Voorbeelden per richting" section now has embedded local screenshots
per direction (A: Honeycomb 3D + Honeycomb flat + Supabase;
B: Open Peeps; C: Tom Froese work grid; D: Risotto Studio) so the
designer can see references immediately without following external
links.
The richting A + B primary/secondary recommendation stands, now
upgraded with A's sub-variants (A1 for general illustrations, A2 for
the hero platform-diagram). Awaiting user confirmation of direction
choice, illustrator-vs-AI for first batch, and MVP illustration count.
…rompts, add Claude Design handoff
Three coupled additions in response to user answers:
1. Richting: A2 only (flat-isometric hex-prism). Dropped B.
2. Production: Midjourney for first batch.
3. MVP count: 10-12 illustrations confirmed.
Plus: user asked for the exact prompt + document references to hand
to Claude Design for the first homepage mock.
1. visual-motifs.md — A2 locked as THE illustration direction
- Replaces the A+B recommendation with a single A2 decision
- Drops richting B (minimal line-art) as secondary
- Handles "human moments" via three fallback options:
abstract hex-figures, blanked hex-portraits, or skip-humans-
entirely (chosen for first iteration — team via text only,
testimonials without avatars)
- Open vragen section replaced with a "Beantwoorde vragen"
section capturing the 3 locked decisions
- Nederlaag-scenario documented: if A2 doesn't yield enough
character after 2-3 Midjourney iterations, we reconsider a
secondary spoor for 1-2 specific use-cases
2. illustration-batch-1.md (new) — 12 specific MVP illustrations with
ready-to-paste Midjourney prompts
Master-prompt defined once with the A2-style boilerplate (flat-
isometric, pointy-top hexagons, cobalt #21468B + KNVB orange
#F36C21 + pastel category-colors, no humans, no gradients, no 3D,
--style raw). Per scene: exact Midjourney prompt, placement,
aspect ratio, and post-production notes (labels to add in Figma,
exact hex-values to fix if Midjourney is off).
Scenes: 1) homepage hero platform overview, 2-5) four value-
teasers (open source / own Nextcloud / no lock-in / NL Design),
6-8) three solutions (WOO / Org register / Zaakafhandeling),
9) About hero, 10) 404, 11) empty-state, 12) Support teaser.
Production workflow included: generate all 12 in one session,
pick variant per scene, upscale, Figma post-production, export
SVG + PNG @2x to brand/assets/illustrations/ for company-wide
reuse. Review checklist confirms 9 criteria per illustration.
3. claude-design-handoff.md (new) — THE answer to "which prompt with
which references do I give Claude Design"
Structured as a ready-to-paste master prompt that tells Claude
Design:
- What to build (static HTML+CSS mock of homepage, no React, no
build-step, pixel-accurate at 1440/768/375 breakpoints)
- Which 11 documents to read and in what order (BRAND.md,
DESIGN.md, tokens.json, website.md, visual-motifs.md, app-
taglines.md, platform-benchmarks.md, support-model.md,
services-model.md, tone-samples.md, plus references/ folder
and illustration-batch-1.md)
- Hard constraints (cobalt-only, hex always pointy-top, no
upgrade-druk, no "Try it free"-CTAs, no add-to-cart, MKB-direct
tone, no banned words like "digitale transformatie")
- Homepage structure in 7 sections
- Exact header and footer content
- Output requirements (single index.html + styles.css, SVG hex
primitives, responsive, Lighthouse 90+, no external deps)
- Three-step feedback loop (summary → mock → list of implicit
scope-B decisions made)
- Iteration model (section by section, homepage first)
Plus a section on order of page-types to iterate (homepage → app-
detail → apps-catalogus → solution-landing (WOO) → solutions-
catalogus → support → services → about → contact → 404).
Plus troubleshooting section for common Claude Design outputs:
generic SaaS feel, inconsistent hexagons, too-formal tone.
4. DESIGN.md — adds "Illustratie-stijl — gekozen richting" subsection
under the hexagon motif section. Documents A2 as the company-wide
illustration style (applies to website, drukwerk, presentations,
app-UIs), with key characteristics and pointer to batch-1.md for
production prompts.
5. briefs/website/README.md — index updated with visual-motifs.md
(new A2 locked note), illustration-batch-1.md, claude-design-
handoff.md, and references/ folder entry.
At this point the brief is handoff-ready: the user can paste the
master prompt from claude-design-handoff.md into a new Claude session
and expect a first homepage mock without further context-engineering.
…+foreignObject, not rasterized
Used Playwright to inspect how honeycomb.io builds their platform
overview diagram (the one the user highlighted as "extreem sterk").
Confirmed it's a hand-built SVG with HTML overlays, not an image or
animation library. This has concrete implications for how we build
ours.
Technical findings:
- Single <svg viewBox="0 0 1290 780"> with responsive wrapper
- 119 <path> elements for hex-prism geometry (each prism = multiple
paths for the top, left, and right isometric faces, creating depth
via three tonal variants of the same pastel color)
- 77 <rect> elements with rounded corners for external info-boxes
("Your Data Sources", "60+ Integrations") and pill-containers
- 8 <foreignObject> elements containing HTML <div>+<span> pills as
feature-labels inside each category hex. This is the key trick:
SVG for geometry, HTML-in-SVG for accessible text labels.
- 87 elements with cursor:pointer — pills are <a> elements linking
to sub-pages (/platform/distributed-tracing etc.)
- CSS transitions (Tailwind transition-colors) for hover, 150ms.
No JS animation library needed.
- Category colors via own design-token palette (hc-sky, hc-green,
hc-purple, hc-gold, hc-red, hc-gray)
This is perfectly buildable by Claude Design as HTML+CSS+inline SVG.
Updated three documents to reflect this:
1. visual-motifs.md §Platform overview pattern — replaced the vague
"implementation options" with a concrete "Implementatie bevestigd
via reverse-engineering" section including pseudocode example
(inline SVG with <g> groups per hex-prism and <foreignObject>
containing HTML pill-<a>s). Lists advantages: crisp at any scale,
accessible (real <a> focus states), SEO-friendly, no JS
animation library required, i18n-ready via HTML-text not baked
image, editable without design tool. Notes what this is NOT
(not rasterized PNG, not Lottie, not React component library,
not external service).
2. illustration-batch-1.md §Scène 1 — adds an "UITZONDERING" warning
at the top: the homepage hero is NOT produced via Midjourney like
scenes 2-12. Instead, it's hand-built as inline interactive SVG
with foreignObject pills. Midjourney can still be used to generate
a visual reference image for composition/angle/palette, but the
final output is SVG. Includes concrete SVG-build instructions:
6 hex-prisms with Conduction category mapping, 3 paths per prism
for top/left/right isometric faces, external boxes for Your
Systems and Integrations, dashed data-flow paths.
3. claude-design-handoff.md §Homepage structuur — updated hero
section to be explicit: "interactieve SVG platform-overview (Honeycomb
style) — géén rasterized image, bouw direct als inline SVG met
foreignObject HTML pills". Also updated the document reference for
illustration-batch-1.md to note scene 1 is the exception.
Bottom line: Claude Design can build the full homepage including the
hero as one coherent HTML+CSS+SVG artifact — no Midjourney dependency
for the hero. Midjourney handles scenes 2-12 (smaller, simpler
compositions) where raster is fine.
…ee implementation variants
Deep technical reverse-engineering of how honeycomb.io builds their
platform-diagram, captured via Playwright across both / and /platform
in two sessions. Resolves the user question "is it the same way they
built it, including any libraries used?"
New: briefs/website/honeycomb-teardown.md (~600 lines, 7 sections)
Section 1 — Frontend stack (verified via DOM/script inspection):
- Next.js (App Router) + Turbopack bundler + React 18+
- Tailwind CSS with custom hc-* color tokens (hc-sky, hc-purple,
hc-gold, hc-red, hc-green, hc-cobalt, hc-denim, hc-gray)
- next/font module-CSS for self-hosted Roboto + Poppins
- VWO (Visual Website Optimizer) for A/B testing — different homepage
visitors see different variants (one with platform-diagram SVG,
another with Lottie AI-demo, with the diagram-section explicitly
display:none on the latter)
- Marketing/analytics: HubSpot, CookieYes, reCAPTCHA, hsforms, G2,
HockeyStack, Tooltip.io
- @lottiefiles/dotlottie-wc loaded — but ONLY for hero AI-demo,
NOT for platform diagram
Animation libraries explicitly NOT present:
- No Framer Motion (no framer-motion / motion-component markers)
- No GSAP / TweenMax / TimelineMax / ScrollTrigger
- No React Spring
- No AOS (no data-aos attributes)
- No tailwindcss-animate plugin
- No Three.js / react-three-fiber
What they DO use for animation:
- CSS transition-colors (Tailwind) — 22 instances on page
- Tailwind duration tokens: duration-50 / duration-200 / duration-300
- IntersectionObserver — for lazy mounting + entrance triggers
- Pure CSS keyframes for flow-line animation (likely on
stroke-dashoffset)
Section 2 — Three different implementations of the SAME diagram:
A. Inline SVG with foreignObject HTML pills (the WINNING technique,
captured in ref-a-honeycomb-3d-platform.png):
- viewBox 0 0 1290 780, 119 paths, 77 rects, 8 foreignObjects,
87 cursor:pointer elements
- Pills are real <a href> elements linking to /platform/* sub-
pages — accessible, focusable, navigation works without JS
- CSS transition-colors for hover, no JS needed
- Category colors via Tailwind tokens
- Pseudo-code example included
B. Static SVG-as-<img> (currently on /platform — INFERIOR):
- 361KB SVG file from Sanity CDN
- 995 paths with text baked as path-shapes (zero accessibility,
zero i18n, zero SEO benefit for the labels)
- Plus separate empty SVG overlay for animated flow-lines
- This is what we should NOT copy
C. Lottie via dotlottie-wc (homepage hero AI-demo):
- JSON file from Cloudinary
- Used for terminal-typing animation, not for the diagram
- Relevant for us only if we want a "demo loop" later
Section 3 — Why we choose Implementation A and how we map it to our
Docusaurus 3.x stack (table comparing Honeycomb's choices to ours).
Key insight: no JS animation library needed — same as Honeycomb.
Section 4 — Practical build checklist for Claude Design / illustrator:
- Step 1: composition sketch using ref-a-honeycomb-3d-platform.png
as anchor, mapping our 6 categories
- Step 2: SVG paths for hex-prism geometry (3 paths per prism, top/
left/right faces with three tonal variants of the same pastel)
- Step 3: foreignObject overlays per category with HTML pills as <a>
- Step 4: CSS pill styles with hover transitions
- Step 5: Optional IntersectionObserver entrance animation
- Step 6: A11y checklist (focus, role, aria, contrast, lang)
Sections 5-7: handoff implications, open questions (couldn't grab the
original interactive SVG source — Conduction will draw fresh
geometry anyway), and one-sentence conclusion.
Also captured a fresh screenshot of the current /platform state
(static-SVG-as-img variant) at:
references/ref-a-honeycomb-current-static-svg.png
Updates to claude-design-handoff.md:
Added a hard constraint: "Geen JS-animatie-bibliotheek toevoegen" —
no Framer Motion / GSAP / React Spring / AOS / tailwindcss-animate /
Three.js. Pure CSS transition-colors + IntersectionObserver is enough,
matching what Honeycomb uses. References honeycomb-teardown.md for
verification.
Updates to briefs/website/README.md:
Added honeycomb-teardown.md to the appendix index. Updated references/
folder description to note the new screenshot count (7).
…atic, spotlight effect via group-hover Follow-up to the Honeycomb teardown after the user asked specifically about the "cool component animation". Verdict via Playwright deep-dive: the diagram is opvallend stil — almost no animation at all. The one genuine interaction is a CSS-only spotlight via group-hover. What I verified by inspecting CSS keyframes, transitions, dashed paths, SMIL elements, and IntersectionObserver markers across the rendered SVG (revealed via VWO bypass through DOM display:block override): - Pills: only `transition-colors duration-150` (0.15s) on hover - Hex paths: `transition-all duration-150` with `group-hover:opacity-100` → the spotlight effect (hovered hex goes to 100% opacity, others stay at lower opacity) - Dashed flow-paths: `stroke-dasharray: 2.41px, 3.85px`, `stroke-dashoffset: 0px`, NO animation, NO transition. Static dashed lines — the "dots" you see are short stroke segments, not particles. - 0 circle elements in the diagram (the visual dots are stroke-dasharray segments, not separate animated <circle>s) - 0 SMIL animation tags (no animate / animateTransform / animateMotion) - 0 IntersectionObserver-driven entrance animations on the diagram - Page-level keyframes (fadeIn, ring, spin, accordion, logoScroll) exist but NONE are applied to diagram elements Two new reference screenshots: - ref-a-honeycomb-default-state.png: all hexes ~70% opacity - ref-a-honeycomb-hover-state.png: REALTIME ACCESS hex at 100% while others stay translucent — the spotlight effect New section "6.5 Animation analysis" appended to honeycomb-teardown.md (~150 lines): - Lists every page-level keyframe + which apply (none to the diagram) - Documents exact computed-style values for pills + hex-paths + dashed paths - Explains the group-hover spotlight mechanism with concrete recipe - Side-by-side default-vs-hover screenshot comparison - Calls out what is NOT animated (entrance, flow-lines, breathing, cycle, etc.) so we don't over-engineer - Concrete recipe for our version: <a class="group"> wrapping each category, hex-paths with group-hover:opacity-100, foreignObject pills with transition-colors. Plus optional 10-line IntersectionObserver entrance and optional 8-line stroke-dashoffset flow-line animation if we WANT to do more than Honeycomb does. - Aanbeveling-table: keep it light. Only spotlight (yes) + color-transitions (yes) + optional entrance fade (yes, subtle). Don't add hex breathing, auto-rotate, Lottie, or Framer Motion.
…/Extra/Integrations) User-proposed cleaner architecture replacing the earlier ad-hoc 6-category mapping (Data Foundation / Integration / Documents / Case & Process / Insights / Design). The 6-category version mixed architectural layer with feature-grouping; this 4-layer version separates "what kind of thing it is" from "what problem it solves". New: briefs/website/app-architecture.md (~280 lines) Layers: 1. Core (3 apps, central foundation cluster): - OpenRegister: data foundation - OpenConnector: integration gateway - DocuDesk: documents These are the 3 apps every Implementation depends on. 2. Implementations (~9-11 apps, ring around Core, user-facing solutions): - OpenCatalogi (federated catalog, WOO) - PipelinQ (CRM) - ZaakAfhandelApp (citizen-case-status) - Procest (case mgmt, VTH, forms) - MyDash (dashboards) - SoftwareCatalog (ITAM) - LarpingApp (worldbuilding) - DeciDesk (decision support) - ShillinQ (ERP — confirmed via DB product_line) - OpenWoo (?), NLDesign (?) — placement flagged for confirmation 3. Extra apps (3 apps, off-center, additions to the ecosystem): - OpenTalk (video, OpenTalk.eu) - Matrix (federated chat, matrix.org) - n8n (workflow automation, n8n.io) These extend the ecosystem without being primary Conduction products. 4. Integrations (external boxes left/right of the diagram): 4a. Nextcloud-platform: Mail, Calendar, Files, Talk, Office, Contacts 4b. External productivity: OpenProject, XWiki, GitLab, Mattermost 4c. NL-government source systems: BAG, BRK, PDOK, BRP, KvK, DSO Document includes: - Per-layer table with responsibility and dependencies - Full ASCII diagram showing data flow: source-systems → Core → Implementations → output-integrations, with Extra apps off-center - Implications for homepage-hero (replaces 6-cat in scene 1), apps-catalogus filter categories, app-detail "Where this fits" sections, and solution-pages stack-diagrams - 7 open questions for user confirmation: ShillinQ spelling, NLDesign placement, status of AssetDesk/BudgetQ/CareDesk/etc., Matrix vs Nextcloud Talk priority, Nextcloud Office classification, source- system roadmap, OpenWoo vs OpenCatalogi overlap Updated: - briefs/website/visual-motifs.md §Platform overview pattern: replaced the 6-category Conduction-translation table with the 4-layer mapping. Notes that the new version separates layer (what it is) from solution (what it solves) cleanly. - briefs/website/illustration-batch-1.md §Scene 1 hero: complete rewrite of the SVG-build instructions with the 4-layer placement: Core cluster in center (3 hexes), Implementations as ring around (8-9 hexes with pastel tints + per-app pills), Extra apps off-center (3 small tiles), source-systems left and integrations right. Includes per-app pill text (e.g. OpenRegister: "Schemas, Objects, Audit") so the SVG-builder has concrete labels not placeholders. References honeycomb-teardown.md §6.5 for the spotlight + transition-colors styling. - briefs/website/README.md: index updated with app-architecture.md description and §6.5 reference for honeycomb-teardown.md.
…oud kernel + ConNext branding Major architectural reframe based on user direction. Replaces: - 6-category mapping (earlier draft, mixed layer + category) - 4-layer architecture (Core/Workplace/Companion/Integrations) with a single coherent component-card model that mirrors Honeycomb's real diagram structure: one central kernel surrounded by peer components that each deliver a coherent capability bundle. Strategic narrative: ConNext is Conduction's proposition that develops Nextcloud from "office suite" into "workspace". The 6 component-cards around the Nextcloud kernel show what that extension contains. Six component-cards (peers, no hierarchy): 1. Technical Core — OpenRegister, OpenConnector, DocuDesk (the foundation Conduction provides) 2. Workplace App — OpenCatalogi, PipelinQ, Procest, ZaakAfhandelApp, DeciDesk, ShillinQ, MyDash, SoftwareCatalog, LarpingApp, OpenWoo (user-facing apps for concrete use cases) 3. AI — Automation, Agents, Intelligence (cross-cutting AI capability, parallel pillar to Core) 4. Integrated Apps — OpenTalk, Matrix, n8n, OpenProject, XWiki, GitLab, Mattermost (third-party OSS apps we integrate; replaces both "Companion apps" and the right-side-box of external integrations) 5. App Builder — Coming soon badge, in active development 6. Admin Tools — App-versions, Crontab (admin utilities, shown dimmed to signal supporting role, not primary product) Central kernel: Nextcloud (Files, Mail, Calendar, Contacts, Talk, Office, SSO/Apps). Visual: cobalt-to-Nextcloud-blue gradient hex, slightly larger than the surrounding component-cards, label "Nextcloud" in Nextcloud-blue. Left side-box only: bron-systemen (BAG, BRK, PDOK, BRP, KvK, DSO + Nextcloud-Files/Contacts as data substrate). Right side-box dropped — external productivity tools now live in the Integrated Apps card. Hero copy (working draft, to be confirmed): - Wordmark: ConNext (Con cobalt + Next Nextcloud-blue) with "by Conduction" subtitle and small Conduction-hexagon-avatar - H1: "Make Nextcloud your workspace, not just your office suite" - Lead: "ConNext is Conduction's set of open-source components that bring data, processes, AI, and integrations to your Nextcloud — turning a file-sync platform into your actual workplace." - Primary CTA: "Browse our apps" → /apps - Secondary CTA: "How does ConNext work?" (scroll to component-overview) Visual rules: - App Builder: Coming soon badge in KNVB orange (attention without alarm), aria-label for accessibility - Admin Tools: dimmed opacity / smaller hex to signal supporting role - Hex-prism uses 3 paths (top/left/right faces) with three pastel tints per category, group-hover:opacity-100 spotlight effect (per honeycomb-teardown.md §6.5), CSS transition-colors duration-150 on pill hover - Static dashed flow-lines from data-sources side-box to Nextcloud kernel, and from kernel to all component-cards - Subtle cross-component connectors between strongly-related pairs (e.g. Workplace App ↔ AI, Technical Core ↔ Integrated Apps) - No flow-line to Admin Tools or from App Builder yet Documents updated: - briefs/website/illustration-batch-1.md scene 1: complete rewrite with the 6-component spec, exact pills per component, side-box contents, App Builder Coming-soon badge styling, dimmed Admin Tools treatment - briefs/website/visual-motifs.md §Platform overview pattern: replaced 4-layer table with the new component-card table; clarified "no hierarchy, peer components"; documented Nextcloud-kernel visual treatment (cobalt-to-NC-blue gradient) - briefs/website/visual-motifs.md §Sectie 1 Hero: working-draft tagline added (workspace-thesis); confirmed isometric-platform-overview is the hero visual - briefs/website.md §6.1 Homepage: rewrote the hero subsection to reference the new 6-component diagram and ConNext branding; CTAs updated; "Solve a problem" replaced by "How does ConNext work?" (more directly addresses the architectural-explanation need) - briefs/website/app-architecture.md: prepended canonical 6-component table as 2026-04-28 reframe; flagged that the rest of the document still describes the older 4-layer version pending full rewrite Open items deliberately left for future doc-rewrite: - BRAND.md, DESIGN.md updates (ConNext as public brand, Nextcloud-blue as second brand color, "Next" coloring rules) - support-model.md, services-model.md (pricing-model implications of ConNext positioning) - claude-design-handoff.md (update with new architecture references) - NLDesign placement decision (own component, part of Technical Core, or cross-cutting overlay — TBD) - App Builder pill content at launch (Schema-driven / Low-code are placeholders) - Workplace App overflow (10 pills may not fit one hex — consider split-into-two or "View all" pill) - Hero-tagline final confirmation (working draft is option (e) workspace-thesis) - Exact Nextcloud-blue hex (working assumption #0082C9 — to verify)
…verlay, NLDesign Theme is the Workplace App Two different things, easy to confuse: 1. NLDesign-the-design-system (NL Design System tokens, accessibility, NL government standards) is an identity overlay across the entire ConNext site and every Conduction app. It's woven into typography, color tokens, components, accessibility patterns — not a component- card on the platform-overview-diagram. Comparable to Material Design not appearing as a component on Google Cloud's diagrams. 2. NLDesign Theme app is a real Conduction-built Nextcloud app that provides extensive theming/customization for a customer's Nextcloud instance (multiple selectable themes, deep customization). This IS a component-card pill, sitting in Workplace App alongside OpenCatalogi, PipelinQ, etc. Pill name "NLDesign Theme" chosen over "NLDesign" alone to disambiguate from the design system identity layer. Customer-facing language stays unambiguous. Updated: - briefs/website/illustration-batch-1.md scene 1: NLDesign Theme pill added to Workplace App pills list with inline note about the distinction - briefs/website/visual-motifs.md §Platform overview pattern: NLDesign Theme added to the Workplace App row; new explanatory table below the main components-table contrasts the two NLDesign-meanings. Updated "open points" note to reflect that overflow is now 11 pills (was 10) and recommend split-into-two-hexes or "View all" pill. - briefs/website/app-architecture.md preface: NLDesign Theme added to Workplace App row with one-sentence disambiguation note. Workplace App now has 11 pills in one hex, which is visually crowded. Split-strategy decision pending — to be resolved with user in next clarifying round.
…ical Core User clarification: NLDesign Theme and MyDash both provide foundational capabilities (theming, dashboards) used by every Workplace App. They belong in Technical Core, not Workplace App. Technical Core now has 5 foundational capabilities: - OpenRegister (data foundation) - OpenConnector (integration foundation) - DocuDesk (document foundation) - NLDesign Theme (theming foundation) - MyDash (dashboard foundation) Each Core pill maps to one foundational capability that Workplace Apps build on. Clean conceptual model. Workplace App drops to 9 pills (was 11 with NLDesign Theme), making the visual crowding problem less acute. Split-strategy still on the table if growth pushes past 10. Updated: - briefs/website/illustration-batch-1.md scene 1: Technical Core gets capability-labels per pill (data, integratie, documenten, theming, dashboards). Workplace App pills list trimmed. - briefs/website/visual-motifs.md §Platform overview pattern: same reorganization in the components-table; updated open-points note to reflect 9 pills (was 11) and de-prioritized split-strategy. - briefs/website/app-architecture.md preface: same reorg in the canonical 6-component table.
Working-draft markers verwijderd; tagline + lead bevestigd: H1: Make Nextcloud your workspace, not just your office suite Lead: ConNext is Conduction's set of open-source components that bring data, processes, AI, and integrations to your Nextcloud — turning a file-sync platform into your actual workplace. Plus inline-noot toegevoegd over de Nextcloud-blauw-markup-conventie voor 'Nextcloud' (en idiomatische 'next') per vraag-5-(c)-rule.
User clarification: App Builder is a vital ecosystem component (own card, not subordinate). It's a UI that uses the Technical Core to: (a) let clients build their own (mini) Nextcloud apps (b) customize existing ConNext apps to fit their workflow Strategic message: 'the client is always right' translated directly into 'the client can modify the software themselves'. Empowerment positioning, not just a feature. Pill content (3 customer-facing capabilities): - Build your own — new mini-Nextcloud apps from scratch - Customize ConNext apps — modify existing apps without Conduction-dev - No code, just configure — UI-driven, no programming required Tagline that goes prominently on the App Builder detail-page: "The client is always right — and now they have the tools to make it true." Replaces the earlier placeholder pills (Schema-driven / Low-code / TBC). 'Coming soon' badge stays — App Builder is in active development. Updated: - briefs/website/illustration-batch-1.md scene 1: App Builder section rewritten with the 3 capability-pills + strategic narrative + tagline - briefs/website/visual-motifs.md §Platform overview pattern: App Builder row in components-table updated with pills + status note - briefs/website/app-architecture.md preface: same update; tagline added below the table for canonical capture
…kernel-hex Verified via nextcloud.com/brand: - Nextcloud Blue (primary): #0082C9 (RGB 0,130,201 · HSL 201/100/39 · Pantone 285C) - Nextcloud Gradient (official): #0082C9 → #1CAFFF (45°) Updated the Nextcloud-kernel visual treatment in: - visual-motifs.md: components-table now lists the kernel with the official Nextcloud gradient. Body description updated to use the Nextcloud-official gradient on the top-face (respects their brand identity) plus cobalt #21468B on the left/right faces (Conduction-context). Composition meaning made explicit: 'Nextcloud is the kernel, Conduction is what surrounds it.' - illustration-batch-1.md scene 1: kernel SVG-build instructions rewritten with the same gradient-top + cobalt-sides treatment. Compositional interpretation note added for the illustrator/Claude Design. This honors Nextcloud's brand without colonizing it (their blue stays on top), while clearly positioning ConNext as the surrounding Conduction-product (cobalt on the sides + on every component-card). Pending: brand/tokens.json should add 'color.nextcloud.blue' (#0082C9) and 'color.nextcloud.cyan' (#1CAFFF) tokens for cross-surface use, plus the gradient as a reusable token. To be done in the larger ConNext-rebrand doc-rewrite alongside BRAND.md/DESIGN.md updates.
Hernoemt de pricing-categorieën van de oude ad-hoc Foundation/Core/ Ondersteunend-indeling naar de canonieke ConNext-component-cards (Technical Core / Workplace App / AI / Integrated Apps / App Builder / Admin Tools). Pricing-getallen blijven placeholder; de structuur reflec- teert nu dezelfde architectuur die op de hero-diagram zichtbaar is. Belangrijkste wijzigingen: - Technical Core (5 apps) — mid-to-high prijspunt: OpenRegister, OpenConnector, DocuDesk, NLDesign Theme, MyDash. Indicatief: Standard €15-20/user/year, Premium €30-40/user/year. NLDesign Theme en MyDash verschoven van 'Ondersteunend' naar Technical Core (consistent met nieuwste architectuur waar zij foundationele capabilities leveren). - Workplace App (9 apps) — mid prijspunt: OpenCatalogi, PipelinQ, Procest, ZaakAfhandelApp, DeciDesk, ShillinQ, LarpingApp, OpenWoo, SoftwareCatalog. Indicatief: Standard €10-15/user/year, Premium €20-30/user/year. Inclusief use-case-kolom per app. - AI (capability-bundel) — pricing TBD. AI is cross-cutting, niet per-app. Komt eigen mechanisme zodra producten landen. - Integrated Apps — Conduction levert GEEN directe Support op deze third-party apps (OpenTalk, Matrix, n8n, OpenProject, XWiki, GitLab, Mattermost). Wat we wel leveren: integratie-laag-Support via OpenConnector. Klanten die Support op die apps zelf willen worden doorverwezen naar de respectieve maintainers. - App Builder — Coming soon. Pricing TBD bij launch (verwacht: per organisatie i.p.v. per user, vergelijkbaar met low-code platforms). - Admin Tools — gratis open-source add-ons, geen Support-tier. Community- supported via GitHub Issues. Toegevoegd onderaan: 'ConNext Platform-tier (toekomstige optie)' — een all-in tier die alle Core + Workplace Apps in één bundel dekt. NIET introduceren bij launch — eerst luisteren of klanten erom vragen, dan toevoegen. Tot die tijd: per-app + 20% bundel-korting. Rekenvoorbeeld bijgewerkt om de nieuwe categorisering te reflecteren (OpenRegister Core, OpenCatalogi Workplace, DocuDesk Core). Algemene voorwaarden (minimum users, bundel-korting, named user, jaar- contract) ongewijzigd.
… tokens.json, handoff, services, website brief)
Complete rebrand pass following all the strategic decisions made over
the last clarifying-questions sessions. ConNext is now the canonical
public product-brand. Conduction stays prominently visible as the
company. Nextcloud-blue is added to the design system as a guest-color
for ConNext-context. The huisstijl is shared between ConNext-product
and the future-refreshed Conduction-corporate site.
1. brand/tokens.json — new tokens
Added under color.primitive:
- nextcloud.blue: #0082C9 (Nextcloud's official primary, RGB 0,130,201)
- nextcloud.cyan: #1CAFFF (gradient endpoint)
Added under color (top-level, not under primitive):
- color.brand.nextcloud reference: points at nextcloud.blue, with
description explaining when to use it (ConNext-wordmark Next-part,
Nextcloud brand-citation in copy, kernel-hex on platform diagrams)
Added under gradient (new top-level node):
- gradient.nextcloud: linear-gradient(45deg, #0082C9, #1CAFFF) —
Nextcloud's officiele brand-gradient, used for the Nextcloud-kernel
hex top-face on platform-overview diagrams
JSON validates.
2. BRAND.md — major additions
New §"ConNext — onze publieke productbrand" with 5 subsections:
- "De relatie in één regel": ConNext is a Conduction proposition for
Nextcloud. Three brands in triangle: Conduction (company),
ConNext (product-brand), Nextcloud (host platform).
- "Hernoeming van ConNext (intern → publiek)": ConNext was internal
name for AI-pipeline (Specter+Hydra+Medusa); per 2026-04-28 that
pipeline is renamed RAD, ConNext freed for public productbrand.
- "Wat ConNext concreet betekent voor klanten": full enumeration of
6 component-cards rondom Nextcloud-kernel.
- "ConNext-wordmark": pure typography, Con cobalt + Next Nextcloud-
blue, no icon, with "by Conduction" subtitle + Conduction-hexagon-
avatar in lockup.
- "Domein": connext.conduction.nl subdomain.
- "Conduction-huisstijl is gedeeld": one huisstijl, two sub-brands
(ConNext-product wordmark, Conduction-corporate hexagon-avatar).
Updated §"Kleurpalet" table with two new rows:
- Nextcloud Blue (#0082C9) with use-cases
- Nextcloud Cyan (#1CAFFF) — only as gradient-endpoint
New §"'Next' in Nextcloud-blauw — markup-conventie" with:
- Three places blue is applied (wordmark, "Nextcloud" citation,
idiomatic "next" referring to Nextcloud-as-platform)
- Three places it's NOT applied (generic "next page", letter-strings
within other words, decoration without brand-meaning)
- Markup examples per use case
3. DESIGN.md — major additions
New §"Nextcloud-blauw #0082C9 als secundaire brand-kleur (voor
ConNext-context)":
- Why we include Nextcloud-blue (we cite, not claim — designed
equivalent of "powered by Nextcloud")
- Official values table (hex, RGB, HSL, Pantone)
- Three strict use-rules (wordmark, copy, kernel-hex)
- "Niet toepassen op" list
- Cobalt-vs-Nextcloud-blue role distinction (cobalt 70%+ of brand
color, Nextcloud-blue ~5% on targeted moments only)
New §"ConNext-wordmark — typografische keuze":
- Why pure typography over icon (typographic color-shift does the
brand work; Conduction hexagon already exists; simplicity scales;
fits tech-product category like Stripe/Linear/Vercel)
- Typographic details (Figtree bold/semibold, light kerning,
CamelCase with capital N)
- Lockup-context with "by Conduction" subtitle and Conduction-
hexagon-avatar
4. briefs/website/claude-design-handoff.md — handoff updated
- Opening: "www.conduction.nl" → "connext.conduction.nl" + ConNext
three-brand framing (Conduction company, ConNext propositie,
Nextcloud platform)
- Foundation reading list expanded:
· BRAND.md description includes ConNext-wordmark spec + Next-
blue markup-conventie
· DESIGN.md description includes Nextcloud-blue + ConNext-wordmark
typografische keuze
· tokens.json description mentions new Nextcloud tokens
- Website-specific reading list expanded from 7 to 13 documents,
adds app-architecture.md and honeycomb-teardown.md as critical
- Hard-constraints "Kleuren" rule updated: Nextcloud-blue and
Nextcloud-cyan now allowed in ConNext-context (3 specific places),
proportion-table includes 5% Nextcloud-blue
- Homepage hero section completely rewritten to reflect 6-component
architecture (was old Data Foundation/Integration/etc.):
· Nextcloud-kernel center with Nextcloud official gradient on
top-face, cobalt sides, Files/Mail/Calendar/Contacts/Talk/
Office/Apps&SSO pills
· Six surrounding cards: Technical Core, Workplace App, AI,
Integrated Apps, App Builder (Coming soon badge), Admin Tools
(dimmed)
· Side-box left only (Your data sources)
· Hover-spotlight via group-hover:opacity-100
· ConNext wordmark + by-Conduction lockup above
· Final hero-tagline + lead with span class=next-blue markup
on "Nextcloud" occurrences
· CTAs: "Browse our apps" + "How does ConNext work?"
5. briefs/website/services-model.md — light update
Added brand-context note at top: Services contractually delivered
by Conduction (legal entity), positioned as discrete offer around
the ConNext ecosystem. Services-page note adjusted: 'Conduction
levert Services rondom het ConNext-ecosystem' — not 'ConNext biedt
Services'. Pricing model unchanged.
6. briefs/website.md — header updated
Title: "Website Design Brief — connext.conduction.nl (2026, ConNext
public site)" with brand-update banner explaining the 2026-04-28
shift. §1 doel updated: "een nieuwe connext.conduction.nl (de
ConNext-site) die bezoekers zo kort mogelijk naar de Nextcloud
app store leidt."
What is NOT in this commit (deliberate):
- Full search-and-replace of "Conduction" → "ConNext" throughout briefs.
Done lightly only where strategic: the brief still references
Conduction-the-company appropriately, and ConNext-the-product where
appropriate. A heavier sweep can come if needed.
- Updates to other website/* docs (app-taglines, app-architecture,
illustration-batch-1, visual-motifs, support-model, honeycomb-teardown,
platform-benchmarks, tone-samples, icon-library) — those were already
updated in earlier commits during the iterative architecture process.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduces the Conduction 2026 brand system — a shared source of truth for colour and typography that all Conduction apps can consume. Ships three deliverables:
brand/— DTCG tokens (tokens.json), usage docs, and logo SVGsWhat's in scope
Scope A only: colours + typography. Spacing, radii, shadows, motion and componenttokens follow in later rounds once apps need them.
Colours (from the official Dutch flag)
#21468B#FF7F00#AE1C28#FFFFFFCobalt is darker than our previous blue — signals trust and seriousness. Windmill orange (not Rijkshuisstijl orange) keeps us distinct from government styling. Vermillion is reserved for status/error.
Typography
Logo
Hexagon-in-hexagon avatar preserved; recoloured to cobalt. Three variants in
brand/assets/:avatar-conduction-on-white.svg— defaultavatar-conduction-on-blue.svg— inverse (hero, dark backgrounds, social)avatar-conduction.svg— transparent (flexible)Design decisions worth reviewing
Full rationale in DESIGN.md, but the three calls that benefit from second opinions:
theme-conduction-2026) that aligns with NLDS where possible, rather than extending an NLDS theme directly. Keeps us recognisable as a company, not a government dienst.What's explicitly NOT in this PR
Test plan
brand/tokens.jsonis valid DTCG JSON (python -m json.tool brand/tokens.jsonor any DTCG parser)profile/README.mdlink additions render on the org landing page preview