feat: redesign — one message, one audience, light pages
CI / TypeScript — type-check (push) Successful in 18s
CI / Publish — build & push image (push) Skipped
CI / TypeScript — type-check (pull_request) Successful in 17s
CI / Publish — build & push image (pull_request) Skipped

The site felt old, unfocused and bloated: 11 pages, a features page of 171
bullets, a homepage of 830 words in card grids around seven mockup-style
screenshots, and no single thing it wanted a visitor to understand.

- Message: control instead of drift. Audience: IT departments in small and
  mid-sized companies. Goal: buy a licence — netOrk itself is free, the
  licence adds vulnerability data and image updates.
- Home is under 400 words: the drift comparison of a real access point, three
  steps, the hardware it runs on, vulnerabilities with a licence, what else is
  in the box, one closing band. Features, Drivers and Roadmap are gone; their
  URLs redirect (router and nginx 301).
- New Pricing page: the free core, Starter / Pro / Enterprise on request with
  the plan differences from the licence server, four questions; buttons go to
  the licence portal. The unit-less KB request limit is left out.
- Persona pages are one template; NIS2 and Plugins are cut to half or less.
  Impressum and Datenschutz exist as marked placeholders; the unsupported
  "MIT licence" claim is gone from the footer.
- Look: light paper and ink, the dark product on a stage, Inter self-hosted,
  split sections and ruled lists instead of cards. Four real, cropped
  screenshots replace eight full-window ones.
- Language follows the browser until someone chooses; <html lang> is set.
  Scroll-to-top on navigation, a catch-all route, no dead /docs/architecture.
- CLAUDE.md, DESIGN.md, PAGES.md and PRODUCT.md describe the new rules.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Christian Manivong
2026-09-29 23:24:49 +02:00
co-authored by Claude Opus 5.5
parent 369f66afdc
commit f70fec496a
35 changed files with 1698 additions and 2716 deletions
+78 -437
View File
@@ -1,442 +1,83 @@
# netOrk Website — Page Structure & Content Plan
# netOrk website — pages
This document defines every page of the website: its purpose, section
structure, and draft copy. Use this as the brief for implementation.
**Audience:** IT departments in small and mid-sized companies — a small team,
mixed hardware (OPNsense, HPE ProCurve/Aruba, TP-Link JetStream, OpenWrt,
Proxmox, Linux), NIS2 on the agenda. Service providers and IT support are
secondary and get their own page each.
---
**One message:** control instead of drift — define the desired state once;
netOrk notices every change, shows what deviates and puts it back.
## Page Overview
**One goal:** buy a licence. netOrk itself is free; the licence adds
vulnerability data and image updates.
| Route | Page | Priority |
All copy is in `src/i18n/translations.ts`, English and German (German uses
"ihr"). The language follows the browser until someone chooses. Every claim
must be backed by `docs/PRODUCT.md`; automatic fixing exists for access point
profiles, so the site says "every deviation", never "every device fixes itself".
## Word budgets (English, text in `<main>`)
`scripts/check/site.py` counts them; Home over budget fails the check.
| Page | Route | Budget |
|---|---|---|
| `/` | Landing (Home) | P0 — build first |
| `/features` | Full feature list | P1 |
| `/drivers` | Supported devices | P1 |
| `/docs/getting-started` | Installation guide | P1 |
| `/roadmap` | Roadmap — planned + under consideration | P1 |
| `/nis2` | NIS2 landing page — Art. 21 mapping, evidence, roadmap | P1 |
| `/docs/architecture` | Technical overview | P2 |
| `/plugins` | Plugin system | P2 |
---
## `/` — Landing Page
### Section 1 — Hero
**Purpose:** Answer "what is this?" in 5 seconds.
**Layout:** Full-width, centered. Heading + subheading + two CTAs + hero
screenshot below.
**Heading:**
```
Network orchestration
for heterogeneous infrastructure.
```
(`text-slate-100` for first line, second line in `text-sky-400` or keep
both `text-slate-100` — designer decides.)
**Subheading:**
```
netOrk discovers, monitors, and manages your routers, switches, access
points, firewalls, and servers from a single UI — regardless of vendor.
No SaaS dependency. Runs on your infrastructure.
```
**CTAs:**
- Primary: `Get started →` → `/docs/getting-started`
- Secondary: `View features` → `/features`
**Hero visual:** Full-width screenshot of the device inventory page
(dark UI visible, framed with the browser chrome component from DESIGN.md).
---
### Section 2 — Problem Statement
**Purpose:** Make the pain relatable.
**Layout:** Single centered paragraph or short 3-column stat row.
**Copy:**
```
Managing a mixed network means juggling a different admin UI for every
vendor — one for OPNsense, one for HP ProCurve, one for OpenWRT, one for
Proxmox. Config changes happen directly on devices with no audit trail.
You find out something drifted when it breaks.
```
---
### Section 3 — Core Capabilities (3-up)
**Purpose:** Communicate the three main things netOrk does.
**Layout:** 3 columns, each with icon + heading + 2–3 sentences.
**Card 1 — Discover & Inventory**
- Icon: `MagnifyingGlassIcon`
- Heading: `Discover everything on your network`
- Copy: `ICMP sweep, SNMP scan, and HTTP probing find devices before you
add them. Fingerprinting identifies vendor and platform automatically.
Adopt results into your inventory with a single click.`
**Card 2 — Monitor & Alert**
- Icon: `ChartBarIcon` or `SignalIcon`
- Heading: `Poll device state continuously`
- Copy: `Every device is polled on a configurable interval via NAPALM.
Interface status, ARP tables, DHCP leases, VLAN membership, Docker
containers, and SNMP health metrics — all in one place.`
**Card 3 — Configure & Enforce**
- Icon: `WrenchScrewdriverIcon`
- Heading: `Detect drift. Fix it.`
- Copy: `Define desired state in netOrk. On every poll, device config is
compared against it. Drifted devices get a warning; a one-click fix
stream applies the correction and shows you live SSH output.`
---
### Section 4 — Driver Grid
**Purpose:** Show breadth of vendor support.
**Layout:** Centered heading + wrapping badge grid.
**Heading:** `Works with your hardware`
**Subheading:**
```
netOrk ships with custom NAPALM drivers for 11 device types, plus all
built-in NAPALM drivers. New drivers follow a documented registration
pattern.
```
**Badge list** (see `docs/PRODUCT.md` — driver table):
OpenWRT, OPNsense, Proxmox VE, Linux, HP ProCurve / Aruba, TP-Link Jetstream,
Netgear, Fritz!Box, Zyxel, OpenMediaVault, Sonos,
Cisco IOS, Arista EOS, Juniper JunOS
Each badge uses the `Driver / Integration Badge` component from DESIGN.md.
---
### Section 5 — Screenshot Walkthrough (alternating)
**Purpose:** Show the UI concretely. Six alternating image + text rows, each a
real screenshot from `scripts/screenshots/shots.py`. Copy lives in
`home.screenshot1`–`screenshot6` in `src/i18n/translations.ts`.
| Row | Heading | Screenshot |
|---|---|---|
| 1 | Device detail at a glance | `device-detail` — an access point, Networking → Interfaces |
| 2 | Intent-based VLAN and SSID management | `vlans` — VLAN list by site |
| 3 | A security assessment for every device | `device-security` — a server, Security → Assessment |
| 4 | One triage queue, decisions that hold | `vulnerabilities` — the triage queue |
| 5 | Dashboards you actually build | `dashboard` — the home dashboard |
| 6 | Service checks every minute | `service-checks` — Network → Service Checks |
Text sits left on odd rows and right on even rows; on mobile the text always
comes first.
---
### Section 5b — NIS2
**Purpose:** Hook for organizations evaluating netOrk in a NIS2 context.
**Layout:** Left column — label + Art. 21 mapping list. Right column — screenshot of the audit log (`audit-log`), the evidence the list refers to.
**Label (eyebrow):** `NIS2 · Art. 21` (sky-500, uppercase, tracking-widest)
**Heading:** `Evidence, not paperwork.`
**Copy:**
```
NIS2 Art. 21 mandates asset inventory, patch management, access control,
and audit trails as baseline technical measures. netOrk doesn't bolt on a
compliance layer — these are its day-to-day outputs.
```
**Art. 21 mapping (4 rows, icon = monospace article ref in sky-500):**
- Art. 21 (2e) → Patch & vulnerability management — Per-device update status, Wazuh CVE counts by severity
- Art. 21 (2h) → Asset management & access control — Full device inventory, RBAC with four roles, complete audit log
- Art. 21 (2a) → Risk analysis baseline — Config drift detection, SNMP health metrics, security agent coverage
- Art. 21 (2b) → Incident detection — Wazuh alert history, CrowdSec decisions, Graylog syslog per device
**Mock UI (right column):** `MockCompliance` — per-site checklist with ✓/⚠ rows, each showing label + detail stat. Label: `netork.local / compliance / HQ`.
---
### Section 6 — Plugin System (brief)
**Purpose:** Signal extensibility without going deep.
**Layout:** Dark card, left-aligned.
**Heading:** `Built to extend`
**Copy:**
```
Integrations (Wazuh, Graylog, CrowdSec, apt-cacher-ng) are plugins
that register into the plugin system — they can be enabled or disabled
per deployment without code changes. Adding a new integration follows
a documented pattern with a hook bus, typed metadata, and a plugin
registry.
```
**CTA:** `Plugin system docs →` → `/plugins`
---
### Section 7 — Deployment (quick)
**Purpose:** Answer "how do I run this?" without going into detail.
**Layout:** Code block + short description.
**Heading:** `Self-hosted. One command.`
**Copy:**
```
netOrk runs in Docker Compose. Five containers: API, two worker pools,
a Beat scheduler, and an nginx UI server. No external dependencies beyond
Redis and PostgreSQL.
```
**Code block:**
```bash
# Clone + configure
git clone https://gitea.example.com/netork/netork.git
cp .env.example .env
# edit .env (DB URL, Redis password, secret key)
# Deploy
bash scripts/deploy.sh 192.168.1.10
```
---
### Section 8 — CTA Footer
**Layout:** Centered, full-width dark section.
**Heading:** `Start managing your network.`
**CTA:** `Read the docs →` → `/docs/getting-started`
---
## `/features` — Full Feature List
**Purpose:** Comprehensive reference for people who want to evaluate in depth.
**Layout:** Vertical list of expandable sections (or just long-scroll with
sticky section nav). One section per capability area.
**Sections** (map directly to feature list in `docs/PRODUCT.md`):
1. Device Management
2. Discovery
3. VM Provisioning
4. Supported Drivers (full table)
5. Networking & Inventory
6. Configuration Management & Drift
7. Configuration Automation (Ansible)
8. Scheduled Operations
9. Satellite Deployments
10. Monitoring & Health
11. Dashboards
12. Security Integrations
13. DNS Management
14. RADIUS Management
15. Access Control (RBAC)
16. NetBox Sync
17. Compliance & Audit (NIS2)
18. Developer Experience
Each section: `text-xl font-semibold text-slate-200` heading +
feature items as a clean list with `text-slate-400` body.
---
## `/drivers` — Supported Devices
**Purpose:** One-page reference for "does netOrk support my device?"
**Layout:** Full table + short description per driver.
**Table columns:** Driver name | Device type | Capabilities | Status
**Capabilities** — checkmarks or tags for:
- `get_facts` `get_interfaces` `get_lldp` `get_vlans` `get_ssids`
`get_health_metrics` `get_docker` `scheduled_reboot` `config_push`
**Status:** `stable` / `beta` / `community` as a badge.
---
## `/docs/getting-started` — Installation
**Purpose:** Get someone from zero to a running instance.
**Sections:**
1. **Prerequisites**
- Docker + Docker Compose
- A PostgreSQL instance (or use the bundled profile)
- Redis
- A Linux host reachable by SSH from the server
2. **Quick start**
```bash
git clone ...
cp .env.example .env
# Edit .env
bash scripts/deploy.sh <server-ip>
```
3. **First run**
- Navigate to `http://<server-ip>`
- Complete the setup wizard (creates admin user)
- Add your first device
4. **Adding a device**
- Fill in hostname/IP, driver, and credentials
- Click Poll to verify connectivity
- Set a poll interval for continuous monitoring
5. **Next steps**
- Configure NetBox sync
- Set up Wazuh integration
- Enable scheduled reboots for OpenWRT APs
---
## `/roadmap` — Roadmap
**Purpose:** Show what's being built and what's under consideration. Signal NIS2 investment clearly.
**Layout:** Page header + two vertical groups ("Planned" / "Under consideration"), each a list of items.
**NIS2 badge:** `NIS2` monospace tag (sky-500/10 bg, sky-400 text, sky-500/20 border) inline next to item title.
**Intro copy:**
```
What's being built and what's being evaluated. Items tagged NIS2 directly
address NIS2 Art. 21 technical baseline requirements.
```
**Planned items (NIS2-tagged):**
- CVE tracking per device — NVD / OSV cross-reference
- Compliance dashboard — per-site Art. 21 checklist view
**Planned items (general):**
- Webhook engine — outbound events with HMAC signing
- Live job log streaming — WebSocket for all long-running tasks
- NetBox sync — manual trigger + status view
**Under consideration (NIS2-tagged):**
- Incident workflow — structured record + NIS2 Art. 23 Fristen-Tracker
**Under consideration (general):**
- mDNS scanner — media device discovery
- Prometheus + Grafana — metrics and dashboards
- Kubernetes Helm chart
---
## `/docs/architecture` — Technical Overview
**Purpose:** Give engineers the mental model before they look at code.
**Content:** Essentially the one-paragraph summary from `docs/PRODUCT.md`
expanded into a readable overview with the architecture diagram (ASCII or SVG).
**Sections:**
1. Overview (request → FastAPI → DB / Celery worker)
2. Driver system (NAPALM + custom drivers + registry)
3. Task queues (which queue does what)
4. Plugin system (register → hook bus → router mount)
5. Data model (UUID PKs, JSONB snapshots, intent-vs-state)
---
## `/plugins` — Plugin System
**Purpose:** Explain extensibility to potential contributors.
**Sections:**
1. What is a plugin? (metadata, router, tasks, hooks)
2. Built-in plugins (Wazuh, Graylog, CrowdSec, apt-cacher)
3. Writing a plugin (step-by-step with code snippets)
4. Hook bus (fire / call / transform)
5. Plugin registry and enable/disable
---
## `/for/*` — Persona Pages
**Purpose:** Answer "is this for me?" from the perspective of a specific
buyer/user, instead of one generic homepage pitch. Reachable via the "Für
wen" / "Who it's for" nav dropdown.
**Shared layout:** hero (icon + heading + sub) → "Your day today" pain-point
cards (persona-specific, concrete workflow friction) → feature-callout cards
(only shipped capabilities, cited from `docs/PRODUCT.md`) → CTA block linking
to `/docs/getting-started`. Same card/section classes as `/plugins`.
- **`/for/it-department`** — core admin/engineer audience. Pain points:
per-vendor admin UIs, no single inventory view, undocumented config
changes, manual SSH just to check state. Features: Device Management,
config drift + one-click fix, Git-backed config history, Ansible
automation, VM Provisioning, Dashboards. Plus a short supported-drivers
strip linking to `/drivers`.
- **`/for/it-support`** — day-to-day operators, less config depth. Pain
points: "is it up right now?", repeated manual reboots, no change record,
full admin access for one ticket. Features: warning system + dashboard
widget, one-click Ack, Wake-on-LAN, scheduled reboots/updates, filterable
audit log + export, roles scoped below engineer level.
- **`/for/msp`** — managed service providers, strongest standalone buying
case. Pain points: unreachable client sites, no cross-client view, proving
what was done, client data in someone else's cloud. Features: Satellite
Deployments, automatic routing around unreachable sites (with the honest
caveat that SNMP metrics + WebSSH still need direct reach), audit trail as
client-facing evidence, per-technician custom roles (**not** phrased as
per-site RBAC — netOrk's roles are global permission sets, not
site-scoped), self-hosted/no per-seat SaaS.
The existing `/nis2` page (security/compliance persona) is linked from the
same dropdown rather than duplicated.
---
## Global Layout
### Navigation (all pages)
```
[ netOrk ] Features Drivers Docs ▾ Für wen ▾ Plugins Roadmap [ Get started ]
```
`Docs ▾`: Getting Started / Architecture / NIS2 Compliance / Glossary
`Für wen ▾`: IT Department / IT Support / MSP / NIS2 Compliance (reuses the Docs dropdown's NIS2 link/label)
### Footer
```
netOrk — self-hosted network orchestration
Links: Resources: Legal:
Features Getting Started MIT License
Drivers Architecture Privacy (none collected)
Plugins Changelog
Roadmap NIS2
Glossary
For IT Departments
For IT Support
For MSPs
```
Footer background: `bg-slate-900 border-t border-slate-800`
Footer text: `text-sm text-slate-500`
| Home | `/` | 400 |
| Pricing | `/pricing` | 300 |
| NIS2 | `/nis2` | 550 |
| Plugins | `/plugins` | 450 |
| Persona ×3 | `/for/it-department`, `/for/it-support`, `/for/msp` | 320 |
| Getting started | `/docs/getting-started` | 80 |
| Glossary, Impressum, Datenschutz | `/glossary`, `/impressum`, `/datenschutz` | — |
Old routes redirect (in `App.tsx` and as 301 in `nginx.conf`): `/features` →
`/#included`, `/drivers` → `/#hardware`, `/roadmap` and `/docs/architecture` → `/`.
## Home
1. **Hero** — "Control instead of drift." The drift comparison of an access
point (`drift`, `drift-narrow` on phones) with a caption saying what is in it.
2. **How it works** (`#how`) — Define → Detect → Fix, three steps.
3. **Hardware** (`#hardware`) — two lines of names: "desired state and fixes"
and "inventory and monitoring"; a note on the untested NAPALM drivers.
4. **Vulnerabilities, with a licence** — the triage queue (`vulnerabilities`),
link to Pricing.
5. **Also in the box** (`#included`) — eight terms, one short line each; a NIS2
row with a link.
6. **Closing band** — "netOrk is free. The licence adds the data."
## Pricing
The free core as one row, then Starter / Pro / Enterprise, each "on request"
with a "Buy a licence" button to the licence portal (`src/data/plans.ts`). Plan
differences come from the licence server's plan defaults; the KB request limit
stays off the page until it has a unit. Four questions below, and the note that
there is no public installer yet.
## Persona pages
One template (`Persona.tsx`): header, three problems, five ways netOrk helps
(desired state and drift first), the shared closing band. The IT-department
page shows the drift screenshot. The service-provider page says where it
stops today.
## NIS2
Article by article (eight rows plus one "out of scope"), a dot and a word for
coverage, what netOrk records along the way, the audit log screenshot. States
plainly that netOrk does not make anyone compliant.
## Plugins, Glossary, Getting started, Impressum, Datenschutz
Plugins: the five included ones with the hosts they talk to, how to write one,
one code example. Glossary: every term from `src/glossary/terms.ts` with a
category index. Getting started: "no public installer yet", write to us.
Impressum and Datenschutz: **placeholders** — the final text must replace the
yellow box before netork.io goes live.
## Navigation and footer
Nav: wordmark · Who it's for ▾ · NIS2 · Plugins · Pricing · DE/EN · "Buy a
licence". Below `lg` a menu button. Footer: product links, persona links,
contact, "no cookies, no tracking, no requests to anyone else", © line with
Impressum and Datenschutz.