GovNL: Von Monaten zu Minuten beim Aufbau von Websites

GovNL kombiniert Open-Source-Drupal-Komponenten mit einem offenen Designsystem, um zahlreiche Websites der niederländischen Regierung zugänglich und skalierbar zu betreiben. Die Zeit für den Aufbau neuer Websites reduziert sich dadurch von etwa drei Monaten auf rund zehn Minuten. Beeindruckend, um es gelinde zu sagen. Das ist ein starkes Beispiel dafür, wie Design für Wiederverwendung in grossem Massstab funktionieren kann.

Europäische Kommission: Koordination ist der Schlüssel zur Skalierung

Die Europäische Kommission betreibt bereits 770 Websites und investiert stark in das Drupal-Ökosystem. Besonders aufgefallen ist mir, wie stark der Fokus auf Koordination liegt. Man muss sicherstellen, dass die richtigen Inhalte über den richtigen Kanal innerhalb dieser grossen Website-Landschaft veröffentlicht werden. Open Source Program Offices (OSPOs) wurden eingerichtet, um Open-Source-Strategien sowohl auf Regierungsebene als auch innerhalb von Organisationen voranzutreiben.

Website des Kantons Basel-Stadt und Alva: ein Blueprint für lokale öffentliche Verwaltungen

Kurz vor der Mittagspause war ich an der Reihe, die verschiedenen KI-Use-Cases vorzustellen, die wir für den Kanton Basel-Stadt umgesetzt haben. Der Kanton setzte mit dem Relaunch von bs.ch neue Standards: mit einem nutzerorientierten Design, einem themenbasierten Zugang statt interner Organisationsstruktur und Alva als erstem KI-basierten Chatbot für einen Schweizer Kanton. Der Tech-Stack basiert auf Open-Source-Komponenten, und Liip hat im Rahmen des Relaunches stark zu Open Source beigetragen. Wir verwenden Drupal als CMS, Nuxt/Vue, den blökkli-Editor für das Headless-Frontend und Elasticsearch für die Suche. Die Inhalte werden von einem departementsübergreifenden Redaktionsteam erstellt, das einer klaren Content-Strategie folgt.

KI zur Unterstützung der Öffentlichkeit und der Editor*innen

Der Vortrag war auch eine Gelegenheit, mehr als 18 Monate nach dem Go-Live Zahlen zu teilen. Heute beantwortet Alva über 10 000 Fragen pro Monat, mit durchschnittlich 1,36 Fragen pro Konversation und einem Wachstum von +44 % seit Alva 2.0. Dank API-Integrationen kann der Chatbot Fragen auf Basis von Echtzeitinformationen beantworten. Alva wird stark von internen Mitarbeitenden des Kantons sowie von der Öffentlichkeit genutzt. Der Chatbot zeigt und überprüft stets seine Quellen, was entscheidend ist, um Vertrauen aufzubauen.

Auf der Redaktionsseite arbeitet blökkli intensiv daran, Texte zu vereinfachen. Mit dem blökkli-Editor und integrierter KI können Editor*innen nun Lesbarkeitsanalysen durchführen, vorgeschlagene Vereinfachungen nebeneinander sehen und diese übernehmen oder anpassen. Alva und die KI-Funktionen auf bs.ch werden kontinuierlich weiterentwickelt, um Editor*innen und Bürger*innen vertrauenswürdige KI-Technologien bereitzustellen.

KI-gestützte Technologien in der französischen Regierung

Ein weiterer inspirierender Vortrag zeigte Use-Cases von KI auf der Plattform Services Publics+ der französischen Regierung. Mit über 140 000 geteilten Erfahrungen und mehr als einer Million Reaktionen nutzt das System KI-gestützte Technologien, um staatlichen Stellen dabei zu helfen, Feedback an Bürger*innen zu geben. Dazu gehören Speech-to-Text und Echtzeit-Zusammenfassungen als zentrale Technologien. C’est magnifique!

Die EU vertraut Open Source mehr denn je

Die Europäische Union hat den Website Evidence Collector eingeführt – ein Open-Source-Tool, das Websites auf Sicherheitsprobleme überprüft. Bemerkenswert ist, dass das Projekt unter der EUPL (European Union Public Licence) veröffentlicht wurde. Diese betont die Interoperabilität zwischen Ländern und Lizenzen und unterstützt mehrsprachige Zusammenarbeit. Ich frage mich, ob es in der Schweiz etwas Ähnliches gibt.

Mit Interoperable Europe bietet die EU ausserdem ein neues Portal mit einem hilfreichen Licensing Assistant. Damit kannst du Softwarelizenzen finden und vergleichen sowie mit einem Kompatibilitäts-Checker prüfen, ob verschiedene Open-Source-Lizenzen kombiniert werden können und ob rechtliche Komplikationen entstehen könnten.

Open Source zu nutzen reicht nicht - wir brauchen Champions

Zum Abschluss betonte Tiffany Farris von der Strategieberatung Palantir.net (nicht zu verwechseln mit Palantir Technologies), dass die Nutzung von Open Source gut ist, aber nicht ausreicht. Organisationen brauchen Champions, die Beiträge zur Community und die Gesundheit des Ökosystems aktiv vorantreiben. Design für Wiederverwendung sollte ein zentrales Prinzip sein. Aus US-Perspektive ist Beschaffung (Procurement) ein grosses Problem: Die Nutzung von Open Source wächst, aber Unterstützungsmechanismen oft nicht. Wenn Open Source als „kostenlos“ betrachtet wird, kann das dazu führen, dass Aufträge an Anbieter gehen, die ihre Arbeit zwar als Open Source vermarkten, aber kein nachhaltiges Ökosystem unterstützen. Sie schlug konkrete Anpassungen der öffentlichen Beschaffung im Sinne von „Public Money, Public Code“ vor, um das Ökosystem besser zu unterstützen. Ein wirklich inspirierender Abschluss für einen intensiven Tag voller Lernen und Austausch.

Wenn du tiefer in die Inhalte eintauchen möchtest, kannst du dir die Playlist der Präsentationen von Drupal4Gov EU 2026 ansehen.

We created a fully themeable chat UI that can be embedded in any website and has no effect on the parent page. Kanton Basel-Stadts Alva and RAMMS' Rocky AI are instances of that UI.

This blog post will show you what we learned about creating web components that do not influence the parent page. Here are the good, the bad and the ugly when working with web components.

The Good

These are the good parts of web components. They will lay the foundation for why you might use them.

Portability

Every system that can handle HTML can handle web components. A simple tag and a script will integrate it into any web framework. It doesn't even need to be a JavaScript framework.

<body>
  <your-webcomponent></your-webcomponent>
  <script src="path/to/your-webcomponent.js"></script>
</body>

Native Feel

IFrames are another way to embed UI into a page, and they are arguably easier to use. But the main difference is that web components feel more native to the page, since they directly integrate into the parent page's layout. This means you can use transparency, intrinsic sizing (size based on the web component's contents), and seamless event communication with the parent page.

Slots

With slots you can provide content that will be added at a specified point inside your web component.

In our chat UI, we used a slot to let integrators provide a custom loading spinner. This spinner needs to be visible immediately, before the full theme loads asynchronously.

Shadow DOM - Isolating Styles

A robust way to ensure that your styles do not affect the parent page is to use the Shadow DOM. Shadow DOM is a web component feature to add a boundary for styles. Styles applied inside the Shadow DOM never apply to the parent page.

Caveat: Inheritable CSS Properties

There is one exception to the isolation where CSS properties of the parent page apply to the web component.

These are the properties that pierce through the boundary:

• Inheritable CSS properties like color, font-family, line-height
• CSS custom properties like --my-var

In practice, we have found it helps to fully specify the common properties like fonts and color on every element. That way you will never be surprised by different styles on integration.

Vite

For bundling web components, we can highly recommend Vite. There are a lot of neat tricks you can apply while bundling. Here are the Vite features we used for our web component.

Inlining Assets

Vite's explicit inline handling feature allowed us to inline our external CSS files into the JS bundle.

import cssContentString from "./index.css?inline";

This feature will not only inline the raw content of the imported index.css. It will also resolve all CSS imports, apply PostCSS transforms, and even work with CSS preprocessors like SASS. While inlined CSS is not the most efficient for browsers to render, the benefit is that we can ship a single JS file.

Library Mode

The Vite library mode provides you with fine-grained control of how the bundle should behave. To enable the library mode just add the build.lib option in your Vite config.

The Bad

Not everything about web components is great though. Here are the bad parts.

SSR - Hard to Get Working

Server-side rendering will almost certainly not work. The rest of the page can still be rendered server-side, but the web component will only show up as a <your-webcomponent></your-webcomponent> tag. Its contents will only be rendered in the browser.

There is one experimental package by Lit Labs that tries to solve this, but we never tried it.

Tailwind - Not a Great Fit

Tailwind feels like a natural choice for web components, but it does not play well with them.

The core issue is twofold. First, Tailwind ships its own CSS reset (called Preflight), which overrides default browser styles. When injected into a page that does not use Tailwind, it potentially breaks the page. Shadow DOM could isolate this reset, but Tailwind is fundamentally not designed to work inside a Shadow DOM. Here is the discussion if you are interested.

There are some hacky workarounds, but we tried them and had no success getting them to work reliably.

Our recommendation is to only use Tailwind if you are guaranteed that the parent page also uses it, and then use web components without Shadow DOM.

The Ugly

Verbose Web Components API

The native web component API is verbose and hard to read. A simple counter component, for example, requires manually defining a class, attaching a shadow root, setting up innerHTML, and wiring event listeners in connectedCallback. This boilerplate adds up quickly. You can see examples of the API here.

Fortunately, web components make for a great compile target. Svelte and Vue directly support compiling to web components. React is a bit trickier, but totally doable as well. We used this approach for our chat UI, where the first iteration was built with React and the current one with Svelte.

Weird Quirks

Advanced web component features come with edge cases
that no documentation warns you about. Even Svelte,
which has excellent web component support, ships with a
notable list of caveats.

We even hit an undocumented edge case with slots in Svelte: the bundle script must
load after the component markup, or slotted content will
not render. An ugly wrapper for slots fixes the problem,
but quirks like this add up and slow you down.

Font Loading - Not Working Inside Shadow DOM

When authoring web components, you get into the habit of defining all stylesheet links etc. in the web component body. As you should, so they do not affect the parent page. But there is another annoying detail here: @font-face will not work when defined in the Shadow DOM. If your web component needs a custom font, you need to inject the font CSS into the parent page to make it work.

Conclusion

I do not want to end on this ugly note though. I really think there are cases where web components are the right choice, and in our case we would choose Svelte & web components again.

To help you get started, here is a Svelte starter template.

Ein Artikel der Initiator*innen dieses Projekts, veröffentlicht in der neuesten Ausgabe der Revue Médicale Suisse, zieht nun eine erste Bilanz ein Jahr nach der öffentlichen Lancierung.

Ein offizielles Angebot statt fehlerhafter Antworten online

Die medizinische Grundversorgung, ein zentraler Pfeiler eines funktionierenden Gesundheitssystems, steht zunehmend unter Druck, selbst in Städten. Wenn Patient*innen ihre Hausärzt*innen nicht schnell erreichen können, suchen sie oft im Internet nach Antworten. Die Informationen, die sie dort finden, sind jedoch häufig ungenau oder sogar potenziell gefährlich.

In diesem Kontext kann eine gut konzipierte KI-Lösung helfen, die richtige Information zur richtigen Zeit bereitzustellen.

Deshalb haben wir die HUG bei der Entwicklung eines RAG-basierten Chatbots (Retrieval Augmented Generation) unterstützt. ConfIAnce ist nicht der erste Chatbot für Patient*innen. Er unterscheidet sich jedoch durch seine institutionelle Wurzeln, die Nutzung lokal validierter medizinischer Inhalte sowie durch Kontrollmechanismen, die die Zuverlässigkeit der Antworten sicherstellen.

Um Sicherheit zu gewährleisten, integriert das System mehrere Kontrollmechanismen, darunter Matching, Groundedness, Harmfulness, automatisierte Tests und semantisches Routing.

Qualitätssicherung durch Kontrolle des Systems

Eine zentrale Herausforderung besteht darin, die Kontrolle über das System zu behalten. Dafür braucht es geeignete Monitoring-Funktionen.

Automatisierte Tests prüfen sämtliche Antworten des Chatbots auf ihre faktische Übereinstimmung mit der Wissensbasis.

Zusätzlich sorgt ein von Administrator*innen anpassbares Routing dafür, dass Fragen gefiltert und bei Bedarf unter menschlicher Aufsicht weitergeleitet werden. Sie können den Chatbot zudem sofort offline nehmen, falls ein Fehlverhalten vermutet wird.

Themen, über die häufig gefragt wird, aber in den Ausgangsdokumenten noch wenig behandelt werden, werden identifiziert und weiter ausgebaut. So wird die Wissensbasis im Rahmen eines kontinuierlichen Verbesserungsprozesses erweitert.

Selbst das beste Tool bringt nur etwas, wenn es genutzt wird

Damit Patient*innen den Chatbot tatsächlich verwenden, haben die HUG eine öffentliche Informationskampagne gestartet. Ziel war es, das Tool bekannt zu machen und gleichzeitig realistische Erwartungen zu setzen.

ConfIAnce ist kein medizinisches Gerät und ersetzt keinen Arztbesuch. Vielmehr ist er ein Informationsangebot, das Fragen zu den häufigsten chronischen Erkrankungen bei Erwachsenen beantwortet.

Im Februar 2025 ging ConfIAnce in der Beta-Version online. Zwischen Anfang Februar und Ende Oktober 2025 haben 3’823 Nutzer*innen mit dem Chatbot interagiert. Daraus entstanden 5’969 Gespräche und 11’781 Fragen, im Durchschnitt etwa zwei Fragen pro Gespräch.

Die direkt im Chatbot abgegebenen Rückmeldungen sind zu 75 % positiv.

Hohe Akzeptanz für einen etwas anderen Chatbot

Chatbots im Gesundheitsbereich werden von Patient*innen meist gut angenommen, vor allem wegen ihrer ständigen Verfügbarkeit und der einfachen Nutzung. Studien zeigen jedoch auch wiederkehrende Probleme: eine uneinheitliche Qualität der Antworten sowie mangelnde Transparenz bei den verwendeten Quellen.

Genau hier unterscheidet sich ConfIAnce von vielen anderen medizinischen Chatbots.
Der Chatbot wurde entwickelt, um die Beziehung zwischen Patientinnen und Ärzt\innen zu unterstützen, nicht zu ersetzen. ConfIAnce entlastet Ärzt*innen in der Grundversorgung und schafft ihnen mehr Zeit für die menschliche Seite ihres Berufs.

Die Autorinnen des Artikels in der Revue Médicale Suisse betonen zudem, dass der Chatbot, der im spezifischen Kontext der HUG und ihrer Dokumente entwickelt wurde, auch in anderen institutionellen Umgebungen eingesetzt werden kann. Damit ein solches Projekt erfolgreich ist, braucht es zunächst hochwertige Daten, wie sie hier zur Verfügung standen. Darüber hinaus ermöglichen Kontrollmechanismen, automatisierte Tests und Nutzer\innen-Feedback eine kontinuierliche Verbesserung – und sorgen für Sicherheit und Relevanz, die Vertrauen schaffen.

The City of Zurich publishes over 900 datasets as open data, spread across six different APIs. There's CKAN for the main data catalog, a WFS Geoportal for geodata, the Paris API for parliamentary information from the Gemeinderat, a tourism API, SPARQL linked data, and ParkenDD for real-time parking data. All public, all freely available. But until now, making an AI assistant actually use these APIs meant writing custom integrations for each one.

The MCP server wraps all six APIs into 20 tools that any MCP-compatible AI assistant can call directly. Ask "How warm is it in Zurich right now?" and it queries the live weather stations. Ask about parking availability, and it pulls real-time data from 36 parking garages. It also covers parliamentary motions, tourism recommendations, SQL queries on the data store, and GeoJSON features for school locations, playgrounds, or climate data. All through a single, standardized Model Context Protocol interface.

Hayal Oezkan built it in Python using FastMCP. One file for the server with all 20 tool handlers. The repo is on GitHub.

Deploying it on our side took very little effort. The server supports both stdio transport for local use (like in Claude Desktop or Claude Code) and SSE and HTTP Streaming for remote deployment. I packaged it with Docker, deployed it to our cluster, and now it's available as a remote MCP server that anyone can add to their AI tools without installing anything locally.

The natural next step was integrating this with ZüriCityGPT. It happened, just not quite in the direction I originally had in mind.

ZüriCityGPT already had its own MCP server at zuericitygpt.ch/mcp, exposing tools for searching the city's website content, "Stadtratsbeschlüsse" and looking up waste collection schedules. Instead of wiring the open data tools into ZüriCityGPT, I went the other way: the open data MCP server now proxies tools from the ZüriCityGPT MCP server. A lightweight proxy client connects to the remote server via streamable-http and forwards calls. The whole thing is about 40 lines of Python.

So now, when you connect to the Zurich Open Data MCP server, you get 23 tools in one place. The 21 original open data tools across six APIs, plus zurich_search for querying the city's knowledge base and zurich_waste_collection for waste pickup schedules (based on the OpenERZ API). One MCP endpoint, many services behind it.

A city employee builds something useful in the open, publishes the code, and within a day it's deployed and available to a wider audience. Open data and open source working together, exactly as intended.

Im Zentrum des Relaunchs steht die Nutzerzentrierung. Statt der Innenperspektive soll eine themenzentrierte Struktur entstehen – wie sie beispielsweise der Kanton Basel-Stadt (mehr zum Projekt hier) bereits erfolgreich etabliert hat.

Das Vorhaben aus Content-Sicht? Ein Mammut-Projekt.

Was braucht es für ein Content-Projekt dieser Grösse?

Organisch gewachsene Inhalte können nicht einfach migriert werden. Ein Relaunch ist meist der Moment, in dem Content nicht nur übertragen, sondern qualitativ neu gedacht wird.

Da dabei ein grosses Volumen an Content überarbeitet werden muss, braucht es ein dezentrales Redaktionsmodell. Zahlreiche Mitarbeitende – oft ohne vertiefte Content-Erfahrung – sind involviert. Gute Prozesse, klare Rollen und gezielte Unterstützung sind daher essenziell:

• Eine entscheidungsfreudige Projektleitung
• Eine solide Bestandesaufnahme
• Konzept und Strategie
• Governance (Prozesse & Verantwortlichkeiten)
• Aufbau und Schulung der Webredaktion
• Operative Content-Produktion
• Qualitätssicherung

Liip darf den Kanton Graubünden auf dieser Reise begleiten. Auf Basis unserer Erfahrungen aus den Projekten in Basel-Stadt, Solothurn und verschiedenen Bundesämtern ist eine vertrauensvolle, effiziente Zusammenarbeit entstanden.

Wie wir zusammenarbeiten

Zwei Content-Strateginnen von Liip arbeiten eng mit der Projektleitung des Kantons zusammen. Die Projektleitung bringt internes Know-how und Entscheidungsstärke ein, Liip ergänzt operative Kapazität und viel Erfahrung aus ähnlichen Settings. Dieses Setup ermöglicht hohe Geschwindigkeit – und eine saubere Verzahnung von internem Wissen und externem Input.

Die Zusammenarbeit erstreckt sich über mehr als 1,5 Jahre.

Was sind die konkreten Lieferobjekte?

• Content Audit
• Content Strategie & Tonalität
• Content Governance & Redaktionsmodell (für die Projektphase und für den Betrieb danach)
• Content Lifecycle Modell
• Content Guidelines für die Redaktion
• Seitentypen & Beispieltexte (in Zusammenarbeit mit dem Design-Team)
• Wordvorlagen für die Erstellung der Texte
• Schulungen & Support der Redaktionsmitglieder
• KI-basiertes Schreibtool «GR-Editor» (basierend auf TextMate)
• Qualitätssicherung

Was bedeutet das im Detail? Vom Audit bis zur Qualitätssicherung

Ein Relaunch mit über 120 involvierten Redaktor*innen und Tausenden Seiten Content braucht vor allem eines: einen klaren Plan für die Umsetzung und gute Vorbereitung. Jeder Schritt baut auf dem vorherigen auf:

1. Content Audit – Klarheit schaffen

Gestartet sind wir in das Projekt mit der Analyse einer repräsentativen Auswahl bestehender Inhalte. Der Audit half bei der Identifizierung von Optimierungspotenzialen und bildete das Fundament für alle weiteren Entscheidungen.

2. Das Redaktionsmodell – Rollen, Verantwortlichkeiten und Prozesse

Die Content Governance und das entwickelte Redaktionsmodell haben einen grossen Teil der «Theorie» gelegt, auf der die operativen Arbeiten mit der Webredaktion dann aufgebaut wurden. Wir haben dabei ein Modell für das Projekt entworfen, ergänzt um einen Plan für nach dem Relaunch.

3. Content Strategie & Tonalität – die Leitlinie

Die Governance regelt Zusammenarbeit und Prozesse – die Content Strategie definiert die inhaltliche Ausrichtung. Sie richtet sich dabei weniger an die künftigen Redaktor*innen, sondern bildet die konzeptionelle und inhaltliche Grundlage für die operativen Elemente. Ergänzt wurden zwei Tonalitäten für den neuen Webauftritt.

Mit abgeschlossener Strategie begann die operative Phase.

4. Seitentypen & Beispieltexte – das Konzept wird konkret

Gemeinsam mit dem Designteam entwickelten wir die neuen Seitentypen. Unsere UX Writerin entwarf erste realistische Seiten, die als Referenz für die Finalisierung der Seitentypen dienten.

Arbeiten mit echten Texten ist entscheidend: Nur so lassen sich Struktur, Inhalt und Design sinnvoll aufeinander abstimmen.

Auch für die Schulung der Redaktor*innen sind die konkreten Text- und Seitenbeispiele wichtig.

5. Content Guidelines – das Handbuch für Redaktionsmitglieder

Abgeleitet von der Content Strategie bündeln die Content Guidelines Regeln, Empfehlungen, Beispiele und konkrete Anleitungen – für verständliche, barrierefreie und konsistente Inhalte.

6. Wordvorlagen – weil das CMS parallel erst entsteht

Da CMS-Entwicklung und Content-Entwicklung parallel laufen, müssen die Texte ausserhalb des CMS entstehen. Dafür erstellten wir Wordvorlagen, die:

• die neue Seitenstruktur abbilden,
• alle relevanten Meta-Informationen integrieren,
• Hinweise für Redaktor*innen enthalten.

Die Wordvorlagen wurden um Visualisierungen der einzelnen Seitentypen ergänzt. Dabei wurde ein reales Textbeispiel pro Seitentyp in Figma gesetzt und mit den Redaktor*innen als PDF geteilt.

7. KI-Schreibtool «GR-Editor» – Unterstützung in Echtzeit

Ein dezentrales Redaktionsmodell führt zwangsläufig zu variierender Textqualität. Der GR-Editor (basierend auf TextMate) wirkt dem entgegen. Er prüft Verständlichkeit, Konsistenz und Tonalität direkt beim Schreiben.

Der Kanton hatte ideale Voraussetzungen: bestehende kantonale Schreibvorgaben, die neuen Content Guidelines und die zwei definierten Tonalitäten.

8. Aufbau der Redaktionen & Schulungen

Zunächst wurden die Redaktionen zusammengestellt, passend zur neuen Website-Struktur: einem Themen- und einem Organisationsteil.

Für den Thementeil entstanden Themenredaktionen mit je einer Koordinator*in. Sie funktionieren als Schnittstelle zwischen den Redaktionen und der Projektleitung. Die Supportorganisation (Projektleitung + Liip) begleitet die Teams.

Die Schulungen waren der erste praktische Einstieg. Vorgestellt wurden die neuen Seitentypen, die Guidelines und der GR-Editor.

9. Redaktionssupport – Begleitung im Alltag

Die inhaltlichen Arbeiten laufen derzeit. Die Supportorganisation organisiert regelmässige Redaktionssitzungen, beantwortet Fragen und erarbeitet Lösungen. Jede Themenredaktion erhält individuelles Sparring zu ersten Texten.

10. Qualitätssicherung – bevor der Inhalt live geht

Bei dieser Menge an Inhalten ist Eigenverantwortung zentral. Die Redaktor*innen erhalten Checklisten, mit denen sie ihre Texte selbst prüfen können. Strategisch ausgewählte Inhalte erhalten spezifisches Feedback.

Auch der GR-Editor trägt wesentlich zur Qualitätssicherung bei.

Erste Learnings aus dem Projekt

Ein Relaunch dieser Grösse strapaziert alle Beteiligten. Ein dezentrales Redaktionsmodell ist unvermeidlich. Verständnis für die Situation der Redaktionsmitglieder, Flexibilität bei der Umsetzung der Planung und pragmatische Lösungen unterwegs sind zentrale Zutaten für ein konstruktives Miteinander.

Was bedeutet das konkret? Einige Beispiele:

• «Der Ton macht die Musik». Sich mit Respekt begegnen, offene Punkte benennen, Probleme ernst nehmen, Mitgestaltung zulassen.
• Den Redaktionen Gestaltungsspielraum für ihr Timing geben – innerhalb des übergeordneten Projektzeitplans.
• Tools flexibel einsetzen (z. B. Excel statt Miro, wenn es besser passt).

Die Arbeit mit realen Textbeispielen in der Entwicklung der Seitentypen hat sich klar als wichtige Entscheidung erwiesen. Bei so vielen Beteiligten braucht es reife Vorlagen und klare Referenzen – um Qualität, Konsistenz und Tempo sicherzustellen. Auch die Visualisierungen der Seitentypen haben einen zentralen Stellenwert. Gerade für Menschen, die stark über das Visuelle funktionieren, ist das Texten in den Wordvorlagen ohne Vorschau des Frontends eine Herausforderung. Die Visualisierungen dienen immerhin als allgemeiner Referenzwert.

Externe Expert*innen können Spitzen brechen und in Diskussionen einen externen Blick beisteuern. Darüber hinaus ist es schön zu sehen, wie ein gemeinsames Team über Organisationsgrenzen hinaus entstehen kann - gemeinsam im Sinn der Sache.

..und genau in diesem Sinne freuen wir uns auf die nächsten, abschliessenden Prozessschritte. Und auf ein spannendes Jahr für den Relaunch :)

The Bias Problem

The problem is bias. If you know that Response A comes from the expensive model and Response B from the cheaper one, you'll unconsciously read them differently. The idea behind our solution is borrowed from classic A/B testing: show two variants to evaluators without telling them which is which, and let the results speak. For RAG chatbots, the question isn't "which model is generally better?" It's "which configuration produces better answers for this specific knowledge base and these specific users?" That requires comparing pre-generated answers, not live model outputs.

Side by Side, Let's Evaluate

So we built Arena mode into the Admin UI. It works like this: you start by running your evaluation set against two different configurations. Maybe you're testing a new system prompt, or switching embedding models, or trying a different retrieval strategy. Each run produces answers for every question in the set. Then you create a comparison, selecting those two runs.

When an evaluator opens the comparison, they see one question at a time. Two answers, labeled A and B. No model names, no hints. The order is shuffled differently for each evaluator using a seeded randomization, so if Alice sees the Claude answer as "A" for question 3, Bob might see it as "B". This prevents evaluators from developing patterns like "A is always the better one."

For each answer, you rate it as Good, Neutral, or Bad. You can add a comment explaining why, which turns out to be incredibly valuable. The quantitative scores tell you which model wins, but the comments tell you why, and often reveal issues you wouldn't catch with automated evaluation.

More Feedback the Merrier

Multiple evaluators can rate the same comparison independently. Getting people involved is easy: share links generate a temporary API key, so you can send a URL to a colleague or a client and they can evaluate in a protected area without needing an admin account. They just enter their name and start rating.

Understand the Results

The results page shows a leaderboard: average score, win rate per model, and a breakdown per evaluator. That last part is where it gets interesting: it surfaces inter-annotator agreement, a standard measure of how much evaluators align in their ratings.

• High agreement: the quality difference is clear and you can act on the result with confidence.
• Low agreement: the two configurations are close enough that the choice may come down to other factors like cost or latency.

You can also drill into individual comments grouped by model, and export everything to Excel for reporting.

Calibrating AI with Human Truth

Building this was a good reminder that evaluation tooling is never "done." Christian recently wrote about using Claude Agent SDK to analyze chatbot answers automatically, which is the other side of the coin: scaling evaluation with AI. Arena mode complements that by providing the human ground truth that automated evaluation needs to calibrate against.

We're using Arena now whenever we make significant changes to a chatbot's configuration. The signal-to-noise ratio is much better than staring at spreadsheets of automated scores. The feature is available in the Admin UI for any organization that uses our evaluation sets.

The Next Steps of the Arena

We're considering adding support for more than two models in a single comparison, and possibly integrating the Arena ratings as ground truth labels for training better LLM-as-a-Judge prompts. For now, blind human evaluation with a simple Good/Neutral/Bad rating scheme gives us exactly what we need: honest answers about which configuration actually works better.

We already had an MCP server running on ZüriCityGPT and other LiipGPT deployments. Tools like knowledge base search, public transport timetables, and waste collection schedules were available to any MCP client, Claude Desktop, Cursor, or custom integrations. The tool definitions, schemas, and execution logic were all there. WebMCP just needed a bridge to bring them into the browser.

The implementation turned out to be surprisingly straightforward. When the page loads, a small script checks if navigator.modelContext exists. If it does, it fetches the available tools from our existing MCP endpoint using a standard JSON-RPC tools/list request and registers each one with navigator.modelContext.registerTool(). When an AI agent calls a tool, the execute handler sends a tools/call request back to the same endpoint. The entire client-side code is about 30 lines of vanilla JavaScript.

navigator.modelContext.registerTool({
  name: tool.name,
  description: tool.description,
  inputSchema: tool.inputSchema,
  execute: function(params) {
    return fetch(mcpUrl, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        jsonrpc: '2.0',
        method: 'tools/call',
        params: { name: tool.name, arguments: params }
      })
    }).then(r => r.json()).then(d => d.result);
  }
});

The beauty is that the tool set is dynamic and per site setup. ZüriCityGPT exposes search with a special mode for city council resolutions (Stadtratsbeschlüsse, see also StrbGPT), waste collection lookups via the OpenERZ API, and Swiss public transport departures. A different LiipGPT deployment would expose its own set of tools. The backend decides what's available, the browser just registers whatever comes back.

One thing worth noting: navigator.modelContext is behind a flag in Chrome Canary (chrome://flags/#enable-webmcp-testing) and not available in any stable browser yet. The script uses feature detection, so nothing happens in unsupported browsers.

To actually test it, you need Chrome Canary and the Model Context Tool Inspector extension (which requires a Gemini API key to do anything useful with the tools). But the registration itself works, and seeing "search", "get_waste_collection", and "get_timetable_info" show up in the inspector when visiting a chatbot page is a nice confirmation that everything clicks together.

Now, ZüriCityGPT is a page with essentially one big input field. It's already a chatbot. An AI agent visiting the site could just type into that field. Exposing structured tools on a page that is itself a tool feels a little redundant. But it does open up genuinely new possibilities. A browser agent could search the knowledge base, check the next tram departure, and look up waste collection dates in parallel, without ever touching the chat UI, and combine the results with data from other sites. The chatbot answers questions one at a time. WebMCP lets agents compose capabilities.

Is this useful today? Not really. No stable browser supports it, and the user base of Chrome Canary with experimental flags enabled is, let's say, select. Google and Microsoft are pushing it through the W3C, and formal browser support is expected by mid-to-late 2026. When that happens, any AI agent visiting ZüriCityGPT will automatically discover what it can do, no documentation reading and UI guessing required.

The interesting part is the convergence. We now have the same tool definitions serving three purposes: LangChain tools for the chatbot's own RAG pipeline, an MCP server for "traditional" AI clients, and WebMCP for browser agents. One set of schemas, three integration points. Adding a new tool to any LiipGPT site automatically makes it available everywhere.

If you want to try it yourself, visit zuericitygpt.ch with Chrome Canary, enable the WebMCP flag, and install the Model Context Tool Inspector extension. You'll see the three registered tools and can ask Gemini when your next paper collection is. Or just type the question into the chatbot, that still works too.

Almost a year ago, I wrote about building a Swiss Parliament Bot with LangGraph. The bot answered questions about the federal parliament by constructing OData queries against the totally unofficial parlament.ch API. It worked, but the OData API had its quirks, was sometimes slow and totally unofficially used. I didn't work on it any further since then.

The migration was smooth. The LangGraph workflow itself didn't need to change at all. It's still the same boring four-step loop: generate API URLs, fetch data, evaluate whether the data is sufficient, and generate a response. If the evaluator says the data isn't enough, it loops back and tries different URLs. That architecture proved its worth here, because swapping out the underlying API was essentially a prompt and data-handling change, not a structural one. And that was the goal of this quick adjustment, not coming up with something totally new. Just use that new, more supported API.

What did change significantly was the prompt. The original prompt listed all OData entities with their fields and taught the LLM how to construct OData filter expressions. The new prompt does the same for OpenParlData's REST endpoints, with parameters like search, search_mode=partial, sort_by=-begin_date, and expand=memberships. The LLM had no trouble adapting. REST with query parameters is arguably more natural for it than OData's somewhat unusual syntax.

The biggest functional upgrade is the scope. The old bot only knew about the Nationalrat and Ständerat. Now it can answer questions about any parliament in the system. Ask "Welche Vorstösse gibt es zum Thema Künstliche Intelligenz?" and it searches across all parliaments. Ask about the "Finanzkommission des Nationalrats" and it narrows to body_key=CHE. Ask about the "Zürcher Kantonsrat" and it filters with body_key=ZH.

The bot is still a prototype and far from perfect. Not all cantonal parliaments have the same data coverage. Some queries work beautifully, others return empty results because the data simply isn't there yet. But the foundation is there, and as more parliaments feed data into OpenParlData, the bot will automatically benefit.

An MCP Server on Top

With the API migration done, I had a clean REST-based data layer sitting there. That made me think: why limit access to the chatbot? The Model Context Protocol (MCP) has been getting a lot of attention as a way for AI assistants to call external tools directly. And a well-structured REST API is pretty much the ideal thing to wrap in MCP tools.

So I built an MCP server that exposes the OpenParlData endpoints as tools that any MCP-compatible client can call — Claude Desktop, Cursor, or anything else that speaks the protocol. Each API endpoint becomes a tool: persons, affairs, votings, memberships, and so on. The AI assistant can search for parliament members, look up voting records, or drill into affair details, all without going through the chatbot UI.

Of course the right place for that MCP would be directly at OpenParlData. I didn't see anything about that yet. Time will tell.

You can try the chatbot at swissparliamentbot.gpt.liip.ch, or connect your MCP client to https://swissparliamentbot.gpt.liip.ch/mcp.

To illustrate I will use the objects below.

const sourceUser = {
    id: "94aef3ae-43d1-4847-b5c3-c2ea2d42c52a",
    email: "falk@liip.ch",
    rights: ["read", "write", "admin"],
    otherStuff: "whatever",
};

const targetUser = {
    id: "3",
    mail: "falk@liip.ch",
    rights: ["read", "admin", "write"],
};

Constraints

I had three constraints for my solution:

• It should only use plain objects. No Sets, Maps or Classes. This keeps things simple if an API sits between.
• The pattern should easily apply to any object once set up.
• It should be built in TypeScript since the rest of the project uses TypeScript.

Let's get right into it.

Mapping the Structure

The first step was to map the sourceUser into the same structure as the targetUser.

const mapUser = ({ email, rights }) => ({ mail: email, rights });

const mappedSourceUser = mapUser(sourceUser);
// {
//    mail: "falk@liip.ch",
//    rights: ["read", "write", "admin"],
// };

I could also have built a configuration based solution like below.

mappings:
    users:
        email: mail
        rights: rights

But in practice, I found it is often easier to just use code. In most cases processing values (like toLowerCase) is needed at some point. At that point you will be better off with just code. The guiding principle here is plan for change.

Comparing Objects

Then I structurally compared the objects.

const hasChanges = !equal(mappedSourceUser, targetUser);

I chose structural comparison here, because it nicely fits the goal of easy application for any object.

Full Update on Change

Whenever a change was detected by the comparison, I updated the whole user in the target database.

I opted for full updates on purpose. While this is less efficient than partial updates, it also makes the system a whole lot simpler. The guiding principle here is KISS (Keep It Simple, Stupid).

Easy enough, right? Here come the problems.

Problems

The first problem is that targetUser contains an additional field id that mappedSourceUser does not have. This means a naive comparison would always find differences, even when the relevant data is identical. We only want to compare fields that are relevant.

The second problem involves the rights array. It is not sorted, but the order does not matter for our purposes. The arrays ["read", "write", "admin"] and ["read", "admin", "write"] should be considered equal.

Finally, there is the question of debugging. How would I troubleshoot this setup if a comparison always flags objects as different? I would need some way to see which fields differ and why.

Conclusion

So basically I need a comparison library that:

• allows picking fields to compare
• ignores order of certain arrays
• logs readable diffs for debugging

Surely something like this exists, right?

Not to my knowledge. That is why I built sameish, a lightweight library that does exactly that. It works in both browser and server environments, with an optimized bundle size of 1.57 kB gzipped. The library is fully type-safe, including the picking of fields to compare.

You can try it out on the playground.

Wir haben bereits letztes Jahr über ein Werkzeug zur Bewertung des Nachhaltigkeitsniveaus von Liips digitalen Projekten gesprochen. Das Hauptziel unserer Plattform ist es: beim Aufbau von Websites und Apps zu helfen, die sowohl effizient als auch umweltfreundlich sind.

Wir wollen digitale Produkte schaffen, die effizient, zugänglich und verantwortungsvoll gestaltet sind. Da immer mehr Kund:innen Nachhaltigkeit inzwischen in ihre Anforderungen aufnehmen, sind wir bereit zu zeigen, dass wir das — und mehr — liefern können.

Die Entwicklung dieser Plattform ist eigentlich der einfache Teil. Die größte Herausforderung liegt im Change Management: Wie helfen wir Designer:innen, Entwickler:innen und Business Developer:innen bei Liip, Nachhaltigkeit in ihre tägliche Arbeit zu integrieren? Das bedeutet, einige unserer Prozesse anzupassen.

Ein Ansatz, den wir gewählt haben, war die Entwicklung maßgeschneiderter Schulungen für jedes Produktionsteam. In der Theorie klang das großartig, in der Praxis war es jedoch komplexer. Obwohl Nachhaltigkeit fest in der Kultur und DNA von Liip verankert ist, mussten wir ein Gleichgewicht finden. Über 150 Personen jeweils 2–3 Stunden zu schulen bedeutet viel Zeit weg von der regulären Kundenarbeit. Und sofern ein Projekt nicht explizit Eco-Design verlangt, ist es normal, dass Menschen ihre Arbeitsgewohnheiten nicht vollständig aufgrund einer einzigen Schulung ändern. Das ist nachvollziehbar. Es ist sinnvoll, sich auf das zu konzentrieren, was nötig ist, um effizient zu bleiben und Projekte termingerecht umzusetzen. Deshalb haben wir uns entschieden, Schulungen nur dann anzubieten, wenn ein Projekt sie tatsächlich benötigt.

Dadurch ergab sich eine weitere Herausforderung: Um unsere Teams weiterzubilden, müssen Kund:innen offen dafür sein, ihre Projekte auditieren zu lassen. Anders gesagt: Wir müssen den echten Mehrwert von Eco-Design aufzeigen.

Die „Nullsummen“-Denkweise rund um Web-Eco-Design

Ein Nullsummenspiel bedeutet, dass der Gewinn der einen Person mit dem Verlust einer anderen einhergeht. Nach meinen bisherigen Erfahrungen wird digitale Nachhaltigkeit oft genau so dargestellt — als müsste man sich zwischen Ökologie und wirtschaftlicher Performance entscheiden, wie bei einem Zielkonflikt. Diese polarisierte Sichtweise erschwert Gespräche über Nachhaltigkeit. Manchmal vermeide ich sogar das Wort „Öko“, wenn ich über die Vorteile nachhaltigen Designs spreche, und konzentriere mich stattdessen auf greifbarere Nutzen.

Der Mehrwert von Eco-Design liegt in besserer Zugänglichkeit, besserem SEO und höherer Performance — all das unterstützt Nachhaltigkeit durch clevere technische Optimierungen und durchdachte Designentscheidungen.

Es gibt außerdem die hartnäckige Fehlannahme, dass eine eco-designte Website automatisch schlicht oder langweilig sein müsse: nur schwarz-weiß, keine Bilder, nichts Ansprechendes. Diese Vorstellung von Eco-Design könnte kaum weiter von der Realität entfernt sein.

Einfachheit und Nachhaltigkeit müssen nicht auf Kosten von Ästhetik oder Nutzer:innenbindung gehen. Im Gegenteil: Durchdachtes Design kann eine Website gleichzeitig attraktiv und effizient machen.

Eco-Design — egal ob für eine Website oder ein physisches Produkt — umfasst Dutzende, wenn nicht Hunderte von Parametern, die berücksichtigt werden müssen, um begrenzte Ressourcen bestmöglich zu nutzen. Im Fall von Websites gibt es zudem viele Best Practices, die bereits angewendet wurden, als es noch kein 3G und keine leistungsstarken Smartphones gab.

Wo stehen wir heute?

Ich hoffe, dass wir eines Tages nicht mehr fragen müssen, ob etwas nachhaltig ist — es wird einfach Teil des Prozesses sein, so wie Barrierefreiheit und Responsiveness. Unser Bewertungstool funktioniert wie eine Checkliste, mit der wir potenzielle Verbesserungen identifizieren können, die in zukünftigen Updates und Wartungsphasen der von uns gelieferten Projekte eingeplant werden.

Wir machen gute Fortschritte. Unterschiedliche Teams bei Liip arbeiten auf unterschiedliche Weise und mit verschiedenen Technologien. Aktuell integrieren bereits einige Teams bei Liip Nachhaltigkeitsbewertungen in ihre Angebote. Unser Ziel ist es, dies unternehmensweit zum Standard zu machen.

Weitere Projekte unterstützen dieses Ziel. So verfeinern wir intern derzeit neue Kriterien für KI-basierte Funktionen und Produkte, und wir untersuchen, wie wir mehr Designer:innen in den Prozess einbinden können — denn die Design-Spezifikationen, die sie den Entwickler:innen liefern, können einen positiven Einfluss auf die Gesamtbilanz haben.

Wenn eine Bewertung Teil eines Projekts ist, arbeiten wir frühzeitig und eng mit den Stakeholdern zusammen, um zentrale Nachhaltigkeitsempfehlungen zu identifizieren und umzusetzen. Erfreulicherweise stellen wir fest, dass viele bewährte Praktiken bereits in unseren Prozessen verankert sind.

Am Ende eines Projekts, beim MVP oder Go-Live, führen wir eine abschließende Bewertung durch, um hervorzuheben, was gut funktioniert hat und wo weiteres Optimierungspotenzial besteht. Die Empfehlungen können anschließend für zukünftige Updates oder die Wartung priorisiert werden. Diese Verbesserungen reduzieren nicht nur die Umweltbelastung, sondern verbessern auch Barrierefreiheit, Geschwindigkeit und die gesamte User Experience.

Wenn Sie ein konkretes Beispiel sehen möchten, werfen Sie einen Blick auf IT4Future, für das wir eine vollständige Evaluation durchgeführt haben. Diese finden Sie auf ihrer Eco-Design-Seite.

Und nicht zuletzt: Lernen Sie Lowwwimpact kennen

Wir planen, in Kürze ein Update unserer Plattform zu veröffentlichen, das es uns ermöglicht, Bewertungen intern deutlich schneller durchzuführen und gleichzeitig unseren Kund:innen einen konkreteren Mehrwert zu bieten. Ich bin überzeugt, dass dies Liip dabei helfen wird, Eco-Design zu einem Standard zu machen.

Wir planen, unsere Plattform für alle zu öffnen — und das Beste daran: Sie können sich bereits jetzt auf unsere Warteliste setzen lassen, um zu unseren ersten Nutzer:innen zu gehören.

Haben Sie eine Frage, einen Kommentar oder eine Inspiration, die Sie teilen möchten? Zögern Sie nicht, Kontakt mit uns aufzunehmen, wenn Sie mehr über unseren Ansatz im Bereich Eco-Design erfahren möchten.