Google Chrome revisited


Vor über zwei Jahren habe ich in aller Kürze ein paar erste Eindrücke zu Google Chrome geäußert, der zu diesem Zeitpunkt gerade neu erschienen war — um mich danach wieder Firefox zuzuwenden. Seit Anfang dieses Jahres, als ich mir ein Netbook von Asus als Reisecomputer zulegte, habe ich Chrome immer öfter verwendet. Erst nur von Zeit zu Zeit, eben ausschließlich auf besagtem Netbook, wegen der besseren Ausnutzung der geringen dort zur Verfügung stehenden Bildschirmfläche; seit einigen Monaten dann auch auf dem “großen” Laptop (aus dem gleichen Grund, aber daneben, weil ich mich so langsam an die Ergonomie gewöhnt und die vielen Plugins entdeckt hatte), und seit Oktober zusätzlich auf meinem Arbeitsplatzrechner und unserem Desktop-PC daheim.

Dass ich damit jetzt den kompletten Umstieg von Firefox zu Chrome vollzogen habe, dafür gab letztlich die fühlbar bessere Performance bei JavaScript-lastigen Webanwendungen den Ausschlag. Ich arbeite viel mit den Tools von Google selbst (also mit Webmail, Online-Textverarbeitung, Newsreader, Kalenderverwaltung, Maps und dem Linkverkürzer goo.gl), nutze aber beispielsweise mit YouTube, Twitter oder dem Nerd-Nachrichtenportal Slashdot auch des öfteren andere durch JavaScript stark dynamisierte  Websites. All diese Seiten profitieren spürbar von der hochoptimierten JavaScript-Engine, die eigentlich das Herz von Chrome ist.

Dazu kommt, dass Google es geschafft hat, seinen Browser so herrlich unaufdringlich zu gestalten. Updates geschehen leise im Hintergrund, Nachfragen an den Benutzer erfolgen dort, wo es notwendig ist. Ein einziges Eingabefeld wird für Internetaddressen und Suchbegriffe genutzt, wobei es sogar ermöglicht wird, damit neben den allgemeinen Suchmaschinen auch die spezielle einer bestimmten Website (wie YouTube) oder gar einen ganz eigenen Suchmechanismus zu nutzen — was mir auf der Arbeit die Bedienung unseres Issue-Tracking-Systems Jira stark vereinfacht. Und die (ja schon seit jeher gegebene und von mir vor 2 Jahren noch beargwöhnte) Eigenschaft, für jede Registerkarte einen eigenen Prozess zu starten, verhindert ziemlich zuverlässig, dass eine lahme oder fehlerhafte Webanwendung den gesamten Browser blockiert. Überhaupt lindert schon der Umstand, dass kein externes Plugin zur Anzeige von PDF-Dokumenten mehr notwendig ist, die schlimmsten Schmerzen.

Also alles gut? Fast – denn natürlich bleibt immer ein unterschwelliges, unangenehmes Gefühl der Unsicherheit, was Google, die alte böse Datenkrake, wohl mit den Informationen anstellen mag, die ein Browser heutzutage so zu Gesicht bekommt. Bei Google bemüht man sich zwar um ostentative Offenheit und Aufklärung der Anwender, aber zwischen den Datenschutzskandalen bei Facebook und Co. einerseits und der Stimmungsmache gegen Google StreetView andererseits bleibt natürlich unweigerlich ein Rest von Zweifel und Verunsicherung — zumal ja auch Google ein Unternehmen ist, das sein Geld hauptsächlich mit Werbung verdient und nur deswegen einen Browser und tausend tolle Webapplikationen kostenlos zur Verfügung stellen kann.

Aber diesen Trend kann man ja ebenfalls vielfältig beobachten: Produkt prinzipiell gut, doch Hersteller aus ideologischen Gründen oder anderen Bedenken ziemlich zweifelhaft. Nicht nur Facebook und Google, sondern auch Apple und Microsoft, Sony und Nokia, Kohle- und Kernkraft stellen uns offenbar nur noch vor die Wahl des geringeren Übels. Entscheidungen werden nicht mehr für ein bestimmtes Produkt, sondern gegen die subjektiv überwiegenden schlechten Eigenschaften der jeweiligen Konkurrenz getroffen. Übertragen auf den hier vorliegenden Fall heißt das: Googles inoffizieller Leitspruch “Don’t be evil” mit seinem absoluten Anspruch wird so schnell zu “Don’t be the greater evil” relativiert. Ob ihnen dies mit Chrome gelingt, muss dann letztlich jeder Nutzer selbst wissen. Ich für meinen Teil bin bereit, mich auf die zu erwartenden Nachteile einzulassen — zumindest für diesen Moment.



Google Chrome in 5 Minuten


…denn mehr Zeit habe ich gerade nicht.

  • Registerkarten als oberstes Gliederungselement des GUI und ein eigener Prozess für jede dieser Registerkarten halte ich für konsequent, aber auch mutig. Denn die Kehrseite der Medaille ist der erhöhte Speicherverbrauch.Google Chrome: About Memory
  • Diesen kann man gut überprüfen, indem man in der Adresszeile “about:memory” eingibt. Hier wird der Speicherverbrauch pro Prozess dargestellt. Besonders nett: Die Statistik führt zum Vergleich auch die anderen momentan laufenden Browser mit auf.
  • Sehr spannend daran ist, dass Webanwendungen, die von der gleichen Domain stammen, offenbar in einem gemeinsamen Prozess laufen dürfen und sich dadurch die genutzten Systemressourcen teilen können.

Ich finde diese Initiative vor allem deswegen begrüßenswert, weil dadurch Innovationen im Segment der Web-Browser forciert werden. Gerade moderne Webanwendungen, die versuchen, die aktuellen W3C-Standards zu implementieren, dürften davon profitieren. Der nächste folgerichtige und auch wünschenswerte Schritt wäre eine konsequente Unterstützung der Spezifikationen für das semantic web. Gerade der Suchmaschinenspezialist Google dürfte ein gesteigertes Interesse daran haben, dass Web-Content nicht nur oberflächlich (also im Bezug auf das Layout) aufbereitet, sondern auch inhaltlich (also im Bezug auf die Semantik) ausgezeichnet wird. Daneben fehlt Googles Chrome natürlich noch die Politur: Plug-Ins zur Unterstützung von Web-Development, Debugging und ein Ad-Blocker möchte ich mittlerweile nicht mehr missen.



Dezentrales Task- und Terminmanagement mit Thunderbird


Mozilla Thunderbird hat mir in den vergangenen Jahren als Email-Client bereits gute Dienste geleistet. Als ich mich im Rahmen meiner Zen to Done-Initiative nun nach einer Anwendung umgesehen habe, mit der ich meine Aufgaben und Termine komfortabel verwalten kann, kam mir als allererstes Chandler in den Sinn. Dieses Tool unterstützt die Getting-Things-Done-Methodik von Grund auf und wurde vom Lotus-Gründer Mitch Kapor ins Leben gerufen. Leider kann Chandler aber nicht so wirklich mit Google Calendar zusammen, mit dem ich meine Termine zu pflegen geruhe. Soll heißen: Ich kann zwar die Termine aus meinen Kalendern abrufen, aber keine neuen Termine in Chandler erstellen, um sie in Richtung Google Calender zu senden. Das hilft mir also nicht weiter. Rainlendar war mein zweiter Gedanke, doch der ist zu ressourcenhungrig, als dass ich auf meinem Arbeitsplatzrechner große Freude damit hätte.

Aber da war doch mal… Sunbird, oder so ähnlich? Ja, es gibt das Kalendertool von Mozilla noch immer, auch wenn das Projekt vor drei Jahren, als ich mich zuletzt dafür interessiert hatte, kurz vor dem Aus zu stehen schien. Und nicht nur Sunbird, auch das begleitende Thunderbird-Add-on Lightning (das früher irgendwie mal anders hieß) ist nicht nur immer noch quicklebendig, sondern darüberhinaus auch erwachsen geworden.

Die Verquickung von Email-Client mit Terminmanager hat mehrere Vorteile. Am wichtigsten finde ich, dass man aus den eingehenden Mails im Handumdrehen gleich Tasks oder Termine machen kann, indem man sie auf die entsprechende Schaltfläche zieht. Ein netter Nebeneffekt ist, dass nicht noch ein Fenster zusätzlich offen sein muss.

Leider ist die Integration von Google Calendar dann doch nicht so einfach wie gedacht — aber im Gegensatz zu Chandler immerhin möglich. Lightning ist durch sog. Provider an jede denkbare Datenquelle/-senke koppelbar. Und natürlich gibt es bereits einen Provider für Google Calendar als Add-on für Thunderbird.

Bleibt nur ein Problem: Während Lightning mit Aufgaben eine komfortable Verwaltung von To-Do-Listen ermöglicht, kennt Google Calender keine Tasks, sondern nur Events. Das könnte man jetzt als Schönheitsfehler abtun, aber wir wollen hier ja das vorhandene Potential ausschöpfen. Und überhaupt hatte ich mir ja gerade deswegen schon vor Längerem einen Account bei RememberTheMilk.com registriert. Und siehe da, nachdem ich fix noch einen Remember the Milk Provider installiert habe, klappt’s auch mit den Aufgaben. MacGyver wäre stolz auf mich.

Das Ganze mag einem zunächst ja ein bisschen wie notdürftig zusammengeflickt vorkommen. Ich würde aber eher von konfigurierbaren Softwarekomponenten sprechen, die alle genau das tun, was man von ihnen erwartet (und nur das), darüberhinaus aber auch noch miteinander gekoppelt werden können. Eine monolithische Lösung mag zwar an sich effizienter sein, aber tut nicht unbedingt das, was ich will. Und damit bremst sie dann doch wieder die Produktivität.

Beteiligte Akteure: