Hypertext (3): Inhaltseinheiten und Verlinkung

siehe auch:
(1): Text und Linearität
(2): Computer und Hypertext

---

Inhaltseinheiten

Das „Neue“ an Hypertext ist nicht die elektronische Form, also nicht die Tatsache, dass Computer derzeit die am ehesten geeignete Hardware liefern. Auch lineare Inhalte lassen sich am Computer konsumieren. Das Neue an Hypertext ist nicht einmal, dass Hypertext Verweise enthalten. Auch herkömmliche, linear orientierte Inhalte enthalten Verweise. Das Neue ist allein, dass Verweise dank der Computertechnik sofort ausführbar sind, und dass dadurch Verweisziele sofort abrufbar sind. Diese Tatsache ist eigentlich trivial, aber doch entscheidend. Denn sie verändert die Art, Inhalte zu strukturieren.

In linearen Medien sind Verweise ein gut gemeintes Angebot, aber ihnen zu folgen, ist mehr oder weniger mühsam. Es ist bei solchen Medien nicht die Regel, dass Verweisen gefolgt wird. Deshalb sind die Inhalte an Verweiszielen in linearen Medien in der Regel auch nicht darauf eingerichtet, sich als potentielles Verweisziel zu präsentieren. Sie stehen stattdessen im Kontext der linearen Struktur, ohne Rücksicht darauf, woher ein Leser kommt.

Bei Hypertext ist das anders. Wegen der leichten Ausführbarkeit von Verweisen muss sich jedes potentielle Verweisziel so präsentieren, dass es von ganz verschiedenen „Quellen“ her gesehen ein sinnvoller, verständlicher und den Leser hoffentlich weiterbringender Inhalt ist. Deshalb gibt es bei allen Hypertext-Konzepten einen wichtigen Grundbegriff, den wir hier als Inhaltseinheit bezeichnen. Gemeint ist damit ein Inhalt, der sich selbst darüber bewusst ist, von ganz verschiedenen, ihm nicht bekannten Stellen aus gesehen ein sinnvolles Verweisziel zu sein.

Es gibt übrigens zahlreiche andere Bezeichnungen für solche Inhaltseinheiten: z.B. node, unit, item, document, card, information blocks, frame, statement, message, article, hyper-molecule oder guideline (all diese Bezeichnungen wurden vor allem durch Hypertext-Softwareprodukte der Vergangenheit geprägt).

Thematische Geschlossenheit von Inhaltseinheiten

Ein Inhalt, der „weiß“, dass er von ganz verschiedenen, ihm unbekannten Stellen aus gesehen ein brauchbares Verweisziel sein kann, darf so wenig wie möglich implizite Bezüge zu Inhalten außerhalb seiner selbst enthalten. Implizite Bezüge sind z.B. stillschweigende Voraussetzungen darüber, was ein Leser zuvor bereits gelesen hat. Oder Anspielungen „zwischen den Zeilen“ auf Inhalte, von denen angenommen werden darf, dass der Leser sie vorher bereits gelesen hat. Aber auch Formulierungen der Art „wie schon früher bemerkt“, die sich auf Inhalte außerhalb einer aktuellen Inhaltseinheit beziehen, sind meistens ungeeignet.

Inhaltseinheiten in einem Hypertext-Umfeld müssen also versuchen, inhaltlich möglichst in sich geschlossen zu sein. Die Forderung nach inhaltlicher Geschlossenheit ist jedoch erst die eine Hälfte. Die andere Hälfte ist das Gegenteil, nämlich die Forderung nach Vernetzung mit anderen Inhaltseinheiten.

Vernetzung von Inhaltseinheiten

Während implizite Bezüge in Inhalten eines Hypertext-Umfelds problematisch sind, sind explizite Bezüge umso wichtiger. Explizite Bezüge sind sichtbare Hinweise, die in den Inhalt eingefügt sind oder ihn umgeben. Im Computer, wo Inhaltseinheiten adressierbar sind, werden solche Hinweise zu ausführbaren Verweisen — Hyperlinks. Durch ausführbare Hyperlinks zu anderen Inhaltseinheiten kann eine Inhaltseinheit alle gewünschten gedanklichen, thematischen, logischen Rück- und Querbezüge zu anderen Inhalten herstellen. Hyperlinks treten damit an die Stelle von impliziten Bezügen.

Indem jede Inhaltseinheit explizite Bezüge zu anderen Inhaltseinheiten herstellt, entsteht unter den Inhaltseinheiten ein Netz. Das Setzen von Hyperlinks wird damit ein Teil des Erstellens von Inhalten. Die Verlinkung verlangt von Hypertext-Autoren die gleiche Aufmerksamkeit und Weitsichtigkeit wie das Strukturieren und Ausformulieren von Inhalten.

Strukturierte Hypertext-Netze

Nun neigen von Menschen geschaffene Netze dazu, kein chaotisches Verbindungsgewirr zu bleiben, sondern Struktur anzunehmen. Zunächst entstehen Überlandstraßen zwischen Orten. Doch früher oder später entstehen auch Fernstraßen, die nicht durch Orte führen, obwohl ihre Benutzer letztlich zu Orten wollen. Stattdessen erleichtern sie es, im Straßennetz einfacher von einem Ort zu einem anderen, weit entfernten Ort zu gelangen. Genauso ist es bei Hypertext-Netzen. Dort entstehen alsbald Inhaltseinheiten, die gar keinen Inhalt im eigentlichen Sinne haben. Stattdessen fungieren sie als Übersichtsseiten oder Verbindungsseiten, die vorwiegend aus Verweisen bestehen. Das Netz nimmt dadurch eine baumartige Struktur an, im Englischen als „Outline“ bezeichnet, die letztlich wieder an die klassische Buchgliederung in Teile, Kapitel, Abschnitte usw. erinnert.

Andere Hypertext-Netze sind dagegen eher so strukturiert wie eine relationale Datenbank. Da gibt es beispielsweise Inhaltseinheiten, die Spielfilme beschreiben, und andere Inhaltseinheiten, die Kurzbiographien zu Schauspielern enthalten. Bei dieser Konstellation kann jede Inhaltseinheit einer Spielfilmbeschreibung eine Liste der im Spielfilm mitwirkenden Schauspieler enthalten, deren Einträge als Hyperlinks ausführbar sind. So kann ein Anwender über Informationen zu Spielfilm A schnell zu Informationen über Schauspieler A gelangen. Die Informationseinheiten zu Schauspielern können wiederium eine Liste aller Spielfilme anbieten, in denen der Schauspieler mitwirkt, und in dieser Liste sind alle Spielfilme als Hyperlinks ausführbar. So kann der Anwender von Informationen über Schauspieler A schnell zu Informationen über Spielfilm B gelangen, von dort zu Informationen über Schauspieler C usw.

So könnte die Visualisierung eines Netzes aus Inhaltseinheiten aussehen — Quelle: Wikimedia

Der Vorteil von Hypertext ist, dass es keine unumstößlichen Vorschriften für die Vernetzungsstruktur gibt. Ein strukturiertes Hypertext-Netz muss weder eine strenge Baumstruktur noch eine strenge Gitternetzstruktur aufweisen. Es wird sich tendenziell an solchen Netztypen orientieren, weil diese Arten, Zusammenhänge herzustellen, dem menschlichen Denken entspringen. Doch es gibt bei echtem Hypertext keinen technisch bedingten Zwang, sich an einen bestimmten Netztyp zu binden.

Hyperlinks

Prinzipiell besteht Hypertext aus nichts anderem als aus:

• Inhaltseinheiten,
• Adressen für Inhaltseinheiten, und
• Links, die andere Inhaltseinheiten adressieren.

Auch das World Wide Web ist so konzipiert. Im Web ist eine Webseite die typische „Inhaltseinheit“. Webseiten besitzen Adressen, die URIs genannt werden. Für die Inhalte von Webseiten gibt es eine Standard-Auszeichnungssprache, nämlich HTML. HTML ermöglicht das Erstellen und Strukturieren von Inhalten und bietet außerdem die Möglichkeit an, Hyperlinks auf andere URIs zu setzen.

Links in der Praxis

Alle Hyperlinks tun letztlich das Gleiche, nämlich einen ausführbaren Link anzubieten, mit dem die Adresse einer anderen Inhaltseinheit verknüpft ist. In einem strukturierten Hypertext-Netz kommt es jedoch schnell dazu, dass Links bestimmte Aufgaben wahrnehmen. Ein Blick auf eine typische Webseite zeigt dies. Dort findet man beispielsweise:

• Links, die zu einer Navigation gehören.
  Die Navigation erscheint auf allen Webseiten einer Website in einem einheitlichen Erscheinungsbild an der gleichen Stelle. Je unterschiedlicher das Gesamtangebot der Website ist, desto wahrscheinlicher ist es, dass eine Webseite in der Navigation Links enthält, die praktisch nichts mit dem konkreten Inhalt der Webseite zu tun haben. Denn die Links der Navigation stehen nicht im Kontext der aktuellen Webseite, sondern im Kontext der gesamten Website. Dadurch werden solche Links aus dem Kontext der Inhaltseinheiten, in denen sie vorkommen, deutlich herausgelöst, obwohl sie noch Teil davon sind.
• Links, die zu einem sogenannten Breadcrumb-Pfad („Brotkrümelpfad“) gehören.
  Links mit dieser Aufgabe bilden eine erkennbare Hierarchie ab, die dem Anwender zeigt, wo eine aktuelle Webseite im Gesamtzusammenhang der Website gedanklich platziert ist. Links in Breadcrumb-Pfaden sind benutzerfreundliche Bestandteile in Hypertext-Netzen, die eine baumartige Netzstruktur aufweisen. Links, die zu einem Breadcrumb-Pfad gehören, sind jedoch ähnlich wie Navigationslinks aus dem eigentlichen Inhalt herausgelöst und nehmen die Standardaufgabe einer gedachten Hierarchie-Abbildung wahr.

Obwohl also Links aus technischer Sicht alle das Gleiche tun und den gleichen Aufbau haben, so erscheint es Benutzern einer Webseite oft so, als ob da grundverschiedene Arten der Verlinkung vorkommen. Im Web gehört es zur Kunst des guten Webdesigns, Webseitenoberflächen so zu strukturieren, dass Links darin ganz unterschiedliche Aufgaben wahrnehmen können.

Verlinkungsdichte

Sackgassen sind ärgerlich, wenn man sich als Fremder darin verfährt. Nicht anders ist es bei Inhaltseinheiten eines Hypertextes, die keinen einzigen Ausgang haben, also nicht einen einzigen Link anbieten. Das andere Extrem ist allerdings nicht weniger verwirrend. So gibt es beispielsweise manche Webseiten, die einen Text enthalten, der eigentlich zum Lesen gedacht ist, bei dem jedoch jedes zweite oder dritte Wort ein Hyperlink ist.

Links mitten in einem zu lesenden Text sollten generell möglichst nur so eingesetzt werden, dass für den Lesenden unmittelbar nachvollziehbar ist, was sich hinter dem Link verbirgt. Separat platzierte Links lösen dagegen weniger Stress bei der Informationsaufnahme aus. Eine Navigationsleiste beispielsweise kann ein Anwender während der Informationsaufnahme "innerlich ausblenden", ein anklickbares Wort mitten im gerade gelesenen Text beschäftigt ihn dagegen und sorgt damit für Ablenkung. Allerdings gibt es durchaus Textsorten, bei denen Leser Links im Text erwarten — auch überraschende, so etwa bei Weblogs.

Hyperlinks sind nötig, denn durch sie drückt eine Inhaltseinheit explizit und für den Anwender ausführbar ihre Bezüge zu anderen Inhaltseinheiten aus. Doch nicht jeder nur erdenkliche Bezug muss an jeder nur erdenklichen Stelle einer Inhaltseinheit durch einen Hyperlink explizit gemacht werden. Wenn beispielsweise in einem zusammenhängenden Text, der aus einer Handvoll Absätzen besteht, insgesamt zehnmal ein Wort vorkommt, das einen Bezug zu einem anderen Inhalt herstellen könnte, so genügt es, den Bezug einmal durch einen Link explizit zu machen.

Ähnlich ist es bei „trivialen“ Bezügen. Wenn sich beispielsweise ein Hypertext-Projekt um Tierarten dreht, die vom Aussterben bedroht sind, dann wirkt es eher befremdlich auf einen Leser, wenn in den Texten das Wort „Tierart“ ständig anklickbar ist. Allerdings gibt es auch ähnlich gelagerte Beispiele, die zu einem anderen Ergebnis führen. Wenn beispielsweise in einem enzyklopädischen Hypertext-Projekt in einer Inhaltseinheit über Berlin steht: „Berlin ist die größte Stadt Deutschlands“, so muss es nicht befremdlich wirken, wenn darin das Wort „Stadt“ anklickbar ist, obwohl angenommen werden darf, dass jeder Leser weiß, was eine Stadt ist. In diesem Fall darf angenommen werden, dass dem Leser sofort klar ist, dass das Verweisziel keine billige Worterklärung ist, sondern sich mit Themen wie Stadtentwicklung, Verstädterung usw. befasst.

All diese Aspekte muss ein Autor oder Redakteur, der Hypertextinhalte erstellt oder bearbeitet, in seine Überlegungen und Entscheidungen zur Verlinkung des Inhalts mit anderen Inhalten berücksichtigen.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Schön. Danke

Tutorial: Ajax (3)

siehe auch:
(1): Was ist Ajax?
(2): Warum heißt Ajax so? Wo kann ich Ajax in Aktion sehen?

---

Worin besteht die Ajax-Schnittstelle?

Die Ajax-Schnittstelle besteht in einem speziellen JavaScript-Objekt, das HTTP-Requests absetzen und HTTP-Responses empfangen kann. Nun gehört ein solches Objekt nicht seit jeher zum Umfang von JavaScript, und deshalb stellt sich natürlich die Frage: wie und wo ist es implementiert, und welcher Browser kennt es?

Die Entwicklungen eines entsprechenden Script-Objekts gehen auf Microsoft zurück. Bereits 1997 verfügte der damalige MS Internet Explorer 4.0 über eine „Remote-Scripting-Komponente“, die allerdings nur mit dem hauseigenen Webserver Exchange funktionierte. Seit Produktversion 5.0 (1999) lässt sich im Internet Explorer ein XML-HTTP-Objekt in Form einer ActiveX-Komponente ansprechen. Seit Version 7.0 kennt der Internet Explorer ebenso wie alle übrigen heute verbreiteten Browser, also etwa Firefox, Safari oder Opera, ein ActiveX-unabhängiges XML-HTTP-Objekt.

Folgende Browserweiche genügt, um die Ajax-Schnittstelle in allen heute verbreiteten Browsern zu initialisieren:

var httpRequest = false;
if(window.XMLHttpRequest)  // Mozilla, Safari, Opera, MS IE 7, ...
   httpRequest = new XMLHttpRequest();
else if(window.ActiveXObject) { // MS IE 5, 6
   try {
      httpRequest = new ActiveXObject("Msxml2.XMLHTTP");
   }
   catch (e) {
      try {
         httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
      }
      catch (e) {}
   }
}

Die Variable httpRequest soll das XML-HTTP-Objekt speichern. Über sie sind nach erfolgreicher Initialisierung Zugriffe auf Eigenschaften und Methoden des XML-HTTP-Objekts möglich. Zunächst wird die Variable mit dem Wert false initialisiert. Wenn ein XML-HTTP-Objekt erfolgreich initialisiert werden kann, ändert sich dieser Anfangswert.

Für alle modernen Browser genügt die Abfrage if(window.XMLHttpRequest). Damit wird geprüft, ob das XML-HTTP-Objekt im JavaScript-Interpreter verfügbar ist. Wenn ja, wird mit httpRequest = new XMLHttpRequest(); eine Instanz des Objekts in der zuvor erwähnten Variable httpRequest gespeichert.

Für das ActivX-basierte XML-HTTP-Objekt früherer Internet-Explorer-Versionen ist die Objektinitialisierung etwas komplexer. Mit if(window.ActiveXObject) wird zunächst herausgefunden, ob der Browser ein ActivXObject kennt, was ihn einigermaßen zuverlässig als Internet Explorer ausweist. Da es von Microsofts XML-HTTP-Objekt zwei Versionen gibt, wird auf beide Versionen geprüft. Zunächst wird getestet, ob die neuere Version ("Msxml2.XMLHTTP") verfügbar ist. Wenn nicht, wird versucht, die ältere Version ("Microsoft.XMLHTTP") anzusprechen. All diese Anfragen werden in try-catch-Statements eingebunden, um Laufzeitfehler zu vermeiden.

Die gute Nachricht lautet: es sind keine weiteren Verrenkungen für einzelne Browser erforderlich. Hat die Variable httpRequest ein XML-HTTP-Objekt gespeichert, kann fortan für alle Browser gleich programmiert werden, da das Objekt selbst, also seine Eigenschaften und Methoden, in allen Browsern gleich implementiert sind.

Wie wird Ajax standardisiert?

Die Entwicklung des XML-HTTP-Objekts verlief zunächst weitgehend ungesteuert. Mittlerweile hat sich jedoch das W3-Konsortium der Sache angenommen. Die aktuelle Spezifikation des XMLHTTPRequest-Objekts, wie es im offiziellen Wortlaut heißt, ist unter folgender Adresse zu finden:

http://www.w3.org/TR/XMLHttpRequest/

Derzeit (Stand: April 2007) ist dort noch keine Empfehlung (Recommendation) zu finden, sondern „nur“ eine Working Draft, also ein Arbeitsentwurf. Da das W3-Konsortium jedoch in diesem Fall eigentlich nur sanktioniert, was längst realisiert ist und genutzt wird, ist in der Spezifikation nicht mehr mit dramatischen Änderungen zu rechnen.

Der Einsatz von Ajax ist also keine halbseidene, proprietäre Angelegenheit mehr, sondern darf sich mittlerweile auf die Normierungshoheit des W3-Konsortiums berufen.

Ein Blog wird sieben Jahre alt

In einem Posting im Webkompetenz-Forum hat uns Schockwellenreiter alias Jörg Kantel verraten, dass sein Blog nun stattliche sieben Jahre alt ist.

„Wir sind eine zivilisierte Spezies. Deshalb soll künftig niemand einen unrechtmäßigen Vorteil aufgrund der Tatsache erlangen, daß wir gemeinsam mehr wissen als einer von uns wissen kann“. So lautet der erste Blog-Eintrag mit dem Titel „Das offene Ohr“ vom 23.04.2000, den ich finden konnte.

Vor sieben Jahren, als gerade die Dotcom-Welle mit lautem Getöse durchs Netz schwabbte, kannte noch so gut wie niemand die Ausdrücke „Weblog“ oder „Blog“. Dabei lässt sich die Geschichte der Blogs laut Wikipedia bis zur Mitte der 90er Jahre zurückverfolgen. Was eigentlich auch nicht weiter verwunderlich ist, denn eine chronologische Orientierung von Inhalten ist schließlich keine Erfindung der jüngsten Zeit. Neueren Datums sind dagegen Vernetzungsstrategien wie Trackbacks/Pingbacks oder die Schlüsselwörter/Labels, um zusätzlich einen thematischen Zugang zu einem Blog zu erhalten.

Wer so früh mit dem Bloggen begann, hat jedoch zweifellos aufs richtige Pferd gesetzt. Denn mittlerweile, wo die Anzahl der Blogs so stark explodiert, wissen viele Novizen gar nicht mehr, dass man früher schon etwas Ähnliches kannte, damals bekannt unter dem Begriff „Homepage“. Der eingangs erwähnte Forumsthread aus dem Webkompetenz-Forum ist dort übrigens nicht der einzige zum Thema in letzter Zeit. Zwei andere Threads, die sich ebenfalls mit dem Bloggen befassen, sind Massebloggen oder Qualitätsbloggen und Falls jemand ein eigenes Blog starten will.

Jörg Kantel jedenfalls auch hier noch einmal „allerschärfsten Glückwunsch“ zum Blog-Geburtstag.

Tim Berners Lee und das Blabla von Web 2.0

Das trifft natürlich genau die Thematik dieses Blogs, die der Telepolis-Artikel mit dem Titel Web 2.0 ist nutzloses Blabla, das niemand erklären kann (Untertitel: Tim Berners-Lee zum Hype des „neuen Web“) anspricht.

Nach einem kleinen Ausflug in die Folgen der „Onlinisierung der Wirklichkeit“ (Depot-Anbieter bietet Depot-Kontoauszüge per Schneckenpost künftig nur noch gegen Aufpreis an) kommt der Artikel zur Sache. Anlass ist ein IBM Developer-Works-Podcast Interview mit Tim Berners-Lee (Textmitschrift in Auszügen oder Original-MP3-Podcast (ca. 17 MByte, ca. 25 Minuten) — beides in Englisch).

Der Interviewer befragt Berners-Lee unter anderem zum Thema „Web 2.0“. Darauf reagiert der Gründervater des Web vergleichsweise gereizt. Eine reine Luftblase sei das, die einen verbinden es mit Blogs und Wikis, die nächsten mit mehr standardisiertem Webdesign, und wieder andere mit Ajax und mehr desktop-artigen Webanwendungen. Doch am Ende hat sich nichts geändert: alle Blogs, alles Wikis, all die neuartigen Anwendungen mit dem Ajax-optimierten Look and Feel benutzen letztlich nichts anderes als HTML, HTTP und URIs. Also pures Original-Web (1.0, wenn man so will).

Das Anliegen von Tim Berners-Lee ist nur zu verständlich, und es ist auch eines der wichtigsten Anliegen des Webkompetenz-Blogs. Nicht zufällig versucht dieses Blog nicht krampfhaft, Teil der „Web-2.0-Szene“ zu werden, sondern eher, diese Szene für Außenstehende zu beobachten. Denn viele interessante Ideen entstehen dort, von denen erwartet werden kann, dass sie künftig im Web von Bedeutung sein werden. Doch in zahlreichen Szene-Blog-Einträgen wird auch peinliche Selbstbeweihräucherung und dümmliche Abgrenzung betrieben, die den Eindruck enstehen lässt, als sei vor der gehuldigten Blogosphäre nur Wüste gewesen im Web.

Letztlich geht es darum, wie Hypertext nicht nur Inhalte, sondern auch Menschen verbindet. Doch das ist kein Verdienst von Web 2.0, sondern eine ganz natürliche Folge der Tatsache, dass hinter vernetzten Inhalten Menschen stehen. Und es ist gut, dass Tim Berners-Lee darauf mal wieder deutlich hingewiesen hat.

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.

BarCamps - die Kreativkonferenzen der Neuzeit

Der gemeine ambitionierte Web-User bemüht sich ja, all die neuen Begriffe rund ums Web 2.0 zu verstehen — egal ob Social Bookmarks, Mashup, Tag Cloud oder Content-Syndication. Jetzt kommt noch eine weitere Vokabel dazu: BarCamp.

Warum das? Nun, wer Blogs liest, die sich mit den neueren Web-Trends auseinandersetzen, liest in letzter Zeit immer häufiger von BarCamp-Meetings. Und der verlinkte Wikipedia-Artikel klärt uns darüber auf, dass Ende September 2006 in Berlin und Wien die ersten BarCamps im deutschsprachigen Raum stattfanden, nachdem die BarCamp-Idee, die ihre Initialzündung ein Jahr zuvor im kalifornischen Palo Alto hatte, sich binnen weniger Monate fieberhaft rund um den Globus ausgebreitet hatte.

Ob der Begriff „BarCamp“ aber nur deshalb so cool ist, weil er aus der gleichen Wortschmiede stammt wie der Begriff „Web 2.0“? Beide gehen auf den O’Reilly Verlag zurück, der die Phantasie der Techie-Szene seit jeher beflügelt — mit vorwiegend gut geschriebenen Computerfachbüchern, auf deren Titel meist ein handgezeichnetes Wildtier prangt. Der O’Reilly Verlag genießt aber auch deshalb Kultstatus, weil er sich stärker als andere Verlage um die OpenSource-Szene kümmert. Das wiederum hängt eng damit zusammen, dass O’Reilly jahrelanger Arbeitgeber von Larry Wall war, dem Entwickler der OpenSource-Scriptsprache Perl.

Doch zurück zu den BarCamps: wie eine Suche bei Bloglines zeigt, wird viel über Barcamps geschrieben. Das ist ja auch ganz normal, da BarCamp-Teilnehmer sich nicht selten über ihre Blogs organisieren. Und die zahllosen Digitalfotos, die zu Real-Life-Treffen von Onlinern gehören wie das Salz zur Brezel, müssen natürlich auch veröffentlicht werden — meist direkt vom BarCamp aus über Flickr oder ähnliche Services.

Und was passiert auf einem typischen BarCamp? Damit es den Charakter einer Fachveranstaltung hat, werden Vorträge gehalten. Die Teilnehmer sind aufgefordert, sich, ihre Arbeit, ihr Projekt oder ein Thema, mit dem sie sich näher befassen, in einem Vortrag vorzustellen. Die Vorträge sollten nicht zu lang sein, um vorzeitige Ermüdungserscheinungen zu vermeiden. Darüber hinaus wird sich natürlich intensiv ausgetauscht. Kennenlernen kann man sich zwanglos beim Versuch, das eigene Notebook am nächsten WLAN anzumelden, oder beim letzten Bier, das man, in den Schlafsack gekuschelt, genießt, bevor die Sonne endgültig schon wieder aufgegangen ist und man seine zwei Stunden Schlaf nimmt.

Wem das jetzt noch zu allgemein ist, der kann ja mal beispielhaft in das Wiki zum Barcamp Frankfurt hineinschauen. Es ist nämlich kein Zufall, dass dieser Beitrag über Barcamps heute veröffentlicht wird. Irgendwas soll das Volk ja lesen, während die Crème de la Crème der Bloggerszene abgesehen von ein paar hastigen Live-Beiträgen direkt vom Barcamp in Frankfurt, das just stattfindet, kaum zum Schreiben kommt. Ein Blick in die Themenvorschläge beweist, dass ein BarCamp durchaus eine Menge Weiterbildungspotential hat. Von modernem Webdesign über Freifunk, CakePHP und die Entwicklung einer Suchmaschine bis hin zu Web 2.0 in China und dem Betreiben eines lokal orientierten Blogs reicht das Themenspektrum, das in diesen Stunden im Firmengelände von Cisco in Frankfurt behandelt wird.

Neu ist die Idee der BarCamps sicher nicht. Schon vor sehr langer Zeit hatten Konzile ganz ähnliche Aufgaben. Doch das ist kein Argument gegen BarCamps, sondern bestätigt eher, dass die Selbstorganisation der modernen Webworker weiter zunimmt. Deren Einfluss sollte niemand unterschätzen. Es ist sehr wahrscheinlich, dass viele Web-Standards, an die wir uns in fünf oder zehn Jahren halten werden, viele Webanwendungen, mit denen wir dann arbeiten werden, und viele Problemlösungen, für die wir dann dankbar sein werden, ihren geistigen Ursprung in einem der vielen BarCamps gehabt haben werden.

Hypertext (2): Computer und Hypertext

siehe auch:
(1): Text und Linearität

---

Hypertext und adressierbarer Speicher

Die wesentliche Eigenschaft von Hypertext besteht darin, Sprünge zwischen entfernten Inhalten sofort ausführbar zu machen. Dazu sind Verweise und adressierbare Ziele (Anker) erforderlich.

Lineare Medien sind für diese Anforderungen schlecht geeignet. Seitenzahlen sind schlechte Adressen, weil das Aufschlagen und Suchen lange dauert, vor allem dann, wenn es viele Male durchgeführt werden soll. Sendezeiten sind noch schlechtere Adressen, weil man abwarten muss, bis eine Sendung anfängt.

Die Voraussetzung für ein nicht-lineares Medium ist, dass ein Zugriff auf darin gespeicherte Inhalte direkt und schnell möglich ist. Computer verfügen heute über solche Speicher. Das war allerdings nicht immer so. In den Anfängen der Computer-Zeit dominierten Magnetbänder, Lochstreifen und ähnliche Medien. Das Speichern von Daten auf solchen Speichern ist nur sequenziell möglich, also genauso linear wie in einem Buch. Zwar ist es möglich, den Computer auf solchen Speichern nach bestimmte Stellen suchen zu lassen, doch wer schon mal versucht hat, auf einem Videoband zehn markierte Szenen eines Films anzuwählen, weiß, dass so etwas letztlich ebenfalls zeitraubend ist.

Den eigentlichen Durchbruch für nicht-lineare Medien stellen Datenspeicher mit wahlfreiem Zugriff (engl.: random access memory, abgekürzt RAM) dar. Zu dieser Art von Datenspeicher zählt in modernen Computern unter anderem der Arbeitsspeicher, der oft als RAM bezeichnet wird, was aber eigentlich nicht korrekt ist, da RAM eine ganze Gattung von Speichern kennzeichnet. Festplatten, CDs, DVDs, USB-Sticks oder SD-Cards gehören ebenfalls zu den RAM-Speichern.

Festplatten-Lese-/Schreibkopf über Plattenscheibe (Platter) — Quelle: Wikimedia

Die Zeiten, die ein Computer benötigt, um auf RAM-Speichern eine bestimmte Stelle zu finden, weichen zwar erheblich voneinander ab. So ist der Zugriff in einem elektrischen Speicher (z.B. Arbeitsspeicher) um ein vielfaches schneller als der Zugriff auf einem magnetischen Speicher (z.B. Festplatte). Doch insgesamt liegen die Zugriffszeiten bei RAM-Speichern weit unter dem, was ein Mensch als konzentrationsstörende Verzögerung wahrnehmen würde.

Hypertext in Netzwerken mit computerübergreifender Adressierung

Führt ein Verweis in einem Buch zu einem ganz anderen Buch, so kann sich die Zeit, um das Verweisziel zu lesen, auf Zeiträume erhöhen, die weit jenseits einer Konzentrationsphase liegen, z.B. dann, wenn das Buch mit dem Verweisziel nur in einer entfernten Bibliothek erhältlich ist. Bei Computern ist das an sich nicht anders. Wenn Inhalte auf andere Inhalte verweisen, die auf einem entfernten, nicht verbundenen Computer gespeichert sind, nutzen die Vorteile des RAM-Zugriffs überhaupt nichts.

Computer-Netzwerke bieten jedoch die Möglichkeit, schnell auf Inhalte entfernter Computer zuzugreifen. Allerdings hängt viel davon ab, wie viele Computer mit relevanten Inhalten an einem Netzwerk hängen, und wie belastbar das Netzwerk ist, wenn viele Benutzer es nutzen. Zwei Faktoren haben entschieden dazu beigetragen, dass heute so etwas wie weltweiter Hypertext möglich ist: zum einen der in vielen Ländern intensiv vorangetriebene Ausbau der physischen Netzwerkverbindungen, und zum anderen die defacto-Einigung auf Netzwerk-Protokollstandards wie TCP/IP, der zum Internet in seiner heutigen Form führte.

Hypertext ist prinzipiell ein Fass ohne Boden. Hypertext besteht aus Inhalten, die sich der Tatsache bewusst sind, dass sie sich inhaltlich in einem Kontext befinden. Durch Verweise (Hyperlinks) wird dieses Bewusstsein explizit ausgedrückt. Die Adressierung von Kontext-Inhalten muss jedoch von der technischen Seite der Computer-Netzwerke entkoppelt werden, da Adressen von Inhalten exakter sein müssen als reine Netzwerkadressen von Computern. Mit dem Konzept der URIs hat Tim Berners Lee eine solche Form der Adressierung geschaffen und standardisiert. Allein schon deshalb gebührt ihm der Titel „Gründervater des Web“.

Hypertext und Computer-Anwender

Bei allen Vorteilen, die RAM-Speicher und Netzwerke bieten, sind Computer nur dann für Hypertext geeignet, wenn angemessene und für Anwender angenehme Benutzerschnittstellen hinzukommen. Noch bis in die 90er Jahre und die Anfänge des World Wide Web hinein waren Computer mit nicht-grafischen, reinen Textoberflächen weit verbreitet, und die meisten Anwender schauten in kleine, flimmernde und unscharfe Röhrenbildschirme.

Doch selbst bei komfortablen Bildschirmen und angenehm empfundener grafischer Benutzeroberfläche bleiben Probleme bestehen: Heutige Personal Computer sind nicht für langes Lesen konzipiert, sondern zur Interaktion zwischen Anwender und Rechner. Hypertext ist nach heutiger Technik nur in elektronischer Form sinnvoll möglich. Aber die elektronische Repräsentation von Inhalten hat in den Köpfen der meisten Menschen noch nicht den selbstverständlichen Platz eingenommen, den das Buch darin hat. Das verwundert auch nicht weiter angesichts der Tatsache, dass bei diesem Vergleich ein, zwei Jahrzehnte an mehreren Jahrhunderten gemessen werden. Außerdem ist nicht unbedingt anzunehmen, dass Computer bis in alle Zeiten elektronik-basiert arbeiten werden (Stichwörter optische Computer und DNA-Computer).

Die Infrastruktur für weltweiten Hypertext existiert mittlerweile, und sie stabilisiert sich. In den Köpfen der Anwender wird Hypertext von Jahr zu Jahr ein wenig selbstverständlicher. Insgesamt gesehen handelt es sich jedoch immer noch um eine sehr junge Repräsentationsform für Inhalte. Viele Menschen kommen noch nicht so gut damit zurecht. Deshalb ist es weiterhin wichtig, die Eigenschaften von Hypertext begreiflich und bewusst zu machen. Der Anwender, besonders der durchschnittliche, ist jedenfalls nicht so leicht zu revolutionieren wie die Technik.

Urheber- und Nutzungsrechte bei user generated content

„Wir können alles — außer Deutsch“, lautet ein selbstbewusster Werbespot des Landes Baden-Württemberg. Dann hat man für das Blog Social Software @ Baden-Württemberg entweder einen Ghostwriter gefunden, oder man hats mittlerweile gelernt. Aktuell behandelt das Blog jedenfalls ein Thema, das allmählich immer brisanter wird: wem gehört eigentlich der sogenannte user generated content, welche Nutzung ist damit erlaubt, und welche Rechte hat ein User, der auf einer Web-Plattform etwas beigetragen hat?

Der Blog-Beitrag Nutzungsrecht von Userbeiträgen verweist dabei auf eine Diskussion im Business-Forum Xing, in der es vor allem um das Recht von Forumsbenutzern auf die Löschung ihrer Beiträge geht. Gerade dieses Problem ist in der Tat aktuell. Arenen wie das SELFHTML Forum, die schon einige Dienstjahre hinter sich haben, sind besonders betroffen. Immer häufiger melden sich dort ehemalige Novizen, die heute nicht mehr wollen, dass ihre dummen ersten Fragen zu HTML und PHP oder ihre verräterischen Zornesausbrüche von einst gefunden werden, wenn jemand nach ihrem Namen googelt, zum Beispiel Personalmanager.

Nun scheint die deutsche Rechtslage den Usern durchaus das Recht zu geben, frühere Beiträge von ihnen zu löschen. Aus Sicht des Persönlichkeitsrechts und des Urheberrechts ist das auch durchaus nachvollziehbar. Problematisch ist jedoch die Tatsache, dass ein User-Beitrag sich nicht immer und überall chirurgisch sauber entfernen lässt. In thread-basierten Foren beispielsweise kann von einem einzelnen Posting eine mehr oder weniger große Substruktur an weiteren Beiträgen abhängen. Ohne das Ausgangsposting würde die Thread-Logik zerstört, weshalb dann möglicherweise ganze Teilbäume von Foren-Threads gelöscht werden müssten. Das könnte wiederum mit Rechten anderer Benutzer konfligieren, die vielleicht viel Zeit und Mühe investiert haben in dem Glauben, dass ihre Beiträge dauerhaft veröffentlicht werden. Ebenso problematisch ist die Kultur des Zitierens. Damit Leser nicht immer zwischen Postings hin- und herwechseln müssen, ist es üblich, Texte aus einem Posting, auf die man sich in einer Antwort konkret bezieht, noch einmal zu zitieren. Nicht selten trifft man sogar auf Fullquotes. Das Löschen eines Postings würde in diesem Fall also nicht genügen. Wieder entsteht dabei die Problematik, dass andere Postings mitgelöscht werden müssen, was im übrigen nicht nur Interessen anderer Benutzer betrifft, sondern auch die Frage aufwirft, wie viel redaktionelle Nachforschung dem Forumsbetreiber zugemutet werden kann, um Löschwünsche wirklich sauber zu erfüllen.

Ein weiteres Problem besteht darin, dass ein Forumsbetreiber zwar Inhalte aus seinen eigenen Archiven löschen kann, nicht jedoch aus dem Datenbestand von Suchmaschinen oder gar Einrichtungen wie der Internet Wayback Machine, die frühere Stände von Websites für die Nachwelt bewahrt. Dieses Problem betrifft immerhin nur Foren oder von Benutzern beigetragene Inhalte, die öffentlich zugänglich sind. Dennoch zeigt die Problematik, dass etwas, das jemals öffentlich im Web stand, nicht so einfach tilgbar ist, wie es den Anschein hat.

Irgendwann wird vermutlich auch die Rechtsauffassung den Umstand berücksichtigen müssen, dass nichts mehr vollständig löschbar ist im Web. Und wer im Web veröffentlicht, und sei es auch nur als content-generierender User in einem Blog-Kommentar, einem Forum, einem Wiki oder einer Community, muss die Kunst der Gelassenheit erlernen: Gelassenheit gegenüber der Tatsache, dass die eigenen Spuren so schnell nicht verwischen. Vielleicht lernen dabei sogar einige, was sie sonst nicht gelernt hätten, nämlich mit der eigenen Vergangenheit zu leben!

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.

Online-Lesen im Wandel?

Als ins breite Bewusstsein gelangte, dass viele Webseiten nicht nur zum Klicken und Mal-Kurz-Reingucken gedacht sind, sondern lesbare Informationen enthalten, war der Widerstand noch groß. Die fehlende Haptik der Bildschirmtexte wurde bemängelt, und natürlich, dass man sie nicht in gemütlicher Umgebung (Bett, Café, Toilette) konsumieren kann.

Dank der modernen Notebooks hat sich zumindest letzteres Argument etwas entschärft. Interessanter ist jedoch ein schleichender Wandel, der mittlerweile zu beobachten ist. Während der 1999 erschienene Artikel Elektronische Wörter und grafischer Zeitgeist noch von revolutionären Ansichten sprach, die man hatte, wenn man eine künftige Ablösung von Papier-Medien durch elektronische Medien ernsthaft in Erwägung zog, so wird mittlerweile viel offener darüber gesprochen. Ein Beispiel ist der aktuell erschienene Heise-Beitrag re:publica: „Print ist tot“.

Hintergrund ist die Veranstaltung re:publica07, die gerade in der Berliner Kalkscheune stattfand. Veranstaltet von zwei führenden Blogger-Institutionen, Spreeblick und Netzpolitik.org, hatte die Blogger-Konferenz den Zweck, den Alltag der Blogger zu reflektieren.

Generell lässt sich feststellen, dass Printmedien noch am ehesten eine lange Zukunft haben, wo Wertigkeit gefragt ist, also etwa bei Hardcover-Büchern und großformatigen Bildbänden. Am bedrohtesten sind dagegen jene Papiermedien, die Aktuelles enthalten und für den schnellen Einwegkonsum gedacht sind — allen voran die Tageszeitungen. Die Absatzzahlen von Zeitungen und Zeitschriften sinken bereits (wohlgemerkt: nur die Absatzzahlen der Printausgaben). Noch spricht niemand vom Blättersterben, weil die meisten Magazine aus Auflagenhöhen sinken, die weit über der Rentabilitätsgrenze liegen. Doch wenn der Sinkflug weitergeht, werden im Lauf der nächsten zehn Jahre bereits etliche Printausgaben von Zeitungen und Zeitschriften betroffen sein. Interessant hierzu ist auch der Artikel Zukunft der Zeitung (PDF) von Dr. Friedhelm Haak.

Einig sind sich gegenwärtige Einschätzungen meist darin, dass derzeit noch nicht genau absehbar ist, wie schnell die Entwicklung tatsächlich voranschreitet, und welche Konsequenzen wann zu spüren sein werden. Viel hängt auch davon ab, wie sich die tatsächliche Akzeptanz des Lesens von Texten online am Bildschirm weiterentwickelt. Feedreader etwa tragen viel dazu bei, das Lesen am Bildschirm effizienter und übersichtlicher zu gestalten. Aber bis es wirklich preiswerte Breitband-Flatrates fürs Funknetz gibt und das Notebook auch in jeder U-Bahn online bleibt, ist immer noch ein gutes Stück Weg.

Osterferien

Im Webkompetenz-Blog wird es für ca. 10 Tage nichts Neues geben. Der Blogger fährt über Ostern mit Kind und Kegel zur Verwandtschaft.

Stimmt es eigentlich, dass in der Schweiz der Kuckuck die Ostereier versteckt, in Hessen und Westfalen der Fuchs, und in Thüringen der Hahn? Und in Australien der Kaninchennasenbeutler, weil der Hase dort als Schädling gilt? Zumindest ist das so laut Wikipedia-Artikel über Ostern. Wen solche Bräuchtümer eher weniger tangieren, der kann sich ja stattdessen darin üben, die Formel zur Berechnung von Ostern zu verstehen. Und pubertierende Leser, die sich gerne böse vorkommen wollen, dürfen ihren Lieben klarmachen, warum Ostern dieses Jahr ausfällt.

Wie auch immer: „Das Herz hat auch sein Ostern, wo der Stein vom Grabe springt.“ (Emanuel Geibel, Lyriker und Dramatiker, 1815-1884)

Tutorial: Ajax (1)

Ajax erfordert ein solides Vorwissen sowohl in JavaScript und dem Document Object Model (DOM), als auch in einer serverseitigen Web-Programmiersprache wie PHP, Perl oder Python. XML-, HTML- und CSS-Kenntnisse werden in vielen Fällen ebenfalls benötigt, sowie nicht selten auch Kenntnisse in Datenbank Management Systemen wie etwa MySQL. Und last but not least sind Kenntnisse über Einzelheiten des HTTP-Protokolls von Vorteil. Wirklich eine Menge Know-How also, weshalb die Ajax-Technologie auch eher im Profibereich angesiedelt ist.

Lassen Sie sich dennoch nicht gleich abschrecken. Wenn Sie von den zuvor genannten Sprachen und Technologien wenigstens schon einmal gehört und eine ungefähre Vorstellung davon haben, werden Sie zumindest die prinzipielle Funktionsweise von Ajax verstehen.

Was ist Ajax?

Für Ajax ist es wichtig zu verstehen, wie die HTTP-Kommunikation üblicherweise abläuft. Werfen wir deshalb zunächst einen kurzen Blick darauf, wie eine Webseite zum aufrufenden Browser kommt. Durch Anklicken eines Links, Eintippen einer Web-Adresse oder Auswählen eines Bookmarks sendet der Browser des Benutzers einen sogenannten HTTP-Request los. Das HTTP-Protokoll muss sich nicht darum kümmern, wie die Anfrage zum gemeinten Webserver gelangt. Dies übernimmt das TCP-Protokoll. Der Inhalt eines HTTP-Requests sieht ungefähr so aus:

GET /search/label/Ajax HTTP/1.1
Host: webkompetenz.blogspot.com
Connection: close
Accept-Encoding: gzip
Accept: text/xml,application/xml,application/xhtml+xml,text/html;
        q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) 
            Gecko/20061204 Firefox/2.0.0.1

Sie müssen nicht alles aus dem Beispiel verstehen. Es genügt zu wissen, dass GET ein HTTP-Kommando ist, mit dem der aufrufende Browser nach Daten verlangt. Die Domain, von der er diese Daten verlangt, ist im Beispiel webkompetenz.blogspot.com. Die Web-Pfadadresse, die er innerhalb dieser Domain verlangt, lautet im Beispiel /search/label/Ajax. Daraus ergibt sich folgende vollständige URL-Adresse:
http://webkompetenz.blogspot.com/search/label/Ajax
Das ist die Adresse, die der aufrufende Browser angefordert hat.

In den weiteren Informationen sendet der Browser noch diverse Informationen darüber mit, etwa in welcher Form er Daten akzeptiert, und wer er selber ist (seine eigene Produktidentifizierung).

Der aufgerufene Webserver beantwortet das GET-Kommando mit einem Response-Kommando. Das Response-Kommando besteht in jedem Fall aus einem HTTP-Statuscode sowie einem HTTP-Header, bestehend aus einem oder mehreren Header-Feldern. Was ein Web-Browser, der obige Webadresse angefordert hat, also beispielsweise als Antwort erhält, könnte in etwa so aussehen:

RESPONSE HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Last-Modified: Thu, 29 Mar 2007 13:27:46 GMT
Cache-Control: max-age=0 private
Etag: "98d95bd1-a138-4c47-a780-3a2bafe45368"
Content-Encoding: gzip
Date: Thu, 29 Mar 2007 19:48:28 GMT
Server: GFE/1.3

Auch das müssen Sie nicht alles verstehen. Die erste Zeile im Beispiel ist der HTTP-Statuscode. Die Nummer 200 bedeutet: alles in Ordnung, angeforderte Daten sind vorhanden, verfügbar und werden gesendet. Die übrigen Angaben sind HTTP-Header-Felder, beispielsweise zum Inhaltstyp der Daten oder zur Datenkompression.

Im Anschluss an dieses Set aus HTTP-Statuscode und HTTP-Header-Feldern folgen in unserem Fall die eigentlichen Nutzdaten, also der HTML-Code der angeforderten Webseite.

HTTP-Kommunikation „zwischendurch“

Kommunikation zwischen Browser und Webserver findet also dann statt, wenn der Browser eine neue URL-Adresse vom Webserver anfordert. Das kann die Primär-URL sein, die ein Anwender durch Anklicken eines Links, Eintippen einer URL-Adresse oder durch ein Bookmark aufruft. Es können aber auch sekundäre URLs sein, etwa URLs von Grafiken oder Flashmovies, die im HTML-Code der aufgerufenen Seite referenziert sind. Sind jedoch alle zu den eigentlich angeforderten Daten gehörenden Datenressourcen angefordert und übertragen, gibt es bis zur nächsten typischen Anwenderaktion (Link klicken, URL-Adresse eintippen, Bookmark aufrufen) keine weitere Kommunikation mehr zwischen Browser und Webserver – es sei denn, Ajax kommt ins Spiel!

Während eine vom Webserver übertragene Webseite im Browser angezeigt wird, kann sich im Browserfenster durchaus einiges tun. Die angezeigte Webseite enthält beispielsweise ein Navigationsmenü, das sich in verschiedene Zustände bringen lässt. Oder es sind Inhalte per Mausklick ein-/ausblendbar. Solche Effekte werden über Scripts gesteuert, die zu den Daten gehören, die mit der angeforderten Webadresse übertragen wurden. Das Script läuft vollständig im Browser ab. Der Browser verfügt über einen entsprechenden Script-Interpreter.

Die übliche Programmiersprache hierfür ist JavaScript. In Verbindung mit dem Document Object Model (DOM), das moderne Browser in ihre Script-Interpreter integriert haben, und mit der Technik der sogenannten Event-Handler ist es möglich, Inhalte einer gerade angezeigten Webseite abhängig von Benutzerereignissen zu manipulieren. So ist es beispielsweise möglich, dass eine Box beim Überfahren mit der Maus optisch hervorgehoben wird, oder dass ein Listenpunkt beim Anklicken um einen erläuternden Text erweitert wird. All das kann JavaScript, und all das passiert im Browser. Es besteht zu diesem Zeitpunkt keine Verbindung zwischen Browser und Webserver.

Mit Ajax erhält JavaScript jedoch eine weitere wichtige Arbeitsschnittstelle: es kann nun auch über HTTP mit einem Webserver kommunizieren, genauso, wie der Browser es selbst tut.

Dadurch wird es möglich, HTTP-Requests an Event-Handler zu binden und über HTTP erhaltene Daten über die DOM-Schnittstelle dynamisch in die bereits angezeigte Webseite zu integrieren!

Das klingt zunächst sehr abstrakt und nicht besonders sensationell. Betrachten wir jedoch ein einfaches praktisches Beispiel:

In einem HTML-Formular für Selbstregistrierungen kann sich ein Benutzer einen Benutzernamen nach Wunsch vergeben. Der Name muss jedoch eindeutig sein. Dazu könnte eine Schaltfläche „Prüfen“ angeboten werden. Wenn der Benutzer darauf klickt, ruft das durch den onclick-Event gestartete JavaScript via Ajax auf dem heimischen Web­server ein PHP-Script auf und übergibt ihm als Parameter den vom Anwender eingegebenen, gewünschten Benutzernamen. Das PHP-Script schaut in einer Datenbank auf dem Server nach, ob der Benutzername schon vorhanden ist. Wenn ja, sendet es FALSE zurück (Benutzername ist leider schon vergeben), wenn nein, TRUE (Benutzername ist noch nicht vergeben, also frei). Das aufrufende JavaScript bastelt aus dieser Information eine Ausgabe wie „Benutzername ist verfügbar“ oder „Benutzername ist leider nicht verfügbar“ und platziert diese über die DOM-Schnittstelle in der Umgebung des Eingabefeldes. Aus Sicht des Anwenders bleibt die aufgerufene Webseite am Bildschirm stehen. Das JavaScript tut scheinbar etwas Übliches: ausgelöst durch einen Event, blendet es via DOM-Schnittstelle eine Information ein. Ungewöhnlich ist jedoch, dass diese Information auf einer im Hintergrund abgelaufenen HTTP-Kommunikation zwischen JavaScript und einem Webserver basiert.

Wie dieses kleine Beispiel konkret realisierbar ist, werden wir im Praxisteil unserer Ajax-Einführung erfahren. An dieser Stelle ist zunächst wichtig zu verstehen, dass Ajax die HTTP-Kommunikationsschnittstelle in JavaScript ist, und dass sich dadurch zahllose neue Möglichkeiten eröffnen, um vor allem Webanwendungen für Benutzer attraktiver und schneller zu machen.

Programmierer auf der Suche nach Code

Wer selber programmiert, gerät häufig in Situationen, in denen ein konkretes Code-Beispiel nützlich wäre. Das kann beim Lösen eigener Aufgabenstellungen helfen, oder es kann zumindest etwas Licht ins Dunkel einer Funktion, einer Methode, eines Operators oder Statements bringen.

Für Programmierer auf der Suche nach Code-Beispielen bietet Google im Rahmen seiner Umorientierung auf ein semantisches Netz eine spezielle Code-Suche an. Die entsprechende Suchseite ist unter www.google.com/codesearch zu finden.

Die Code-Suche arbeitet per Default mit regulären Ausdrücken. Nun ist deren Syntax nicht jedermanns Sache, doch nur so wird wirklich präzises Suchen möglich. Allerdings sind auch literale Zeichenketten als Suchausdruck erlaubt. Dazu kommen Syntax-Möglichkeiten, um die Suche auf bestimmte Programmiersprachen oder Dateitypen zu beschränken. Die Suchmöglichkeiten sind auf der Suchstartseite erläutert.

Nehmen wir ein Beispiel. Wer schon mal mit der Funktion pack zu tun gehabt hat, weiß, dass deren Syntax und Möglichkeiten sich nicht gleich jedem erschließen. In Sprachen wie Perl ist diese Funktion jedoch beispielsweise bestens geeignet, um eine UU-Enkodierung auf eine Zeichenkette anzuwenden. In das Suchfeld von Google's CodeSearch geben wir ein:

lang:"perl" \spack\("u"

Präsentiert wird uns dieses Ergebnis. Zu jedem gefundenen Perlscript, in dem pack("u" vorkommt, werden entsprechende Code-Ausschnitte in der Ergebnisanzeige der Suchtreffer gleich angezeigt. Die gefundenen Perlscripts sind anklickbar und führen zu vollständigen Listings der jeweiligen Scripts. Darin sind die gefundenen Suchtreffer nochmals optisch hervorgehoben.

Ein zweites Beispiel: wer hier fleißig mitliest, kennt das Tutorial zu Mikroformaten. Nun mag ein solches Tutorial beim Einstieg in die Materie helfen, doch es kann sicher nicht alle Frage beantworten. Angenommen, wir möchten ein paar konkrete Beispiele zu class="dtstart" (betrifft das hCalendar-Mikfoformat) sehen. Wir geben in der CodeSearch ein:

\sclass="dtstart"

In diesem Fall haben wir auf die Angabe der Sprache verzichtet, weil sich herausgestellt hat, dass auf diese Weise mehr Ergebnisse zustande kommen. Der Grund ist, dass HTML eben auch innerhalb von Programmiersprachen wie PHP häufig als Output vorkommt.

Das Beispiel zeigt aber auch, dass die Code-Bibliothek, die Google bislang zusammengetragen hat, noch nicht so umfangreich ist, wie das wohl später einmal sein soll. Kein Wunder, denn die Code-Suche befindet sich wie viele der anderen Google-Services noch im Beta-Stadium.

Und wie sucht sich die Code-Suche ihre Listings zusammen? Zum einen durch gewöhnliches Crawling, also durch das, was der Google-Robot tut, wenn er Webseiten besucht. Weitere Listings finden ihren Eingang in das Archiv der Code-Suche durch explizites Hinzufügen. Google bietet dazu ein Formular zum Beitragen von Code an.

Die Google Code Search hat aber, als sie im Oktober 2006 online ging, auch Bedenken ausgelöst. Vor allem wenn es dem Google-Robot gelingt, an den Quelltext etwa von PHP-Scripts zu kommen, die innerhalb der Document Root eines Webservers liegen, könnten ungewollt sensible Daten in das öffentlich durchsuchbare Archiv gelangen, beispielsweise Datenbankzugangsdaten, die im Script kodiert sind. Passieren kann ein solches Versehen, wenn aus irgendwelchen Gründen Backups von Webanwendungen in Form von GZIP- oder TAR-Archiven innerhalb der Document Root abgelegt sind, oder wenn — möglicherweise nur vorübergehend — einmal die Webserverkonfiguration fehlerhaft ist und aufgerufene Scripts nicht ausgeführt, sondern im Quelltext an den aufrufenden Client ausgeliefert werden.

Wenn Sie selber glauben, über lehrreiche Listings zu verfügen, die Sie gerne mit anderen teilen möchten, dann ist die Form des Veröffentlichens über das erwähnte Formular sicher eine geeignete Form.

Lesenswert zu diesem Thema:

• Google talks about its newly launched CodeSearch (Artikel mit Podcast eines Interviews) [en]
• Googles Code Search als Hackertool
• Sicherheitshinweis von Joomla
• Google Code Search oder wie finde ich lustige Kommentare

Und last but not least natürlich die Google Code-Suche nach Bill Gates...

Trauriger Aprilscherz?

Nicht wenige Websites haben sich auch dieses Jahr wieder einen Aprilscherz einfallen lassen — mal mehr, mal weniger gelungen. Doch wie sehen eigentlich Aprilscherze im Web 2.0 aus? Richtig: man publiziert eine Ente, und die Ente wird dank Trackbacking oder Backtracking? binnen Minuten und Stunden vervielfältigt. Dazu kommen noch die ganzen Kommentare hier und da.

Möglicherweise gibt es bereits mehrere blogosphärische Aprilscherze. Einer ist mir heute jedenfalls aufgefallen. Die Meldung lautet: Eilmeldung: WCAG 2.0 fertiggestellt. So lautet die Meldung jedenfalls beim „Einfach-für-alle“-Blog. Man klicke auf den Link in der Eilmeldung, und hoffentlich gut angekommen auf der Zielseite, dort auf einen weiteren Link zu dem Thema, und auf dem nächsten Ziel wieder, usw. So lernt man zahlreiche Blogs in kurzer Zeit kennen. Nur eines erfährt man nicht: wo dieser ominöse Kandidat zur Empfehlung (W3C-Deutsch) nun eigentlich sein soll. Unter der latest-version-Adresse http://www.w3.org/TR/WCAG20/ jedenfalls nicht — dort ruht eine Working Draft seit dem 27. April 2006 friedlich vor sich hin. Und genau das dürfte der Grund für den Aprilscherz sein.

Sorry, liebe beteiligte Blogger, dass ich jetzt nicht mehr mitmache. Der 1. April ist bald zuende, und außerdem bin ich ein hoffnungsloser Aufklärer ;-)

Blogcounter und webkompetente Browser

Nach einer gewissen Testphase, welchem kostenlosen Statistik-Service ich das hiesige Blog anvertraue, habe ich mich nun erst mal für Blogcounter entschieden. Ausprobiert habe ich noch die Services Google Analytics und Blogscout. Blogcounter bietet meiner Ansicht nach von allen die ausführlichsten Statistiken.

Einziges Manko bei Blogcounter ist die etwas anrüchige Form von versteckter Werbung, durch die sich der Service finanziert. Ende 2005/Anfang 2006 hat das für einige Empörung in der Szene gesorgt (Beispiel). In dem HTML-Code, der zum Funktionieren der Statistik in das eigene Blog-Template eingebunden werden muss, ist neben dem dafür üblichen JavaScript-Aufruf innerhalb eines alternativen noscript-Bereichs ein Link versteckt. Da die große Mehrheit der User in ihrem Browser JavaScript eingeschaltet hat, sieht sie nichts von diesem Link. Er stört also fast niemanden. Doch Suchmaschinen-Robots sollen ihm folgen und ihn beispielsweise beim PageRanking berücksichtigen. Besonders ärgerlich ist dabei, dass diese Links vornehmlich zu zweifelhaften Sites führen, deren Betreiber ein bekannter Spammer ist.

Ich habe mir erlaubt, im hiesigen Quelltext den Link aus dem noscript-Bereich einfach zu entfernen, denn in den AGB von Blogcounter habe ich nichts gefunden, was das verbietet. Der Counter funktioniert auch ohne den Link. Wenn dem Betreiber das nicht passt, soll er mich halt von dem Service ausschließen, und ich suche mir einen anderen Service.

Doch nun zum erfreulicheren zweiten Teil dieses Beitrags: neben anderen Statistiken bietet Blogcounter auch eine Browser-Statistik an. Für das Webkompetenz-Blog weist die Statistik folgende Zahlen aus:

Die Abbildung zeigt nur Browser mit einem Anteil von über 1%. Erstaunlich ist dabei, dass es „MZ 1.8“, wohinter sich in aller Regel ein Firefox 2.0 verbirgt, auf satte 65% bringt, während der MS Internet Explorer in allen Versionen bei gerade mal 11% landet. Da kommen sogar schon Opera 9 (knappe 7%) und ein weiterer Gecko-Browser, nämlich Netscape (8%) nah heran. So ganz dem Volksdurchschnitt entspricht diese Verteilung leider noch nicht. Ich interpretiere sie jedoch als Zeichen von — na? Webkompetenz natürlich!