Google Docs jetzt auch mit Präsentationsmodul

Auch wenn andere Anbieter wie etwa Zoho es schon lange und in besserer Qualität anbieten, haben doch viele darauf gewartet: Google Docs, die Online-Office-Suite von Google, die bislang nur aus einer Textverarbeitung und einer Tabellenkalkulation bestand, wurde nun um ein Präsentationsmodul erweitert:

Google-Präsentation im Bearbeitungsmodus

Die Euphorie muss allerdings gedämpft werden. Wirklich individuelle Präsentationen sind mit diesem Tool vorerst nicht möglich. Gerade mal 15 fixe Motive für Folien-Basislayouts werden angeboten, und außer Text frei platzieren und formatieren und Pixelgrafiken einfügen ist nichts weiter an Funktionen vorgesehen. Keine Vektorgrafik, und schon gar keine Extras wie Datenübernahme von Diagrammen aus der Tabellenkalkulation. Bleibt zur Linderung der Enttäuschung darüber nur die Bemerkung, dass die meisten Menschen, die eine Präsentation erstellen, ohnehin hoffnungslos überfordert sind mit dem Funktionsumfang von Programmen wie Powerpoint oder Impress. Dementsprechend schematisch und langweilig sehen die meisten Präsentationen auch aus.

Einen unbestreitbaren Vorteil hat die Online-Lösung auf jeden Fall. Sie ermöglicht es, Präsentationen online einem anwesenden Publikum vorzuführen:

Google-Präsentation im Vorführmodus inklusive Teilnehmer-Chat

Der Vorführmodus einer Präsentation erhält eine eigene dynamische URL-Adresse. Gibt ein Vorführender diese URL per Mail, Messenger, Telefon usw. an andere weiter, können diese durch Aufruf der Adresse direkt an der Präsentation teilnehmen. Gegebenenfalls ist dabei noch ein E-Mail-Handshake mit dem Einladenden erforderlich. Aktionen des Vorführenden wie Weiterblättern werden bei den übrigen Teilnehmern automatisch ausgeführt. Gleichzeitig wird ein Chat eingeblendet. Dieser kann vom Vorführenden benutzt werden, um seinen verbalen Vortrag zur Präsentation zu halten. Zumindest bei chat-erprobten Schnelltippern könnte das hinhauen, ohne dass das Publikum einschläft. Die übrigen Teilnehmer können ebenfalls chatten, sofern sie dazu ermächtigt wurden. Außerdem können Berechtigte die Präsentation übernehmen. So können sich beispielsweise mehrere Präsentierende mit Tippen des Vortragstexts abwechseln.

Eine Lösung für Live-Audio- oder gar Live-Video-Broadcasting wäre natürlich spannender. Andererseits haben textbasierte Chats durchaus auch Vorteile. So ist der Vortragstext der Präsentation für alle noch mal nachlesbar. Und da Tippen langsamer geht als Reden, wird bei solchen Präsentationen ja vielleicht nicht ganz so viel Überflüssiges verzapft ...

Hypertext (9): Tim Berners Lee: World Wide Web

siehe auch:
(1): Text und Linearität
(2): Computer und Hypertext
(3): Inhaltseinheiten und Verlinkung
(4): Suchen und Stöbern
(5): Orientierungsmittel für Hypertext
(6): Hypertext und Informationsaufnahme
(7): Vannevar Bush: Memex
(8): Ted Nelson: Xanadu

---

Die Mehrheit der Bürger ist im Internet, was allein schon ein unglaublicher Wandel ist, der da innerhalb von 10 bis 15 Jahren stattgefunden hat. Nicht wenige verdienen ihr Geld im oder durch das Internet. Dabei meinen die meisten, wenn sie vom Internet reden, gefühlt zu etwa 80% World Wide Web, zu 15% E-Mail und zu 5% Sonstiges, wie Instant Messaging, VoIP-Telefonie, IRC-Chat, Peer-to-Peer-Anwendungen usw. Für viele Menschen ohne tiefere Internet-Kenntnisse sind Internet und World Wide Web schlichtweg Synonyme. Denn erst durch das Web ist das Internet ein Massenmedium geworden. Dabei ist das Web jedoch kein ultrakomplexes Produkt, sondern ein griffiges Konzept, das im Kopf eines einzigen Mannes entstanden ist.

Die Vorgeschichte

Tim Berners-Lee (persönliche Homepage beim W3-Konsortium, persönliches Weblog) ist ein bescheidener Zeitgenosse geblieben, obwohl seine kulturgeschichtliche Bedeutung immer wieder mit derjenigen von Johannes Gutenberg verglichen wird, und obwohl er als britischer Landsmann im Jahre 2004 von Queen Elizabeth II zum Ritter geschlagen wurde. Der 1955 geborene Berners-Lee studierte Physik in Oxford und gelangte 1984 zum europäischen Kernforschungszentrum CERN in Genf. wo er 1980 erstmals als Software-Consultant tätig gewesen war.

Bereits Ende der 70er, Anfang der 80er Jahre war Berners-Lee besessen von der Idee einer Software, die alles mit allem verknüpft. Die Idee selbst war ja dank Persönlichkeiten wie Vannevar Bush oder Ted Nelson nicht mehr neu. Doch in der Zeit, von der hier die Rede ist, war es alles andere als selbstverständlich, dass jemand wie Berners-Lee sich mal eben mit der bisherigen Hypertextgeschichte auseinandersetzen und auf vorhandenen Konzepten aufsetzen konnte. Das, was dazu nötig gewesen wäre, gab es einfach noch nicht: nämlich weltweit vernetzte, sofort verfügbare Information. Außerdem wurde Nelsons Terminus Hypertext erst Ende der 80er Jahre zu einem zumindest in der Wissenschaft verbreiteten Begriff.

Berners-Lee experimentierte zunächst mit einer selbst geschriebenen Software namens Enquire (to enquire = erkundigen, nachfragen, erforschen), die er bei seinem ersten CERN-Consulting 1980 konzipiert hatte. Er nutzte Enquire, um alles zu vernetzten, was er an persönlichen Daten und Dokumenten hatte: Adressen, Notizen usw. Enquire war ein lokal ausgerichteter Hypertext-Interpreter. Er erlaubte Links innerhalb eines Dateisystems und Links zu definierten Ankern innerhalb einer Datei, später auch zu Zielen jenseits des lokelen Dateisystems. Seine Informationen speicherte er in einer einzelnen Datenbankdatei. Doch damit war Berners-Lee auf die Dauer nicht zufrieden. Er wollte keine Hypertext-Software-Lösung für Einzelbenutzer oder geschlossene Arbeitsgruppen, sondern eine globale Lösung, ein dezentral auf beliebig weit entfernte, leitungsverbundene Rechner verteilbares Hypertext-System, das nicht aus einer Zentraldatenbank bestand. So kam Berners-Lee auf die Idee, seine Hypertext-Idee als Dienst für das Internet zu konzipieren.

Die Säulen des Web

Die meisten Internet-Dienste sind client-server-orientiert. Benutzer, die den Dienst nutzen wollen, verwenden einen Dienste-Client. Der Dienste-Client ermöglicht es, eine Anfrage in der diensteigenen Protokollsprache an einen anderen Rechner im Internet zu richten (Internet-Dienste werden durch sogenannte Portnummern unterschieden). Wenn auf dem angewählten Rechner ein entsprechender Dienste-Server läuft, bekommt dieser die protokolleigene Anfrage über die vereinbarte Portnummer zugewiesen, kann sie auswerten und entsprechend reagieren, z.B. durch Senden angeforderter Daten. Nach diesem Muster konzipierte Berners-Lee auch das World Wide Web. Wer Informationen auf einem Internet-Rechner anbieten wollte, benötigte einen dienste-spezifischen Server, in diesem Fall einen Webserver. Wer solche Informationen abrufen wollte, benötigte hingegen einen Web-Client. Berners-Lee entwickelte folgende zentrale Komponenten des Webs:

• einen Dienste-Server für den neuen Dienst World Wide Web, also einen Webserver,
• einen entsprechenden Dienste-Client, also einen Web-Browser,
• ein Dienste-Protokoll, das sogenannte Hypertext Transfer Protocol (HTTP),
• eine Standardauszeichnungssprache für Web-Dokumente, die sogenannte Hypertext Markup Language (HTML),
• ein Adressierungsschema, mit dessen Hilfe Links auf beliebige Dokumente oder darin enthaltene Anker auf beliebigen Webservern verweisen können, das Schema der sogenannten Uniform Resource Identifiers (URIs).

Nachdem die ersten Fassungen des Webservers und des HTTP-Protokolls zur Verfügung standen, konnte der erste Web-Browser zum Einsatz kommen. Es war ein reiner Zeilen-Browser für eine nichtgrafische Oberfläche. Auf Unix-Systemen war er typischerweise unter /usr/local/bin/www aufrufbar. Er benutzte eine zum Programmumfang gehörende Datei namens default.html als voreingestellte Startseite.

Screenshot von Tim Berners-Lee's Original-WorldWideWeb-Browser für Textoberflächen
Original siehe http://info.cern.ch/LMBrowser.html

Der Browser für den Textmodus entsprach allerdings nicht Berners-Lee's Vorstellungen von der Zukunft von Hypertext. Anfang der 90er Jahre gewannen grafische Benutzeroberflächen immer mehr an Bedeutung. Berners-Lee selbst arbeitete bevorzugt mit NeXT-Rechnern, einem unix-basierten Edel-Betriebssystem von Apple-Gründer Steve Jobs. Der erste NeXT-Browser entsprach weitgehend dem, was Berners-Lee sich vorstellte:

Screenshot von Tim Berners-Lee's Browser für NeXT-Computer
Original siehe http://info.cern.ch/NextBrowser.html

Genauer betrachtet, dachte Berners-Lee nicht nur in den Kategorien Informationsangebot und Informationsnachfrage. Das Web sollte von Beginn an auch dazu dienen, das Anbieten von Information überhaupt zu ermöglichen. Der Web-Client, den Berners-Lee sich vorstellte, sollte nicht wie heute üblich ein reiner Browser sein, sondern ein Kombi aus Browser und Remote-Editor.

Auch etwas anderes ist an dem NeXT-Screenshot erkennbar: der Browser-Benutzer hatte die Möglichkeit, sich sein persönliches Stylesheet einzurichten. Für die Standardelemente der Original-HTML-Sprache konnte sich der Benutzer bequem einstellen, wie Elemente der entsprechenden Typen bei ihm erscheinen sollen. So hatten alle auf HTML basierenden Web-Dokumente für den Benutzer ein einheitliches Aussehen, das seinen persönlichen optischen Vorlieben entsprach. HTML selbst enthielt deshalb auch gar keine Sprachbestandteile für Formatierungen, abgesehen von primitiven Formatauszeichnungen wie Fettschrift oder Kursivschrift.

Die Kommerzialisierung des Web

Die Kommerzialisierung des Web begann mit einem jungen Mann, der von der Idee des Webs fasziniert war, aber eher mit Dollarzeichen in den Augen und weniger im Dienste der Enzyklopädie des menschlichen Wissens: Marc Andreessen entwickelte den ersten grafischen Web-Browser für bekanntere Benutzeroberflächen als NeXT. Sein Browser mit dem Namen Mosaic avancierte binnen kürzester Zeit zum Volkswagen des Web, erhältlich unter anderem auch für Microsoft Windows. Es war jedoch ein reiner Browser ohne Editier-Funktionalität. Damit war die erste entscheidende Weiche gestellt: die erste große Besucherwelle im Web war beeindruckt davon, in einem einfachen Anwendungsfenster Dokumente aus aller Welt betrachten zu können, die auch noch untereinander vernetzt waren, sodass man nicht viel mehr können musste als auf Links zu klicken. Doch den vielen tausend Menschen, die zwischen 1993 und 1994 durch Artikel in namhaften amerikanischen Zeitungen und Zeitschriften auf das Web aufmerksam wurden und das Glück eines Internetzugangs hatten, wurde durch den Mosaic-Browser auch vermittelt: da gibt es ein paar Gurus, die wissen, wie man Dokumente ins Web bringt, und von denen hängt letztlich ab, was im Web angeboten wird.

Nicht Berners-Lee, sondern Andreessen war es, durch dessen Software-Fenster die Welt das Web erblickte. Gemeinsam mit James H. Clark gründete er eine neue Firma namens Netscape, die einen auf Mosaic basierenden Browser namens Netscape Navigator entwickelte. Dieser Browser brach mit einem weiteren zentralen Konzept von Berners-Lee. Statt dem Benutzer zu überlassen, wie er Inhalte optisch dargestellt bekommen möchte, baute Netscape die HTML-Sprache munter und spontan zu einer bunten Formatiersprache aus. Autoren von Webseiten konnten plötzlich mit Hintergrundfarben, Hintergrundbildern, bunten und veränderlich großen Texten arbeiten, Informationen in mehrere Frame-Fenster verteilen und mit einer kleinen Scriptsprache namens JavaScript allerlei Unfug treiben. Dier Beruf des Webdesigners war geboren (mittlerweile versteht man unter einem Webdesigner natürlich etwas anderes als jemanden, der Texte bunt macht und Benutzer mit kleinen trivialen dynamischen Effekten nervt).

Der Netscape-Browser hatte Mitte der 90er Jahre unter den Web-Browsern eine Marktdominanz wie heute etwa Google bei den Suchmaschinen. Es dauerte reichlich lange, bis der führende Welt-Software-Riese Microsoft bzw. sein Chef Bill Gates erkannten, dass da gerade ein Zug am Abfahren war. In einem gewaltigen Kraftakt versuchte Microsoft verschlafenes Know How aufzuholen. Ab 1997 bzw. Version 4 des hauseigenen Browsers Internet Explorer gewann Microsoft tatsächlich Oberwasser im Browser-Markt. Der Grund war jedoch, dass man den Browser einfach ins Betriebssystem Windows so fest integrierte, dass er bei jeder neuen Windows-Installation der Default-Web-Browser war. Die Konkurrenz strengte Prozesse gegen die Browser-Integration ins Betriebssystem an, doch ohne Erfolg. Der Internet-Explorer verdrängte den Netscape Navigator, doch an der Marschrichtung änderte sich nichts. Web-Browser wurden als Fenster in ein kommerziell orientiertes Web konzipiert. Ohne Editiermöglichkeit, realisiert als möglichst ausgereifte und fehlertolerante Sklaven für die optischen Vorstellungen von Webdesignern und ausgerüstet mit proprietären Techniken für neuere, vor allem kommerziell interessante Nutzungsmöglichkeiten. Die Wunsch-Software der Dotcom-Blase.

Tim Berners-Lee berichtet in seiner Biographie (Weaving the web, deutsche Übersetzung: Der Web-Report) über Begegnungen mit Marc Andreessen. Daraus geht deutlich die Abneigung hervor, die Berners-Lee gegen Andreessens Abkehr von den ursprünglichen Browser-Editor-Vorstellungen und die Anbiederung an die Kommerzwelt hegte. Die Blütezeit der Dotcom-Welle muss für Berners-Lee eine sehr ambivalente Erfahrung gewesen sein: einerseits hatte sein World Wide Web tatsächlich die Welt erobert. Doch andererseits hatte sich das Web in eine vorherrschende Richtung entwickelt, die nicht mehr viel mit den ursprünglichen Vorstellungen von der freien Informationsvernetzung zu tun hatte.

Web 1.0 — Web 2.0

Nicht weniger problematisch ist allerdings das Verhältnis zwischen Tim Berners-Lee und dem, was sich mittlerweile selbst allerortens als Web 2.0 feiert. Denn eigentlich wirkt vieles von dem, was zu den Kern-Features von Web 2.0 gehört (mehr Editiermöglichkeiten für Benutzer, Techniken für intensivere Informationsvernetzung), wie ein Versuch, nachträglich das zu realisieren, was eigentlich das Web des Tim Berners-Lee hätte werden sollen. Andererseits muss es Berners-Lee schmerzen, wenn die Web-2.0-Bewegung von einem falschen Erstzustand des Web ausgeht. Denn das, was diese als das rein konsumorientierte, für passive Benutzer konzipierte Web 1.0 bezeichnet, war eben nicht aber das ursprüngliche Web von Tim Berners-Lee, sondern das Web von Marc Andreessen und Bill Gates. In einem Podcast-Interview (Textmitschrift in Auszügen oder Original-MP3-Podcast (ca. 17 MByte, ca. 25 Minuten) — beides in Englisch) äußert sich Berners-Lee auf diesem Hintergrund sehr kritisch über den Web-2.0-Hype.

Was die Web-2.0-Szene indessen erkannt hat, ist die richtige Mischung für eine produktive Web-Atmosphäre. Sie besteht vorwiegend aus OpenSource und OpenContent, gepaart mit der freiwilligen Energie von Social Networking und nicht-marktschreierischem Unternehmergeist. Das Web ist auch kein reines Wissenschaftsnetz mehr wie in den anfänglichen Vorstellungen von Berners-Lee. Es integriert vielmehr Menschen unterschiedlichster Kulturen und Bildungsschichten, Experten und Dummies, von denen quer durch alle Bänke ein Teil auch aktiv an den Inhalten des Webs mitwirkt. Die von Berners-Lee angedachte Web-Client-Software alleine könnte das Web in heutiger Zeit nicht mehr voranbringen. Denn das Web besteht nur noch zu einem Teil aus Dokumenten im herkömmlichen Sinn. Zum anderen, immer größer werdenden Teil besteht es aus Anwendungen und aus Multimedia. Einflussreiche Webanwendungen wie Google Maps, Wikipedia oder große Blogger-Plattformen verändern das Web und das darin enthaltene Hypertext-Potential nachhaltig. So kann man heute nicht mehr nur auf Dokumente und vielleicht noch auf Mailadressen verlinken, sondern auch auf Geo-Koordinaten und Newsfeeds. Fehlende Hypertext-Features im Web, wie etwa ein stabiles Versionensystem bei Dokumenten oder bidirektionale Links, werden ebenfalls auf Ebene der Webanwendungen ausgeglichen, nämlich durch Features wie Permalinks oder Trackback-Funktionalität. Dazu kommt der stetig wachsende Anteil an Multimedia, der sich zwar derzeit noch stark auf einzelne Plattformen wie YouTube oder MyVideo konzentriert, die jedoch zu den meistbesuchtesten im Web gehören.

Berners-Lee hat das Web in weiser Voraussicht software-unabhängig konzipiert. Für die Ausformung der notwendigen technischen Standards hat sich das W3-Konsortium gegen proprietäre Herstellerinteressen durchgesetzt. Damit ist das Web ein eigentlich erstaunlich stabiles Fundament für weltweiten Hypertext. Hohe Nutzerzahlen und ein unter Webentwicklern und Webdesignern wachsendes Bewusstsein für Standardkonformität sorgen für weitere Stabilität. Unter den Ansätzen für globalen Hypertext ist das Web der erste und einzige, der bislang zum Erfolg geführt hat. Der Vergleich zur Kulturtechnik des Buches ist angesichts der Bedeutung des Webs alles andere als abwegig. Absehbar ist auch, dass das Web nicht nur den herkömmlichen Printmedien-Markt verändert. Schon längst hat es den Tonträgermarkt verändert, und ebenso wird es auch die Rundfunk- und Fernsehlandschaft verändern. Printmedien, Tonträger, Rundfunk und Fernsehen in herkömmlicher Form werden in bestimmte Nischen (Liebhaber, Outdoor usw.) gedrängt. Der bezahlbare Medienstandard wird dagegen das Web sein, zugänglich über Breitband-Flatrate. Der Umgang mit Hypertext wird dadurch so selbstverständlich, wie es einst das Umblättern von Seiten oder das Einlegen von Cassetten war.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Zum Blog-Eintrag: Hypertext (9): Tim Berners Lee: World Wide Web

An Wikipedia schrauben im Dienste der Barrierefreiheit

Wie das Barrierefrei-Magazin Einfach für alle am 24. Juli 2007 berichtete, hat sich eine Initiative gebildet, um Wikipedia besser zugänglich zu machen — zu finden auf der Wikipedia-internen Seite Wikipedia:BIENE. Die BIENE ist der bekannteste deutsche Award im Bereich Barrierefreiheit. Anlass für die Initiative innerhalb der Wikipedia ist, dass die BIENE sich für 2007 vorgenommen hat, große Anbieter von Web-2.0-typischen Services genauer unter die Lupe zu nehmen. Dabei wird auch Wikipedia genannt.

Nun weiß jeder, der sich einmal mit der Barrierefreiheit von Webseiten befasst hat, dass dies eine vielschichtige Angelegenheit ist. Es beginnt schon damit, dass der Ausdruck „barrierefrei“ sich nicht einfach als Euphemismus für „behindertengerecht“ versteht. Auch Unübersichtlichkeit oder schwere Textverständlichkeit stellen Barrieren dar, und nicht nur Menschen mit Behindertenausweis scheitern an solchen Barrieren. Wobei die Grenzen natürlich von Mensch zu Mensch sehr verschieden sind. Ebenso verschieden wie die Ansprüche und anvisierten Zielgruppen von Web-Inhalten. Es gibt formale Regeln, die mit etwas redaktioneller Disziplin leicht einhaltbar sind, etwa die Verwendung von Alternativtexten bei Grafik und Multimedia, oder zusammenfassende Beschreibungen für Tabellen. Doch bei Themen wie Unübersichtlichkeit oder Textverständlichkeit scheiden sich die Geister. Manche finden viele Links auf der Startseite praktisch, andere werden dadurch verwirrt. Die einen verstehen keinen Satz mit mehr als zehn Wörtern, und andere fühlen sich eher für dumm verkauft, wenn sie wie bei der Sendung mit der Maus angesprochen werden.

Ein Webprojekt wie Wikipedia, dessen Bedeutung für die Menschheit von Tag zu Tag wächst, muss sich allerdings mit all diesen Dingen auseinandersetzen. Die BIENE-Initiative ist dabei wohl sicher nicht der erste Gedanke, der bei den Wikipedianern an das Thema Barrierefreiheit verschwendet wurde. Denn trotz des chaotischen HTML- und CSS-Gewirrs, durch das sich das Standard-Monobook-Layout der MediaWiki-Software auszeichnet, macht die komplexe Wikipedia-Startseite zumindest im Lynx-Browser einen recht ordentlichen Eindruck, wie auch der Lynx-Viewer von K&K Software bestätigt.

Gut gelöst ist beispielsweise die Möglichkeit, sehr weit oben im Text, für grafische Browser unsichtbar, zur Navigation und Suche springen zu können. Damit wird bereits ein typisches Hindernis und Ärgernis überwunden, an das nur wenige Seiten denken. Denn einerseits ist es für Erstbesucher schlecht, wenn zuerst die Navigation und erst dann der Seiteninhalt präsentiert wird, doch andererseits ist es für Benutzer, die von einer Artikelseite zur Hauptseite zurückspringen absolut nervtötend, sich jedesmal wieder durch den Einführungstext bis zur Navigation quälen zu müssen.

Auch die relativ weit oben angesiedelten Links zur Groborientierung, die zu Unterportalen wie Geographie, Geschichte oder Gesellschaft führen, sind durchdacht platziert. Auf den ersten Blick wirkt die Wikipedia also nicht so, als ob man sich überhaupt noch keine Gedanken zu dem Thema gemacht hätte. Gerade das aber könnte für Webdesigner, die über tieferes Know How in Sachen Barrierefreiheit verfügen, ein Anreiz sein, sich an der Wikipedia:BIENE zu beteiligen. Auf der Seite selbst kann man sich als Mitstreiter eintragen, indem man sie editiert. Oder man probiert erst mal durch Teilnahme an den Diskussionen, wie gut es mit der Wellenlänge mit den anderen Interessenten klappt. Benötigt werden aber nicht nur Webdesign-Experten, sondern auch Vertreter der Zielgruppe, also Web-Benutzer mit Handicaps.

Wichtig ist der Initiative, dass vor allem Lösungen erarbeitet werden, die nicht zur Folge haben, abertausende von Wikipedia-Artikeln umschreiben zu müssen. Die Lösungen sollen bereits auf der Software-Ebene von MediaWiki greifen, oder zumindest auf der Ebene der Skins, also etwa in den Sourcen des Monobook-Layouts. Da ist eigentlich alles erlaubt zu denken, von software-seitiger Artikel-Inhalts-Optimierung bis hin zu einem intelligenten System aus medienabhängigen CSS-Stylesheets. Falls die Initiative zu Ergebnissen führt, könnten die Lösungen möglicherweise auch für andere Software-Anbieter (etwa für Anbieter von Content-Management-Systemen) von Interesse sein.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Wikipedia will barrierearmer werden

Wie das Web den Rest des Internets frisst (1)

Die (1) im Titel suggeriert, dass hier eine neue Serie entsteht. Steht aber noch nicht fest. Ein Trend setzt sich jedoch immer stärker durch, der mit Sicherheit noch mehr als diese eine Meldung hervorbringen wird. Diese Meldung hier lautet: Mozilla will sich von Thunderbird trennen. Mozilla ist bekanntlich die Dachorganisation einiger sehr erfolgreicher OpenSource-Produkte, alle hervorgegangen aus der Mozilla Application Suite. Das bekannteste davon ist zweifellost der Firefox-Browser, dessen Anteile auf dem Browsermarkt 20-30% betragen, Tendenz steigend.

Nicht ganz so bekannt wie Firefox ist das E-Mail-Programm Thunderbird. Dennoch ist seine Verbreitung groß genug, um es nicht einfach abzustoßen wie ein faules Stück Haut. IT-News-World, wo eingangs verlinkter Artikel zu lesen ist, meint die wahre Antwort zu kennen. Wenn sie wahr ist, ist sie sicherlich spektakulär. Dem Artikel zufolge steckt Google dahinter. Google, das sich ja immer deutlicher als einziger ernstzunehmender Konkurrent zu Microsoft profilieren will, unterstützt aus ebendiesem Grund die Entwicklung des Firefox-Browsers. Das ist übrigens keine bloße Behauptung. So optimiert Google Suchergebnisse im Firefox-Browser, und Nutzer des Microsoft-Browsers MS Internet Explorer bekommen beim Aufruf der Google-Startseite schon mal Werbung für Firefox eingeblendet.

Als Gegenleistung dafür, so vermutet IT-News World, verlangt Google nun, dass Mozilla in Zukunft nur noch Web-Software anbietet. Und zwar aus dem einfachen Grund, weil Google die „Webifizierung“ des Internets massiv vorantreibt. Google Docs soll die Alternative zur Desktop-Anwendungswelt von Microsoft Office werden, Google Groups soll die alter NNTP- und Newsreader-Welt überflüssig machen, und Google Mail tritt an, um E-Mail-Programme aus dem Rennen zu werfen. Wie also sollte Google einen Software-Anbieter unterstützen, der unter anderem auch ein zumindest nicht völlig unbekanntes Mailprogramm vertreibt?

Die Mutmaßungen von IT-News World sind zwar nicht belegbar, doch von der Hand zu weisen sind sie auch nicht. Mozilla kämpft weiter um wichtige Prozente im Browser-Markt. Ob man das Thunderbird-Projekt nun abstoßen will, um sich stärker auf die Weiterentwicklung des Firefox-Browsers zu konzentrieren, oder ob dies nur die offizielle Lesart eines Drucks ist, der in Wirklichkeit von Google ausgeht? Eins ist jedenfalls sicher: das allmähliche Sterben der klassischen Internet-Dienste geht weiter, weil sie durch leistungsstarke Webanwendungen und verändertes Nutzerverhalten (Flatrates) verdrängt werden. Web-Browser werden zur nächsthöheren allgemeinen Anwendungsschicht jenseits des Betriebssystems. Es ist kein Problem, wenn sie zwei Drittel des Arbeitsspeichers für sich alleine beanspruchen. So viel andere Anwendungen benötigt der konsequente Weblife-Mensch ja nicht mehr. Mozilla und Google haben diesen Trend jedenfalls erkannt. Google wohl schon länger, und Mozilla mittlerweile auch. Ob Google bei dieser Einsicht nachgeholfen hat, bleibt offen.

Tutorial: Ajax (7)

siehe auch:
(1): Was ist Ajax?
(2): Warum heißt Ajax so? Wo kann ich Ajax in Aktion sehen?
(3): Worin besteht die Ajax-Schnittstelle? Wie wird Ajax standardisiert?
(4): Welche Nachteile hat Ajax? Wie sicher ist Ajax?
(5): Ein einfacher Ajax-Kernel
(6): Eigenschaften und Methoden des XMLHTTPRequest-Objekts

---

Ajax-Beispiel: Formularüberprüfung

Einer der klassischen Anwendungsfälle für JavaScript ist das Prüfen von Anwendereingaben in Formularen, bevor das Formular abgesendet wird. So war es beispielsweise immer schon möglich, mittels JavaScript zu prüfen, ob in einem Feld ein numerischer Wert, eine Mailadresse mit gültigem Format oder ein realistisches Datum eingegeben wurde. Nicht möglich war es jedoch zu prüfen, ob etwa ein eingegebener Name, der in einer Datenbanktabelle auf dem Server eindeutig sein soll, dort bereits vorhanden ist oder nicht. Ajax kann diesen Fall lösen, und unser erstes kleines Beispiel zeigt wie.

HTML-Formular

Nehmen wir an, in einem Content Management System (CMS) können Anwender Templates anlegen und verwalten. Jedes Template erhält einen Namen, unter dem es auflistbar ist – beispielsweise beim Erstellen von Webseiten. Der Template-Name muss deshalb eindeutig sein. Im HTML-Formular notieren wir dazu neben dem Eingabefeld für den Template-Namen eine Schaltfläche mit der Beschriftung Prüfen:

<div><input type="text" name="template_name" id="template_name" 
       class="text" style="width:390px" accesskey="n"> 
<input type="button" name="check_name" 
       class="button" style="width: 96px" value="Prüfen" 
       onclick="ajaxCheckDBValue('templates', 'name', 'string', 
                document.getElementById('template_name').value, 
                'check_result', 0)"></div>
<div id="check_result"></div>

Den Rest des gedachten HTML-Formulars sparen wir uns, da er nichts zur Sache beiträgt. Das erste input-Element definiert ein einzeiliges Eingabefeld, das unter anderem ein id-Attribut mit dem Wert template_name erhält. Das zweite input-Element definiert die Schaltfläche mit value="Prüfen" (Beschriftungstext). Damit die Schaltfläche beim Anklicken etwas tut, erhält das Element einen Event-Handler onclick=. Der JavaScript-Code, der diesem Event-Handler zugewiesen wird, ist der Aufruf einer JavaScript-Funktion namens ajaxCheckDBValue(). Dieser Funktion werden folgende Parameter übergeben:

• 'templates' ist der Name einer Datenbanktabelle, in der die Namen von Templates gespeichert werden.
• 'name' ist der Name der Tabellenspalte, in der die Namen von Templates gespeichert werden.
• 'string' markiert die Art, wie die Daten in MySQL zu behandeln sind. Als mögliche Angaben benötigt dieser Parameter nur die möglichen Werte 'string' und 'num'.
• document.getElementById('template_name').value referenziert den aktuellen Eingabewert des ersten input-Elements.
• 'check_result' referenziert das div-Element, das unterhalb der beiden input-Elemente notiert ist. Dort soll das Ergebnis der Prüfung ausgegeben werden.
• 0 bedeutet: es soll kein Datensatz von der Gegenprüfung ausgeschlossen werden. Was dieser Wert genau bedeutet, werden wir noch genauer beschreiben.

JavaScript zur Steuerung

In dem HTML-Dokument mit dem zuvor beschriebenen Formularausschnitt muss in jedem Fall unser Ajax-Kernel (siehe (5): Ein einfacher Ajax-Kernel) eingebunden werden. Angenommen, wir haben den Code des Kernels in einer Datei namens ajax.js gespeichert, die im gleichen Verzeichnis liegt, kann diese Datei wie üblich zwischen <head> und </head> so eingebunden werden:

<script type="text/javascript" src="ajax.js"></script>

Der Einfachheit halber notieren wir die Funktion ajaxCheckDBValue() ebenfalls in der Datei ajax.js — beispielsweise unterhalb der beiden Funktionen des Kernels. Die Funktion besteht aus folgendem Code:

function ajaxCheckDBValue(DBTable, DBField, type, fieldValue, outputId, exclDBId) {
   if(!document.getElementById)
      return;
   if(fieldValue == "") {
 document.getElementById(output_id).innerHTML = 
         "<span class=\"errortext\">Keinen Wert angegeben!</span>";
 return;
   }
   scriptUrl = "http://localhost/ajax-test/checkDBValue.php";
   paramStr = "?table=" + DBTable + "&field=" + DBField + "&type=" + 
               type + "&value=" + encodeURIComponent(value) +
               "&excldbid=" + exclDBId;
   doHttpRequest(scriptUrl + paramStr, outputId);
}

Die Funktion erwartet fünf Parameter, die wir zuvor beim Aufruf der Funktion im HTML-Code bereits an einem Beispiel kennengelernt haben.

Zunächst überprüft die Funktion mit if(!document.getElementById), ob überhaupt die DOM-Schnittstelle zur Verfügung steht. Anschließend prüft sie, ob der übergebene Feldwert (Parameter fieldValue) überhaupt einen Wert hat. Falls der Benutzer in unserem Beispiel auf die Schaltfläche Prüfen klickt, ohne in dem Eingabefeld einen Wert eingegeben zu haben, können wir uns die Ajax-Verbindung nämlich sparen. In diesem Fall reagiert die Funktion mit der Ausgabe des Fehlers Keinen Wert angegeben. Die Ausgabe erfolgt dynamisch innerhalb des Formulars an der Stelle, an der auch die Ajax-Meldungen erscheinen sollen.

Sind diese Prüfunden überstanden, wird der Aufruf der Zentralfunktion doHttpRequest() des Ajax-Kernels vorbereitet (siehe siehe (5): Ein einfacher Ajax-Kernel). Der Funktion wird die URL eines serverseitigen Scripts übergeben sowie der id-Attributwert des HTML-Elements (outputId), in dem die serverseitig erzeugte Ergebnismeldung ausgegeben werden soll. Die URL des serverseitigen Scripts setzen wir zusammen aus der vollständigen HTTP-Adresse der Scriptdatei, gespeichert in scriptUrl, sowie einem GET-Parameterstring, gespeichert in paramStr. Über die GET-Parameter versorgen wir das serverseitige Script, ein PHP-Script, mit den nötigen Input-Daten. Alle Parameter, die unsere Funktion ajaxCheckDBValue() selbst erhalten hat, werden dabei an das serverseitige Script weitergegeben. Da der Feldwert, also die vom Anwender eingegebenen Daten (gespeichert in fieldValue) auch Zeichen enthalten können, die in einer URL-Adresse besondere Bedeutung haben, wenden wir die JavaScript-Standardfunktion encodeURIComponent() auf den Feldwert an. So wird der Feldwert URL-gerecht kodiert.

Zum Schluss wird die Ajax-Kernel-Funktion doHTTPRequest() mit den vorbereiteten Daten aufgerufen. Mehr ist nicht nötig. Die Ergebnismeldung wird vom serverseitigen Script erzeugt, und die Ajax-Kernel-Funktion sorgt dafür, dass sie an der gewünschten Stelle (nämlich im HTML-Element mit id-Attribut, das in outputId gespeichert ist) ausgegeben werden.

Serverseitige Verarbeitung

Wir nehmen für unser Beispiel an, dass es auf dem Server eine MySQL-Datenbank mit dem Namen cms gibt, zu der eine Tabelle namens templates gehört. In dieser Tabelle seien bislang folgende Daten gespeichert:

 +----+-------------+
 | id | name        |
 +----+-------------+
 |  1 | einspaltig  |
 |  2 | zweispaltig |
 |  3 | dreispaltig |
 +----+-------------+

Die id-Spalte speichert Autoincrement-Werte, wie sie in Datenbanktabellen häufig verwendet werden. In der Spalte name werden Template-Namen gespeichert. Diese Namen sollen tabellenweit eindeutig sein.

Unser serverseitiges PHP-Script checkDBValue.php, das in der Ajax-JavaScript-Funktion ajaxCheckDBValue() aufgerufen wird, hat also die Aufgabe, zu prüfen, ob der übergebene Wert, den der Benutzer im Feld eingegeben hat, in der Spalte name bereits vorhanden ist oder nicht.

Das PHP-Script hat in unserem Beispiel folgenden Code:

<?php

$dbh = mysql_connect("localhost", "dbuser", "dbpassword");
if(!$dbh)
   echo "<div>Keine Verbindung zum Datenbank-Management-System"; 
$sql = "USE cms";
$sqlResult = @mysql_query($sql, $dbh);
if(!$sqlResult)
   echo "<div>Keine Verbindung zur Datenbank</div>"; 
if(! isset($_GET['table']) or empty($_GET['table']))
   echo "<div>Keine Datenbanktabelle angegeben</div>";
if(! isset($_GET['field']) or empty($_GET['field']))
   echo "<div>Keinen Feldnamen angegeben</div>";
if(! isset($_GET['type']) or empty($_GET['type']))
   echo "<div>Keinen Feldtyp angegeben</div>";
if($_GET['type'] != "string" and $_GET['type'] != "num")
   echo "<div>Falschen Feldtyp angegeben</div>";
if(! isset($_GET['value']) or empty($_GET['value']))
   echo "<div>Keinen Wert angegeben</div>";
if(! isset($_GET['excldbid']))
   echo "<div>Keine Angabe zu auszuschließenden Datensätzen</div>";

if($_GET['type'] == "string")
   $fieldValue = "'" . $_GET['value'] . "'";
else
   $fieldValue = $_GET['value'];
$sql = "SELECT COUNT(*) AS count FROM " . $_GET['table'] ." WHERE " .
       $_GET['field'] . " = " . $fieldValue;
if((int) $_GET['excldbid'] > 0)
   $sql .= " AND id <> " . (int) $_GET['excldbid'];
$sqlResult = @mysql_query($sql, $dbh);
if(!$sqlResult) 
   echo "<div>Kein Datenbankergebnis</div>";
else {
   $res = mysql_fetch_array($sqlResult, MYSQL_ASSOC);
   if($res['count'] > 0)
       echo "<div><span class=\"warning\">Wert bereits vorhanden! 
             Bitte einen anderen Wert eingeben!</span></div>";
   else
       echo "<div>Der eingegebene Wert ist verfügbar</div>";
}

?>

Das Script baut zunächst mit der PHP-Funktion mysql_connect() eine Verbindung zum MySQL-System des Servers auf. Die dabei übergebenen Parameter sind natürlich in einer anderen Umgebung entsprechend anzupassen. Anschließend wird das SQL-Statement USE cms an MySQL gesendet, um die gewünschte Datenbank auszuwählen.

Daran anschließend überprüft das Script seine per GET-Parameter erhaltenen Daten. Fehlen übergebene Parameter oder enthalten sie keine oder ungültige Werte, wird mit echo eine entsprechende Fehlermeldung ausgegeben. Alles, was das Script übrigens mit echo ausgibt, wird von Ajax verarbeitet und wie definiert in der aktuell angezeigten Webseite dynamisch eingeblendet.

In der zweiten Hälfte baut das Script dann das SQL-Statement der eigentlichen Prüfabfrage zusammen. Mit SELECT count(*) ... wird ein Statement erzeugt, bei dem MySQL als Ergebnis nur die Anzahl der Datensätze (Tabellenzeilen) zurückliefert, auf die die formulierte WHERE-Klausel zutrifft.

Falls der GET-Parameter excldbid einen Wert größer 0 hat, wird die WHERE-Klausel dahingehend erweitert, dass der Datensatz, bei dem die Spalte id den Wert von excldbid hat, nicht mit berücksichtigt wird. Warum das? Ganz einfach: angenommen, das HTML-Formular, welches den Ajax-Request auslöst, ist ein Formular, in dem Daten eines bestehenden Templates geändert werden. In diesem Fall ist der vorbelegte Feldwert in der Datenbank natürlich schon vorhanden. Ein Klick auf Prüfen würde aus eben diesem Grund das für den Benutzer verwirrende Ergebnis Wert bereits vorhanden! Bitte einen anderen Wert eingeben! erzeugen. Um dies zu verhindern, kann beim Ändern eines bestehenden Datensatzes dessen id-Wert im Parameter excldbid übergeben werden.

Das PHP-Script kann seine Arbeit beenden, wenn das MySQL-Ergebnis vorliegt. Wurden mehr als 0 Datensätze gefunden, ist der Wert nicht mehr verfügbar. Entsprechende Meldungen werden mit echo ausgegeben und vom Ajax-JavaScript in die Webseite eingefügt.

Alle Quelltexte dieses Beispiels einschließlich komplettem HTML-Dokument und MySQL-create-Daten können Sie als ZIP-Datei downloaden.

Mozilla meets SELFHTML and Webkompetenz

Die PR-Agentur Arcendo hatte geladen, und die geladenen Gäste erschienen. Zusammengebracht werden sollten namhafte Vertreter von Mozilla Europe und vom Webprojekt SELFHTML. Keine schlechte Wahl, denn schließlich verzeichnen die Browser mit der Gecko-Engine in den Juni-2007-Statistiken von SELFHTML als Netscape getarnt eine satte Führungsrolle, und auch die Leser des Webkompetenz-Forums verwenden Mozilla-Browser, vor allem natürlich Firefox, zu über 50%. Nun bin ich ja eigentlich kein Vertreter von SELFHTML mehr, doch da der Event in den Räumen von Arcendo in München Haidhausen stattfand, fragte Thomas J. Sebestyen mich, ob ich dabei sein möchte.

Wir trafen auf keine Geringeren als auf den Kanadier Mike Shaver, ehemaliger Netscape-Mitarbeiter und Mitbegründer des Mozilla-Projekts, sowie auf den Franzosen Tristan Nitot, Präsident von Mozilla Europe. Die beiden sind derzeit auf einer PR-Tour, in der es um Themen geht, die uns allen wichtig sein sollten: um ein offenes, für alle zugängliches und für alle mitgestaltbares Web, damit einhergehend natürlich um OpenSource, um offene Kritik an bestehenden Webstandards sowie um die Frage, wie gefährlich jüngere Versuche kommerzieller Software-Firmen sind, dem Web neue, proprietäre Stempel aufzudrücken — vor allem sind damit Microsoft Silverlight und Adobe AIR gemeint.

Die knappe Zeit von etwas weniger als zwei Stunden reichte natürlich nicht aus, um über all diese Themen erschöpfend zu reden. Es wurde jedoch deutlich, dass die Mozilla-Leute die gegenwärtige technische Infrastruktur des Web, bestehend aus W3C-Standards, einem ECMA-Standard und einem breitgefächerten OpenSource-Angebot für die Server-Seite für ein sehr produktives Gespann hält, das es zu schützen und natürlich auch weiterzuentwickeln gilt, das aber auch noch Lücken hat. Es wurde festgestellt, dass sich das Web von einem ursprünglich dokument-orientierten Charakter hin zu einem multiplen Medium wandelt, das einerseits nach wie vor zahllose „Dokumente“, also textorientierte Informationen enthält, aber mittlerweile auch immer mehr Applikationen, also desktop-artige Anwendungen, die den Benutzern ermöglichen, persönliche oder Team-Daten im Web zu verwalten und zu verarbeiten, sowie immer mehr Multimedia. Vor allem bei diesen neuen Realitäten des Web fehlt es aber noch an der Dominanz und Präsenz offener Standards. Im Applikations-Sektor, der gerade erst so richtig zu boomen beginnt, stehen Microsoft, Adobe und einige andere kommerzielle Anbieter hächelnd in den Startlöchern. Das W3-Konsortium hat zwar applikations-relevante Spezifikationen wie das Document Object Model (DOM) oder die XMLHttpRequest-Schnittstelle (= Ajax) unter seinen Fittichen, doch das allein genügt nicht, um für den künftigen Markt der desktop-artigen Webanwendungen gerüstet zu sein. Und im Multimedia-Sektor hat Flash längst so deutlich das Rennen gemacht, dass es nur noch über die eigenen Füße stolpern könnte. W3C-Standards wie SVG oder SMIL wurden einfach nicht angenommern.

So betrachtet wird also nachvollziehbar, welchen tieferen Sinn der gegenwärtige PR-Feldzug von Mozilla hat: gerade jener Bereich des Web, der gerne als Web 2.0 bezeichnet wird (der Ausdruck ist in den ganzen zwei Stunden des Meetings übrigens höchstens ein oder zweimal gefallen ;-), eröffnet neue zu besetzende Felder. Und es wäre schade, wenn wir am Ende für mehr als die Hälfte aller Web-Inhalte Browser-Plugins benötigen, weil dahinter proprietäre Closed-Source-Technologien stecken, die sich durchgesetzt haben. Alles in allem also ein sehr interessantes Gespräch mit zwei führenden Köpfen der OpenSource-Welt, an dessen Ende es noch ein paar Merchandizing-Geschenke gab, die auch bei meinen Kleinsten gut ankamen:

Amos und Joshua „firefoxing“

Partner-Eintrag zu diesem Eintrag im SELFHTML Weblog:
Die Zukunft des Open-Webs: SELFHTML im Gespräch mit Mozilla

Wahltag in Frankreich mit Blogpole

44,5 Millionen Franzosen sind am heutigen Sonntag aufgerufen, den Nachfolger oder die Nachfolgerin von Staatschef Chirac zu wählen. Die Wahl gilt als spannend, weil es den letzten Umfragen zufolge viele noch unentschlossene Wähler gibt.

Nun nehmen wir mal den Fall an, dass solche Leser im Internet Orientierung holen. Das trifft sicherlich nicht auf all diese Wähler zu, doch auf einen stetig wachsenden Teil der Wählerschaft ohne Zweifel. Doch von wo aus könnte man als Suchender eine solche Orientierungsreise starten? Über einen entsprechenden Beitrag bei SoSo.net bin ich auf den Service Blogpole gestoßen.

Und was tut Blogpole? Es bietet eine grafische Übersicht des politischen Fraktionsspektrums in Frankreich — zumindest wenn man ein einigermaßen aktuelles Flash-Plugin in seinem Browser installiert hat. In alle politischen Kreise kann man hineinzoomen, und erhält dann eine grafische Darstellung eines Netzes. Jeder Punkt im Netz ist ein Weblog. Die Vernetzung zeigt, welche Blogs mit welchen interagieren, also besonders eng verlinkt sind. Und alle Blogs eines Netzes werden ideologisch betrachtet dem jeweiligen politischen Kreis zugeordnet. Die Blogs sind anklickbar, und wenn man das Öffnen von Popups nicht verweigert, gelangt man schnell in die Tiefen der einzelnen Blogs.

Ob sich jedes Blog, das sich hauptsächlich oder teilweise mit Politik befasst, tatsächlich so einfach einer bestimmten politischen Richtung zuordnen lässt, sei dahingestellt. Ein interessanter Versuch ist es aber allemal, der da unternommen wird. Interessierte können auf diese Weise sehr schnell in medias res zoomen, also in mehr oder weniger persönliche (authentische?) Ansichten, Argumentationen und Wahrnehmungen.

Blogpole kann als ein weiterer Versuch gelten, Zugänge zu Inhalten zu jenseits klassischer Suchmaschinen oder Webverzeichnisse zu vermitteln. Services dieser Art haben auf jeden Fall Zukunft und werden in den nächsten Jahren vermutlich noch in großer Zahl aus dem Boden sprießen. Da die Technik und oft auch die Redaktion dahinter jedoch nicht trivial ist, wird auch diese Vielfalt wieder den üblichen Lauf nehmen: alles, was fließt, fließt am Ende in ein, zwei, vielleicht drei große Ströme.

Tutorial: Ajax (2)

siehe auch:
(1): Was ist Ajax?

---

Warum heißt Ajax so?

Das Akronym Ajax steht für „Asynchronous JavaScript and XML“. Mit „asynchron“ ist in diesem Zusammenhang gemeint, dass eine HTTP-Kommuniktation zwischen Browser und Webserver auch ohne Anfordern einer komplett neuen Seite stattfinden kann, also während eine Webseite im Browser angezeigt wird — ausgelöst etwa durch Anwenderereignisse wie das Anklicken eines Elements.

Die Erwähnung von XML rührt daher, dass die Ajax-Technologie eng verknüpft ist mit dem Einsatz des vom W3-Konsortium standardisierten Document Object Models (DOM). Denn Inhalte, die JavaScript via Ajax-Schnittstelle vom Webserver anfordert, sollen in aller Regel dynamisch in eine bereits angezeigte Webseite eingebaut werden. In den meisten Praxis-Fällen erhält ein JavaScript vom Webserver einfach eine Portion HTML-Code, der dann mit der nicht ganz DOM-konformen, aber sehr beliebten Eigenschaft innerHTML in ein vorhandenes HTML-Element der angezeigten Webseite eingefügt wird.

Wer strenger DOM-konform arbeiten möchte, hat jedoch auch die Möglichkeit, sowohl in JavaScript als auch server-seitig mit DOM-Objekten zu arbeiten. Die JavaScript-Interpreter moderner Browser unterstützen das DOM zumindest so ausreichend, dass es sich sinnvoll einsetzen lässt. Serverseitig müssen Scripts, welche die Daten erzeugen, Wege finden, anstelle von HTML-Code in Textform DOM-Objektdaten zu erzeugen. In Programmiersprachen wie PHP gibt es dafür entsprechende Funktionsbibliotheken.

Dass in der Praxis viel häufiger mit textbasierten HTML-Code-Portionen und Einfüge-Operationen wie innerHTML gearbeitet wird, liegt auch daran, dass diese Form sowohl server- als auch client-seitig viel anspruchsloser und deshalb in aller Regel erheblich schneller ist. In den Praxisbeispielen dieses Tutorials werden wir uns der Einfachheit halber ebenfalls auf diese Variante beschränken.

Wo kann ich Ajax in Aktion sehen?

Ajax ist meistens dann im Spiel, wenn eine Website sich plötzlich so verhält, wie man es von leistungsstarken Desktop-Anwendungen gewohnt ist.

Beispiel 1: Google-Service Google Suggest:

http://www.google.com/webhp?complete=1&hl=en

Tippen Sie in das Suchfeld langsam etwas ein, etwa Ihren Vornamen. Nach jedem eingegebenen Zeichen erscheint eine Dropdown-Liste mit Vorschlägen für mögliche Suchausdrücke. Nach dem ersten Zeichen wird die Auswahl in der Regel noch sehr sinnlos sein, doch zwischen dem vierten bis zehnten Zeichen lässt sich der gewünschte Suchausdruk in aller Regel so weit eingrenzen, dass etwas Gewünschtes in der Liste dabei ist. Interessant bei der Vorschau ist vor allem die Angabe der Suchtrefferanzahl. So lässt sich bereits im Vorfeld einschätzen, ob eine Suche nach dem entsprechenden Ausdruck sinnvoll ist.

In diesem Fall ist jeder Tastendruck, den Sie eingeben, während sich der Cursor im Suchfeld befindet, ein auslösendes Ereignis. Sparen Sie sich jedoch die Mühe, im Quelltext der Suchseite von Google Suggest etwas Verständliches zu finden. Das SELFHTML-Beispiel zum Event-Handler onkeydown verrät Ihnen das Prinzip, wie eine Ereignisbehandlung dieser Art in JavaScript mit einfachen Mitteln zu bewerkstelligen ist.

Der Unterschied etwa zum erwähnten SELFHTML-Beispiel besteht darin, dass das JavaScript, das bei Google Suggest auf Tastendruck hin gestartet wird, im Hintergrund eine HTTP-Anforderung an den heimischen Server sendet. Dort erzeugt ein serverseitiges Programm aus dem Datenbankbestand von Google die Daten der kleinen Dropdown-Liste und sendet sie an das aufrufende JavaScript. Aus den erhaltenen Daten wird dann über DOM-Methoden die Dropdown-Liste in den HTML-Code der angezeigten Google-Suggest-Webseite eingefügt.

Übrigens arbeiten fast alle neueren Google-Services intensiv mit Ajax. Das Bewegen etwa im bekannten Service Google Maps basiert ebenso auf Ajax-Kommunikation wie das automatische serverseitige Zwischenspeichern beim Verfassen von E-Mails in Google Mail.

Beispiel 2: TurboDBAdmin

Dieses Beispiel werden Sie am ehesten nachvollziehen können, wenn Sie schon einmal mit einer grafischen Verwaltungsoberfläche für Datenbank-Management-Systeme gearbeitet haben. TurboDBAdmin ist eine web-basierte Verwaltungsoberfläche für MySQL. Eine Live-Demo des Freeware-Produkts ist auf dem Server des Anbieters aufrufbar:

http://www.turboajax.com/turbodbadmin_demo/

Links in der explorer-artigen Auswahl wird als oberster Eintrag der Host angezeigt, dessen Datenbanken verwaltbar sind. In der nächsten Ordnungsebene folgen die verwaltbaren Datenbanken. Im Demo ist dies lediglich eine einzige Datenbank. In der dritten Ordnungsebene werden die Tabellen der Datenbank angezeigt. Klicken Sie auf eine der Tabellen, z.B. PC-Res. Im Hauptbereich der Anwendung werden nun die Inhalte der Tabelle angezeigt. Die angezeigten Daten sind reichlich sinnlos, da es nur eine Testdatenbank ist, in der jeder — auch Sie — Datensätze einfügen, ändern oder löschen kann.

Wenn Sie beispielsweise auf eine der Spaltenüberschriften klicken, ändert sich die Sortierung der Tabelle so, dass nach der angeklickten Spalte sortiert wird. Dabei kommt Ajax zum Einsatz. Beim Anklicken (Event-Handler onclick) der Spaltenüberschrift wird ein JavaScript gestartet, das über HTTP ein serverseitig ausgeführtes Script aufruft. Dieses Script fragt mit einem SQL-Statement die Datenbank so ab, dass die neue Sortierung zustande kommt. Die erhaltenen Daten werden über HTTP an das aufrufende JavaScript übergeben. Das JavaScript sort für die Änderungen im HTML-Code der angezeigten Seite.

Mit der Menüschaltfläche Create Row können Sie der aktuell angezeigten Tabelle einen neuen Datensatz hinzufügen. Schreiben Sie einfach in die Tabellenzellen. Über die Menüschaltfläche Apply Edit können Sie die Eingaben speichern. Auch dabei wird wieder ein JavaScript aufgerufen, das via Ajax-Schnittstelle bzw. HTTP ein serverseitiges Script aufruft, das die Daten übergeben bekommt und in die Datenbank schreibt.

Dies ist nicht der Ort, um die einzelnen Möglichkeiten und Funktionen von TurboDBAdmin zu beschreiben. Wenn Sie selbst einen Webserver verwalten (beispielsweise auch einen lokal installierten Webserver) und PHP und MySQL in dessen Umgebung integriert haben, können Sie TurboDBAdmin downloaden und einfach in der eigenen Umgebung ausprobieren. TurboDBAdmin wird hier deshalb erwähnt, weil es eine typische ajax-basierte Webanwendung ist, von deren Sorte zur Zeit mehr und mehr entstehen.

Beispiel 3: web-basierter Chat von Fritz Weisshart

Ein idealtypisches Beispiel für den Einsatz für Ajax ist ein Chat. Denn ein Chat benötigt eine einen Server, damit die Chat-Teilnehmer interaktiv Text eintippen und die beigetragenen Inhalte anderer anwesender Teilnehmer sehen können. Das IRC-Protokoll, das für Internet-Chats gedacht ist, ist für Chat-Verbindungen optimiert. Dennoch haben viele Webanbieter auch den Wunsch, einen web-basierten Chat auf ihren Seiten anzubieten. Eine mögliche Lösung dafür stellt der Ajax-basierte Chat von Fritz Weisshart dar:

http://webdesign.weisshart.de/chat/

Der Link führt direkt zu einer Live-Demo des Chats. Zum Testbesuch können Sie sich mit den Daten Gast und demo anmelden.

Die Anwendungsoberfläche, die dann erscheint, ist dem Fensterinhalt eines Chat-Clients nachempfunden. Im Hauptbereich stehen zuletzt gepostete Beiträge. Rechts werden anwesende Benutzer angezeigt, und der Wechsel zu weiteren Chat-Räumen ist möglich. In dem Eingabefeld unterhalb des Hauptbreichs können Sie selbst Text eintippen und sofort beitragen.

Damit der Eindruck einer Live-Teilnahme entsteht, muss in regelmäßigen, relativ kurzen Intervallen eine Kommunikation zwischen JavaScript und Server stattfinden. Im Weisshart-Chat ist sie per Default auf 1 Sekunde eingestellt, wobei die Intervalle jedoch dynamisch seltener werden, je inaktiver der Chat ist (dies verrät ein Blick in den Quelltext des Chat-JavaScripts). Solche Konzepte sind auch nötig, um den Webserver nicht zu überlasten. Über die JavaScript-Methoden setTimeout() und setInterval() ist es möglich, JavaScript-Code intervall-gesteuert automatisch auszuführen. Der so ausgeführte Code kann selbstverständlich auch eine HTTP-Kommunikation über die Ajax-Schnittstelle starten. Auf genau diesem Prinzip basiert der Chat. Serverseitig verwaltet ein PHP-Script die aktuellen Logins und die aktuell verfügbaren Beiträge. Neue Beiträge oder Änderungen bei den anwesenden Benutzern werden an das aufrufende JavaScript übergeben. Dessen Aufgabe besteht dann darin, hinzugefügte Beiträge einzufügen und gegebenenfalls die Liste der Benutzer zu aktualisieren.

In Verbindung mit einer Server-Push-Technologie wäre es sogar möglich, einen Ajax-Web-Chat nicht in Form von intervall-gesteuerten Ajax-Aufrufen zu gestalten, sondern ereignisabhängig. Dann würde das verarbeitende Chat-Script auf dem Server nur aufgerufen, wenn ein Teilnehmer etwas beiträgt oder z.B. ein neuer Teilnehmer den Raum betritt. Das Script könnte den Server dann veranlassen, den neuen Chat-Zustand an alle übrigen Teilnehmer zu senden, ohne von ihnen einen HTTP-Request erhalten zu haben (Server-Push). Da heutige Webserver jedoch aus teils guten Gründen keine Server-Pushs unterstützen, bleibt die intervall-gesteuerte Ajax-Kommunikation in einem Chat wie dem von Fritz Weisshart die einzige Wahl.