In aller Regel werden die Aufgaben speziell für diesen Zweck generiert, entweder mit geeigneten Tools und Funktionsbibliotheken vom eigenen Server oder per Webservice von einem externen Anbieter. Es handelt sich meist um Darstellungen von Buchstaben und Zahlen in unterschiedlichen Fonts, Größen, Farben und Neigungen, die zusätzlich durch Überlagerung mit anderen grafischen Elementen verschleiert werden. Seltener werden Rechenaufgaben oder Wissensfragen gestellt. Alternativ werden manchmal für visuell eingeschränkte Nutzer Höraufgaben angeboten.

An diesem Punkt setzt der Webservice reCaptcha der Carnegie Mellon University an, der mittlerweile von Google aufgekauft wurde. Er bietet Text- und Spracherkennungsaufgaben, an denen moderne OCR- und Audio-Erkennungssysteme bei der Digitalisierung von Büchern, Zeitschriften und Rundfunksendungen gescheitert sind. Man bekommt also Captchas von guter Qualität und liefert im Gegenzug durch die Benutzereingaben Beiträge zur Komplettierung der Digitalisierungsprojekte. Aber wie kann der Service entscheiden, ob die Aufgabe richtig gelöst wurde? Ganz einfach: Es werden immer zwei Wörter angezeigt, von denen eines bereits bekannt ist. Um den Test zu bestehen, muss das bekannte Wort richtig erkannt werden. Der Lösungsvorschlag für das neue Wort jedoch fließt in eine statistische Berechnung ein, die irgendwann eine gesicherte Lesart für dieses Wort nachweist.

Die Einbindung von reCaptcha erfolgt über Javascript bzw. im <noscript>-Tag in einem iFrame. Es ist zu überlegen, ob man den <noscript>-Teil nicht völlig weglassen kann, um einen zusätzlichen Schutz vor automatisierten Zugriffen zu erreichen, da viele Spambots nicht oder nur rudimentär mit clientseitigen Scripten zurecht kommen. Die Darstellung der Captcha-Abfrage ist nur bei Einbindung über Javascript konfigurierbar, die API ist gut dokumentiert. Sinnvollerweise verwendet man die Bibliothek mit dem AJAX-API, die ein leicht zu handhabendes Javascript-Objekt bereitstellt, das über die create-Funktion konfiguriert und direkt ausgegeben werden kann.

<script type="text/javascript" src="http://api.recaptcha.net/js/recaptcha_ajax.js"></script>
<script type="text/javascript">
Recaptcha.create(
    "<api_key>",
    "recaptcha_div", {
        theme: "white",
        lang: "de",
        ...
        callback: Recaptcha.focus_response_field
    }
);
</script>


Und hier kann man nach Herzenslust mit diesem Captcha spielen:

Wird der Schutzmechanismus nur selten benötigt, genügt es, ihn erst bei Bedarf per AJAX zu laden. Ein Beispiel findet man auf meiner Kontaktseite: Der vermeintliche E-Mail-Link dient nur als Trigger für das Laden des Captchas. Erst wenn dieses gelöst wurde, wird die E-Mail-Adresse angezeigt.

Mit Mailhide bietet ReCaptcha einen eigenen Service zum Schutz von E-Mail-Adressen an. Auch hier wird die Lösung eines Captchas gefordert, bevor die E-Mail-Adresse angezeigt wird. Leider gibt es bei Mailhide noch keine Möglichkeit, das Layout individuell anzupassen. Außerdem läuft der Service immer in einem eigenen Fenster, lässt sich also nur bedingt in eigene Seiten integrieren. Und es wird Vertrauen vorausgesetzt, denn die zu schützenden E-Mail-Adressen müssen beim Anbieter hinterlegt werden.

Um das zu verhindern macht es Sinn, sich für eine Variante, gleich ob mit oder ohne www zu entscheiden, und Requests auf die jeweils andere mit einem Redirect des Servers zu beantworten: die Suchmaschine erkennt die Umleitung, duplicate content wird vermieden.

Nun hat man sich aber womöglich für die Variante mit www entschieden, und sucht nach einem passenden Code-Schnipsel. Der erfahrenen Programmierer mag entweder als faul oder als effizient gelten, aber zunächst googelt er, ob vielleicht ein Kollege das zu lösende Problem schon bearbeitet hat, bevor er das Rad neu erfindet. Und im vorliegenden Fall findet er Lösungen zum Redirect für einen Domainnamen, nicht aber die Umleitung per regular expression für beliebig viele Namen. Selbst die Gegeninitiative www. is not deprecated (www.yes-www.org/) stellt nur Code für eine Domain zur Verfügung. Solchermaßen versichert, dass die Neuentwicklung sinnvoll ist, musste ich den Code eben selbst schreiben und stelle ihn der interessierten Öffentlichkeit zur Verfügung.

In den folgenden Code-Ausschnitten werden die Rewrite-Anweisungen für Apache-Webserver in allen Varianten zusammengestellt. Obwohl durch die beiden Versionen mit regular expressions eigentlich alle Fälle abgedeckt werden, mag man sich bei Umleitung eines einzelnen Domainnamens womöglich für eine der beiden einfacheren Varianten entscheiden. Die Anweisungen sind zur Verwendung in einer .htaccess-Datei im Server-Root gedacht. Zum Einfügen in die Konfigurationsdateien des Webservers müssen sie u.U. geringfügig angepasst werden.

Umleitung zu ohne www

Für einen Domainnamen

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ http://example\.com/$1 [R=301,L]

Für beliebig viele Domainnamen

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L] Quelle: http://no-www.org/

Umleitung zu mit www

Für einen Domainnamen

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

Quelle: http://www.yes-www.org/redirection/

Für beliebig viele Domainnamen

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(?!www\.)(.+)$ [NC]
RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

Der Knackpunkt im letzten Code-Schnipsel, um das es mir hier eigentlich geht, ist der Ausdruck für fehlendes www: ^(?!www\.). Er beruht auf einer negative look-ahead assertion. Gemäß Definition prüft die Formel Ausdruck1(?!Ausdruck2), dass Ausdruck2 nicht auf Ausdruck1 folgt. Genau was gesucht wurde! Wenn www. nicht auf den Zeilenanfang (^) folgt, dann ist die Bedingung erfüllt und die RewriteRule wird ausgeführt: die Umleitung wird geschaltet.

Ein Nachteil dieser Pauschalumleitung sei nicht verschwiegen: Sie setzt www. auch gnadenlos vor jede Subdomain! Will man Subdomains verwenden, muss man also entweder dafür sorgen, dass der Server auch deren Umleitung richtig ausliefert, oder man passt die ReWrite-Bedingung an. Aber für das Problem, für das die beschriebene Lösung entwickelt wurde, hat sie sich bewährt: Eine Typo3-Site mit RealUrl-Extension und vielen Domainnamen, von denen einige noch auf Subsites innerhalb der Typo3-Installation gelenkt werden. Wer so etwas schon einmal aufgesetzt hat, weiß wovon ich rede.

Bei dynamischen Daten stößt man damit schnell an Grenzen. Ein serverseitiges Script kann die Aufgabe lösen, sofern die benötigte Grafik-Funktionalität auf dem Server verfügbar ist. Die Qualität der Ausgabe ist jedoch abhängig von den verwendeten Funktionsbibliotheken nicht immer zufriedenstellend.

Webbrowser-Statistik September 2009

Google ist unser Freund und stellt eine Chart API zur Verfügung, die im einfachsten Fall direkt über das src-Attribut des <img>-Tags angesprochen werden kann. Sie liefert ein Bild im PNG-Format zurück.

cht=p3                                   // Diagrammtyp 3-dimensionales Tortendiagramm chd=t:65,26,4,3,2                        // Daten chs=350x100                              // Gesamtgröße der Grafik in Pixel chco=ffcc00,ff6633,cc3333,339933,3333cc  // Farbwerte für die Daten chl=Internet Explorer|Mozilla Firefox|Safari|Google Chrome|Andere                                          // Text für die Legende

Der Aufruf erfolgt genauso wie das Laden einer statischen Grafik über <img src="http://chart.apis.google.com/chart?cht=p3&chd=t:65,26,4,3,2&chs=350x100&chco=ffcc00,ff6633,cc3333,339933,3333cc&chl=Internet Explorer|Mozilla Firefox|Safari|Google Chrome|Andere" />.

Breitband-Internet-Dichte in Europa Dezember 2008

Einige Diagrammtypen, die Google bereitstellt, sind geradezu spektakulär, wenn man bedenkt, mit welchem Aufwand man sie von Hand produzieren müsste. Andere bestechen durch automatische Berechnung und Markierung von bestimmten Werten wie Maximum oder Durchschnittswert, Kurvenverlaufspunkten oder Bereichen. Die umfangreiche Dokumentation zeigt alle Möglichkeiten, die die API zu bieten hat.

Bleibt die Frage, ob man Google seine Daten anvertrauen möchte. Zunächst einmal ist festzuhalten, dass für jede Grafik separat Daten übermittelt werden. Sie zusammenzuführen und auszuwerten dürfte aufwändig sein, sie zu deuten fast unmöglich. Bleibt vielleicht der Suchtfaktor. Ihn zu messen sollte für Google machbar sein: Von einer bestimmten Domain kommen in messbarer Häufigkeit Anfragen mit gleicher Struktur aber unterschiedlichen Werten. Ihn auszunutzen, scheint das Ziel von Google: Wer die Chart API zu schätzen gelernt hat, steigt vielleicht schon bald auf die Google Visualization API um. Die bietet noch ganz andere Möglichkeiten und lässt sich direkt mit strukturierten Daten aus verschiedensten Quellen füttern. Am bequemsten geht das, wenn man die Datenquelle über HTTP-Requests abfragen kann, wie zum Beispiel ein Google Spreadsheet.

&choe=UTF-8" style="float: right;" /> Ein Schelm, wer Böses dabei denkt. Liegen nicht unsere E-Mails bereits auf Servern von Google oder Microsoft? Und unsere digitalen Fotografien bei Picasa und Flickr? Und sie liegen dort, weil die jeweilige API den Zugriff darauf so bequem macht, sowohl für den Programmierer als auch - über eine Weboberfläche - für den Endnutzer. Einige dieser Services sind ganz offensichtlich so genial, dass es schwer fällt, sie nicht zu benutzen. Und deshalb traue ich mich, sogar meine persönlichen Daten an Google zu schicken, um daraus ein ganz besonderes Diagramm erzeugen zu lassen: einen dreidimensionalen Barcode (QR Code). Den können Sie mit Ihrem Handy vom Bildschirm abfotografieren, dekodieren und Ihrem Adressbuch hinzufügen. Es handelt sich um meine Visitenkarte im vCard-Format.

Quelle: http://web2.wsj2.com

Aus technischer Sicht werden dem Web 2.0 Verfahren zugeordnet, die zwar teilweise schon länger bekannt sind, deren Verwendung aber erst mit der Verfügbarkeit breitbandiger Netzzugänge Sinn macht. Die Tendenz geht dahin, den Browser zur universellen Client-Anwendung zu machen, die mit der jeweils benötigten Applikation auf dem Server kommuniziert. Die persönliche Arbeitsumgebung ist von jedem internetfähigen PC an jedem beliebigen Ort aus verfügbar. Selbstredend werden Daten nicht mehr auf der lokalen Festplatte, sondern auf dem Server abgelegt.

Schöne neue Welt! Auf ideologische Gesichtspunkte will ich nicht weiter eingehen. Lassen wir außer Acht, ob es vertretbar ist, persönliche Daten auf fremden Servern abzulegen oder auf die Korrektheit von Informationen zu vertrauen, die prinzipiell jeder verändern kann. Mein Punkt ist vielmehr, dass das Buzzword Web 2.0 eine Entwicklung benennt, die zwar keinen Paradigmenwechsel darstellt, aber durch das Bild des Versionssprungs sehr treffend beschrieben wird. Die neue Version von Web beruht auf der alten Version, sie kann mehr als der Vorgänger, und sie bringt so etwas wie ein neues, erweitertes Dateiformat mit. Das ist mein Bild für etwas, was der Benutzer gar nicht wahrnimmt. Es ist nur eine Frage der Zeit, bis es sich auf breiter Front durchgesetzt haben wird.

Wir können die Entwicklung nun benennen, wie wir einst die Webseiten mit den vielen Layout-Tabellen und Blind-GIFs benennen konnten. Mittlerweile sind wir bei Seiten der vierten oder fünften Generation angekommen, ohne dass jemand mitgezählt hätte. Web 3.0 wird es ebensowenig geben. Buzzwords muss man immer wieder neu erfinden. Aber hilfreich sind sie schon.

Für den Webserver setze ich auf die bewährten LAMPP-Systeme. Sie werden von so gut wie jedem Webhosting-Provider angeboten. Damit sind die Scriptsprachen und das Datenbanksystem vorgegeben. Aus den für diese Konstellation verfügbaren Applikationen empfehlen sich je nach Einsatzzweck verschiedene Produkte. Eine Hand voll Anwendungen, die man immer wieder gerne einsetzt, gehören zum Repertoire eines jeden Beraters, auch wenn er mit kommerzieller Software handelt. Ich beschränke mich auf Applikationen, die ich verstehe, anpassen und ggf. erweitern kann, und von denen ich weiß, dass eine rege Entwickler-Community existiert: Voraussetzungen, die nur Open Source-Software erfüllen kann.

Aus der Entwicklergemeinschaft gehen immer wieder spezialisierte Dienstleister hervor, die Investitionen in die Installation, Anpassung und Erweiterung einer Software für kundenspezifische Szenarien zukunftssicher machen. Steht der ausgesuchte Dienstleister irgendwann nicht mehr zur Verfügung, so hat man keine Probleme, Ersatz zu finden.

Die Inhalte einer Website werden sinnvollerweise in der modernsten Variante der Internet-Markupsprache HTML (Hypertext Markup Language), der XML-Untermenge XHTML, ausgezeichnet und damit strukturiert. Durch die Verwendung von XHTML wird u.a. erreicht, dass der Code automatisiert überprüft und ggf. in andere XML-Dialekte umgewandelt werden kann. Mit der Strukturierung wird ersichtlich, dass ein bestimmter Satz eine Hauptüberschrift darstellt, während ein anderer Teil einer Aufzählung ist. Rückschlüsse dieser Art sind sowohl dem den Quelltext lesenden Menschen als auch bei der maschinellen Verarbeitung möglich. Screenreader und Suchmaschinen-Robots orientieren sich fast ausschließlich an den solchermaßen strukturierten Texten.

Form nach Bedarf

Die Layout-Informationen werden in separaten Dateien (CSS - Cascading Style Sheets) nachgeliefert. Und sie werden dem Zweck oder Anzeigegerät entsprechend angepasst. Auf dem PC-Bildschirm können die Informationen aufwändiger präsentiert werden als auf dem Mobiltelefon oder Handheld. Beim Drucken möchte man sich vielleicht auf bestimmte Elemente beschränken, also Navigationsstrukturen ausblenden, aber einen Copyright-Hinweis hinzufügen. Und wird ein Redesign der Website fällig, so genügt es im besten Fall, die Layout-Dateien allein zu ändern.

Die Kombination von XHTML und CSS ergibt sehr kompakte Quelltext-Dateien, die von den zugreifenden Applikationen selbständig selektiert oder ignoriert werden. Ein Suchmaschinen-Robot wird die CSS-Dateien gar nicht laden. Aber da die XHTML-Datei den zu indizierenden Text ganz ohne störende Designelemente präsentiert, wird er sehr viel davon einlesen und anhand der Strukturen gewichten können. Ein moderner Browser holt sich zunächst zusätzlich zur XHTML- die CSS-Datei für die Bildschirmausgabe und lädt ggf. das Drucklayout nach. Ein älterer Browser kann die CSS-Datei vielleicht nicht auswerten, stellt den Inhalt aber entsprechend der strukturellen Auszeichnung im XHTML richtig und vollständig dar.

Moderner Quelltext ist schnell geladen, suchmaschinenfreundlich, ansatzweise barrierefrei, geräteunabhängig und zukunftsicher. Und er hat natürlich Vorteile für den Entwickler, denn er ist übersichtlich und pflegeleicht.

Die einfachste Konstellation geht von einer Internetpräsentation aus, bei der lediglich bestehende Seiten aktualisiert werden sollen und kein Rechtemanagement benötigt wird. Das Navigationsmenü unterliegt demnach keinen regelmäßigen Änderungen, es geht lediglich darum, den Contentbereich einer Seite bearbeiten zu können. Mit entsprechenden Vorkenntnissen könnte man statische HTML-Seiten direkt im Quelltext modifizieren.

Etwas bequemer und sicherer ist es, wenn die Seiten so unterteilt und in mehrere Dateien abgespeichert sind, dass nur die Datei mit dem Content bearbeitet werden muss. Der Server setzt die Seitenteile beim Aufruf dynamisch zusammen. Der Code im Editor ist übersichtlicher und es besteht keine Gefahr, dass an der falschen Stelle etwas verändert wird.

... oder ohne?

Für immer gleich strukturierte Daten kann man Formate verwenden, die ganz auf die Bedürfnisse des Bearbeiters abgestimmt sind, beispielsweise das Exportformat einer lokal verwendeten Software. Will man dem Redakteur jedoch ermöglichen, Text nach eigenen Vorstellungen zu formatieren, ohne dass er HTML beherrscht, lässt sich das nicht mehr durch das lokale Bearbeiten einer Textdatei realisieren. Eine Editorkomponente muss in die Website integriert werden, mit der die einzelnen Seiten im Webbrowser bearbeitet werden können.

Ein WYSIWYG-Editor (ein Eingabeprogramm, bei dem man die Auswirkungen der Formatierung unmittelbar sehen kann) im Backend der Website (also in einem Bereich, auf den nur der Redakteur Zugriff hat) ist bereits ein Schritt hin zu einem komplexeren Content Management System. Denn vorgeschaltet muss eine Auswahlmöglichkeit für die zu bearbeitende Seite sein, und sehr bald wird der Wunsch erwachen, neue Seiten hinzufügen zu können.

Content Management Systeme

Mit einem Content Management System (CMS) hat man in der Regel zusätzlich die Möglichkeit, den Zugriff für mehrere Redakteure zu steuern. Dass neue Seiten automatisch in die Navigation aufgenommen und gelöschte entfernt werden, versteht sich von selbst. Bei der Auswahl ist einerseits die gewünschte Funktionalität und andererseits die Komplexität der Applikation zu berücksichtigen.

Modular aufgebaute Systeme können je nach Bedarf erweitert werden, z.B. um bereits vorhandene Daten aus anderen Systemen automatisiert abzurufen, aufzubereiten und auszugeben.