Antragsgrün 3.7

Jetzt, wo ich schon seit ein paar Wochen an der neuen Version 3.8 von Antragsgrün arbeite, wird es auch langsam einmal Zeit, Version 3.7 offiziell zu veröffentlichen – was hiermit getan ist. 🙂

Diese Version wurde großteils vom Deutschen Bundesjugendring in Auftrag gegeben, der wie viele seiner Mitgliedsorganisationen inzwischen auch regelmäßig Antragsgrün einsetzt. Das genaue Einsatzszenario des DBJRs unterscheidet sich dabei aber doch deutlich von dem, wie Antragsgrün bei Bündnis 90 / Die GRÜNEN eingesetzt wird: vor allem das Überarbeiten des Antrags, bei dem die Änderungen der Änderungsanträge auf einer Präsenzveranstaltung eingepflegt werden, spielt hier eine große Rolle. Die wichtigsten Neuerungen in der Version 3.7 beziehen sich also auch auf diese Funktion.

Aber auch bei der Darstellung der Änderungen in Änderungsanträgen gab es eine ganze Reihe an Verbesserungen, besonders wenn längere Textpassagen davon betroffen sind. Insbesondere gibt es nun auch die Möglichkeit, Änderungsanträge als „Globalalternative“ zu kennzeichnen, die daraufhin separat dargestellt werden.

Eine der wichtigsten Neuerungen ist aber nicht-technischer Natur: es gibt nun erstmals auch ein Handbuch, das die wesentlichen Funktionen von Antragsgrün beschreibt.

Eine genaue Liste der Änderungen in der neuen Version gibt es im Changelog.

Stadtpolitik Transparent / Open Source Ratsinformationssystem

Über zwei Jahre ist es her, dass ich München Transparent veröffentlicht hatte – ein Projekt, das ich über mehrere Jahre hinweg zuerst alleine, später zusammen mit Konstantin Schütze und Bernd Oswald in meiner Freizeit entwickelt hatte. Die Seite ist nahezu durchgehend sehr gut angenommen worden, und obwohl wir nie größer Werbung dafür machten und die Weiterentwicklung seitdem zugegebenermaßen eher auf Sparflamme lief, hat sie täglich zwischen 400 und 500 Besucher. Bürgerinnen und Bürger Münchens können davon profitieren, dass sie E-Mail-Benachrichtigungen erhalten, wenn es Beschlüsse oder Auskünfte aus dem Stadtrat oder den Bezirksausschüssen zu ihrem Lebensumfeld gibt, Journalist*innen und Mitarbeiter*innen der Stadtverwaltung schätzen die unkomplizierte Suchfunktionen.

Als der Prototype Fund ausgerufen wurde, eine recht interessante Kooperation aus der Open Knowledge Foundation (OKF), dem Deutschen Luft- und Raumfahrtzentrum (DLR) und dem Bundesministerium für Bildung und Forschung (BMBF), hatten Konstantin unabhängig voneinander die selbe Idee: die Erfahrungen von München Transparent nutzen, um ein neues Ratsinformationssystem zu schreiben, das nicht nur auf München zugeschnitten ist, sondern sich für beliebige Kommunen einsetzen lässt – selbstverständlich als Open Source.

Die Bewerbung und die Vorbereitung nahm dabei einiges an Zeit in Anspruch: die Bewerbungsphase lief im März, im Juni schließlich bekamen wir den erhofften Anruf mit der Bestätigung, von Juni bis Juli hieß es dann, alle notwendigen Unterlagen sammeln, GbR gründen, Konto eröffnen, und jetzt, Anfang September, geht es endlich los! Heute fand der Kick-Off-Workshop in Berlin statt, bei dem wir die anderen geförderten Teams kennenlernen durften.

Zuerst heißt es einmal, den genauen Projektumfang abzustecken und die Arbeitsaufteilung festzulegen. Konstantin und ich haben recht unterschiedliche Schwerpunkte, was sich aber recht gut ergänzen dürfte: durch seine Arbeit am OParl-Standard hat Konstantin bereits viel Erfahrung mit der Modellierung von RIS-Daten und wird sich besonders um die Such-Funktionalität sowie das Backend kümmern, ich interessiere mich vor allem für die Geodaten, die Benachrichtigungs-Funktionalität sowie die Benutzerverwaltung und werde wohl auch größere Teile des Frontends übernehmen.

Generell ist das Ziel, ein Frontend für Ratsinformationssysteme zu schaffen, das sich aus den öffentlichen Daten eines existierenden RIS-Systems speist – Rechte-Verwaltung, interne Dokumente und dergleichen nehmen wir derzeit explizit aus – das sich möglichst einfach für andere Städte anpassen lässt. OParl wird dabei eine wichtige Rolle spielen, da es der einzige Standard ist, über den RIS-Daten maschinenlesbar ausgelesen werden können, was eine Voraussetzung für unser System ist (um nicht wie bei München Transparent für jede Stadt aufwändig einen Scraper schreiben zu müssen). Wir wollen das System dabei auf für mindestens eine Stadt prototypisch implementieren, schon alleine um die Vorteile unseres Systems anschaulich darstellen zu können. Welche Stadt das sein wird, werden wir aber erst evaluieren müssen.

 

PS: Die Bewerbungsphase für die dritte Runde des Prototype Funds läuft noch – wer also auch Open Source Anwendungen entwickelt und sich für eine Förderung interessiert, kann sich noch bis Ende September bewerben.

Muenchen.de

Seit diesem Jahr arbeite ich als regelmäßiger Freelancer bei der „Portal München Betriebs-GmbH“ – oder besser bekannt einfach als „muenchen.de“, also dem offiziellen Münchner Stadtportal.

Nikolaus Gradl, den ich schon seit seiner Stadtratszeit kenne, hatte mich als einer der Projektleiter dort eingeladen und mit einem Projekt geködert, bei dem ich nach München Transparent wohl ein recht naheliegender Kandidat war: der Web-Umsetzung der Münchner Rathaus Umschau, einer werktäglich erscheinenden „Zeitschrift“ der Stadtverwaltung, die neben einer Printversion bisher nur im PDF-Format erschienen ist. Die Herausforderung dabei war, das so in den bisherigen Prozess der Rathaus Umschau zu integrieren, dass dieser erst einmal weit gehend unverändert weiter laufen kann und das PDF auch weiterhin die „Referenzfassung“ bleibt. In der Praxis heißt das, dass die Web-Version hauptsächlich durch ein automatisiertes Parsen des PDFs erstellt wird. Das PDF wird dabei in die einzelnen Meldungen, Terminhinweise, Anträge usw. zerlegt, analysiert und dann veröffentlicht. Das ist sicher nicht die eleganteste Lösung (PDFs wieder zurück in Text umzuwandeln ist leider nicht ganz so komplikationsfrei wie man annehmen könnte), aber hier erst einmal das zweckmäßigste.

Da die PHP-Anwendungen im muenchen.de-Umfeld (der Kern von muenchen.de selbst läuft nicht unter PHP) hauptsächlich auf Laravel basieren, war das außerdem einmal eine gute Gelegenheit, mich damit intensiver zu beschäftigen – sonst hatte ich ja hauptsächlich mit Yii und früher noch mit Zend gearbeitet. Mein persönlicher Favorit bleibt aber bis auf weiteres Yii2. 😀

Ansonsten geht es technisch recht bislang recht abwechslungsreich zu: ein automatischer Konverter von HTML nach AMP war dabei, mit München 360° die Web-Umsetzung einer VR-App auf Basis des Tools krpano, und aktuell ein Projekt, bei dem ich einmal mit Angular2 und Typescript auf Tuchfühlung gehen kann. Typescript finde ich sehr cool, da ich inzwischen ein recht großer Freund statischer Typisierung bin. Mit Angular 2… komme ich auch langsam zurecht, auch wenn ich das 1er darin eigentlich gar nicht mehr wiedererkenne. Wahrscheinlich wäre es sinnvoller, darin gleich ein komplett unabhängiges, neues Framework zu sehen, und weniger einen Nachfolger von Angular 1. Für größere Projekte sehe ich auf alle Fälle die Vorteile gegenüber dem 1er, auch wenn es um einiges komplizierter erscheint.

OpenSlides 2.1

Bei der demnächst neu erschienen Version 2.1 von OpenSlides hatte ich die Gelegenheit, auch ein paar wichtigere neue Funktionen beizutragen: die Zeilennummerierung, das Inline-Bearbeiten von Anträgen sowie die Verwaltung von Änderungswünschen inkl. Änderungsansicht. Alles sind natürlich Funktionen, von der Art, mit der ich bei Antragsgrün bereits Erfahrung gesammelt habe, auch wenn sich die konkrete Implementierung schon allein deshalb maßgeblich unterscheidet, dass sie bei Antragsgrün hauptsächlich serverseitig in PHP implementiert, während OpenSlides hauptsächlich AngularJS-basiert (mit minimalem Python-Backend) ist. Das hat Vor- und Nachteile: grundsätzlich ist das Interface von OpenSlides dadurch natürlich deutlich responsiver. Gerade bei den aufwändigeren Algorithmen (Zeilennummern und Änderungsansichten sind komplizierter, als man anfangs oft meint) und bei längeren Texten stellt das aber auch höhere Ansprüche an die Leistungsfähigkeit des Client-Rechners, und mindestens an einer Stelle konnten wir aus diesem Grund auch nicht die beste Implementierung wählen.

Spannend war auch das Erzeugen des PDFs auf Basis der JavaScript-Bibliothek PDFMake. Es ist einerseits cool, dass es überhaupt funktioniert, PDFs rein clientseitig im Browser zu erzeugen – andererseits sind wir auch an einige problematische Einschränkungen gestoßen. Wobei der Antragsgrün-Ansatz, auf LaTeX bzw. XeTeX als Backend fürs PDF-Rendering zu setzen, auch nicht unproblematisch ist.

Ich bin auf alle Fälle gespannt, wie es sich weiter entwickelt – und wie sich das Zusammenspiel zwischen OpenSlides und Antragsgrün weiterentwickelt. Anders als einige andere sehe ich die zwei Tools ja auch immer noch als eher komplementär zueinander, und weniger als Konkurrenz. Auf alle Fälle wird ein weiteres Betätigungsfeld sein, die Schnittstellen zwischen den beiden Tools weiter zu verbessern.

pflege.de

Seit Ende Oktober bin ich nun selbstständig, und nach zwei Weiterentwicklungs-Sprints für Antragsgrün im Auftrag vom Grünen-Bundesverband einerseits und dem Deutschen Bundesjugendring andererseits bin ich nun im ersten größeren Projekt: bei der Seite pflege.de, die im hübschen Hamburg sitzt.

Moment, Hamburg?

Ja, die Situation ist tatsächlich: ich wohne weiterhin in München, arbeite unter der Woche aber in Hamburg. Mein erster Gedanke bei der Idee war, einmal die Woche mit dem Zug zwischen München und Hamburg pendeln geht gar nicht. Andererseits: vor wenigen Monaten bin ich erst über 15.000km mit dem Zug von München nach Saigon gefahren und habe das als erholsamen Urlaub empfunden, da können mich ein paar Stunden im ICE nun auch nicht mehr schocken.

Nach einer anfänglichen Überraschung – als PHP-/JavaScript-/HTML-Entwickler angeheuert, durfte ich stattdessen erst mal hauptsächlich auf Ruby on Rails, CoffeeScript und HAML programmieren – hab ich mich inzwischen recht gut eingelebt. Und das das eigentliche Projekt, für das ich ins Boot geholt wurde, hat nun auch den ersten großen Meilenstein erreicht: den Relaunch des Content-Management-Systems. Zum Glück auf PHP-Basis. 🙂

Screenshot von pflege.de (nach dem Relaunch)

Converting HTML to OpenDocument Text and Spreadsheet

I moved one of the components of Antragsgrün into a separate library, as it might be useful for other projects: HTML2OpenDocument converts formatted HTML content to OpenDocument Text- and Spreadsheet-Files (ODT / ODS). It can handle basic formattings like bold, italic, underlined, strike-through, inserted and deleted text. Lists are supported in Text-Files. The library is licenced under the MIT licence and is available on GitHub and on Packagist / Composer.

Radtour bei Yangshuo

Endlich hab ich es geschafft: eine Radtour. Im Umland von Yangshou, das ich mit dem Bus erreichte, war das zum Glück auch sehr leicht zu organisieren: Fahrradverleiher gibt es jede Menge und man kommt trotz der vielen Berge entlang dem Fluss sehr leicht ebenerdig voran. Bei der Rückfahrt hab ich mich dann doch völlig verfahren, was dazu geführt hat, dass ich das Fahrrad ein, zwei Kilometer durch Reisfelder schleppen durfte und etwa ein Dutzend Mal bei Einheimischen nach dem Weg fragen musste. Kurz: ein großes Spaß und unbedingt empfehlenswert. (Das Dorf Yanghou selbst ist sehr auf Tourismus ausgelegt, aber sobald man von den Hauptschlagadern weg ist, ist es eine himmlische Idylle.)

Guilin

Guilin wirkt als “Stadt zwischen den Bergen” fast schon surreal. Die Stadt selbst ist völlig flach, nur immer wieder völlig abrupt hineingeklotzte Berge (Karstberge). Ideal für spontane Kurz-Bergwanderungen.

Bezirksausschuss Laim: Website

Vor wenigen Tagen ging nach langer Vorbereitungszeit endlich die neue Website des Laimer Bezirksausschuss online:

Screenshot der Website des Bezirksausschuss Laim (Internale)

Die lange Vorbereitungszeit lag dabei nicht an der eigentlichen Gestaltung – technisch ist die Seite eher trivial, wie man denke ich recht schnell sieht. Ungewohnt war für mich nur, einmal komplett ohne serverseitigen Skriptsprachen zu arbeiten und stattdessen nur auf statische HTML-Seiten zu setzen – aber dank Jekyll & co ist das ja inzwischen auch kein Problem mehr. Die rechtliche Klärung dauerte dafür aus nicht ganz nachvollziehbaren Gründen locker fünfmal so lang wie die eigentliche Programmierung. Na ja, Ende gut, alles gut – jetzt ist sie endlich da und alle sind glücklich. 🙂

Choosing Android’s System Sounds for Cordova Push Notifications, using Native Configuration Screens

One of the features most wished for in one of my Cordova-based android apps was to let the users choose another sound for push notifications, or to disable sound altogether (without having to mute the whole smart phone and still keeping vibration). The Push Plugin supports custom sounds, however all sound resources have to be embedded in the app. In my case, I wanted to let the users choose among the system sounds provided by Android itself, which apparently isn’t possible without some major changes to the plugin.

Here, I’m going to outline the changes necessary to integrate Android’s native RingtonePreference dialog into a Cordova-based app to let the users choose another notification sound. I’ve published the modified plugin that should work on android projects on Github.

Screenshot_2015-04-29-18-13-18Screenshot_2015-04-29-18-13-23

Configuration Dialog

Choosing the preferences for push notifications is done in a native android PreferenceScreen that is opened from within the app using a new javascript-method on the pushNotification-Object. The configuration screen is defined by a xml file stored at platforms/android/res/xml/pushsettings.xml:

The referenced strings are stored in platforms/android/res/values/strings-gcm.xml:

Translated versions can be stored in files like platforms/android/res/values-de/strings-gcm.xml

Opening the dialog
First of all, a new activity has to be defined in the platforms/android/AndroidManifest.xml:

The Activity itself is pretty simple, just remember to replace the „CORDOVA_PACKAGE_ID“ by the id of your app (necessary to access the R.xml.pushsettings-resource):

This activity is called from PushPlugin.java’s execute-method, something like:

The JavaScript-method to call this in PushNotification.js is:

With all these changes applied, a call to plugins.pushNotification.showPushSettings() should open the configuration dialog and let the user apply her desired notification sound. The settings are stored automatically in android’s SharedPreferences. In the source code of the plugin, I also added a getPushSettings()-method that returns the settings into JavaScript, if you ever need to query these settings.

Using the settings for the notification
The actual notification sound is triggered in GCMIntentService.java’s onMessage-method. The new code reads the settings from the SharedPreferences and acts accordingly:

I’m using the Ringtone.play() instead of the setSound()-method of NotificationCompat.Builder, as the latter one somehow didn’t actually change the sound, even with the URL of the sound provided. I haven’t yet figured out why, but there probably is a solution that’s more elegant than the one showed above.
That’s it. Have fun! 🙂