Donnerstag, 28. Juni 2007

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.


Mittwoch, 27. Juni 2007

Bund fördert Wikipedia-Inhalte

Frei und gleichzeitig erfolgreich zu sein ist eine wirklich tolle Mischung, die leider nur selten gelingt. Bei Wikipedia ist sie bekanntlich gelungen, und zwar so gut, dass selbst die notorischen Kritikaster des größten Enzyklopädie-Projekts der Menschheit ihre helle Freude daran haben, weil sie immer wieder neue Gründe für Schmähungen geliefert bekommen. der neueste Grund könnte diese Meldung sein. Das Bundesministerium für Ernährung, Landwirtschaft und Verbraucherschutz (kurz: Seehofer) beauftragt die Fachagentur Nachwachsende Rohstoffe e.V. (FNR) damit, Fachartikel für Wikipedia zu erstellen oder bestehende Artikel zu verbessern. Betroffen ist das Themengebiet nachwachsende Rohstoffe.

Das Kalkül ist klar und wird auch gar nicht verschwiegen: Wikipedia ist die ideale Plattform, um Sachinhalte einführend und allgemeinverständlich zu publizieren. Ein interessanter Sinneswandel, der zum Weiterdenken einlädt. Bislang hat man wegen jedem Pippifurz dieser Art erst mal eine neue Domain eröffnet (in diesem Fall also beispielsweise www.nachwachsende-rohstoffe.de ;-). Doch nun entdeckt man plötzlich, dass man nicht mehr für alles eine neue Adresse braucht, sondern dass es manchmal sinnvoller ist, Inhalte im Rahmen bestehender Plattformen zu publizieren, die user generated content ermöglichen. Nicht mehr ins Web stürmen nach dem Motto „hallo ihr da draußen, jetzt kommen wir!“, sondern erst mal überlegen, wie man sich in der gewachsenen Hypertext-Struktur des Webs am sinnvollsten platzieren kann. Diese Lektion haben die Seehofer-Leute also wirklich gut gelernt.

Der andere Aspekt der Angelegenheit ist jedoch etwas heikler. Da sollen also bezahlte Auftragsschreiber in Wikipedia editieren, die natürlich nur des' Liedchen singen, wes' Brötchen sie essen (Seehofers Brötchen in dem Fall). Bezahlen tun wir es letztendlich mit unseren Steuergeldern, insofern ist der Kreislauf so weit in Ordnung. Denn Informationen sind längst so wichtig wie Autobahnen, also ist es normal, dass Steuergelder in die Bereitstellung von Bürgerinformation fließen. Doch wie viel wird das kosten, sollten sich die Auftragsschreiber in den endlosen Edit-Wars einer kollaborativen Web-2.0-Plattform verlieren? Und wie unabhängig kann das Wikipedia-Projekt auf die Dauer gesehen bleiben, wenn das Beispiel Schule macht und sich in den nächsten Jahren alle möglichen Verbände, Vereine und Lobbyisten hauptberuflich „ihren“ Themenbereich in Wikipedia krallen und beackern wie ein Bauer „sein“ Stück Land? Vielleicht kann man es ja auch mal ganz entspannt als Versuchsballon betrachten.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Zum Blog-Eintrag: Bund fördert Wikipedia-Inhalte


Sonntag, 24. Juni 2007

Gmail und Germany

Lebenslang sollten sie gültig sein, die E-Mail-Adressen der Deutschen Post, mit der schönen Endung @epost.de. Doch schon nach zwei oder drei Jahren kam das Aus: Unrentabel sei der Service, so das deutsche Vorzeige-Unternehmen mit dem immer noch halbstaatlichen Versorgungsnimbus. Also mussten die Deutschen doch bei anderen, kommerziellen und erfolgreicheren Mailprovidern anheuern. Viele etwa bei GMX, Yahoo oder Web.de. Und schließlich kam Google daher, bot einen Mail-Service namens Gmail alias™ Googlemail an, der kostenlos war, bei dem in den Mails keine nervige Werbung mitverschickt wurde, wo man vergleichsweise üppige zwei und mehr Gigabyte Speicher hatte, der sowohl mit einer neuartigen, Ajax-basierten Web-Oberfläche als auch via POP3 mit normalen Mail-Clients nutzbar war, und mit dessen Account man nebenbei noch all die anderen Services von Google nutzen konnte, vom Kalender über Bookmarks, Notebook, Groups bis hin zu einem eigenen Blog bei Blogger.com.

Doch nun droht Google, seinen Mail-Service zu schließen. Nicht überall und nicht aus Rentabilitätsgründen, nein, sondern nur in Deutschland. Der Grund: ein deutscher Minister namens Wolfgang Schäuble, dessen eindeutig erkennbarer Wunsch ein Überwachungsstaat als Mittel zur Bekämpfung unerwünschten Elementen ist, will ein “Gesetz zur Überwachung des Telekommunikations- und Datenverkehrs im Internet” durchdrücken, das mit den Anonymitätsgrundsätzen von Google Mail nicht mehr vereinbar ist. Natürlich nicht nur mit Google Mail nicht. Google ist nur der erste Provider, der reagiert hat. Andere werden folgen. Millionen von E-Mail-Konten könnten gelöscht werden, Terabytes persönlicher Daten könnten verlorengehen. Im Grunde muss jede Internet-Plattform und jeder Internet-Service für deutsche Staatsbürger unerreichbar werden, die irgendeine Art von Kommunikation mit anderen Internet-Nutzern ermöglicht, wobei nicht eindeutig identifizierbar ist, welcher Bürger da mit welchem anderen kommuniziert hat.

Doch warum? Immerhin wurde die umstrittene Gesetzesvorlage bereits abgemildert. Ursprünglich sah sie nämlich sogar vor, dass man E-Mail-Adressen nur noch gegen Identifikation wie etwa durch persönliche Vorlage von Personalausweis, Rentenversicherung(?) oder Fingerabdruck(?) erhalten sollte. Und außerdem steckt hinter dem Gesetzesentwurf eine EU-Vorgabe. Was also läuft speziell in Deutschland schief, dass Google solche Drohungen nur für dieses Land ausstößt? Und dann ist da bei manchen Internet-Hardlinern noch diese Doppelverwirrung. Einerseits ist Google für sie das Böse schlechthin auf Erden, wo alles über jeden gespeichert werden soll. Und nun protestiert Google mit Berufung auf seinen Anonymitätsgrundsatz? Wird man nun etwa zum Schäuble-Sympathisanten, weil man scheinbar auf seiner Seite gegen die Datenkrake Google kämpft?

Vielleicht hilft es sich bewusst zu machen, dass Google sehr wohl alles über jeden Google-Account speichert, um so Nutzungs- und Interessensprofile zu erstellen. Vorgeblich, um die Qualität der eigenen Suche sowie anderer eigener Services wie AdSense-Werbung zu erhöhen. Nach Ansicht nicht weniger Misstrauischer aber eher, um solche Profile teuer weiterzuverkaufen. Wie auch immer: am Anfang steht eine schlichte Selbstregistrierung bei Google, die keine anderen Rückversicherungen verlangt als heute üblich: selbst wählbare Werte für Benutzername und Passwort, Ausweisung als Mensch durch Abtippen einer grafischen Buchstabenkette, und Anklicken eines Bestätigungslinks, der an eine vorhandene andere Mailadresse des Registrierenden gesendet wird. Google weiß nicht, wer sich hinter dem Registrierenden verbirgt. Es ist auch kein Problem und wird von Google ohne Einwand akzeptiert, wenn eine Person sich mehrere Google-Accounts zulegt, sei es aus Gründen des persönlichen Identitätsmanagements oder einfach um mehr Mailspeicher zu erhalten. IP-Adressen werden bei Google wohl wie überall sonst auch geloggt, aber IP-Adressen sind relativ, selbst wenn sie den Zugangsprovider verraten und dieser genau protokolliert, welcher Kunde wann mit welcher IP-Adresse im Netz ist. Es kann sich jedoch um eine Router-Adresse handeln, an der etliche PCs unterschiedlicher Personen hängen. Es kann sich auch um die IP-Adresse eines Anonymizer-Services handeln, falls der Internet-Benutzer nicht möchte, dass seine echte IP-Adresse mitgeloggt wird. Es kann sich um einen Hack auf TCP/IP-Ebene handeln, wo die IP-Adressen der Datenpakete manipuliert wurden. Für Kriminelle und Terroristen ist es also kein Problem, Google-Accounts (und alle anderen, vergleichbaren Accounts bei Mailprovidern oder auch bei vergleichbaren Services wie den allseits beliebten Instant Messengern für konspirative Zwecke zu nutzen, ohne dass die Service- oder Content-Provider einen verlässlichen Bezug zu realen Personen herstellen können. Egal wie viel Google zu einem Account an Daten für seine Profilerstellung speichert.

Schäuble dagegen will diese Anonymitätsmöglichkeiten vollständig ausschalten. Seine Vorstellung ist ein Internet mit IP-Adressen, die so eisern und transparent sind wie ein deutscher Festnetz-Telefonanschluss in Zeiten vor der Telekom und des freien Telekommunikationsmarkts. Sein Wunsch sei ihm in allen Ehren gelassen. Doch von einem Minister muss man verlangen, dass er Folgen bedenken kann. Die Folge seines Wunsches ist die Abschaltung des gesamten Internets in Deutschland, nach dem Vorbild von Nordkorea vielleicht. Denn da er keinen Einfluss hat auf ausländische Server und Services, vom E-Mail-Provider bis zum Anonymizer, ist sein Feldzug nur ein lächerlicher Kampf gegen Windmühlen. Alles was er erreichen wird ist eine verheerende Schwächung von Internet-Kompetenz in Deutschland, doch keine Terroristenmail weniger wird deshalb ihren Weg durchs Netz finden. Es wird Zeit, dass die wahlberechtigte Bevölkerung erkennt, dass dieser Innenminister und seine Schargen eine ernsthafte Gefahr für das Land darstellen.

Andere Artikel, die sich mit diesem Thema befassen:

Bemerkenswerte Zitate aus anderen Beiträgen:

Flickr, vorerst kein deutsches youtube und jetzt das deutsche Gmail. Es zeichnet sich ein Muster ab. Und zwar eins, das eine deutliche Sprache spricht: Internationale Unternehmen erkennen, dass die deutsche Gesetzgebung größtenteils internetfeindlich ist. Das liegt natürlich auch zu einem Großteil an der Tatsache, dass die deutsche Legislative größtenteils internetfeindlich ist: Der deutsche Wirtschaftsminister lässt zum Beispiel das Internet bedienen. “Bundesminister für Wirtschaft und Technologie”.
(Neunetz.com: Internet: Standortnachteil Deutschland)

Mit der Registrierung wäre Googles Businessmodell in Gefahr. Sobald Google weiss, wer sich hinter einem Computer verbirgt, darf Google aus Datenschutzgründen keine Daten mehr sammeln oder aggregieren. Dies beträfe natürlich nicht nur den E-Mail-Dienst sondern alle Goolge-Dienste. In der Schweiz zum Beispiel, hätte jeder das Recht, bei Google die Offenlegung der über ihn gespeicherten Daten zu verlangen. Schlicht nicht handlebar.
(Internet-Briefing.ch: Google macht Politik - aber kein Staat)

Google hat Ahnung von Computern und was man mit diesen Daten anfangen kann, Politiker haben diese Ahnung nicht. Hier scheint eher eine Art „Hauptsache wir haben was, irgendwie können wir es schon verwenden“ Mentalität zu walten. Und Google will mich nicht überwachen. Google will mich nicht verdächtigen. Google beschuldigt mich nicht. Google gibt mir viel eher etwas zurück. Die Dienste und gleichzeitig Werbung, die vielleicht sogar ganz interessant sein kann. Bei Google habe ich nicht die Angst, mir so etwas wie einen „Bundestrojaner“ auf meinen Rechner zu laden.
(der Wendlaender: Warum wir Google vertrauen)

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Internetüberwachung


Mittwoch, 20. Juni 2007

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


Montag, 18. Juni 2007

Web 2.0 und der Eiffelturm bei Nacht

Einer der Gründe, weshalb „Web 2.0“ so viel Begeisterung auslöst, ist die große Freiheit, die damit verbunden ist. Es ist die gleiche Begeisterung, die Mitte bis Ende der 90er Jahre schon einmal herrschte, als viele Menschen begriffen, dass eine eigene Homepage ein vollwertiges Kundgebungsorgan sein kann. Der Unterschied ist nur, dass man mittlerweile keine eigene Homepage und all das entsprechende Know How mehr benötigt, sondern einfach die zahlreichen Services im Web nutzen kann, die das Beitragen von Inhalten ermöglichen.

Doch die große Freiheit wird wie schon vor zehn Jahren wieder in Schranken gewiesen. Über den Blog-Artikel Man sägt nicht an dem Ast, auf dem man sitzt bin ich auf den dort behandelten Beitrag Erstickt Web 2.0 an seiner eigenen Freiheit? gestoßen.

Zwei Aspekte finde ich an dem Thema bemerkenswert und neu gegenüber der Situation von vor zehn Jahren:

Erstens ist es offenbar mittlerweile gar kein großes technisches Problem mehr für größere Site-Anbieter, ganze Länder und Staaten vom Zugriff auf ihre Inhalte oder auf bestimmte ihrer Inhalte auszuschließen. Wenn das in immer mehr Fällen ohne großes Medienrauschen funktioniert, werden wir in wenigen Jahren ein fein dezidiertes System aus Zugriffsberechtigungen auf Content-Provider-Ebene haben, das still und leise jenseits von Logins und Passwörtern operiert. Dann sieht der Franzose was der Deutsche nicht sehen darf, und dieser sieht was der Türke nicht sehen darf. Der eine bekommt beim Google-Suchbegriff „Staatsterrorismus“ 90.000 Treffer, sein Nachbarländer ganze 40.000. Letzterer wirds verschmerzen, weil er auch 40.000 Treffer nicht alle auswerten kann. Es bleibt ein Gefühl von grenzenloser Freiheit, obwohl in Wirklichkeit mehr als die Hälfte zensiert wird.

Zweitens hat sich eines geändert: die einfachen User, die in einem Web-2.0-Service Content generieren, kann man nicht mehr so einfach greifen und gezielt abmahnen. Stattdessen müssen sich Abmahnanwälte und Firmen, die keine Nachtaufnahmen des Pariser Eiffelturms dulden, weil sie ein Urheberrecht auf dessen Beleuchtungseffekte haben, mittlerweile mit den Anbietern der Content-Plattformen selbst auseinandersetzen, also beispielsweise mit ausgewachsenen Boliden wie Flickr oder YouTube, wohinter dann noch größere Player wie etwa Google stehen können. Das ist einerseits beruhigend, denn die haben ein wirtschaftliches Interesse am sorglos beigesteuerten User-Content und sind deshalb auch bereit zu teueren Prozessen. Andererseits reduzieren sich dadurch die Angriffsflächen, und wenn einer der großen Services tatsächlich mal an einem derartigen Rechtsstreit zerbrechen sollte, würde der Sog, den er beim Sinken erzeugt, möglicherweise die ganze schöne Web-2.0-Welt mit in die Tiefe reißen.

Vielleicht wird die große Freiheit wieder unterdrückt. Vielleicht entwickelt sich aber auch ein Pingpong-Spiel, bei dem auf jeden neuen Freiheitsrausch ein Dämpfer erfolgt, in dessen Dunst dann wieder eine neue Form von Netzfreiheit entsteht. Vielleicht wird man die Versionsnummern des Webs irgendwann nach diesen Aufschwüngen zu neuen Möglichkeiten der Freiheit zählen.


Samstag, 16. Juni 2007

Hypertext (6): Hypertext und Informationsaufnahme

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


Vernetzte Inhalte für vernetztes Denken

Hypertext ist die Vernetzung von Inhalten. Vernetzung ist jedoch kein hypertext-spezifischer Begriff; „Vernetzung ist ein Begriff aus der Systemtheorie“, definiert Wikipedia. Immer dann, wenn man ein komplexes System betrachtet, z.B. das System der weltweiten Warenflüsse oder das Ökosystem der Alpen, kommt man mit reinen Ursache-Wirkungs-Ketten nicht weiter. Denn die Ursachenkette beißt sich am Ende selber in den Schwanz und bildet mindestens Kreisläufe, meistens aber noch viel chaotischere, scheinbar wahllos querverbundene Faktorenstränge, die visualisiert aussehen wie ein Straßennetz oder ein komplizierter Schaltplan.

Hypertext ist eine Folge dieser systemtheoretischen Betrachtungsweise. Um Systeme, deren Komponenten ein vernetztes Gefüge bilden, adäquat beschreiben zu können, ist eine lineare Abhandlung diesem Gedankenansatz zufolge ungeeignet. Besser geeignet erscheint eine Darstellungsform, die den Netzcharakter einfach direkt abbildet. Die Systemkomponenten sind dabei einzelne Inhaltseinheiten, und ihr Gefüge wird durch Hyperlinks zwischen den Inhaltseinheiten abgebildet.

Die Argumentation geht aber noch weiter: „Hypertext scheint unter der Annahme kognitiv plausibel zu sein, dass Wissen [...] im menschlichen Gehirn in vernetzt topologischen, nichtlinearen Strukturen organisiert sei. Unter dieser Annahme könnte die Wissensaufnahme über eine vergleichbare Organisationsform, wie sie durch Hypertext gegeben ist, effizienter sein als eine Aufnahme, die den 'Umweg' über lineare Präsentationsformen (Vorlesungen, Texte) nimmt“ — so schreibt der Informationswissenschaftler Rainer Kuhlen in dem Buch Hypertext. Ein nichtlineares Medium zwischen Buch und Wissensbank, Berlin, Heidelberg, New York, 1991. Nicht nur betrachtete Systeme bestehen aus vernetzten Komponenten, sondern auch das menschliche Gehirn bzw. die Struktur all dessen, was in ihm gespeichert ist. Auch das menschliche Gehirn selbst wird also im modernen Denken als System begriffen. Das war nicht immer so — auch diese Auffassung ist eine Folge der systemtheoretischen Betrachtungsweise.

Hypertext entpuppt sich demnach als der Versuch, ein Denken, das sich selbst und all die Systeme in Natur und Technik, die es erkunden oder verstehen will, adäquat abzubilden. Hypertext soll systemtheoretisch orientiertes Denken in einer Form vermitteln, die selbst ins systemtheoretische Denken passt. Der Erfolg dieser Annahme sollte sich dann aber daran messen lassen, ob Wissen, das über Hypertext vermittelt wurde, gründlicher in die Köpfe der Lernenden gelangt als Wissen, das auf traditiionelle, nicht-lineare Weise (Buch, Vorlesung usw.) vermittelt wurde.

Gegen die Annahme, dass vernetzte Wissenspräsentation die Aufnahme von Wissen erleichtert, lassen sich zwei Argumente anführen:

Das erste Gegenargument führt ins Feld, dass sich der Hypertext-Leser seine Leselinie erst selbst bahnen muss, was Zeit und Energie kostet. Wobei die Wissensaufnahme letztlich nicht anders funktioniert als bei herkömmlichem Text: sie „findet..., auch durch die Navigation in Hypertext, in einer zeitlich sequentiellen Reihenfolge statt, sodass jeder faktische Weg letztlich doch wieder linear ist“ (Kuhlen).

Dem zweiten Gegenargument zufolge ist gerade die Integration von vernetztem Wissen in ein Wissensnetz problematischer als die Integration „einfachen“ Wissens in das Wissensnetz. Dahinter steht die Annahme, „dass zwei Netze, zumal wenn sie polyhierarchisch strukturiert sind, schwieriger zu integrieren sind als eine lineare Struktur in ein bestehendes Netz“ (Kuhlen).

Studien und Versuchsanordnungsprobleme

Mittlerweile sind diverse Studien durchgeführt worden, die sich mit der Frage befassen, ob Hypertext nun besser oder schlechter abschneidet im Vergleich zu herkömmlichen, linearen Medien. Eine knappe Zusammenfassung inklusive eigener kleiner Studie bietet das Dokument Wissenserwerb, Navigationsverhalten und Blickbewegungen bei Text und Hypertext (PDF-Dokument).

Aus der kleinen Studie wird deutlich, was eigentlich auch einleuchtet: ein zusammenhängender Inhalt wird linear besser aufgenommen als in einer zerstückelten Hypertext-Form. Der Hauptgrund ist, dass bei Hypertext immer ein Teil der Aufmerksamkeit für die Navigation benötigt wird. Dagegen zeigt Hypertext leichte Vorteile, wenn es darum geht, aufgrund einer Fragestellung geeignete Inhalte zu finden. Der Grund ist, dass in diesem Fall der Navigation insgesamt mehr Aufmerksamkeit geschenkt werden muss als dem Textinhalt.

Frühere Studien, etwa die bekannte Schnotz-Studie (Textverstehen als Aufbau mentaler Modelle. In: Mandel, H./ Spada. H.: Wissenspsychologie, München 1989), lassen Hypertext gegenüber linearem Text noch deutlich schlechter aussehen. Viele dieser früheren Studien datieren allerdings aus den frühen 90er oder gar 80er Jahren des 20. Jahrhunderts. Normale Computeranwender waren zu jener Zeit völlig unvertraut mit Hypertext — eine Voraussetzung, die sich mittlerweile durch den anhaltenden Erfolg des World Wide Web wesentlich verändert hat. Waren Hypertext-Systeme früher exotische Einzelanwendungen, so ist Hypertext heute gleichbedeutend mit dem World Wide Web. Wer über Jahre hinweg einen Web-Browser einsetzt, so darf deshalb vermutet werden, der lernt, sich in Navigationsumgebungen immer schneller zurechtzufinden. Dazu kommen immer ausgereiftere Werkzeuge im Bereich von Bookmarks und Suchmaschinen. Bei großen Websites haben sich längst gewisse Standards im Layout durchgesetzt. Eine weitere wichtige Entwicklung des Web-2.0-Zeitalters ist das Abonnieren von Newsfeeds, also das Aufnehmen von Informationen unter einer persönlich gestaltbaren, einheitlichen Bedienoberfläche. All diese Entwicklungen verkürzen die Orientierungsphase und ermöglichen dadurch eine stärkere Konzentration auf die eigentlichen Inhalte.

Wir befinden uns also mitten in einem Wandel, in dessen Verlauf der alltägliche Umgang mit Hypertext für immer mehr Menschen so selbstverständlich wird wie das Aufschlagen eines Buches. Die Schnelligkeit, mit der sich der Wandel vollzieht, erschwert natürlich die Ausarbeitung von Studien mit stabilen Ergebnissen. Derzeit gehen Risse quer durch Generationen und Bildungsschichten. Jüngere Menschen gehen tendenziell selbstverständlicher und routinierter mit elektronischen Inhalten in Hypertextform um als ältere, und Menschen mit höherem Bildungsgrad finden sich tendenziell leichter in Hypertextumgebungen zurecht als Menschen mit niedrigerem Bildungsgrad. Doch das sind allenfalls Tendenzen, die niemals als zuverlässige Einschätzungsprognosen für Einzelpersonen taugen.

Teamworking als Faktor

Studien und Thesen, die sich damit befassen, ob Hypertext der besseren Informationsaufnahme dienlich ist, lassen außerdem häufig einen Aspekt außer Acht, der gegenwärtig immer mehr an Bedeutung gewinnt. Viele erfolgreiche Projekte im Web verdanken ihren Erfolg nämlich dem sogenannten user generated content. Dabei wird die Rezipientenrolle mehr oder weniger stark aufgehoben. Der Rezipient kann aktiv agieren und reagieren, Texte beitragen, seine Meinung kundtun, Fragen stellen oder beantworten. Er wird zum Bestandteil des Hypertextprozesses. Das ist in Foren der Fall, aber auch in kollaborativen Webanwendungen wie Wikis. Neben dem Faktor der freien Navigation im Inhalt kommt dadurch also noch ein weiteres Merkmal für modernen, web-basierten Hypertext hinzu: die Kommunikation mit anderen Teilnehmern.

Wenn der Rezipient zum Partizipienten wird, hat das zwangsläufig auch Folgen für die Art und Qualität der Informationsaufnahme. Eigene Aktivität erhöht die Spannung. Fremdinhalte müssen nicht „heruntergeschluckt und gepaukt“ werden, sondern sind Anlässe für eigene Kommentare, Antworten oder Auseinandersetzungen. Andererseits sind diskursive, von Anwendern beigetragene Inhalte oftmals chaotisch strukturiert, unvollständig und ohne klare Autorenkonzepte wie Trennung von sachlicher Darstellung und subjektiver Einschätzung. Vor allem für Lernende, die in einer solchen Hypertextumgebung versuchen, sich Wissen anzueignen, scheint das ein Nachteil zu sein. Denn Lernende befinden sich in einem „anomalous state of knowledge“. Während sie sich Wissen aneignen wollen, suchen sie nach präzisen Begriffen und eindeutigen Antworten auf ihre Fragen. Die erfahrene Führung eines Lehrbuchautors erscheint dazu wesentlich geeigneter als die ungefilterte Inhaltsmasse eines kollaborativen Hypertextes.

Möglicherweise trifft das jedoch nur auf Wissen zu, das ein Lernender sich kurzfristig und selbstdisziplinarisch aneignen will. Denn gerade jüngere Menschen, die mit dem Web vertraut sind, berichten häufig, dass sie Fachinhalte wie Programmiersprachen vorzugsweise durch Teilnahme an entsprechenden Fachforen erlernen — gegebenenfalls in Verbindung mit verlässlichen Dokumentationen und viel eigenem Herumprobieren. Diese eher unorthodoxe Zugangsweise benötigt mehr Zeit, wird dafür vom Lernenden aber kaum als Pflicht erlebt, und das so erworbene Wissen wird wohl nachhaltiger gespeichert als im Paukmodus, den es ohnehin ohne Prüfungswesen vermutlich gar nicht geben würde.

Fazit

Zusammenfassend könnte man sagen, dass Hypertext gegenüber linearen Medien tendenziell eher nachteilig bewertet wird. Was dabei jedoch meist nicht hinterfragt wird, ist die Art, wie Informationsaufnahme vorgeblich zu funktionieren hat. Wird unter Informationsaufnahme eher die klassische, zeitlich begrenzte Wissensaneignung (lerne bis dahin und dann wird dein Wissen abgefragt) verstanden, so dürften die hypertext-kritischen Studien Recht behalten. Wird dagegen von einer spielerischen, zwanglosen und zeitlich stresslosen Wissensaneignung ausgegangen, so kann Hypertext seine Vorteile eher ausspielen, und zwar erst Recht in Umgebungen, die zusätzlich die Kommunikation mit anderen Teilnehmern zulassen.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Zum Blog-Eintrag: Hypertext (6): Hypertext und Informationsaufnahme (FAZIT


Mittwoch, 13. Juni 2007

Blogs als Parasiten

Jeder, der sich öfters in die Welt der Blogs begibt oder verirrt, kennt das. Die „Großen“ wie Heise, Springer und Konsorten bringen eine Meldung wie „Safari-Browser jetzt auch für Windows“ oder „Paris Hilton wieder frei“, und die halbe Blogosphäre plappert sie mehr oder weniger bewusstlos nach. Manchmal wird sogar einfach nur kopiert, oder es wird schlicht und einfach Content-Syndication betrieben.

Sinnvoll wäre es ja durchaus, wenn die Blog-Beiträge sich als intelligente Kommentare zur Original-News verstehen würden, sozusagen als digitales Leserbrief-Echo aus dem Netz. Doch allzuoft sind es einfach nur verkürzte Wiedergaben oder verkrüppelte Zitate des Originals, mit der zigtausendmal täglich die eigene thematische Ideenlosigkeit übertüncht werden soll. Nun könnte man argumentieren, dass vielleicht nicht jeder Leser alle Original-News liest und stattdessen über ein Privat-Blog seines Vertrauens zumindest eine subjektive Auswahl davon mitbekommt. Es bleibt jedoch zweifelhaft, ob ein Blog, welches das Sprachrohr einer Persönlichkeit sein soll, mit schlecht wiedergekäuten News aus dem Profi-Journalismus tatsächlich sein Ziel erreicht. Und aus Sicht eines Lesers, der News aus der Informationsflut filtern will, ist es wohl besser, auf Feedreader zurückzugreifen.

Robert Niles hat sich schon vor einiger Zeit die Frage gestellt: Are blogs a 'parasitic' medium?. Er fragte ein wenig herum zu dem Thema, und bekam von Rich Gordon, Professor und Direktor für Digital-Technologie in Lehre und Erziehung, unter anderem folgendes zur Antwort (hier übersetzt): „Wer aus der Ecke der traditionellen Medien kommt und glaubt, Blogger seien parasitär, sollte mal den Traffic seiner Website dahingehend analysieren, wie viele Besucher über Links aus Blogs kommen. Wenn es wenige sind, gibt es nichts zu befürchten. Wenn es viele sind, profitiert die eigene Site von den Parasiten. Die korrekte wissenschaftliche Bezeichnung sollte dann aber wenigstens 'symbiotisch' lauten, nicht 'parasitär'.“

Nun ist an der Argumentation zumindest nachvollziehbar, dass die Original-News-Anbieter oder Mainstream-Medien von Bloggern profitieren, die ihre Meldungen aufgreifen und weitergeben. Wie groß die Besucherströme in dieser Richtung (also von kleinen Blogs hin zu Major-Playern der News-Branche) tatsächlich sind, muss allerdings erst noch erforscht werden. Fakt ist jedenfalls, dass das vielhundertfache „Wiederkäuen“ auch eine Menge zusätzlicher Daten im Web produziert, die beispielsweise von Suchmaschinen verarbeitet werden müssen. Letztere reagieren immerhin so, dass originärer Content deutlich höher bewertet wird als wortwörtlich nachgeplappertes Zeug.

Publizieren ist kinderleicht geworden. Der Blogger von heute muss nicht mal mehr in die Homepage-Grundschule. Doch dass es auch ohne Autoren geht, ist ein Trugschluss. Autoren, ganz allgemein gefasst als Schaffende von originären, authentischen Inhalten, sind sogar massenhaft erforderlich, wenn das Web nicht zu einer Wüste wiederholter Worte mutieren soll.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Blogs als Parasiten


Samstag, 9. Juni 2007

Personal Webdesign mit Stylish

Wenn man jenes ominöse Web 1.0, das nie existiert hat, aus der Sicht von Web 2.0, das es ebenfalls nicht wirklich gibt, versucht zu charakterisieren, dann gehört auch dazu, dass das Web 1.0 anbieter-orientiert war, während das Web 2.0 benutzer-orientiert ist. Doch welche Konsequenzen hat das eigentlich fürs Webdesign? Ist ein anbieter-orientiertes Webdesign überhaupt noch zeitgemäß, oder outet sich jemand, der noch auf das unverwechselbare Design seines Webangebots Wert legt, mittlerweile als Ewiggestriger, der noch nicht mitbekommen hat, dass dreiviertel seiner User seine News längst über Feedreader lesen?

Man muss das nicht so radikal sehen, doch es gibt gute Gründe, Gedanken über einen schleichenden Wandel vom anbieter-zentrierten Webdesign zum benutzer-zentrierten Webdesign anzustellen. Die meisten Web-User surfen ja nicht ziellos umher, sondern haben ihre Stamm-Sites, die sie immer wieder besuchen. Die einen tummeln sich den ganzen Tag bei E-Bay, die nächsten bei Xing, wieder andere in den Heise-Foren oder bei Wikipedia. Millionen verbringen nicht wenige Minuten täglich mit Google-Suchergebnissen oder anderen Google-Services. Einige solcher Sites bieten vielleicht gewisse Einstellmöglichkeiten oder sogar verschiedene Skins an. Doch an den Rädchen, die einen persönlich am meisten stören, kann man häufig nicht drehen.

Eine Möglichkeit für benutzer-orientiertes Webdesign bietet die Erweiterung Stylish für den Firefox-Browser. Um damit wirklich individuelle Ergebnisse zu erzielen, sind allerdings Kenntnisse in der Web-Layoutsprache CSS erforderlich. Wer es gerne mal probieren möchte, sollte sich die Stylish-Erweiterung für Firefox installieren. Schauen Sie sich auf den Webseiten von Stylish ruhig auch mal näher um. Sie finden dort etliche bereits vorgefertigte Stylesheets für bekannte Sites. Im Webkompetenz-Forum finden Sie auf der Seite Stylish: see it your way! außerdem eine Kurzanleitung und zwei Beispiel-Stylesheets (eines für Google, eines für SELFHTML)

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
RSS (Atom) und User-CSS


Donnerstag, 7. Juni 2007

Tutorial: Ajax (6)

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


Eigenschaften und Methoden des XMLHTTPRequest-Objekts

Das XML-HTTP-Objekt verfügt entsprechend der Spezifikation des W3-Konsortiums über folgende Eigenschaften und Methoden:

Eigenschaft: onreadystatechange

Genaugenommen ist dies ein Event-Handler, dem beliebiger JavaScript-Code zugeordnet werden kann, beispielsweise ein Funktionsaufruf: onreadystatechange = tuWas();

Das Ereignis dieses Event-Handler wird immer dann ausgelöst, wenn sich der Verbindungsstatus einer zuvor abgesetzten HTTP-Anfrage ändert. Bei jedem Auslösen des Ereignisses nimmt die Objekteigenschaft readyState einen anderen Wert an.

Eigenschaft: readyState

Diese Eigenschaft speichert den aktuellen Verbindungsstatus einer zuvor abgesetzten HTTP-Anfrage, und zwar in Form einer Zahl. Folgende Werte sind möglich:

0 (oder Konstante: UNINITIALIZED):
Diesen Wert hat die Eigenschaft, bevor die Methode open() aufgerufen wurde, die eine HTTP-Anfrage einleitet.

1 (oder Konstante: LOADING):
Dieser Wert bedeutet, dass die HTTP-Verbindung zum Webserver erfolgreich zustande kam. Diesen Wert hat die Eigenschaft, wenn open() eine Verbindung mit dem Webserver aufnehmen konnte, aber noch keine konkrete Anfrage mit send() gestartet wurde.

2 (oder Konstante: LOADED):
Dieser Wert bedeutet, dass der HTTP-Request vollständig übertragen wurde, und dass die Antwort-Header-Zeilen vom Webserver bereits vorliegen. Wenn readyState diesen Wert hat, können bereits die Methoden getAllResponseHeaders() und getResonseHeader() angewendet werden, um die Server-Antwort schon vor der Übertragung der Nutzdaten auszuwerten.

3 (oder Konstante: INTERACTIVE):
Diesen Wert hat die Eigenschaft, während die eigentlichen Nutzdaten vom Webserver empfangen werden. Die Eigenschaften responseText bzw. responseXML werden während dieses Zustands nach und nach mit den empfangenen Daten gefüllt.

4 (oder Konstante: COMPLETED):
Dies ist der Endzustand und bedeutet, dass die Server-Antwort komplett übertragen wurde.

Leider ist die Implementierung der Zustände von readyState in den verschiedenen Browsern nicht zuverlässig und einheitlich implementiert. So wertet beispielsweise der Opera-Browser nur die Zustände 3 und 4 aus. In der Praxis warten die meisten Ajax-Anwendungen deshalb bis readyState == 4, und beginnen dann mit der Verarbeitung der erhaltenen Antwortdaten.

Eigenschaft: responseText

Diese Eigenschaft enthält die vom Server gesendeten Nutzdaten als String. Was die Daten enthalten, hängt davon ab, was angefragt bzw. gesendet wurde. Bei Textdaten ist auch nichts weiter zur Zeichenkodierung festgelegt — all das sind Dinge, die das aufrufende JavaScript im Zusammenhang mit einem Aufruf vorher wissen muss.

Wenn es sich um Text oder HTML-formatierten Text handelt, werden empfangene Daten in der Regel über die DOM-0-Eigenschaft innerHTML in die aktuell angezeigte Webseite eingebaut.

Eigenschaft: responseXML

Diese Eigenschaft enthält nur dann einen konkreten Wert, wenn die Serverantwort explizit aus XML-Daten besteht. Gedacht ist diese Eigenschaft als Schnittstelle für das Document Object Model (DOM). Mit Hilfe der DOM-Schnittstelle von JavaScript lassen sich so empfangene Daten gezielt in die Dokumentstruktur der aktuell angezeigten Webseite einbauen.

Eigenschaft: status

Diese Eigenschaft speichert den HTTP-Statuscode einer Server-Antwort, sobald diese vorliegt. Nachfolgende Tabelle listet die wichtigsten HTTP-Statuscodes auf:

HTTP-Statuscode Erklärung
200 Der Server kann die angeforderten Daten wie gewünscht versenden. Dies ist der Normalfall, wenn keine Probleme auftauchen.
204 Der Server hat die Anfrage erhalten, sendet jedoch keine Daten zurück. Gut verwendbar ist dieser Status-Code bei Verwendung in serverseitigen Scripts, die zwar etwas auf dem Server erledigen, aber keinen neuen HTML-Code senden wollen.
301 Die angeforderten Daten befinden sich nicht mehr unter dem URI, sie wurden dauerhaft auf eine andere Adresse verschoben. In der Statusmeldung (Eigenschaft statusText) wird angegeben, unter welchem URI sich die Daten jetzt befinden.
302 Die angeforderten Daten wurden vorübergehend zu einem anderen URI verschoben. In der Statusmeldung (Eigenschaft statusText) wird angegeben, unter welcher Adresse sich die Daten derzeit befinden.
304 Die angeforderten Daten haben sich gegenüber einer früheren Anfrage nicht geändert und werden deshalb nicht erneut gesendet.
400 Die Anfrage enthält Syntaxfehler. Der Server kann die Anfrage deshalb nicht bearbeiten.
401 Die angeforderten Daten sind zugangsgeschützt. Der Server kann die Daten nur senden, wenn eine gültige Zugangskennung, bestehend aus Benutzername und Passwort, bei der Anfrage mit gesendet wird.
403 Der Server möchte die angeforderten Daten nicht herausgeben. Das passiert zum Beispiel, wenn der Zugriff auf die Ressource von dem IP-Adress-Bereich, aus dem die Anfrage kommt, in der Serverkonfiguration verboten wurde, die Ressource ganz und gar gesperrt wurde oder man versucht, ein Verzeichnislisting zu bekommen, dies jedoch in der Serverkonfiguration abgeschaltet wurde.
404 Der angeforderte URI existiert nicht.
500 Der Server kann die angeforderten Daten nicht senden, weil auf dem Server ein Fehler aufgetreten ist. Beispielsweise konnte das aufgerufene Script auf dem Server nicht gestartet oder korrekt ausgeführt werden.

Eigenschaft: statusText

Diese Eigenschaft ist nur im Zusammenhang mit der Eigenschaft status zu betrachten. Sie enthält die vom Webserver mitgelieferte Textmeldung zu einem Statuscode. In einigen Fällen (z.B. bei den Statuscodes 301 und 302) enthält die Meldung wichtige zusätzliche Angaben.

Methode: abort()

Mit dieser Methode wird eine laufende Kommunikation mit dem Webserver abgebrochen. Der Event-Handler onreadystatechange wird auf 0 zurückgesetzt. Die verwendete Instanz des XMLHTTPRequest-Objekts kann für eine neue Webserver-Anfrage genutzt werden. Sinnvoll ist der Einsatz dieser Methode beispielsweise, wenn der Anwender die Möglichkeit hat, eine Aktion, für die Ajax zum Einsatz kommt, mit Hilfe einer „Abbrechen“-Schaltfläche zu stoppen. Die Abbrechen-Schaltfläche kann in einem solchen Fall die abort()-Funktion starten.

Methode: getAllResponseHeaders()

Diese Methode ist aufrufbar, sobald der Server zumindest seinen Antwort-Header gesendet hat (die Eigenschaft readyState muss mindestens den Wert 2 haben). Sie liefert die gesamten Header-Felder der Server-Antwort als eine Zeichenkette zurück. Um bestimmte Header-Felder abzufragen, ist die Methode getResponseHeader() besser geeignet. Beispiel (httpRequest ist der Name der Objektinstanz des XMLHTTPRequest-Objekts):

httpRequest.getAllResponseHeaders();

erzeugt eine Rückgabe, die so ähnlich aussieht wie:

Date: Sun, 10 Jun 2007 04:58:38 GMT
Server: Apache/1.3.31 (Unix)
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain; charset=utf-8

Methode: getResponseHeader(name)

Diese Methode ist ebenso wie getAllResponseHeaders() aufrufbar, sobald der Server zumindest seinen Antwort-Header gesendet hat (die Eigenschaft readyState muss mindestens den Wert 2 haben). Im Parameter name muss die Bezeichnung eines HTTP-Header-Feldes übergeben werden. Die Methode liefert dann den zugehörigen Wert als Zeichenkette zurück, sofern das Feld im HTTP-Antwort-Header überhaupt vorkommt. Beispiel:

httpRequest.getResponseHeader("Content-Type");

erzeugt eine Rückgabe, die so ähnlich aussieht wie:

Content-Type: text/plain; charset=utf-8

Methode: open(method, url[, asyncFlag[, userName[, password]]])

Die open()-Methode öffnet eine HTTP-Verbindung zu einem Webserver. Dabei müssen mindestens die beiden Parameter method und url übergeben werden.

Der Parameter method bestimmt die Übertragungsmethode. Üblich sind die Angaben "get" und "post". Weitere mögliche HTTP-Methoden sind "put" und "head", die jedoch in der Praxis seltener verwendet werden. Die Standardmethode ist "get". Die Methode "post" wird dann verwendet, wenn das Ajax-Script selbst schon Nutzdaten an den Server senden will. Ein möglicher Anwendungsfall wären Formulardaten, die bereits während der Eingabe und vor dem Absenden des Formulars auf dem Server zwischengespeichert, überprüft oder anderweitig verarbeitet werden sollen.

Der Parameter url ist keine vollständige HTTP-Adresse, sondern nur eine Pfadangabe. Denn wie bereits erwähnt, kann ein Ajax-Script nur Adressen auf demjenigen Webserver aufrufen, von dem aus es selbst an den Browser übertragen wurde. In aller Regel handelt es sich bei der Adresse, die mit url übergeben wird, um ein für den Webserver ausführbares Script, also z.B. um ein PHP-Script oder um ein CGI-Script in Perl.

Wenn Sie für den Parameter asyncFlag explizit einen Wert übergeben wollen, müssen Sie true oder false übergeben. Mit true erzwingen Sie einen asynchronen Scriptablauf, und mit false einen synchronen Scriptablauf.
Ein asynchroner Scriptablauf bedeutet, dass JavaScript nicht wartet, bis die Antwort des Webservers vollständig übertragen wurde, sondern dass der Rest des JavaScripts sofort abgearbeitet wird. Bei einem synchronen Scriptablauf verhindert der Aufruf der Methode send() den weiteren Ablauf des JavaScripts so lange, bis die Serverantwort vollständig eingetroffen ist.
Der Default-Wert ist true, also ein asynchroner Scriptablauf. Der Vorteil davon ist, dass JavaScript seine Aufgaben erledigen kann und weitere Anwenderaktionen beispielsweise nicht blockiert sind. Dabei entsteht jedoch das Problem, dass die Daten des Webservers erst eintreffen, wenn das JavaScript bereits fertig durchgelaufen oder zumindest im Ablauf schon weiter ist. Aus diesem Grund wird bei asynchonem Scriptablauf eine sogenannte Callback-Funktion definiert, die dann aufgerufen wird, wenn die Serverantwort vorliegt. Der Event-Handler dafür ist onreadystatechange.

Die Parameter username und password sind nur dann von Bedeutung, wenn der Webserver für die über Ajax aufgerufene URL eine Identifizierung verlangt. Es ist jedoch nicht empfehlenswert, solche Inhalte über Ajax aufzurufen, da dann Benutzername und Passwort im JavaScript-Quelltext stehen, der für Web-Benutzer leicht einsehbar ist.

Methode: send([content])

Diese Methode sendet eine HTTP-Anfrage an den Webserver. Zuvor muss die Verbindung zum Webserver mit der Methode open() erfolgreich hergestellt worden sein. Wenn Sie als Anfragemethode get verwenden, übergeben Sie send() keinen Parameter. Wenn Sie dagegen post verwenden, müssen Sie send() eine Zeichenkette übergeben, welche die zu postenden Daten enthält. Diese Daten müssen in der Form www-form-urlencoded vorliegen, also so kodiert sein wie ein GET-Parameterstring (Felder durch & trennen, Feldname und Feldwert durch = trennen, www-form-url-eigene Zeichen hexadezimal kodieren — für letzteres stellt JavaScript die Funktion encodeUri() zur Verfügung).

Methode: setRequestHeader(name, value)

Mit dieser Methode können Sie der HTTP-Anfrage gewünschte HTTP-Header übergeben. So können Sie beispielsweise gewünschte Zeichensätze angeben — im Prinzip kann name alles sein, was in HTML an <meta http-equiv=... zugewiesen werden kann, und value alles, was im gleichen HTML-Tag content= zugewiesen werden kann.


Mittwoch, 6. Juni 2007

Auslese der Next Web Conference 2007

Wer hier mitliest, interessiert sich selbstredend auch für die Zukunft des Web, wie es in einigen Jahren vielleicht aussehen wird, und in welchem Ausmaß es Alltags und Beruf prägen wird. Mit genau diesen Aspekten hat sich die Next Web Conference beschäftigt, die dieses Jahr zum zweiten Mal stattfand. Austragungsort war Amsterdam, und über die Bühne ging alles an einem Tag, dem 1. Juni 2007.

Namhafte Web-Größen wie etwa Eric A. Meyer (Webdesign-Experte) oder David Weinberger (Mitbegründer des Cluetrain-Manifests) trugen Video-Inhalte bei, und Leute wie Felix Petersen (Gründer von plazes.com) oder Tapan Bhat (Vizepräsident von Yahoo) hielten Vorträge.

Halt! Felix Petersen sagte leider in letzter Minute ab. Seine neun Monate alte Tochter sei krank geworden, und deshalb müsse er nach Berlin. „Share where you are right now and what you are doing there“, heißt es auf der Startseite von Petersens erfolgreicher Site plazes.com. Natürlich nutzt auch Petersen selbst seinen Service. Und laut dessen Daten war er zum Zeitpunkt der Next Web Conference nicht in Berlin bei seinem kranken Töchterchen, sondern in Kopenhagen auf der gleichzeitig zur Next Web Conference stattfindenden Reboot conference, wo er es sich bei Dinner, Bier und Wein offenbar gut gehen ließ.

Wer lieber nicht gefunden werden möchte, zum Beispiel, weil er vorgibt an einem Ort zu sein, an dem er gar nicht ist, sollte Plazes meiden wie ein Vampir das Zazikifass. Bis zum vorigen Freitag wäre man davon ausgegangen, dass Felix Petersen, der Chef und Gründer von Plazes, das weiß. Offenbar nicht.“, so der SPIEGEL, der sich ebenfalls diesem Thema widmet und titelt Firmenchef entblößt sich im Mitmachnetz.

Ein kleiner Lapsus also im Strom des Weltgeschehens. Jedoch einer, der uns sagen will: nicht alles, was Leute verbindet („connecting people“ ist ja der Wahlspruch des Web 2.0), ist immer und in jeder Situation von Vorteil. Manchmal ist es besser, sich aus der lückenlosen alltäglichen Selbstpräsentation im Web zu verabschieden. Denn nur, wer sich auf seinen Abwegen noch sicher fühlen darf, kann ein glückliches Leben führen.


Samstag, 2. Juni 2007

Linz 2009 oder Wege ins Wissen

Auf freienetze.at, die Website, um die es hier geht, bin ich durch den Blogeintrag Buchrezension: Wege ins Wissen im Datenschmutz-Blog aufmerksam geworden. Das Buch „Wege ins Wissen“ bildet den zentralen Inhalt von freienetze.at. Um seinem Anspruch gerecht zu werden, ist das Buch kapitelweise in PDF-Form downloadbar, aber natürlich gleichzeitig auch über den Buchhandel erwerbbar, online beispielsweise via Amazon. oder auch direkt über freienetze.at

Der Anlass des Buches ist wenn man so will langweilig: Die österreichische Stadt Linz, die 2009 Europäische Kulturhauptstadt sein wird, möchte in diesem Buch auf die eigene Stadt bezogene Zukunftsszenarien für die Teilnahme an der Informations- und Mediengesellschaft vorstellen. Für das Buch hat man allerdings hochkarätige Co-Autoren und Interview-Partner gefunden: Richard Stallman etwa, der Urvater des OpenSource-Gedankens, oder Lawrence Lessig, Gründer der Creative-Commonns-Initiative. Keine Frage also, dass das Buch auch für Leser interessant ist, die rein gar nichts mit der Stadt Linz zu tun haben.

In neun Kapiteln behandelt das Buch verschiedene Aspekte der freien Wissensgesellschaft. Themen sind unter anderem freie Funknetze für den ungehinderten Internetzugang, eine kritische Beleuchtung der geltenden Urheberrechte, die Öffnung der universitären Lehre, OpenSource-Software natürlich, sowie die Bedeutung frei verfügbarer Publikationsformen wie Blogs und Wikis.

Anlesetipp: Kapitel 2: Kreativität in den Fesseln
Wie Urheberrecht Kreativität behindert und doch mit seinen eigenen Waffen geschlagen werden kann.