feat: add bilingual blog post about dialog-based applications

Add new blog post "Computer, ..." exploring how modern language models enable Star Trek-like computer interactions. Includes a practical experiment with dialog-based member management using MCP and GraphQL. Features: - German version at /de/blog/dialogbasierte-anwendungen/ - English version at /en/blog/dialog-based-applications/ - Translated URL slugs linked via translationKey - Content sourced from Notion with natural English translation - OpenSpec proposal with validation passing 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-25 16:53:55 +01:00
parent 285f7a2eed
commit e599e0404c
5 changed files with 330 additions and 0 deletions
@@ -0,0 +1,38 @@
 ---
 title: "Computer, ..."
 date: 2025-11-25
 description: "Modern language models make it possible to interact with computers almost like in Star Trek. An experiment with dialog-based member management shows how chatbots can control complex applications."
 translationKey: "dialogbasierte-anwendungen-post"
 ---
 **TL;DR:** Modern language models make it possible to interact with computers almost like in Star Trek. Instead of complicated programs, a chatbot could manage members, import data, and generate reports. This makes tasks simpler because you only need to describe what you need in plain language. Whether this is actually more reliable and productive than traditional interfaces in everyday use remains to be seen.
 🔗 **Source code for my experiment:** [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber)
 ## From Science Fiction to Breakthrough: How Language Models Are Revolutionizing Computer Interaction
 Since my childhood, I've been captivated by [Star Trek: The Next Generation](https://en.wikipedia.org/wiki/Star_Trek:_The_Next_Generation). The interaction with the ship's computer in natural language was one of the aspects that fascinated me and that I remember well. With the keyword "Computer, ..." the crew could engage in dialogue with the system, for example to query analyses of the ship's status, scan for life forms, or contact other crew members.
 For me, this was science fiction until recently. While there were always attempts to build such voice assistants – one of the first I experimented with back in 2003 was A.L.I.C.E. – not even Siri, Alexa and Co. were truly usable by my standards. Then came the breakthrough with the first public [language model](https://en.wikipedia.org/wiki/Language_model) from OpenAI. Suddenly it was possible to interact with the computer even in complex language. For me, it already feels almost a bit like talking to the ship's computer, perhaps even somewhat more natural – in Star Trek, the voice interface was operated less in dialogue and more in command form.
 ## Why Chatbots Could Be the Better User Interface
 Since language models have interfaces with tools and can essentially communicate with the outside world, I've been wondering whether you couldn't simply use this to effectively build a productivity application. Why do I need a complex user interface when I can just talk to a chatbot and manage the data that way? This has several advantages. You don't have to create a UI, but can focus entirely on data management. Users don't have to learn the system visually, study dialogs and interfaces, or worry about the "correct" workflow. On the contrary: the system thinks along and assists with the work. The input language is irrelevant; I can even operate the system in Swiss German with an Appenzell dialect. Minor linguistic errors are recognized and compensated for. However, you don't actually find completely dialog-based operation of business applications. While Microsoft builds a Copilot into every product, when you call it up in Teams, it can't access chats, and Outlook can't write emails either – at least not when I last tried it in fall 2025.
 ## A Very Simplified Dialog-Based Member Management System as an Experiment
 For over a year now, I've been asking myself whether you could build such a dialog-based application – and how. At first, I toyed with the idea of testing it with the online registration form for the playgroup in the village: so that you simply talk to a chatbot that asks all the questions to parents who want to register their child. Back then I tried it with ChatGPT and the tools functions. However, the implementation was too complex and time-consuming for me.
 With the current models and the [Model Context Protocol (MCP)](https://en.wikipedia.org/wiki/Model_Context_Protocol) developed by Anthropic, new possibilities are emerging. Time for a second attempt. This time I chose a simple scenario: member management. The code for this experiment can be found at [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber). The idea is that you take the model and chatbot of your choice that supports MCP calls and use it to operate the database interface. As a first step, I defined a simple table for members in a [SQLite](https://en.wikipedia.org/wiki/SQLite) database. The database can be replaced later, for example with PostgreSQL. The MCP server is not directly connected to the database, but communicates with a [GraphQL](https://en.wikipedia.org/wiki/GraphQL) API, which in turn executes the database operations. This has the advantage that you could easily connect another application, such as a web application, to the API at a later time. GraphQL also has the advantage that the schema is documented at all times and can be made available to a chatbot again via MCP to define queries itself.
 ## The Brave New World with Many Possibilities?
 Now some very concrete applications are conceivable that would not be possible or only difficult to implement with a traditional user interface if you consistently optimize them for voice interaction:
 - "Attached is an Excel list of members to be entered. Open the list and save it to the database."
 - "Export me a CSV list with email address and last name of members who were registered in the last 6 months. Since we don't record gender, try to define the salutation based on the first name. If this is not possible, choose a neutral salutation with first and last name. The final CSV list should contain: creation date, salutation, last name, email address."
 - "Count how many members are distributed across Switzerland by canton. Which canton has the most members?"
 With this, we're already very close to the example of verbal communication with the ship's computer of the Starship Enterprise.
 But is this also practical in reality? Does it result in a productivity gain, and how reliable is the collaboration? These are questions that we will hopefully get answers to soon. Personally, I see it as motivating, because in the long run, people find it more pleasant to discuss and work together with someone on equal footing than to click through anonymous interfaces.
@@ -0,0 +1,38 @@
 ---
 title: "Computer, …"
 date: 2025-11-25
 description: "Moderne Sprachmodelle machen es möglich, mit dem Computer fast wie in Star Trek zu diskutieren. Ein Experiment mit dialogbasierter Mitgliederverwaltung zeigt, wie Chatbots komplexe Anwendungen steuern können."
 translationKey: "dialogbasierte-anwendungen-post"
 ---
 **TL;DR:** Moderne Sprachmodelle machen es möglich, mit dem Computer fast wie in Star Trek zu diskutieren. Statt komplizierter Programme könnte ein Chatbot die Mitglieder verwalten, Daten importieren und Auswertungen machen. So werden Aufgaben einfacher, weil man nur noch in klarer Sprache beschreiben muss, was man braucht. Ob das im Alltag wirklich zuverlässiger und produktiver ist als klassische Oberflächen, muss sich erst noch zeigen.
 🔗 **Source Code zu meinem Experiment:** [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber)
 ## Vom Science-Fiction zum Durchbruch: Wie Sprachmodelle die Computer-Interaktion revolutionieren
 Seit meiner Kindheit hat mich die Serie [Star Trek: The Next Generation](https://de.wikipedia.org/wiki/Star_Trek:_The_Next_Generation) in den Bann gezogen. Die Interaktion mit dem Bordcomputer in menschlicher Sprache war einer der Aspekte, die mich faszinierten und an die ich mich gut erinnere. Mit dem Stichwort „Computer, …" konnte die Besatzung mit dem System in Dialog treten, um beispielsweise Analysen des Schiffszustands abzufragen, nach Lebensformen zu scannen oder eine andere Besatzung zu kontaktieren.
 Für mich war das bis heute Science-Fiction. Zwar gab es immer mal wieder Versuche, solche Sprachassistenten zu bauen – eines der ersten, mit denen ich anno 2003 herumexperimentiert habe, war A.L.I.C.E. – aber wirklich brauchbar waren meinem Gusto nach nicht einmal Siri, Alexa und Co. Mit dem ersten öffentlichen [Sprachmodell](https://de.wikipedia.org/wiki/Sprachmodell) von OpenAI kam nun der Durchbruch. Plötzlich war es möglich, selbst in komplexer Sprache mit dem Computer zu interagieren. Es fühlt sich für mich schon fast ein bisschen wie das Sprechen mit dem Bordcomputer an, vielleicht sogar etwas natürlicher – in Star Trek wurde das Sprachinterface weniger im Dialog, sondern eher in Befehlsform bedient.
 ## Warum Chatbots die bessere Benutzeroberfläche sein könnten
 Seit Sprachmodelle Schnittstellen mit Tools besitzen und sozusagen mit der Aussenwelt kommunizieren können, frage ich mich, ob man das nicht auch einfach nutzen kann, um effektiv eine Produktivitätsanwendung zu bauen. Wieso brauche ich eine komplexe Bedienungsoberfläche, wenn ich auch einfach mit einem Chatbot sprechen kann und so die Daten verwalte? Das hat einige Vorteile. Man muss keine UI erstellen, sondern kann sich ganz auf die Verwaltung der Daten konzentrieren. Die Anwender müssen das System nicht visuell erlernen, keine Dialoge und Oberflächen studieren und sich nicht um den „richtigen" Arbeitsablauf kümmern. Im Gegenteil: Das System denkt mit und assistiert bei der Arbeit. Die Sprache der Eingabe ist irrelevant, ich kann das System sogar auf Schweizerdeutsch mit Appenzeller Dialekt bedienen. Kleinere sprachliche Fehler werden erkannt und ausgeglichen. Die komplett dialogbasierte Bedienung von Business-Applikationen findet man aber eigentlich nicht. Zwar verbaut Microsoft in jedem Produkt einen Copilot, aber wenn man das Ding in Teams aufruft, kann es nicht auf die Chats zugreifen, und Outlook kann auch keine Mails schreiben – zumindest nicht, als ich es im Herbst 2025 das letzte Mal versucht habe.
 ## Ein sehr vereinfachtes dialogbasiertes Mitgliederverwaltungssystem als Experiment
 Nun frage ich mich seit etwas über einem Jahr immer wieder, ob man so eine dialogbasierte Anwendung bauen könnte – und wie. Zuerst spielte ich mit dem Gedanken, es mit dem Online-Anmeldeformular für die Spielgruppe im Dorf zu testen: Also, dass man einfach mit einem Chatbot redet, der den Eltern, die ihr Kind anmelden wollen, alle Fragen stellt. Damals versuchte ich es mit ChatGPT und den Tools-Funktionen. Die Implementation war mir aber zu komplex und langwierig.
 Mit den aktuellen Modellen und dem von Anthropic entwickelten [Model Context Protocol (MCP)](https://en.wikipedia.org/wiki/Model_Context_Protocol) ergeben sich nun neue Möglichkeiten. Zeit für einen zweiten Anlauf. Diesmal habe ich ein simples Szenario gewählt: eine Mitgliederverwaltung. Der Code für dieses Experiment findet sich unter [https://codeberg.org/gurix/clubber](https://codeberg.org/gurix/clubber). Die Idee ist, dass man das Modell und den Chatbot seiner Wahl nimmt, der MCP-Calls unterstützt, und damit die Schnittstelle zur Datenbank bedient. In einem ersten Schritt habe ich eine simple Tabelle für Mitglieder in einer [SQLite](https://de.wikipedia.org/wiki/SQLite)-Datenbank definiert. Die Datenbank kann später ausgetauscht werden, beispielsweise mit PostgreSQL. Der MCP-Server ist nicht direkt mit der Datenbank verbunden, sondern kommuniziert mit einer [GraphQL](https://de.wikipedia.org/wiki/GraphQL)-API, die ihrerseits die Datenbankoperationen ausführt. Dies hat den Vorteil, dass man zu einem späteren Zeitpunkt auch problemlos eine andere Applikation, beispielsweise eine Webapplikation, an die API anbinden könnte. GraphQL hat darüber hinaus den Vorteil, dass das Schema jederzeit dokumentiert ist und wieder via MCP einem Chatbot zur Verfügung gestellt werden kann, um selbst Abfragen zu definieren.
 ## Die schöne neue Welt mit vielen Möglichkeiten?
 Nun sind einige ganz konkrete Anwendungen denkbar, die so mit einem klassischen User Interface nicht oder nur schwer umsetzbar wären, wenn man sie konsequent auf Sprachinteraktion optimiert:
 - „Im Anhang befindet sich eine Excel-Liste mit Mitgliedern, die zu erfassen sind. Öffne die Liste und speichere diese in der Datenbank."
 - „Exportiere mir eine CSV-Liste mit E-Mail-Adresse und Nachname der Mitglieder, die in den letzten 6 Monaten erfasst wurden. Da wir das Geschlecht nicht erfassen, versuche anhand des Vornamens die Anrede zu definieren. Ist dies nicht möglich, wähle eine neutrale Anrede mit Vor- und Nachname. Die finale CSV-Liste soll beinhalten: Erstelldatum, Anrede, Nachname, E-Mail-Adresse."
 - „Zähle, wie viele Mitglieder über die Schweiz nach Kantonen verteilt sind. In welchem Kanton leben die meisten Mitglieder?"
 Damit sind wir dem Beispiel mit der verbalen Kommunikation mit dem Bordcomputer des Raumschiffs Enterprise schon sehr nahe.
 Doch ist dies in der Realität auch praktikabel? Ergibt sich daraus ein Produktivitätsgewinn, und wie zuverlässig ist die Zusammenarbeit? Das sind Fragen, die wir hoffentlich bald beantwortet bekommen. Ich persönlich sehe es als Motivation, denn Menschen finden es auf Dauer angenehmer, mit jemandem auf Augenhöhe zu diskutieren und zusammenzuarbeiten, als anonyme Oberflächen durchzuklicken.
@@ -0,0 +1,51 @@
 # Proposal: Add Dialogbasierte Anwendungen Blog Post
 ## Context
 Create a new bilingual blog post based on Notion content about dialog-based applications and language model interactions. The post explores how modern language models enable Star Trek-like computer interactions and includes a practical experiment with a member management system.
 ## Motivation
 This blog post:
 - Shares a practical exploration of dialog-based interfaces using language models
 - Documents a real-world experiment with MCP and GraphQL
 - Demonstrates the potential of conversational UI for business applications
 - Provides both German and English versions for broader reach
 ## Scope
 ### In Scope
 - Create new blog post page bundle under `content/blog/dialogbasierte-anwendungen/`
 - German version (original from Notion)
 - English version (AI-translated)
 - Proper frontmatter with title, date, description
 - All external links and references preserved
 - Validation that post renders correctly in Hugo
 ### Out of Scope
 - No changes to existing blog posts
 - No template or layout modifications
 - No Hugo configuration changes
 - No new images or assets (uses external links)
 ## Dependencies
 None. This is a new content addition that doesn't affect existing functionality.
 ## Risks
 Low risk. Adding new content only, no structural changes.
 ## Success Criteria
 - Blog post exists in both German and English
 - Content accurately reflects Notion source
 - English translation is natural and maintains meaning
 - Hugo builds successfully
 - Post displays correctly in both languages
 - All links are functional
 - OpenSpec validation passes
 ## Related Changes
 None. First implementation of blog post content addition workflow.
@@ -0,0 +1,167 @@
 # Spec: Blog Post - Dialogbasierte Anwendungen
 ## Overview
 Specification for the bilingual blog post "Computer, ..." about dialog-based applications using language models. Uses translated URL slugs with separate directories linked via translationKey.
 ## ADDED Requirements
 ### Requirement: Blog post directory structure with translated slugs
 The blog post MUST exist in separate directories for German and English with appropriate URL slugs.
 **Rationale**: Using translated slugs provides better SEO and user experience, with language-appropriate URLs.
 #### Scenario: Directories created with translated slugs
 **Given** the Hugo content directory structure
 **When** creating the new blog post
 **Then** a directory `content/blog/dialogbasierte-anwendungen/` must exist for German
 **And** a directory `content/blog/dialog-based-applications/` must exist for English
 **And** German directory must contain `index.de.md`
 **And** English directory must contain `index.en.md`
 **And** both files must include `translationKey: "dialogbasierte-anwendungen-post"` in frontmatter
 ---
 ### Requirement: German blog post content
 The German version MUST accurately represent the Notion source content.
 **Rationale**: Preserve the original German text exactly as written by the author.
 #### Scenario: German content matches Notion source
 **Given** the Notion page content at https://www.notion.so/Computer-2b5c4dc46de08053954ff3a14b171b47
 **When** creating the German blog post file
 **Then** the content must match the Notion source text
 **And** all formatting (headings, lists, emphasis) must be preserved
 **And** all external links must be preserved
 **And** the TL;DR section must be included
 **And** the Codeberg repository link must be included
 #### Scenario: German frontmatter is correct
 **Given** the blog post requirements
 **When** creating the German blog post
 **Then** the frontmatter must use YAML format (three dashes)
 **And** must include `title: "Computer, …"`
 **And** must include `date: 2025-11-25`
 **And** must include `translationKey: "dialogbasierte-anwendungen-post"`
 **And** must include a `description` field with appropriate summary text
 **And** must be valid YAML syntax
 ---
 ### Requirement: English blog post translation
 The English version MUST be a natural, accurate translation of the German content.
 **Rationale**: Make the content accessible to English-speaking readers while maintaining technical accuracy and readability.
 #### Scenario: English translation is natural and accurate
 **Given** the German blog post content
 **When** creating the English translation
 **Then** the translation must convey the same meaning as the German original
 **And** must use natural English phrasing and idioms
 **And** must maintain technical accuracy for all concepts
 **And** must preserve the same structure (sections, lists)
 **And** Star Trek references must be preserved (universally known)
 #### Scenario: English frontmatter is correct
 **Given** the blog post requirements
 **When** creating the English blog post
 **Then** the frontmatter must use YAML format (three dashes)
 **And** must include `title` with natural English translation
 **And** must include `date: 2025-11-25` (same as German)
 **And** must include `translationKey: "dialogbasierte-anwendungen-post"`
 **And** must include a `description` field with English summary
 **And** must be valid YAML syntax
 #### Scenario: External links are adapted appropriately
 **Given** external reference links in the German version
 **When** creating the English translation
 **Then** Wikipedia links should point to English Wikipedia versions where applicable
 **And** code repository links (Codeberg) must remain unchanged
 **And** all links must be functional
 ---
 ### Requirement: Content formatting and structure
 Both versions MUST use proper markdown formatting consistent with Hugo blog posts.
 **Rationale**: Ensure consistent rendering and readability across the blog.
 #### Scenario: Markdown structure is correct
 **Given** the blog post content
 **When** creating the blog post files
 **Then** headings must use proper markdown hierarchy (##, ###)
 **And** lists must use proper markdown syntax
 **And** links must use markdown link syntax `[text](url)`
 **And** emphasis must use proper markdown (*italic*, **bold**)
 **And** code references must use inline code backticks where appropriate
 #### Scenario: Special characters are handled correctly
 **Given** the blog post contains German umlauts and special characters
 **When** creating the blog post files
 **Then** files must be saved with UTF-8 encoding
 **And** all special characters must render correctly (ä, ö, ü, ß, …)
 ---
 ### Requirement: Hugo build compatibility
 The blog posts MUST build successfully with Hugo and render correctly.
 **Rationale**: Ensure the content integrates properly with the existing Hugo site.
 #### Scenario: Hugo builds successfully
 **Given** the new blog post files
 **When** running `hugo build`
 **Then** the build must complete without errors
 **And** no warnings related to the new blog post must be generated
 #### Scenario: Blog posts are accessible at correct translated URLs
 **Given** a successful Hugo build
 **When** viewing the site
 **Then** the German version must be accessible at `/de/blog/dialogbasierte-anwendungen/`
 **And** the English version must be accessible at `/en/blog/dialog-based-applications/`
 #### Scenario: Blog posts appear in blog listings
 **Given** a successful Hugo build
 **When** viewing the blog index pages
 **Then** the new post must appear in the German blog listing at `/de/blog/`
 **And** the new post must appear in the English blog listing at `/en/blog/`
 **And** the post must display with correct title and description
 #### Scenario: Language switcher works correctly
 **Given** both language versions with matching translationKey
 **When** viewing either version of the blog post
 **Then** the language switcher must link to the corresponding translation
 **And** switching from German to English must navigate to `/en/blog/dialog-based-applications/`
 **And** switching from English to German must navigate to `/de/blog/dialogbasierte-anwendungen/`
 ---
 ### Requirement: Content validation
 The implementation MUST pass OpenSpec validation.
 **Rationale**: Ensure compliance with project standards and specification requirements.
 #### Scenario: OpenSpec validation passes
 **Given** the completed implementation
 **When** running `openspec validate add-dialogbasierte-anwendungen-post --strict`
 **Then** validation must pass with no errors
 **And** no warnings should be generated
@@ -0,0 +1,36 @@
 # Tasks: Add Dialogbasierte Anwendungen Blog Post
 ## Implementation Tasks
 1. **Create blog post directory structure**
   - Create `content/blog/dialogbasierte-anwendungen/` directory
   - Set up page bundle for bilingual content
 2. **Create German blog post**
   - Create `content/blog/dialogbasierte-anwendungen/index.de.md`
   - Add YAML frontmatter with title, date, description
   - Transfer content from Notion source
   - Preserve all formatting, links, and structure
   - Verify markdown rendering
 3. **Create English blog post**
   - Create `content/blog/dialogbasierte-anwendungen/index.en.md`
   - Add YAML frontmatter with translated title, date, description
   - Create natural English translation maintaining technical accuracy
   - Adapt Wikipedia links to English versions where applicable
   - Verify markdown rendering
 4. **Validate implementation**
   - Run `openspec validate add-dialogbasierte-anwendungen-post --strict`
   - Resolve any validation issues
 5. **Test Hugo build**
   - Run `hugo build`
   - Verify no build errors
   - Check both German and English versions render correctly
   - Verify all links are functional
 6. **Review and commit**
   - Review generated content
   - Create git commit with conventional commit message
   - Ready for user review before merging to main