Das neue Google Docs ist da und es sieht toller aus, lässt sich besser Bedienen – und es ist die große MS Office-Konkurrenz und brauch sich vor Vergleichen nicht zu scheuen. In der Technik steckt aber viel Arbeit: Früher war es auf einer Ebene mit dem Browser, für das neue Docs mussten extra JavaScript-Bibliotheken geschrieben werden.
Wir haben schon lang auf das neue Docs gewartet, als es herauskam brachte es viele neue Features mit. Doch dass Google Docs erst einmal Tabstopps, Formatierungen und Drag & Drop kann, musste von Grund auf neu Erfunden werden. Einige Desktop-Entwickler werden wissen, wie viel Arbeit hinter einem normalen Texteditor steckt: Lineale, Formatierungen, Schriftarten, Schriftgrößen: Alles muss erst einmal programmiert werden, bis es so ist, wie man es sich vorstellt und der Benutzer es wünscht. Sicher: Man kann hier auf fertige C-Bibliotheken zurückgreifen, aber bei JavaScript und dem Browser gibt es einfach keinen Ansatz – und da kommt Google mit dem neuen Editor ins Spiel.
Das alte Google Docs verwendete Standard-JavaScript (JS)-Biliotheken. Dabei benutzt der Editor Standard-Textfelder, Formatierungen waren schnell kaputt, es war ein Mischmasch aus den Standard-Browser-Funktionen und JavaScript. Wenn man bspw. einen Tab in den Browser getippt hat, übersetzt der JS-Editor den Tab in HTML (&tab;). Wenn man das Dokument dann in einem Browser geöffnet hat der kein Tab versteht, war die komplette Formatierung kaputt. Die Implementation war aber einfach und der Editor war schnell zusammengestrickt.
Im neuen Google Docs ist das nun komplett anders. Die von Google entwickelte JavaScript-Bibliothek übersetzt alle Formatierungen in spezielles HTML, welches aber keine Formatierungen verliert. Das kann man sich nun so vorstellen, als dass bspw. für das Tab-Problem 4 Leerzeichen ersetzt wurden. Das Interface war eine richtig komplexe Entwicklung: Für jeden Click, für jedes Mouseover, für jedes Zeichen wird ein HTML-Code und CSS-Wert festgelegt. Auch Tabstopps werden gesondert realisiert.
Die neue Editor-Oberfläche
Wenn man jetzt Docs öffnet, sieht alles so aus, wie man es vom Desktop-Word-Tool gewohnt ist. Bis es soweit ist, bedarf es einigen Stunden und Wochen an Arbeit. Um sich das genauer vorzustellen, muss man den Editor mal aus der Seite des Browser sehen. Zunächst muss man wissen, wie groß und wie weit jeder einzelne Buchstabe ist. Das ist wichtig, um den JavaScript-Cursor richtig zusetzen. Das Ganze ist ja keine gewöhnliche Textarea mehr, sondern ein HTML-Frame. Klickt man beim neuen Docs also auf eine Position, so wird eine x– und y-Position aus der Breite, der Höhe, und der Form der Schrift errechnet und dann wird der Cursor platziert. Der Cursor ist ein einfacher Div-Container, der per CSS auf 2px Breite gestellt wird. Wenn man also [Tab] drückt, rechnet der Editor genau die Breite eines Leerzeichens aus und setzt den Cursor dann hinter diese Leerzeichen. Klingt eigentlich ziemlich einfach, aber die JavaScript-Bibliothek muss Alles(!) in HTML umsetzen.
Ganz zu schweigen von der Rechtschreibkontrolle und den ganzen Shortcuts, Funktionen, Linealen – alles muss mit JavaScript in HTML umgewandelt werden. Kein Standard-HTML-Objekt, sondern richtig viel JS-Code!
Die neue Layout-Engine
Was keiner so auf dem Bildschirm hat, ist bei jedem Word-Prozessor ein Höllenakt: Wenn man alle Buchstaben, alle Lineale, Links, Formatierungen richtig anordnen möchte, muss man auch alles exakt umsetzen. Ein Buchstabe ist nicht einfach ein Buchstabe, sondern ein HTML-Objekt, welches berechnet und angepasst werden muss. Wenn man bspw. „a“ tippt, dann ist das „a“ nicht einfach nur ein a, sondern es ist ein JavaScript-Befehl, der mehrere Funktionen aufruft und dem JavaScript sagt, das „a“ in den HTML-Kontext zu bringen. Wenn man ein Leerzeichen tippt, muss der Editor jedes Wort mit der Google-Rechtschreibprüfung abgleichen. Wenn jemand ins Fenster klickt, dann rattert irgendwo ein Prozessor, der diesen Klick umsetzt, den Cursor setzt – genau wie beim Betriebssystem. Es ist also eine enorme Arbeit, so etwas wie auf dem Screenshots hinzubekommen! Man muss HTML aka Browser sagen, dass er die Breite, Höhe und die Formatierung via CSS immer beizubehalten hat. Und jeder Webmaster kennt das Problem, dass man seine Seite an verschiedene Browser möglichst gleich anpassen möchte.
Es muss also viel Arbeit gekostet haben, bis irgendwann so ein Objekt möglich wurde, welches genau auf Maß anzeigt und dabei alle Formatierungen und Schriftarten und -Größen beachtet.
Kollaboration
Das wichtigste Thema im neuen Editor ist aber die Kollaboration. Wichtig dabei ist der Crash-Effekt, dass also mehrere Benutzer an einem Dokument arbeiten können, ohne dass Editierungen verloren gehen. Dafür hat Google scheinbar auf bestehende Mittel zurückgegriffen, war es aber bis dahin ein langer Weg: Wenn man Buchstabe für Buchstabe tippt, dann muss das über JavaScript an die Server gehen, die Server müssen den Benutzer verstehen, müssen die Buchstaben ein Zeichen auswerten. Bei dem einen Benutzer ein Cursor (wieder mit JavaScript) und bei dem Anderen das Selbe darstellen. Es muss also pro Buchstabe und Wort ein Aufruf an die Server stattfinden und das JavaScript muss den Server immer wieder befragen, ob etwas Neues vorliegt. Das ist wirklich anstregend und nur mit aufwändigem Ajax (JS+XML) zu realisieren. Zudem muss man gewisse Grenzen kennen, denn jeder Server ist auch irgendwann ausgelastet, auch bei Google.
Man sieht also, wie viel Arbeit in so einem „einfachen“ Dokument-Prozessor steckt, bis es endlich so aussieht, als wäre Docs eine native Applikation. Man benötigt nicht nur ausgeweitete Server- und HTML-Kenntnisse, sondern muss auch in JavaScript und Ajax ein richtiger Profi sein.
Dieser Blogpost wurde durch den originalen Post von Google inspiriert, aber nochmals erweitert.