Meine Stadt Transparent, Teil 2: Die Technik

Seit fast vier Monaten entwickeln Tobias Hößl und ich Meine Stadt Transparent (Demo, GitHub). Im ersten Teil ging es darum, wie es dazu kam und warum wir dieses Projekt machen. In diesen Teil geht es um den momentanen Status und die technische Details.

Ziele

Wie in Teil 1 beschrieben gibt es bereits genügend kommerzielle Systeme, die sich hauptsächlich an Verwaltungsmitarbeiter und Stadträte richten, aber für Bürger kaum benutzbar sind. Wir wollen die Lücke eines bürgerfreundlichen Systems füllen. Anders gesagt wollen wir Zugänglichkeit für alle schaffen.

Verständliche Sprache: Existierende Systeme sind oft eine Mischung aus unverständlichen Abkürzungen und Wortmonstern wie „Beschlussvollzugkontrolle“, „Ratsinformationssystem“ und „Anliegenmanagement“, die die meisten Nutzer erst mal googlen müssen. Das macht Thema „Stadtpolitik“ nur noch unsexier als es sowieso schon ist. Wir vermeiden deswegen Abkürzung, Fachbegriffe und Techspeak soweit möglich.

Googlebarkeit: Informationen, die man durch die Suche nicht findet, existieren nicht. Natürlich kann man auch versteckte Daten finden, aber das ist Zeitaufwendig und scheitert oft auch einfach daran, dass man nicht weiß, was überhaupt existiert.

Likability: Politik ist eines dieser Themen, die zwar sehr wichtig aber auch sehr langweilig sind. Deshalb ist es umso wichtiger, dass man eine Website dazu auch benutzen möchte. Technische Perfektion ist schön und gut, aber wenn eine Webseite so interessant ist wie ein Ladebalken wird sich kaum einer freiwillig dort aufhalten. Das heißt nicht, dass wir Seite mit Achievements, Kalendarsprüche und Animationen vollstopfen, aber ein paar Katzenbilder und Eastereggs dürfen es schon sein.

Barrierefreiheit: Politik betrifft alle Menschen. Leider werden die Dokumente in der Regel nur als pdf veröffentlicht, woran wir aber im Moment leider nichts ändern können. Wir versuchen deshalb zumindest die Seite an sich durch html-aria-tags und Linter möglichst Barrierefrei zu halten.

Nachhaltigkeit: Wenn Software nicht so gebaut ist, dass sich gut weiterentwickeln und damit an neue technische Entwicklungen anpassen lässt, veraltet sie und verliert dadurch nach und nach ihre Nutzbarkeit.

Likability durch cat content (Symbolbild)

Frameworks und Bibliotheken

Um diese Ziele umzusetzen brauchen wir einen ganzen Stapel an Technik.

Das Backend ist in pyhton 3 mit django geschrieben. Als Datenbank verwenden wir Mariadb bzw. teilweise sqlite und für die Suche elasticsearch. Synchronisiert werden die Daten über django-elasticsearch-dsl, als Server läuft gunicorn hinter einem nignx. Für das Fontend nutzen wir Bootstrap 4 in django-Templates, dazu etwas javascript in einer npm-es6-babel-webpack-pipeline.

Wir hatten am Anfang überlegt, ein Javascript-Framework zu verwenden, uns dann aber dagegen entschieden. Mit Angular hatten wir beide bereits Erfahrung, wollten es aber aber aus unterschiedlichen Gründen nicht verwenden, genauso wenig verwenden wie vue.js noch React. Bei den meisten anderen Frameworks muss man davon ausgehen, dass sie in der schnelllebigen Javascript-Welt untergehen und damit nicht für ein langfristiges Projekt taugen, wie der Stack Overflow Blog sehr anschaulich gezeigt hat. (Immer noch aktuelle Leseempfehlung dazu: How it feels to learn JavaScript in 2016). Ich persönlich würde am liebsten elm oder rust/webassembly verwenden, leider sind beide aber nicht annähernd ausgereift genug.

Nach 3 Monaten mit Bootstrap bin ich mit unserer Entscheidung immernoch glücklich; Die Dokumentation von Bootstrap ist exzellent, die fertigen Klassen nehmen einem eine Menge Arbeit ab und für zwei nicht-Designer sieht die Seite nicht schlecht aus. Das Design kann später über Themes gut anpasst werden, was z.B. praktisch ist, um die Seite an verschiedene Städte anzupassen. Für Javascript-Bibliotheken brauchen wir außerdem keine Framework-Anbindung.

Die Live Demo

Wir haben eine Live-Demo unter meine-stadt-transparent.de, die echte Daten der Stadt Jülich anzeigt.

Dank des großartigen Github Auto Deploy ist die Demo immer auf dem aktuellen Stand. Das heißt aber auch, dass ein falscher Commit die Seite zerschießen kann (und momentan auch darf).

Der Datenimport

Die Seite ist so gebaut, dass man mit etwas eigenem Python-Code prinzipiell beliebige Daten importieren kann. Damit das Projekt aber nicht nur einen hypothetischen Zweck sondern auch eine realen praktische Nutzen hat, haben wir einen Importer für OParl-Schnittstellen geschrieben. OParl spezifiziert dabei eine API, mit der Daten aus deutschen Ratsinformationssystemen (RIS) in einem einheitlichen json-Format über eine REST-Schnittstelle exportiert werden können. OParl 1.0 wurde zwar komplett ehrenamtlich entwickelt, wird aber mittlerweile von vier großen RIS-Herstellern angeboten bzw. entwickelt. Durch Open.NRW gibt es mittlerweile eine offizielle OParl-Unterstützung in 21 Kommunen mit Sternberg SD.NET. Eine der 21 Kommunen, die Kleinstadt Jülich, nutzen wir für unsere Demo-Seite.

Den Importer zu schreiben war komplexer als gedacht und wir hatten kompliziertere Bugs und andere Probleme. Eines der gößeren Probleme war und ist die Integration von liboparl, da die Integration von gnome-Bibliotheken wie liboparl in Python deutlich schlechter funktioniert als erwartet. (Bedeutet in der Praxis, dass wir python-gobject/gi verwenden müssen, das aber nur mit System-Python und einem symbolischen Link in die virtualenv funktioniert. Das undokumentierte Über-pip-Installieren geht zwar theoretisch, in der Praxis dann aber doch nicht)

Die Installation

Meine Stadt Transparent soll sich möglichst einfach aufsetzen lassen. Dafür haben wir eine Schnellstart-Anleitung im readme, die mittels docker compose alle benötigten Dienste (im Moment mariadb, elasticsearch und django) einrichtet, startet und verbindet. Wegen schlechten Managments bei Docker und dem Datenimport ist immernoch etwas Handarbeit dabei, die wir aber so gering wie möglich halten.

Ausblick

Wir haben noch etwa zwei Monate bis zum Demoday am 28. Februar. Die Hauptaufgaben bis dahin sind ein OParl-Export, eine Änderungshistorie für alle wichtigen Objekte sowie ein paar interne Umbauten.