diff --git a/CHANGELOG.md b/CHANGELOG.md index 1ec1bdf..b260ef5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,19 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). ## [Unreleased] +### Changed — Design system: flatter, white-first look (v1) +- Surfaces go white: `--ds-bg-page` and `--ds-bg-subtle` are now `#ffffff`, with a light `--ds-bg-muted` (`#f4f6f6`) reserved for hover/disabled/neutral fills +- Subtler hairline borders (`--ds-border-default` `#e3e8e8`, `--ds-border-subtle` `#edf0f0`) and tighter radii (`md` 4→3px, `lg` 6→4px, `xl` 10→5px, `2xl` 14→6px) +- Tables are now flat: no header fill, no zebra striping — horizontal rules only, with a slightly stronger border under the header row +- Button/ghost hover and disabled-input/neutral-alert fills repointed from the now-white `--ds-bg-subtle` to `--ds-bg-muted` so they stay visible; `card-elevated` keeps its opt-in shadow +- Updated `tokens.md` reference table and radius scale to match + +### Added — Fælles Skabelonløsning Project +- Analysis and proposal for an open source alternative to DynamicTemplate (DSG Scenario 3) — built on open standards (ODF/DOCX/PDF) and shareable via OS2, addressing Aarhus Kommune's 2.464 templates and 10.000+ phrases +- Report (`index.md`) with background, eight core components, a Mermaid architecture diagram, open-standards landscape, the team's two caveats (glidende overgang + komplekse skabeloner) as a warning callout, open questions and success criteria +- Estimeringsnotat with a phased hour estimate (Fase 0 afklaring → 1 POC → 2 MVP → 3 fuld løsning), a dedicated Claude Code-acceleration section explaining where the estimate is reduced (and where it is not), and a drift/economics note +- Interactive admin-interface mock (`docs/public/projects/skabelonloesning/mocks/index.html`) visualising skabelonregister, frasebibliotek, a template detail with kolofon data and a complex guided input-flow (macro replacement), and a simulated dokumentmotor preview — design-system opt-in, client-side only + ### Changed — Whitelisted municipality sign-up (ai-bibliotek) - Sign-up's "Myndighed eller organisation" field is now a select limited to whitelisted municipalities, and registration enforces that the email domain matches the selected municipality's domain (shared `MUNICIPALITIES` list in `auth.js`) - Documented the intended access model in `index.md`: whitelisted email domains, account verification via email link on sign-up, and a per-domain admin who can delete and promote users (these remain design intent — the `localStorage` mock does not implement them) diff --git a/CLAUDE.md b/CLAUDE.md index ce5d42b..1942e01 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -52,6 +52,7 @@ Taskfile.yml # Task automation (dev, build, lint | `roboway` | Roboway | No | | `dansk-viden-til-dansk-ai` | Dansk Viden til Dansk AI | No | | `ai-bibliotek` | AI Bibliotek | No | +| `skabelonloesning` | Fælles Skabelonløsning | No | ## Conventions diff --git a/docs/.vitepress/sidebar.mts b/docs/.vitepress/sidebar.mts index c07ede6..e49c41f 100644 --- a/docs/.vitepress/sidebar.mts +++ b/docs/.vitepress/sidebar.mts @@ -119,6 +119,17 @@ const aiBibliotek: DefaultTheme.SidebarItem[] = [ }, ] +const skabelonloesning: DefaultTheme.SidebarItem[] = [ + { + text: 'Fælles Skabelonløsning', + items: [ + { text: 'Overview', link: '/projects/skabelonloesning/' }, + { text: 'Estimeringsnotat', link: '/projects/skabelonloesning/estimeringsnotat' }, + { text: 'Interactive Mocks', link: '/projects/skabelonloesning/mocks' }, + ], + }, +] + const designSystem: DefaultTheme.SidebarItem[] = [ { text: 'Design System', @@ -146,6 +157,7 @@ export function sidebar(): DefaultTheme.Sidebar { '/projects/roboway/': roboway, '/projects/dansk-viden-til-dansk-ai/': danskVidenTilDanskAi, '/projects/ai-bibliotek/': aiBibliotek, + '/projects/skabelonloesning/': skabelonloesning, '/projects/design-system/': designSystem, } } diff --git a/docs/index.md b/docs/index.md index 00307a3..6121449 100644 --- a/docs/index.md +++ b/docs/index.md @@ -50,4 +50,8 @@ features: details: Fælles bibliotek hvor danske myndigheder kan dele og hjemtage AI-assistenter — med katalog, søgning, modelkort, vidensopskrift og versioneret JSON-eksport, så lokale use cases kan skaleres nationalt. link: /projects/ai-bibliotek/ linkText: View project + - title: Fælles Skabelonløsning + details: Analyse og oplæg til et open source-alternativ til DynamicTemplate — bygget på åbne standarder og delbart via OS2. Med løsningsbeskrivelse, faseopdelt timeestimat og en interaktiv visualisering af administrationsgrænsefladen. + link: /projects/skabelonloesning/ + linkText: View project --- diff --git a/docs/projects/design-system/tokens.md b/docs/projects/design-system/tokens.md index a7049ed..1aa6300 100644 --- a/docs/projects/design-system/tokens.md +++ b/docs/projects/design-system/tokens.md @@ -77,10 +77,12 @@ shifts. | `--ds-text-secondary` | `--ds-gray-700` | | `--ds-text-muted` | `--ds-gray-600` | | `--ds-text-link` | `--ds-teal-600` | -| `--ds-bg-page` | `--ds-gray-50` | +| `--ds-bg-page` | `#ffffff` | | `--ds-bg-surface` | `--ds-white` | -| `--ds-bg-subtle` | `--ds-gray-100` | -| `--ds-border-default` | `--ds-gray-300` | +| `--ds-bg-subtle` | `#ffffff` | +| `--ds-bg-muted` | `#f4f6f6` | +| `--ds-border-default` | `#e3e8e8` | +| `--ds-border-subtle` | `#edf0f0` | | `--ds-border-focus` | `--ds-teal-500` | | `--ds-color-primary` | `--ds-teal-500` | | `--ds-color-success` | `--ds-green-500` | @@ -120,8 +122,8 @@ Line heights: `--ds-lh-tight` (1.25), `--ds-lh-snug` (1.4), ## Radii -`--ds-radius-sm` (3px), `--ds-radius-md` (6px), `--ds-radius-lg` (10px), -`--ds-radius-xl` (16px), `--ds-radius-2xl` (24px), `--ds-radius-pill` +`--ds-radius-sm` (2px), `--ds-radius-md` (3px), `--ds-radius-lg` (4px), +`--ds-radius-xl` (5px), `--ds-radius-2xl` (6px), `--ds-radius-pill` (fully rounded), `--ds-radius-full` (alias for `pill`). ## Shadows diff --git a/docs/projects/skabelonloesning/estimeringsnotat.md b/docs/projects/skabelonloesning/estimeringsnotat.md new file mode 100644 index 0000000..3b3bc9e --- /dev/null +++ b/docs/projects/skabelonloesning/estimeringsnotat.md @@ -0,0 +1,72 @@ +**Project:** Fælles Skabelonløsning · **Status:** Estimat (oplæg) + +# Fælles Skabelonløsning — Estimeringsnotat + +**Dato:** juni 2026 +**Projekt:** Open source-alternativ til DynamicTemplate (DSG Scenarie 3) +**Fase:** Analyse / oplæg + +::: warning Bemærkning +Notatet er bevidst holdt på et overordnet niveau. Det er et oplæg, ikke et tilbud — formålet er at give en størrelsesorden og efterlade manøvrerum i den videre proces. Estimaterne er grove og afhænger af de afklaringer, der er beskrevet i [hovednotatet](./). Scenarie 3 er, jf. DSG-indstillingen, det scenarie med størst usikkerhed. +::: + +--- + +## Overordnet estimat + +Estimatet er delt i faser, så projektet kan startes småt og udvides, efterhånden som koncept og behov afklares. Timetallene er **nedjusteret for udvikling med Claude Code** — se afsnittet [Claude Code-acceleration](#claude-code-acceleration) for antagelsen bag. + +| Fase | Indhold | Estimat | Tidshorisont | +|---|---|---|---| +| **Fase 0 — Afklaring** | Lagringsmodel (DMS vs. git vs. andet), standard for skabelon-/fraseformat, governance-model, strategi for komplekse skabeloner, fagsystem-snitflader, juridisk afklaring af deling | 120–200 t. | 1–2 mdr. | +| **Fase 1 — POC** | Dokumentmotor: JSON → DOCX/PDF på 1–2 reelle Aarhus-skabeloner, simpel datamodel, simpel lagring, test af krav om komplekse skabeloner | 250–400 t. | 1,5–2,5 mdr. | +| **Fase 2 — MVP** | Skabelonregister (versionering, rettigheder, publicering), frasebibliotek, adminmodul-UI, web-editor-integration (OnlyOffice/Collabora), første fagsystem-integration | 700–1.100 t. | 4–6 mdr. | +| **Fase 3 — Fuld løsning** | Integrations-API til Cura/GetOrganized/Modulus Social, Word add-in + LibreOffice-extension, komplekse skabeloner/input-flows, migreringsværktøj (2.464 skabeloner + 10.000 fraser), OS2-udgivelse | 1.200–2.200 t. | Løbende | +| **Sum (fase 0–2)** | | **1.070–1.700 t.** | **ca. 6–10 mdr.** | +| **Sum (fase 0–3)** | | **2.270–3.900 t.** | **ca. 12–18 mdr.** | + +### Anbefalet første skridt + +**Fase 0 + Fase 1** leverer afklaring og en fungerende POC, der opfylder succeskriteriet: data flettet ind i reelle Aarhus-skabeloner med DOCX/PDF-output, og en afklaring af, om motoren kan bære kravet om komplekse skabeloner. Estimat **370–600 t.**, tidshorisont **ca. 3–4 måneder**. + +Det giver et konkret beslutningsgrundlag for, om der skal investeres i fase 2 og 3 — uden at binde sig til hele løsningen på forhånd. + +--- + +## Claude Code-acceleration + +Udviklingsteamet anvender nu **Claude Code**, og estimaterne ovenfor er allerede nedjusteret for den produktivitetsgevinst. Gevinsten er konkret for netop dette projekt: + +- **Analyse af de eksisterende skabeloner og fraser.** En `.docx` er reelt en zip med XML (OOXML). De 2.464 skabeloner og 10.000+ fraser kan derfor udtrækkes, kategoriseres og analyseres programmatisk — fx hvilke placeholders, kolofon-felter og makroer der faktisk bruges. Claude Code er stærkt til at skrive og iterere på den slags udtræks- og analysescripts. +- **Migreringsværktøjet (fase 3).** Konverteringsscripts fra eksisterende skabeloner til det åbne målformat er gentaget, mønsterbaseret arbejde — netop hvor Claude Code accelererer mest. Det er den tungeste post i fase 3, og den hvor gevinsten er størst. +- **Scaffolding.** Dokumentmotor, REST-API, datamodel og adminmodul-UI har genkendelige mønstre, der kan stilladseres hurtigt med god testdækning fra start. +- **Test og dokumentation.** Testdækning og teknisk dokumentation kan genereres og holdes ved lige løbende. + +::: warning Hvor gevinsten ikke ligger +Claude Code accelererer **kode**, ikke **afklaring**. Fase 0 — governance, juridisk afklaring af deling af skabeloner/datagrundlag, fagsystem-snitflader og brugerdialog om den glidende overgang — drives af mennesker og er ikke nedjusteret. Det samme gælder verifikation af, at de migrerede skabeloner er korrekte: udtrækket kan automatiseres, men den faglige kvalitetskontrol kan ikke. +::: + +--- + +## Drift og driftsomkostninger + +En løsning af denne type er ikke et "byg og glem"-projekt. Den væsentligste langsigtede omkostning er **drift**, ikke selve udviklingen. Følgende skal afklares tidligt: + +- **Hosting og ejerskab.** Hvem driver og betaler for platformen — et OS2/fælleskommunalt fællesskab, en værtskommune eller en central aktør? Driften skal have en fast ejer, ellers forfalder løsningen. +- **Løbende vedligehold.** Sikkerhedsopdateringer, afhængigheder, brugerstyring og support koster typisk **15–25 % af udviklingsestimatet pr. år**. For fase 0–2 svarer det groft til **160–425 t./år**. +- **Migrering som engangs-storopgave.** Udfasning af DynamicTemplate vil — uanset scenarie — involvere medarbejdere i stort set alle afdelinger. Selve det tekniske udtræk kan automatiseres, men den faglige gennemgang og godkendelse af 2.464 skabeloner og 10.000+ fraser er en betydelig, manuel opgave. +- **Governance og kvalitet.** Delte skabeloner og fraser skal kunne reviewes — fagligt ejerskab, rettigheder og korrekthed. Det kræver en proces og dermed tid, ikke kun teknik. +- **Projektledelse.** DSG-indstillingen forudsætter en dedikeret projektleder til implementering (ca. **1 årsværk**) for scenarie 2, 3 og 4. Det ligger ud over udviklingsestimatet ovenfor. + +**Konklusion:** udviklingsomkostningen er en engangsinvestering; driften, governance og migreringen er løbende forpligtelser, der skal have et budget og en ejer fra dag ét. + +--- + +## Forudsætninger og forbehold + +- Estimaterne forudsætter genbrug af eksisterende ITKdev-fundament (auth, hosting-mønstre, design) og udvikling med Claude Code. +- De forudsætter, at en open source-dokumentmotor kan dække kravet om **komplekse skabeloner** (betingede felter, gentagelige sektioner, input-flows). Hvis ikke, vokser fase 1–3 markant — dette er den største enkeltstående usikkerhed og skal verificeres i POC'en. +- Lagrings- og versioneringsmodellen er uafklaret (git er uegnet til binære formater) og påvirker både fase 2 og driften. +- Fagsystem-integration (Cura, GetOrganized, Modulus Social) afhænger af systemernes API'er og af, om der overhovedet skal integreres eller bruges indbyggede løsninger — dette afklares i fase 0 og kan flytte væsentligt på fase 3. +- Migreringsvolumen (2.464 skabeloner + 10.000 fraser) er stor; estimatet antager, at en høj andel kan automatiseres, men den faglige verifikation kan ikke. +- Tallene er grove oplægs-estimater og skal kvalificeres i fase 0. diff --git a/docs/projects/skabelonloesning/index.md b/docs/projects/skabelonloesning/index.md new file mode 100644 index 0000000..6d18530 --- /dev/null +++ b/docs/projects/skabelonloesning/index.md @@ -0,0 +1,150 @@ +**Project:** Fælles Skabelonløsning · **Status:** Analyse / oplæg · **Date:** juni 2026 + +# Fælles Skabelonløsning + +**Et open source-alternativ til DynamicTemplate — en delbar skabelonløsning bygget på åbne standarder, som kan udvikles i fællesskab via OS2 og frigøre kommunerne fra dyr leverandørafhængighed.** + +--- + +## Baggrund + +Aarhus Kommune har i 12 år anvendt **DynamicTemplate** fra Dania Software som fælles skabelonløsning. Løsningen integrerer med Office-produkterne og fagsystemerne Cura, GetOrganized og Modulus Social. I dag er der: + +- **2.263 unikke brugere**, der aktivt anvender løsningen +- **2.464 unikke skabeloner** +- **mere end 10.000 fraser** + +Dania Software er opkøbt af Omnidocs, som har lanceret **Create** — en cloudbaseret erstatning for DynamicTemplate med en annonceret, væsentlig prisstigning. Det har fået Digitaliseringsstyregruppen (DSG) til at tage stilling til fire scenarier for den fremtidige skabelonløsning: + +| Scenarie | Indhold | +|---|---| +| 1 | Fortsæt med DynamicTemplate | +| 2 | Skift til cloudløsningen Create | +| 3 | **Udvikling af en alternativ, åben løsning** | +| 4 | Brug kun skabelonløsninger i fagsystemerne | + +Dette notat behandler **Scenarie 3**. Scenariet er behæftet med de største usikkerheder og kræver — jf. DSG-indstillingen — yderligere analyse samt eventuelt et tilbud fra ITK. Formålet her er at levere netop den analyse, som grundlag for en ansøgning om økonomi til at bygge løsningen. + +::: info Hvorfor Scenarie 3? +En åben løsning reducerer afhængigheden af dyre Office-licenser og af en enkelt leverandør, understøtter et længe ønsket behov for integration i Microsoft 365 Online, og kan — bygget på åbne standarder — deles og samudvikles med andre kommuner via OS2. Det er i tråd med den fællesoffentlige digitaliseringsstrategi, EU's interoperabilitetsprincipper og ønsket om digital suverænitet. +::: + +## Formål + +Notatet undersøger spørgsmålet: **Hvordan kan en åben, delbar skabelonløsning bygget på åbne standarder se ud i praksis — og hvad koster det at bygge den?** + +Output er, jf. oplægget: + +- en **løsningsbeskrivelse** (dette dokument) +- **spørgsmål der skal afklares** yderligere +- et **estimat med usikkerheder** (se [Estimeringsnotat](./estimeringsnotat)) +- en **visualisering af administrationsgrænsefladen** (se den [interaktive prototype](#interaktiv-prototype)) + +## Kernekomponenter + +Løsningen består af otte kernekomponenter: + +| Komponent | Formål | +|---|---| +| **Skabelonregister** | Versionering, rettigheder, ejerskab, metadata, gyldighed og publicering af skabeloner | +| **Frasebibliotek** | Centrale tekstblokke med versionering, fagligt ejerskab og adgangsstyring | +| **Datamodel** | Fælles struktur for afsender, modtager, organisation, sagsdata, CPR/CVR-data og fagsystemdata | +| **Dokumentmotor** | Genererer DOCX, ODT, PDF og evt. HTML fra skabelon og data | +| **Integrations-API** | Gør det muligt for Cura, GetOrganized, Modulus Social og andre systemer at kalde løsningen | +| **Klienter** | Word add-in, LibreOffice-extension, webportal og integration til onlinekontorpakker | +| **Adminmodul** | Skabelonredigering, test, publicering, statistik, logning og governance | +| **Migreringsværktøj** | Udtræk, analyse og konvertering af eksisterende skabeloner og fraser | + +## Arkitektur + +Arkitekturen bygger på åbne standarder og open source-komponenter. Data hentes fra fagsystemer via API'er, flettes ind i en skabelon af en dokumentmotor og leveres som DOCX, ODT eller PDF — med et separat lag til redigering, lagring og versionering af selve skabelonerne. + +```mermaid +flowchart TD + subgraph kilder["Datakilder"] + fag["Fagsystemer
(Cura, GetOrganized,
Modulus Social)"] + cpr["CPR / CVR"] + org["Organisationsdata"] + end + + api["Integrations-API / ETL
(REST · JSON)"] + motor["Dokumentmotor
(skabelon + data → dokument)"] + + subgraph admin["Skabelonforvaltning"] + register["Skabelonregister
versionering · rettigheder"] + fraser["Frasebibliotek"] + editor["Web-editor
(OnlyOffice / Collabora)"] + end + + subgraph output["Output"] + docx["DOCX / ODT / PDF"] + arkiv["Arkivering i ESDH
· download · e-mail"] + end + + kilder --> api --> motor --> docx --> arkiv + admin --> motor +``` + +::: info Klienter og glidende overgang +Brugerne møder løsningen via flere klienter — en **webportal**, en **Word add-in** og en **LibreOffice-extension** — så overgangen kan ske gradvist uden at tvinge alle over på ét format eller én klient på én gang. +::: + +## Åbne standarder og open source + +Løsningen skal kunne deles via OS2 og overholde deres principper, og den skal bygge på åbne standarder. Relevante formater og kandidatkomponenter, der bør undersøges i en afklaringsfase: + +- **Formater:** ODF (ODT) som åbent kerneformat, med output også i DOCX og PDF for at sikre en glidende overgang. +- **Dokumentmotor:** docxtemplater (template + JSON → DOCX), Jinja2, Open Document Mail Merge (ODMM), LibreOffice Mail Merge. +- **PDF:** WeasyPrint (HTML + CSS → PDF) eller tilsvarende. +- **Web-editor / samarbejde:** OnlyOffice eller Collabora Online. +- **Lagring og versionering:** afklares — git er teknisk uegnet til binære docx/odt-filer; et DMS (fx Nextcloud) er en mulighed, men tilfører et ekstra led, der skal driftes. + +En løsning baseret på åbne standarder og open source kan med fordel samudvikles og genbruges via fx **OS2** eller **KOMBIT**. Tilsvarende offentlige initiativer findes allerede i bl.a. Tyskland (Bundesdruckerei, ODF), Frankrig (OpenFisca + Mako Templates) og Norge (Open eGov, XSLT/HTML-fletning). + +## Hensyn fra udviklingsteamet + +::: warning To centrale forbehold skal adresseres i designet +**1. Glidende overgang frem for et stort spring.** Med flere tusind brugere er det risikabelt at flytte alle over på ODT, Markdown eller git på én gang. Nextcloud og git løser et lagrings­problem, men er et stort skridt for brugerne og endnu et led at vedligeholde. Designet skal muliggøre en gradvis migrering — ikke en "big bang". + +**2. Komplekse skabeloner, ikke kun simple placeholders.** Flere skabeloner kan ikke løses med simple `{navn}`/`{dato}`-placeholders. Der findes i dag Word-makroer, der interaktivt beder brugeren om en række input. Hvis motoren kun understøtter simpel substitution, bygger projektet sig ind i et hjørne, hvor en POC er mulig, men nye features bliver dyre. Motoren skal fra start kunne håndtere **betingede felter, gentagelige sektioner og brugerstyrede input-flows**. +::: + +## Faseopdelt tilgang + +For at imødegå usikkerheden startes småt og udvides, efterhånden som koncept og behov afklares: + +- **Fase 0 — Afklaring.** Lagringsmodel, format-standard, governance, strategi for komplekse skabeloner og fagsystem-snitflader. +- **Fase 1 — POC.** En skabelonmotor der fletter JSON-data ind i 1-2 reelle Aarhus-skabeloner og udskriver DOCX og PDF. +- **Fase 2 — MVP.** Skabelonregister, frasebibliotek, adminmodul-UI, web-editor og første fagsystem-integration. +- **Fase 3 — Fuld løsning.** Integrations-API til fagsystemerne, Word add-in og LibreOffice-extension, migreringsværktøj og OS2-udgivelse. + +Se [Estimeringsnotat](./estimeringsnotat) for timeestimat, tidshorisont og forbehold. + +## Hvad prototypen viser + +Den interaktive prototype visualiserer **administrationsgrænsefladen** — den del fagredaktører og administratorer arbejder i. Den er klientside-only (ingen backend) og et visuelt diskussionsgrundlag, ikke en færdig løsning. Den viser: + +- **Skabelonregister** — liste over skabeloner med version, ejer, afdeling og status (kladde / publiceret / udløbet), med søgning og filtre. Indholdet er fiktivt (eksempelafdelinger og generiske dokumenttyper), kun til illustration. +- **Frasebibliotek** — centrale tekstblokke med fagligt ejerskab, version og adgang. +- **Skabelon-detalje og redigering** — placeholders, kolofon-data (afsender, sagsbehandler, DokID fra ESDH) og et eksempel på et **komplekst input-flow**, der adresserer makro-behovet. +- **Dokumentmotor-preview** — udfyld med testdata og generér DOCX/PDF (simuleret). + +## Spørgsmål der skal afklares + +1. **Lagring og versionering.** Git er uegnet til binære docx/odt-filer. Skal der bruges et DMS (Nextcloud/Alfresco), og hvilke ulemper (ekstra drift, brugervenlighed) accepteres? +2. **Brugerparathed til åbne formater.** Er brugerne klar til ODT/Markdown, eller skal DOCX forblive det primære arbejdsformat i en overgangsperiode? +3. **Komplekse skabeloner.** Hvordan erstattes Word-makro-baserede input-flows — betingede felter, gentagelige sektioner, guidede formularer? +4. **Fagsystem-integration vs. indbyggede løsninger.** Skal Cura, GetOrganized og Modulus Social integrere med den fælles løsning, eller bruge deres egne indbyggede skabelonløsninger? Hvordan håndteres "skjulte" integrationer, hvor brugere åbner Word-dokumenter i fagsystemet? +5. **Migrering.** Hvordan udtrækkes, analyseres og konverteres 2.464 skabeloner og 10.000+ fraser? Hvor meget kan automatiseres? +6. **Hosting og ejerskab.** Hvem driver og betaler for platformen — et OS2-fællesskab, en værtskommune eller en central aktør? +7. **Governance.** Hvordan sikres kvalitet, fagligt ejerskab og rettigheder til delte skabeloner og fraser på tværs af organisationer? + +## Succeskriterie + +En fungerende **POC**, der fletter JSON-data ind i 1-2 reelle Aarhus-skabeloner og udskriver korrekt formateret DOCX og PDF — sammen med en demonstrerbar **administrationsgrænseflade**. POC'en skal samtidig afklare, om motoren kan håndtere kravet om komplekse skabeloner, så projektet ikke bygger sig ind i et hjørne. + +--- + +## Interaktiv prototype + +Åbn administrationsgrænsefladen ↗ diff --git a/docs/projects/skabelonloesning/mocks.md b/docs/projects/skabelonloesning/mocks.md new file mode 100644 index 0000000..16f9c6d --- /dev/null +++ b/docs/projects/skabelonloesning/mocks.md @@ -0,0 +1,8 @@ +**Project:** Fælles Skabelonløsning + +# Interaktive Mocks + +--- + +**Administrationsgrænseflade — prototype ↗** +Visualisering af administrationsgrænsefladen til en åben skabelonløsning. Viser skabelonregister med version, ejer, afdeling og status, frasebibliotek med fagligt ejerskab, en skabelon-detalje med kolofon-data og et komplekst input-flow (makro-erstatning), samt en simuleret dokumentmotor-preview (udfyld testdata → generér DOCX/PDF). Klientside-only, fiktivt illustrativt indhold. diff --git a/docs/public/design-system/v1/components.css b/docs/public/design-system/v1/components.css index 91b6a47..cce769b 100644 --- a/docs/public/design-system/v1/components.css +++ b/docs/public/design-system/v1/components.css @@ -27,8 +27,8 @@ white-space: nowrap; } -.ds .btn:hover { background: var(--ds-bg-subtle); } -.ds .btn:active { background: var(--ds-bg-muted); } +.ds .btn:hover { background: var(--ds-bg-muted); } +.ds .btn:active { background: var(--ds-gray-200); } .ds .btn:disabled, .ds .btn[aria-disabled="true"] { @@ -62,7 +62,7 @@ background: transparent; border-color: transparent; } -.ds .btn-ghost:hover { background: var(--ds-bg-subtle); } +.ds .btn-ghost:hover { background: var(--ds-bg-muted); } .ds .btn-danger { color: var(--ds-text-inverse); @@ -173,7 +173,7 @@ .ds .input:disabled, .ds .select:disabled, .ds .textarea:disabled { - background: var(--ds-bg-subtle); + background: var(--ds-bg-muted); color: var(--ds-text-muted); cursor: not-allowed; } @@ -202,10 +202,13 @@ border-bottom: 1px solid var(--ds-border-subtle); } +/* Flat tables: no fills, horizontal rules only. The header is defined by a + slightly stronger bottom border rather than a background. */ .ds .table th { font-weight: var(--ds-fw-semibold); color: var(--ds-text-secondary); - background: var(--ds-bg-subtle); + background: transparent; + border-bottom: 1px solid var(--ds-border-default); position: sticky; top: 0; z-index: 1; @@ -213,9 +216,9 @@ .ds .table tbody tr:last-child td { border-bottom: 0; } -.ds .table-zebra tbody tr:nth-child(even) { background: var(--ds-bg-subtle); } +.ds .table-zebra tbody tr:nth-child(even) { background: transparent; } -.ds .table-hover tbody tr:hover { background: var(--ds-color-primary-soft); } +.ds .table-hover tbody tr:hover { background: var(--ds-bg-muted); } /* -------------------------------------------------------------------------- */ /* Modal */ @@ -376,7 +379,7 @@ padding: var(--ds-space-3) var(--ds-space-4); border-radius: var(--ds-radius-md); border-left: 4px solid var(--ds-border-default); - background: var(--ds-bg-subtle); + background: var(--ds-bg-muted); font-size: var(--ds-fs-sm); } diff --git a/docs/public/design-system/v1/tokens.css b/docs/public/design-system/v1/tokens.css index 42f1c01..56322eb 100644 --- a/docs/public/design-system/v1/tokens.css +++ b/docs/public/design-system/v1/tokens.css @@ -75,16 +75,16 @@ --ds-text-link: var(--ds-teal-600); --ds-text-link-hover: var(--ds-teal-700); - /* Semantic — surfaces */ - --ds-bg-page: #f5f4f2; + /* Semantic — surfaces (flat, white-first) */ + --ds-bg-page: #ffffff; --ds-bg-surface: var(--ds-white); - --ds-bg-subtle: var(--ds-gray-100); - --ds-bg-muted: var(--ds-gray-200); + --ds-bg-subtle: #ffffff; + --ds-bg-muted: #f4f6f6; --ds-bg-inverse: var(--ds-gray-900); - /* Semantic — borders */ - --ds-border-default: var(--ds-gray-300); - --ds-border-subtle: var(--ds-gray-200); + /* Semantic — borders (subtle hairlines) */ + --ds-border-default: #e3e8e8; + --ds-border-subtle: #edf0f0; --ds-border-strong: var(--ds-gray-500); --ds-border-focus: var(--ds-teal-500); @@ -144,12 +144,12 @@ --ds-space-7: 3rem; /* 48 */ --ds-space-8: 4rem; /* 64 */ - /* Radii */ + /* Radii (tightened for a flatter, more modern look) */ --ds-radius-sm: 2px; - --ds-radius-md: 4px; - --ds-radius-lg: 6px; - --ds-radius-xl: 10px; - --ds-radius-2xl: 14px; + --ds-radius-md: 3px; + --ds-radius-lg: 4px; + --ds-radius-xl: 5px; + --ds-radius-2xl: 6px; --ds-radius-pill: 9999px; --ds-radius-full: 9999px; diff --git a/docs/public/projects/skabelonloesning/mocks/index.html b/docs/public/projects/skabelonloesning/mocks/index.html new file mode 100644 index 0000000..c29911e --- /dev/null +++ b/docs/public/projects/skabelonloesning/mocks/index.html @@ -0,0 +1,348 @@ + + + + + + Fælles Skabelonløsning – administrationsgrænseflade (prototype) + + + + + + +
+
+
+ SK + Skabelonløsning
administration · prototype
+
+
+ +
+ + +
+
+
+ + + +