München und Hamburg

Anfang April hat sich bei mir beruflich nun wieder einiges geändert. Die Zeit des ununterbrochenen Pendelns zwischen München und Hamburg ist nun vorbei und ich werde endlich wieder deutlich mehr Zeit in meiner selbstgewählten Heimatstadt verbringen können. Hamburg hat es mir aber durchaus auch angetan, ich mag die Stadt und werde auch weiterhin ein bis zweimal im Monat dort sein: seit diesem Monat bin ich auf Teilzeitbasis bei web care LBJ / pflege.de als “Head of Development” angestellt, statt wie bisher nur als Freelancer.

Meine selbstständige Tätigkeit behalte ich aber bei, und hatte da auch gleich wieder Glück: auch jetzt seit Anfang April arbeite ich an einem Projekt beim offiziellen Münchner Stadtportal muenchen.de. Da ich mit München Transparent ja auch schon in ähnlichen Gebieten unterwegs war, liegt mir das natürlich thematisch auch sehr.

Codeception: HTML and Accessibility Validation

For my latest web project, Antragsgrün 3, I’m heavily using Codeception for acceptance testing. As I want to ensure that the system validates against the HTML5 standard and is accessible, I’ve written two helpers for Codeception that I want to share: one Helper that validates the current site using the Nu Html Checker (http://validator.github.io/validator/), and one that validates it against WCAG2.0 (A, AA or AAA) or Section 508 using Pa11y.

Both helpers are using the command line tools, so they do not rely on an online web service and can be used offline. While the accessibility validator works with both the PhpBrowser and the Webdriver module of Codeception, the Html Validators needs Webdriver (which, while a bit more difficult to set up, is superior anyway).

Validating the current site is as easy as:

(There are also some parameters for choosing the accessibility standard and to ignore certain errors).

The code and installation instructions are on these two gists:
HTML Validator
Accessibility Validator

Antragsgrün 3 – Aktuelle Planung

In den letzten Wochen und Monaten kam wieder einiges an Schwung in die Weiterentwicklung von Antragsgrün. Da sich momentan eine komplette Überarbeitung des Antragstools abzeichnet, will ich hier die aktuellen Planungen kurz umreißen.

Rückblick

Die erste Version von Antragsgrün hatte ich 2012 für den Landesverband Bayern von Bündnis 90 / Die Grünen geschrieben, um die Antragsverwaltung auf den Landesdelegiertenkonferenzen sowohl für Delegierte als auch die Geschäftsstelle zu vereinfachen. Es unterstützte damals unter anderem schon Anträge, Änderungsanträge, Kommentare und automatisch generierte PDFs. Es war relativ schnell klar, dass auch andere grüne Verbände Interesse daran haben, und dass das anfängliche Modell, für jeden Verband eine neue Instanz zu installieren, nicht wirklich skalierte. Daher folgte schnell Antragsgrün 2, dessen wichtigste Neuerung die Mandantenfähigkeit war – also dass eine zentrale Installation beliebig viele Verbände bedienen kann. Antragsgrün ist damit einerseits Open-Source-Software, die frei auf eigenen Servern installiert werden kann – andererseits aber auch ein zentrales Portal www.antragsgruen.de, über das sich alle grünen Verbände kostenlos ohne technische Kenntnisse eigene Programmdiskussionen einrichten können.

Neue Anforderungen

Nun zeigt sich aber, dass Antragsgrün auch für deutlich mehr als nur reine Antragsarbeit verwendet wird und damit auch ein großer Bedarf für neue Anwendungsszenarien besteht, die momentan nicht oder nur auf Umwegen abgedeckt werden. Beispiele dafür sind Bewerbungen und strukturierte Programmarbeit, was beispielsweise einen Bilder-Upload und deutlich flexiblere Formulare benötigt als Antragsgrün mit seiner momentan noch recht starren Fixierung auf das „Antragstext + Begründung“-Schema liefern kann. Oft gewünscht wird auch eine Tagesordnungsfunktion, bessere Anpassbarkeit in so ziemlich allen denkbaren Gebieten (Wording, Layout, verschiedene Antragsschlüsse, …) und eine bessere Kompatibilität mit verwandten Tools wie OpenSlides und cvtx. Um diese Funktionen einzubauen, müssen einige grundlegende Strukturen von Antragsgrün überarbeitet werden.

Nicht zuletzt gibt es auch einige rein technische Gründe, die für eine größere Überarbeitung sprechen: von den meisten verwendeten Software-Bibliotheken gibt es nach vier Jahren nun große neue Versionen, insbesondere vom zugrunde liegenden PHP-Framework Yii. Und, um ehrlich zu sein: einige grundlegende Design-Entscheidungen beim bisherigen Antragsgrün waren rückblickend schlicht falsch und warten auf Korrektur. Eine Überarbeitung ist außerdem ein guter Anlass, auch endlich automatisierte Tests mit einzubauen, die die allgemeine Softwarequalität langfristig deutlich erhöhen sollte. Zumindest hatten sich zuletzt häufig Fehler eingeschlichen, die beim konsequenten Einsatz von Unit- und Acceptance-Tests vermieden hätten werden können.

Antragsgrün 3 soll mit den eben genannten Punkten und Verbesserungen noch im diesen Sommer erscheinen. Zeitlich ist das zwar ambitioniert, nach meiner aktuellen Einschätzung und mit der bisherigen Vorarbeit und Unterstützung aber realistisch.

Aktuelle Entwicklung

Die konkreten Arbeiten an Antragsgrün 3 begannen schon im Februar diesen Jahres, als sich abzeichnete, dass sowohl ein Grüner Landesverband Interesse an den Bewerbungen und der Tagesordnungsfunktion hat, als auch der Bundesverband Interesse bekundete, Antragsgrün verstärkt einzusetzen. In einem neuen Github-Branch liegt demnach auch schon einiges an Code – natürlich noch in einem recht frühen Zustand, da es bislang nur in meiner Freizeit entwickelt ist. Allerdings sind bereits alle wichtigen Kerntechniken grundlegend implementiert – von der neuen Datenstruktur über einen neu geschriebenen Diff-Algorithmus bis hin zu den Unit- und Acceptance-Tests.

Ein Großteil der Entwicklungsarbeit wird im Juli stattfinden. Im Juli werde ich, dank der Unterstützung durch den Grünen-Bundesverband sowie einiger -Landesverbände, in Vollzeit an Antragsgrün arbeiten können und in dieser Zeit hoffentlich einen Großteil der oben genannten Punkte umsetzen können. Es wird demnach wohl Ende Juli eine erste Beta-Version geben, die erste stabile Version ist für August geplant. Natürlich ist damit dann nicht die Entwicklung ein für alle mal abgeschlossen – nur wird das Tempo wieder stärker davon abhängen, wie viel Freizeit ich habe bzw. ob sich für bestimmte Neuerungen „Sponsoren“ finden.

Technischer Überblick

Achtung: hier folgt viel Technik-Fachsimpelei, das man auch einfach überspringen kann. Ab dem nächsten Abschnitt wird es wieder verständlicher. 🙂

Frameworks

Antragsgrün 3 wird technisch auf das Yii2-Framework aufsetzen, benötigt mindestens PHP 5.5, wird in der Produktivversion aber entweder auf PHP7 oder HHVM laufen.

Als CSS-Framework kommt Bootstrap 3 in der SASS-Variante, oder, falls bis dahin verfügbar, Bootstrap 4.

Für die Unit- und Acceptance-Tests setze ich Codeception ein, plus diverse Tools zur statischen Code-Analyse (PHP Mess Detector, PHP Code Sniffer). Als Coding-Standard verwende ich PSR-2. Noch unschlüssig bin ich bei der Wahl des Continuous-Integration-Tools; aktuell verwende ich noch PHPCI, bin allerdings nicht so ganz zufrieden und möchte daher auch mindestens noch Jenkins und Travis testen.

Es gibt auch schon ein prototypisches Docker-Image; eine Vagrant-basierte Umgebung ist angedacht.

Datenstrukturen und Features

Das große Motto von Antragsgrün 3 ist „Flexibilisierung“ (mit sinnvollen Voreinstellungen):

  • Es wird nicht mehr vorgegeben, aus welchen Bestandteilen ein Antrag, eine Bewerbung etc. genau besteht. Diskussionsvorschläge können beispielsweise nur ein Textfeld haben, Anträge dagegen zwei, und Bewerbungen noch ein Bild und tabellarische Angaben wie Geburtsjahr, KV usw. Zwar gibt es Voreinstellungen, die für die üblichen Verwendungszwecke (Parteitag mit Anträgen und Bewerbungen, Programmdiskussion, …) maßgeschneidert sind, die Strukturen werden aber nicht mehr fest einprogrammiert sein wie das bisherige Antragstext+Begründungs-Schema.
  • Es kann mehrere Dokumententypen pro Veranstaltung / Diskussion geben, die einerseits unterschiedlich strukturiert sind, andererseits aber auch unterschiedliche „Regeln“ haben. Damit ist es beispielsweise möglich, unterschiedliche Antragsschlüsse für Anträge, Satzungsänderungsanträge, Eilanträge und Bewerbungen festzulegen, oder unterschiedliche Voraussetzungen (ein Antrag, der z.B. 5 UnterstützerInnen benötigt, während es für Bewerbungen keine benötigt).
  • Möglichst alle Textbausteine auf einer Seite sollen auf Wunsch anpassbar sein.
  • Es wird die Möglichkeit geben, aus mehreren PDF-Vorlagen für Anträge, Änderungsanträge, Bewerbungen etc. zu wählen.

Weitere Änderungen sind unter anderem:

  • Verbessert werden soll auch die BenutzerInnenverwaltung. Beispielsweise fehlen aktuell noch grundlegende Funktionen wie eine Passwort-Zurücksetzen-Funktion, die nachgerüstet wird.
  • Texte werden nun intern nicht mehr als BBCode, sondern direkt als (normalisiertes) HTML gespeichert. Die Entscheidung für BBCode war indirekt für viele kleinere Probleme verantwortlich, die es bei Antragsgrün momentan noch gibt – auch scheinbar unzusammenhängende Probleme wie die unzulängliche Absatzerkennung bei der Eingabe von Texten.
  • Ein Betrieb auf eigenen Servern soll vereinfacht werden; beispielsweise soll kein eigener E-Mail-Server mehr vorausgesetzt werden.
  • Neben MySQL soll auch SQLite als Datenbank unterstützt werden.
  • Die Liste von AntragstellererInnen und UnterstützerInnen eines Antrags werden sauberer von der User-Tabelle getrennt sein. Die aktuelle Verschränkung dieser beiden Tabellen hatte häufiger für unerwartete Seiteneffekte gesorgt.
  • Die Funktion zur Anzeige von Änderungen wird nun direkt in Antragsgrün implementiert, nicht mehr über eine externe Bibliothek. Dadurch können Probleme hier leichter behoben werden, wie zum Beispiel die oft sehr unvorteilhafte Anzeige, wenn größere Textblöcke als ganzes durch Neue ersetzt werden.

Antragsgrün 4, 5, …

Bei den internen Treffen mit VertreterInnen anderer Landesverbände zeigte sich schon, dass es auch weit über die hier vorgestellten Funktionen noch größere Visionen gibt, die allerdings zeitlich dieses Jahr noch nicht umgesetzt werden können.

Das langfristige Ziel sollte bei Antragsgrün sein, die Arbeit der Antragskommission komplett ohne Medienbrüche abbilden zu können – was schon alleine deshalb herausfordernd ist, da die verschiedenen Antragskommissionen der Verbände teils grundlegend unterschiedlich arbeiten. Solche Medienbrüche, die derzeit noch üblich sind, sind das Ausdrucken von Spreadsheets/Excel-Tabellen, Google Speadsheets, oder die Verwendung anderer Tools für einzelne Aspekte der Antragsbearbeitung.

Auch eine Offline-Variante von Antragsgrün wird immer wieder gewünscht, was aber mit PHP gerade auf Windows leider doch komplizierter ist als beispielsweise mit Python. Ansatzpunkte könnten PHP Desktop oder PHPWebkit sein – allerdings habe ich hier noch keine Praxiserfahrung und wäre auch über sachdienliche Hinweise dankbar. 🙂

Ein weiterer Nachteil von Antragsgrün, auch der kommenden 3er-Version ist, dass es sich nicht in andere Content-Management-Systeme integrieren lässt. Für WordPress punktet hier das cvtx-Plugin von Alexander Fecke, für Typo3 ist mir keines bekannt. Ob eine WordPress- und/oder Typo3-Variante von Antragsgrün realistisch ist, müsste genauer evaluiert werden.

Da auch international keine wirklich mit Antragsgrün vergleichbare (Open-Source-)Software gibt, bietet sich eine Internationalisierung auch geradezu an. Da schon Antragsgrün 3 Mechanismen vorhält, Textbausteine auf der Seite flexibel zu ersetzen, ist auch schon ein erster Schritt in diese Richtung getan.

Using the Ionic Framework for Windows (Phone) 8.1 apps

Update: Most of the patches mentioned here are not necessary anymore, since they have been addressed by the v1.0.0-rc.5 release of the Ionic Framework.

Cordova not only supports Windows Phone 8, but also the new Windows platform, which includes Windows 8, Windows 8.1 and Windows Phone 8.1 apps. Currently, I love creating apps for Android and iOS with the Ionic Framework. So I wondered how difficult it would be to deploy an Ionic-based app to Windows Phone, even though it’s not officially supported (yet). For Windows Phone 8, there are several threads discussing problems and ways around them, like this one. So I concentrated on Windows Phone 8.1, Windows 8.1 and the Windows Push Notification Service. It turned out, that it is in fact possible to run basic Ionic-based apps, although with some major issues.

The Ionic Demo, running as a Windows desktop App

The Ionic Demo, running as a Windows desktop App

Development Environment

You will need at least Windows 8.1 to develop apps for Windows 8.1 and Windows Phone 8.1. The free technical Preview of Windows 10 works as well (except for the App Certification Kit, which is needed when submitting an app to the store).

As an IDE, the free Microsoft Visual Studio Community 2013 with Update 4 (download) works perfectly. When installing Visual Studio, it is important to include all optional features (ie. the Windows Phone 8.0 SDK and the Tools for Maintaining Store Apps For Windows 8).

Other programs I needed:
The Git Bash
NodeJs

Starting the app

Now, the CordovaApp.Phone.jsproj (for Windows Phone 8.1) and CordovaApp.Windows.jsproj (for Windows 8.1) in MyWinApp\platforms\windows\ can be opened with Visual Studio.

Problems and getting around them

1. Security vs. innerHTML

Angular doesn’t work with Windows Phone 8.1 by default, as Angular relies on the innerHTML-property, which is not accessible on Windows Phone 8.1 for security reasons. Trying to start the blank Ionic app results in the following message:

Unhandled exception at line 10951, column 9 in ms-appx://2f930110-8ae3-11e4-b252-af36a362e5f3/www/lib/ionic/js/ionic.bundle.js

0x800c001c – JavaScript runtime error: Unable to add dynamic content. A script attempted to inject dynamic content, or elements previously modified dynamically, that might be unsafe. For example, using the innerHTML property to add script or malformed HTML will generate this exception. Use the toStaticHTML method to filter dynamic content, or explicitly create elements and attributes with a method such as createElement. For more information, see http://go.microsoft.com/fwlink/?

MSOpenTech provides a shim that almost solves the problem. The file winstore-jscompat.js needs to be included before ionic.bundle.js.
However, the shim as it is does not completely solve the problem, as there still occurs an exception that leads to a blank page:

Error: [$compile:tplrt] Template for directive ‘ionTabNav’ must have exactly one root element.
http://errors.angularjs.org/1.3.6/$compile/tplrt?p0=ionTabNav&p1=

Replacing the “cleansePropertySetter(“innerHTML”” block in winstore-jscompat.js by the following code (as suggested by Arjan Snoek) really solves the problem:

Now, the app starts, even the icons work perfectly (unlike with Windows Phone 8.0) and the Tabs are working too.

2. Broken Links in the app (“Search for app in the Store”)

When trying to open a person in the “Chats” tab of Ionic’s demo app, the message “Search for app in the Store” appears and nothing happens inside the app.
This happens because of the URI Scheme of these links: “unsafe:ms-appx://[appid]/www/index.html”. It can be solved by registering the URI schemes with Angular, by adding the following line to the .config-Function of app.js (line 25ff in the demo app):

3. Hidden elements (ng-show / ng-hide) are still visible

ng-show and ng-hide hide elements by adding the CSS-class “ng-hide” to the affected elements.
It seems like the necessary stylesheets are not added to the document automatically, so we need to add the following rule explicitly in the stylesheet (eg. in css/style.css):

4. Scrolling does not work

Unfortunately, this problem seems to be much more complex and I did not find a real solution until now.
However, adding the following CSS-rule to the stylesheets enables the browser-internal scrolling, which works surprisingly well:

This is just a dirty hack, though, and probably breaks a couple of things.

5. Not fixed yet: Back Button

With Windows Phone 8.0, listening on the “backbutton” event was pretty simple, just as with android. On WP8.1, this event is not triggered anymore.
I haven’t figured out how to enable it yet. Any hint would be appreciated.

6. Not fixed yet: Hover/Touch effect is permanent

When starting a touch gesture on a link without clicking it (e.g. when starting to scroll), the hover effect is not disabled afterwards.
This is probably related to the scrolling issue.

AntragsGrün

Heute hat die öffentliche Diskussionsphase des Entwurfs des Wahlprogramms für die kommenden Landtagswahlen in Bayern begonnen. Das ist mir vor allem deshalb einen Eintrag hier wert, da ich (zusammen mit der Netzbegrünung) die Website, auf der das stattfindet, programmiert habe: das “AntragsGrün”.

Die Motivation hinter dem Tool war zuerst hauptsächlich, ein Tool für die Antragsverwaltung für Parteitage zu erstellen, das den Beteiligten die Arbeit erleichtern soll; wer hätte sich vor Ort auf einer LDK, angesichts der Erkenntnis, dass der 18-seitige sorgsam studierte A1 zwischenzeitlich durch einen A1neu ersetzt wurde, nicht auch schon einmal ein Tool gewünscht, das einem einfach nur die Änderungen zwischen den beiden Versionen auflistet? 🙂

Nun, für die bayerische LDK 2012 war ich leider zu spät dran, nächstes Jahr klappt das hoffentlich besser. Dafür waren von meinem ursprünglichen Konzept nur ein paar Erweiterungen nötig, um es für das Wahlprogramm anzupassen – und hier sieht man es auch schon in Aktion: http://parteitool.netzbegruenung.de/

Ich hab den Quellcode auf Github veröffentlicht , zusammen mit einer etwas genaueren Beschreibung des Projekts. In den nächsten Wochen werde ich vermutlich noch damit beschäftigt sein, eventuelle Fehler zu beheben; an weitere Features mache ich mich danach.

Diploma Thesis: System Malfunction Recognition and Response Based on User Behavior

Abstract

Computer systems that observe user behavior in order to detect malfunctions and respond to them are mostly unexplored from a scientific point of view until now. However, they may hold much potential to improve human-computer interaction. This thesis proposes a reference model for such systems. It describes common computer problems and their symptoms, reactions by the users and ways to respond to such problems on system side. Taxonomies covering common use-cases are provided and both psychological and technical aspects are covered.

In order to show the effectiveness of behavior-based malfunction response, three systems were implemented: the Microphone Helper assists the user in configuring the microphone. The Mouse Helper recognizes confused user behavior in situations of mouse cursor freezes.

The  Frustration 2.0 project tries to prevent user frustration when encountering buggy JavaScript-based websites and provides the manufacturer of the website with diagnostic information. The first two projects were evaluated empirically in user studies: the detection rate and the time gains were measured and the opinions of the users about such systems were analyzed. The results indicate that behavior-based malfunction response can be helpful in many cases, but they also show specific problems that have to be considered when designing such systems.

The full diploma thesis (PDF, ~2MB)

GEOS für den C=64

Aufsatz im Rahmen der Übung zu “Mensch-Maschine-Interaktion”, WS 2004/05

Drei Jahre nach Einführung des “Commodore 64” wurde 1985 von “Berkeley Softworks” (BSW) die Benutzeroberfläche GEOS – “Graphic Environment Operating System” – veröffentlicht. Es lehnte sich stark an den damaligen Macintosh an, dem ersten erfolgreichen Heimrechner mit grafischer Oberfläche. GEOS musste zwar mit einer deutlich schwächeren Hardware-Plattform auskommen – der 8bittige C=64 hatte eine Taktfrequenz von nur einem knappen MegaHertz und mit 64kb Arbeitsspeicher gerade einmal ein Zehntel dessen, was genug für jeden ist. Dafür war der C=64 aufgrund des wesentlich geringeren Preises um einiges verbreiteter, weswegen man in einer grafischen Oberfläche für diesen viel Potential sah und diese sehr schnell weiterentwickelte.

GEOS war im Gegensatz zu MacOS kein Betriebssystem, sondern wie das später erschienene Windows nur eine grafische Oberfläche. Es hatte viele Funktionen und Elemente, die man schon von MacOS her kannte: Einfache Dialogboxen, Buttons und Pull-Down-Menüs. Dateien konnten mit Drag&Drop verschoben werden und in einen Papierkorb verschobene Dateien wiederhergestellt werden. Das Menü befindet sich wie bei MacOS am oberen Rand des “Desktops” und variiert von Anwendung zu Anwendung. (“deskTop” war ursprünglich der Titel des Dateimanagers).

In den ersten Versionen gab es “Fenster”, wie wir sie heute kennen, nur in vagen Ansätzen: in der Mitte des Startbildschirms befindet sich ein “Dashboard”, das zwar den Fenstern ähnelt (es gibt eine Titelleiste mit dem Namen des aktuellen Laufwerks und einem Schließen-Button), aber weder verschiebbar noch in der Größe änderbar ist. In den Fenstern befindet sich der Inhalt des jeweiligen Datenträgers, also Programme sowie normale Dateien. Da das Dateisystem der C=64-Floppys von sich aus keine Verzeichnisse unterstützt, gab es anfangs auch unter GEOS keine Unterverzeichnisse. Das war aber auf Grund der ohnehin sehr begrenzten Speicherkapazität der Floppys kaum eine wirkliche zusätzliche Einschränkung. Die Standardansicht des Dateimanagers verwendet Icons für jede Datei. In das “deskTop”-Fenster passen nur acht Dateien auf einmal. Sind mehr als acht Dateien auf einem Datenträger, wird nicht gescrollt, sondern geblättert, indem man ein Icon am links unteren Rand anklickt. Man konnte nur vorwärtsblättern, wobei man von der letzten Seite aus wieder zur ersten kommt. Es ist aber auch möglich, die Icons auszublenden und nur die Dateinamen mit einigen Details wie Dateigröße anzuzeigen – wahlweise sortiert nach Dateiname, Größe oder Dateityp. In diesem Fall wird dann nach unten gescrollt, wenn die Dateien auf einer Seite keinen Platz mehr finden.

Gesteuert wurde GEOS im allgemeinen über ein Gerät, das am Joystick-Port hing; entweder über einen Joystick selbst, oder eine Maus, die einen Joystick emulierte.

Einen großen Reiz von GEOS machte aus, dass es bereits mit einem “What you see is what you get”-Editor ausgeliefert wurde (geoWrite) sowie mit einem Malprogramm (geoPaint), das aber zunächst in Schwarz-Weiß gehalten war. Texte sowie Bilder konnten zwischen Applikationen unter anderem per Drag&Drop ausgetauscht und schließlich auf einem Drucker ausgegeben werden. Mehrere Bitmap-Schriftarten waren bereits vorinstalliert, weitere ließen sich durch extra Schriftpakete nachinstallieren.

Die 1988 veröffentlichte Version 2.0, die unter anderem auch eine Rechtschreibkorrektur mitbrachte, wurde eine Zeitlang direkt mit dem C=64 im Bundle ausgeliefert, was für eine große Verbreitung sorgte. Weitere Applikationen, die mit der Zeit hinzu kamen, waren unter anderem ein Tabellen-Kalkulationsprogramm und eine Datenbank. Wegen der großen Beliebtheit und dem Kult-Status unter vielen Computer-Freaks wird das System auch heute noch weiter gepflegt – TCP/IP- und Modem-Treiber gibt es ebenso wie einen grafischen Browser (“The Wave”, entwickelt im Jahr 2000).

Insbesondere letztgenannte Entwicklungen waren aber nur dadurch möglich, dass auch der C=64 hardwaremäßig weiterentwickelt wurde. Neben dem Nachfolgemodell C=128 gab es später auch fortschrittlichere Speichermedien als die Floppy (oder gar die alte Datasette). Noch wichtiger waren Speichermodule, mit denen man den C=64 über den User-Port erweitern konnte und noch später die externe CPU-Erweiterung “SuperCPU”, mit der man den C=64 mit bis zu 20MHz ausstatten konnte.

GEOS wurde stets dahingehend weiterentwickelt, auch diese neue Hardware zu unterstützen. Uns zwar aus gutem Grund: es mag zwar erstaunlich sein, was das System aus einem Standard-C=64 herausholt, doch die oft langen Ladezeiten von der Floppy waren extrem störend. Die Beschränkungen mussten ohnehin schon mit einer ganzen Reihe an Tricks umgangen werden – beispielsweise war das ganze System auf zwei Floppy-Disks verteilt, die man während dem Betrieb gelegentlich wechseln musste. Erst mit einer Speichererweiterung konnten nennenswert Daten gecached werden, was langsame Disketten-Zugriffe vermied. In Verbindung mit diesen Speichererweiterungen bot GEOS außerdem die Möglichkeit, Ramdisks anzulegen.

Was nicht bzw. nur eingeschränkt möglich war, ist Multi-Tasking. Der Grund dafür ist wohl in der Hardware zu suchen, die dafür schlichtweg nicht ausgereicht hätte. Einige kleine Tools bildeten dabei aber eine Ausnahme: Taschenrechner, Notizblock und Ähnliches konnten ab der Version 2.0 aus den meisten Anwendungen heraus kurzzeitig aufgerufen werden, ohne das ursprüngliche Programm zu beenden.

Einen großer Schritt nach Vorne war zumindest aus technischer Sicht die 1993 nur in Deutschland (von Markt&Technik) veröffentlichte Version 2.5: der Dateimanager “deskTop” wurde durch “TopDesk” ersetzt, der deutlich am Konzept der Fenster feilte: bis zu vier Fenster waren ab dann möglich, und diese auch vergrößerbar und verschiebbar. Außerdem wurden erstmals Unterverzeichnisse unterstützt – wenn auch auf eine recht kuriose Weise, die zu keinem anderen System kompatibel war. Auch TopDesk wird noch weiterentwickelt, und unterstützt (über einige Hardware-Tricksereien) auch aktuellere Geräte wie CD-ROMS, und ist inzwischen sogar farbig. Insbesondere in den letzten zehn Jahren haben sich die Weiterentwicklungen allerdings sehr stark aufgesplittet. Neben der genannten deutschen Version 2.5 (die im Kern eigentlich ein reguläres 2.0 war, das um einige Programme wie das eben genannte TopDesk aufpoliert war) gibt es mehrere parallele, voneinander unabhängige Weiterentwicklungen. Creative Micro Designs veröffentlichte 1996 die Erweiterung “gateWay” (u.a. 2-Prozess-Multitasking) für den C=64/128, 1998 folgte “Wheels” von Maurice Randall (Unterstützung für SuperCPU-Beschleunigung), 1999 kam von MegaCom das Upgrade “MP3”. Daneben wurde auch noch versucht, GEOS auf andere Hardwareplatformen zu portieren und dort weiterzuentwickeln. Neben einer Portierung für den Macintosh ist vor allem “PC-Geos” erwähnenswert, das für den PC entwickelt wurde, und unter DOS lief. Die Tatsache, dass es den damaligen Windows-Versionen sogar überlegen war, hat freilich nicht genügt, um langfristig auf dem “feindlichen Boden” MS-DOS zu bestehen. Dafür war ihm auf diversen mobilen Geräten ein etwas länger währender Erfolg beschert. Das ursprüngliche GEOS C=64 Version 2.0 ist seit einem knappen Jahr (Februar 2004) sogar kostenlos verfügbar – wenn auch weiterhin als proprietäre Software.

GEOS Screenshot 1

War GEOS für den C=64 nun ein Durchbruch oder gar eine “Revolution”, wie es von Fans manchmal betitelt wird? Nein, eher nicht. Man könnte es als ein “technisches Wunder” bezeichnen, was GEOS auf den begrenzten Hardwarevoraussetzungen herausholte – eine Sparsamkeit, die man schon wenig später nur noch selten antraf. Trotzdem reichte dies in der Praxis nicht aus, um wirklich produktiv mit GEOS zu arbeiten, zumindest nicht auf dem handelsüblichen C=64/128. Insbesondere die langen Wartezeiten beim Laden von Floppy auch nach dem Start machten das Arbeiten zur Geduldsprobe. Noch ein weiteres Problem ergab sich aus den Floppys, in Verbindung mit der damals noch viel größeren Raubkopier-Problematik: Berkeley Softworks schaffte das Kunststück, die Floppys mit einem Kopierschutz auszustatten, der wirklich viele Jahre nicht geknackt wurde. Da die Datenträger aber wie alle anderen Floppys des C=64 extrem fehleranfällig waren, bedeutete dies trotz einer (ebenfalls anfälligen) beigelegten Sicherheitskopie, dass man schnell in der Situation war, das System nicht mehr booten zu können. Zwar gab es Umtauschmöglichkeiten, aber letztlich bedeutete die nicht vorhandene Möglichkeit, sich selbst Sicherheitskopien anlegen zu können, eine ständige Quelle für Unannehmlichkeiten und Ärgernisse. Konzeptionell bot GEOS auch wenig Neues; man orientierte sich eben sehr stark an MacOS. Insofern war GEOS nicht der große Durchbruch grafischer Oberflächen auf dem Massenmarkt, bot aber zumindest vielen, die sich damals keinen Mac leisten konnten, ein frühes Bild davon, was viel später dann wirklich große Verbreitung fand.

 

 

Quellen: