Das Tutorial beschreibt ein erdachtes WordPress-Plugin mit folgender Verzeichnisstruktur:

my-plugin/
    i18n/
        mce_locale.php
    js/
        editor_plugin.js
    my_plugin.php

TinyMCE

Ein TinyMCE-Plugin ist wie Folgt aufgebaut:

Sämtliche Plugin-Dateien sind in einem eigenen Verzeichnis zusammengefasst. In der editor_plugin.js wird das Plugin initialisiert:

(Das ist der Standard von TinyMCE, die Datei kann natürlich auch anders heißen). Dafür wird der Methode tinymce.create() neben dem Namen des Plugin-Objekts an zweiter Stelle ein Objekt übergeben, welches u.A. die Methode init definiert. Diese akzeptiert wiederum zwei Parameter: das Objekt des Editorfensters und die URL zum Pluginverzeichnis. Mit dem Editor-Objekt und dessen Methoden kann man sich in die Funktionalität von TinyMCE einklinken und z.B. einen Button registrieren, ein Kommando definieren, dass beim Klick auf den Button zur Ausführung kommt und so fort. Über die Methode editor.getLang() kommt man an die übersetzten Textbausteine heran. Dazu später mehr. Um nun ein Dialog mit mehreren Eingabemöglichkeiten zu öffnen, geht TinyMCE den Weg über eine externe HTML-Datei die es in einem Inline-Frame öffnet. Das ist in sofern von Nachteil, da in diesem Kontext nur schwerlich an die WordPress API heranzukommen ist. Von der umständlichen Handhabung, das Fenster so zu stylen, dass es im WordPress-Look daher kommt mal ganz abgesehen.

WordPress bietet eine andere Option an: Das Markup (in den meisten Fällen ein HTML-Formular) für das Dialogfenster wird einfach über den Hook wp_footer in die Seite eingesetzt und per CSS ausgeblendet.

Die Funktionalität des Popups stellt das WP-Interne TinyMCE-Plugin »WP-Dialog« zur Verfügung. Der Methode editor.windowManager.open wird anstelle eines Pfads zum Popup einfach die ID des Formulars übergeben. Das ganze an ein Befehl gebunden, der wiederum an einen neuen Button gebunden wird, öffnet das Fenster beim Klick auf selbigen.

WordPress

WordPress kümmert sich dankenswerter Weise um die Integration des Plugins in TinyMCE. Dazu sind die Filter mce_external_plugins für das Plugin-Script und mce_buttons für den Button bereit gestellt. Beide Filter werden auf je ein Array angewendet, dass erweitert zurück gegeben wird. Um etwas Abstand zwischen die Buttons zu bekommen, setzt man als ein Array-Element einen senkrechten Stricht '|'.

Dynamik in den Dialog bekommt man wie gewohnt über ein JavaScript, dass mit der Funktion wp_enqueue_script() geladen wird. Innerhalb dieses Scripts kommt man über das globale JavaScript-Objekt tinyMCEPopup an den Editor bzw. mit edCanvas an die Textarea im HTML-Modus heran. Zu beachten ist, dass tinyMCEPopup zum Zeitpunkt des jQuery-eigenen Events ready nocht nicht verfügbar ist.

i18n

Um innerhalb des TinyMCE Plugins lokalisierbare Strings zu nutzen, bedarf es einer weiteren PHP-Datei, die über den Filter mce_external_languages geladen wird. Genauer gesagt loopt WordPress über mehrere solche Dateien und erweitert dabei einen String, der die entsprechenden Textausteine enthält, die in bekannter Weise übersetzt werden können. Der String selbst ist JavaScript-Code, der die Methode tinymce.addI18n() aufruft. Über den hier definierten Namensraum sind die Textbausteine dann verfügbar.

Das Laden übernimmt wieder WordPress:

In der Adresszeile wird die URL jetzt um das Protokoll beschnitten. Zumindest wenn es sich dabei um das HTT-Protokoll handelt. Was das bringen soll, kann ich nur vermuten. Mir gefällt es jedenfalls nicht. In about:config kann man das unter dem Schlüssel browser.urlbar.trimURLs beheben.

Ein weiterer Punkt der eher Kopfschütteln verursacht ist die Implementierung der CSS-Eigenschaft text-overflow samt Wert ellipsis. Diese von Microsoft erfundene Eigenschaft führt dazu, dass Text der nicht in das umgebende Element passt (sic!) gekürzt wird und durch eine Ellipse (…) ergänzt wird. In gutem Webdesign passt sich die Box dem Text an und nicht… lassen wir das. Fakt ist, dass der Text der im Quelltext steht auch am Bildschirm zu sehen sein muss. Wenn man seine Texte schon kastrieren will, dann ist das keine Aufgabe des Stylesheets sondern des Scripts auf dem Server. Also kommt gar nicht erst auf dumme Gedanken, liebe Webdesigner da draußen. Danke.

http://subdomain.domainname.tld/pfad/zurm/ziel

Ich hatte noch nie Probleme die einzelnen Teile einer URL zu erfassen und bei gut gemachten Seiten sind die Permalinks eine Orientierungshilfe (wenn überhaupt sollte man also den Pfad hervorheben). Was mir Probleme bereitet sind schwache Kontraste.

Um die URL gewohnt darstellen zu lassen gibt man in die Adressleiste about:config ein, sucht nach dem Eintrag browser.urlbar.formatting.enabled und setzt den Wert auf false. Nach einem Neustart des Browsers ist der Unsinn behoben.

Jonathan Snook reduziert das Problem der Einheit px, wie häufig in dieser Diskussion, auf den InternetExplorer. An der Einheit em stört ihn die Ungenauigkeit und die Vererbbarkeit. Ersteres ist leider nich einmal das Hauptproblem und Letztere kann man als Probleme sehen.

Absolut jeder Browser, nicht nur der IE, stellt die Schrift in der Größe dar, in der sie in px bemaßt ist. Ebenfalls in jedem Browser ist die Möglichkeit gegeben, eine Schriftgröße einzustellen, die den persönlichen Gegebenheiten Rechnung trägt – das müssen noch nicht mal körperliche Einschränkungen sein, es reicht z.B. ein 15″-Bildschirm mit einer hohen relativen Auflösung zu nutzen. Zugegeben, diese Möglichkeit wird wahrscheinlich eher selten genutz, aber wer nutzt sie denn? Jemand, der sich nicht jedesmal auf’s Neue den Text zurechtzoomen möchte. Muss er aber, wenn die Schriften mal wieder in px bemaßt sind! Einziger Ausweg ist, die Mindestschriftgröße (die in vielen Browsern ab Werk nicht gesetzt – also null – ist) auf einen erträglichen Wert herauf zu setzen. Die (bedauernswert häufige) Folge: zerschossene Layouts oder Text, der im Nirgendwo verschwindet. „Barrierefreies Webdesign? – Noch nie gehört!“

Die bessere Alternative zu px heißt em. Diese bedarf allerdings im Einsatz etwas mehr der Vorüberlegung. Unachtsam auf ein Element wie ul angewendet, führt eine Verschachtelung zu einer Multiplikation der relativen Schriftgrößenwerte. Für eine konsistente Schriftgößengestaltung würde man also darauf verzichten einzelne Textbausteine wie Absätze oder Listen mit Schriftgrößen zu versehen sondern ganze Inhaltsbereiche wie Navi oder die Sidebar. Wem das zu kompliziert ist, der darf auf CSS3 hoffen, dass mit rem eine Einheit einführt, die sich auf das Wurzelelement bezieht und somit das Verschachtelungs-„problem“ umgeht.

Bleibt noch die Ungenauigkeit die em, bzw. auch rem als Nachteil ausgelegt wird. Jonathan fängt an rumzurechnen: auf Basis der Standardschriftgröße (in den meisten Fällen 16) versucht er, das Verhältniss 10:1 für px:em in der Darstellung zu erreichen und kommt auf einen Umrechnungsfaktor von 62,5%. Wem die Zahl bekannt vorkommt: Diese Idee war schon vor über 5 Jahren schlecht und sie ist es noch heute, denn es läuft auf das selbe Problem hinaus: die Ignorierung der Schriftgröße im Browser. Diese um über ein Drittel zu reduzieren nötigt Betroffene einmal mehr zur Mindestschriftgröße zu greifen. Schade eigentlich.

Angesichts solcher Kommentare zur aktuellen Lage in Japan, erschien mir eine Definition dieses Begriffs nötig.

Facebook war nicht Zuckerbergs erstes Projekt. Aus einer Idee, unanttraktive Bilder seiner Kommilitonen mit Fotos von Tieren zu vergleichen, die ihm nach eigenen Angaben im Suff unter Alkoholeinfluss kam, entstand FaceMash.com, ein visuelles Bewertungssystem für Studenten. Die Bilder dafür »besorgte« Zuckerberg sich übrigens aus den geschützten Netzwerken der Harvard-Uni. Erst Später folgte Facebook, das schrittweise erst Studenten, später auch Schülern der Vereinigten Staaten und schließlich allen zur freien Nutzung geöffnet wurde. Es stellte sich als das bessere Geschäftsmodell heraus.

Heute sind weltweit über 500 Millionen Nutzer bei Facebook registriert. Unzählige Websites bieten einen Facebook-Link an, oft kann man sich sogar mit dem Facebook-Account bei anderen Diensten anmelden. Dem Nutzer bieten sich eine Fülle von Möglichkeiten sämtliche Kontakte zentral zu verwalten und sich selbst zu präsentieren in dem man Fotos oder Videos hochläd oder einen Weblog führt. Dabei entscheidet jeder selbst, was und wieviel er von sich preis gibt und kann einstellen, wer die Informationen einsehen darf. (Ein Fortschritt im Vergleich zu Zuckerbergs erstem Projekt.) Eine derart prall gefüllte Datenbank, voll von persönlichen Interessen, Personenbeziehungen oder auch dem aktuellem Standort, beschert Facebook dennoch regelmäßig finanzkräftige Investoren.

Was erhält man, wenn man die Schnittmenge aus Kunden eines bekannten Internetdienstanbieters und einer großen Handelskette mit Rabattsystem auf Basis persönlicher Kundenkarten bildet? Eine beachtenswert große Versuchsgruppe, an der man die nachhaltige Wirkung von Werbung nachweisen kann, völlig ohne das Wissen der Probanden. So geschehen bei einem Experiment das in Kooperation zwischen Yahoo und einer nicht genannten Handelskette in den USA stattfand. Das Ergebnis ist erschreckend eindeutig: die 80% der Versuchsobjekte, die regelmäßig Werbung des Händlers eingeblendet bekamen, gingen deutlich häufiger bei diesem einkaufen und gaben auch mehr Geld pro Einkauf aus, ohne dass es ihnen bewusst gewesen wäre. Dabei war es unerheblich, ob die Bannerwerbung angeklickt wurde oder nicht. Diese Art der Manipulation Werbung ist also hoch effektiv und darüber hinaus kostengünstig. Um die Effektivität dieser suggestiven Kundenaquise weiter zu steigern müsste man die eingeblendete Werbung nur noch auf die persönlichen Interessen des Menschen vor dem Bildschirm anpassen. Und wo würde man genauere Informationen über die »Wünsche« des »Kunden« erfahren als in den Datenbanken eines omnipräsenten sozialen Netzwerks?

Seit Neuestem kann man sich bei Facebook auch aktiv zum Objekt der Werbekampagnen degradieren. Dazu reicht es, der Welt über sein Smartphone mitzuteilen, dass man sich gerade in der Filiale eines Geschäftspartners von Facebook aufhält. Als Gegenleistung erhält man kostenlos eine Tüte Popcorn von der Lieblings-Kinokette oder einen Fanschal des Lieblingsvereins. Wäre es nicht sogar echt praktisch, wenn im Anschluss an den Kinobesuch sich der Lieblingsklamottenladen meldet, der zufällig ein Superschnäppchen nur für »Dich«  und noch zufälliger, genau in deiner Größe parat hat?

Mark Zuckerberg, der die Privatsphäre für überholt hällt, behauptet, die Leute würden freiwillig immer mehr Daten über sich preisgeben um sie mit anderen zu teilen. Facebook würde sich diesem Trend lediglich anpassen. Damit mag er recht haben. Ich unterstelle ihm, dass sich Facebook diesem Trend nicht nur anpasst, sondern ihn maßgeblich antreibt und zwar nicht um den Leuten die Möglichkeit zu geben sich mit anderen auszutauschen, sondern mit diesen Informationen Geld zu verdienen – möglichst ohne das die Nutzer davon wissen.

Es ist also nicht der lockere Umgang mit persönlichen Daten, den man Facebook vorwerfen muss, liebe Frau Aigner. Selbst bei völliger Transparenz der Datenschutzeinstellungen, Facebook muss niemandem direkten Zugriff auf seine Datenbanken geben, oder Adressen verkaufen, wie es in der Dialogmarketingbranche gern gemach wird. Es reicht, die entsprechenden »Werbeflächen« für Kundenprofile zu verkaufen, die nahezu beliebig scharf abgegrenz werden können. Anstatt also zu laschen Datenschutz anzuprangern, sollten Sie vieleicht lieber Anfangen, die Leute aufzuklären, welchen Preis sie für ihre Mitgliedschaft wirklich zahlen. Aber das könnte ja langfristig indirekt der Binnennachfrage schaden.

Wie sehr es bei dem Staatsvertrag um das eigentliche Thema Jugendschutz geht, kann man abschätzen, wenn man das politische Kasperletheater in den einzelnen Länderparlamenten im Ganzen betrachtet. In Sachsen stimmt die CDU für den Staatsvertrag, im Rot-Rot regierten Berlin dagegen. Bei den Linken ist es andersrum. Grün ist in Sachsen dagegen, in Hamburg winkt man ihn noch schnell durch, bevor man die Regierung verlässt. Da ringt man mit sich, das Vertrauen in dieses verkrustete System nicht zu verlieren.

Den Vogel schoß derweil ein Herr Beermann von der CDU ab. An die Linke Julia Bonk gerichtet sagte er:

… den 14. Medienschutz-Staatsvertrag in seinem Lauf, … halten weder Ochs noch Esel auf.

Was er damit ausdrücken wollte, kann man nur mutmaßen. Wahrscheinlich asoziiert er die Linke mit der sozialistischen DDR-Regierung, keine Ahnung. Was er hingegen gesagt hat, spiegelt auf eine wunderbar präzise Art und Weise die erkentnissresistente, starköpfige Ignoranz wieder, die ihn und seine Fraktionskolegen weit näher an die Haltung alter DDR-Regierungsmitglieder rücken, als die Linke jemals gewesen wäre. Auf jeden Fall zeigt es aber, wie abgehoben einige Volksvertreter inzwischen sind. Komm du mir noch mal auf den Wahlzettel!

wp_nav_menu ( array (
              'menu' =>; 'main_navigation',
              'container' =>; '',
              //Seit Version 3.1 geht das hier nicht mehr, Nachtrag beachten!
              'menu_id' =>; 'navigation" role="navigation',
              'menu_class' =>; ''
             )
        )
);

Zu meinem Erstaunen funktioniert das so einwandfrei. Ich kann mir zwar kaum vorstellen, dass das so gewollt ist und dauerhaft funktionieren wird, aber wenn es so einfach ist, braucht es vorerst keinen zusätzlichen Filter. (Zur Erläuterung: die Funktion zeigt das Menü mit dem Namen „main_navigation“ ohne umschließendes Element und ohne eine Klasse an, allerdings mit dem ID-Wert: navigation" role="navigation woraus der Quelltext

<ul id="navigation" role="navigation">&lt/ul>

resultiert.) Der Wert wird also ungefiltert übernommen, also aufpassen, was man reinschreibt.

Nachtrag:

Achtung! Spätestens seit Version 3.1 funktioniert das nicht mehr (wahr auch zu erwarten). Hier kann man zu folgender kurzer Funktion greifen, die man in den Filter wp_nav_menu einhängt:

/**
* fügt ein role-Attribut mit dem Wert 'navigation'
* dem Ersten öffnenden HTML-Tag von $a
* hinzu
*/
function mytheme_add_nav_role($a) {
 
    $a = preg_replace('#^\s*< ([a-z]+)([^>]*)>#i','< ${1}${2} role="navigation">',$a);
    return $a;
}
add_filter('wp_nav_menu','mytheme_add_nav_role');

Seitenauswahl einrücken

Jetzt aber ab ins Backend und das Menü anlegen um zu sehen, wie das funktioniert. In den meisten Fällen wird die Navigation sicher die Stuktur der angelegten Seiten abbilden. Warum die Seiten also nicht in ihrer hirarchischen Anordnung sondern in einer einfachen Liste, ihrem Titel nach sortiert, dargestellt werden, ist mir ein Räzel. Spätestens wenn die Seiten nicht mehr allein durch ihren Titel sondern durch die Beziehung zu anderen Seiten identifizierbar sind, steht man vor einem echten Problem.

Dabei ist der Core-Code nur eine Zeile von der Lösung entfernt. Da in diesen untiefen des WordPress-Codes keine Möglichkeit besteht über die Plugin-API einzugreifen, habe ich die entsprechende Funktion und eine Klasse kurzerhand in einem Plugin geklont. Jetzt existiert eine weitere Metabox in der das Chaos weitgehend gebannt ist.

Das Plugin trägt den schönen Namen „nav-menu-page-tree“ und kann hier herunter geladen werden:

nav-menu-page-tree.zip.

Nachtrag
Mit Version 3.2 werden die existierenden Seiten von WordPress selbst auch hirarchisch geordnet dargestellt, womit das Plugin obsolet geworden ist.

Markup aufräumen

Das durch wp_nav_menus() erzeugte Markup der Navigation im Frontend ist gewohnt tadellos, allerdings reichlich überladen. Jedes Listenelement hat eine ID und mehrere Klassen. Darauf kann ich getrost verzichten. Im Falle der ID geht das ganz unkompliziert mit folgendem Filter:

add_filter('nav_menu_item_id',create_function('$a',' return ""; '));

Bevor Worpress das ID-Attribut in den Quelltext einfügt, wird geprüft, ob der Wert überhaupt existiert. Wir haben ihn hier gerade gelöscht. Bei den Klassen funktioniert das seltsamer weise nicht. Nachdem ein Filter die Klassen mit einem leeren String überschrieben hat, müssen vor der Ausgabe des Markups die leeren Attribute entfernt werden:

add_filter('nav_menu_css_class',create_function('$a',' return array();'));
add_filter('wp_nav_menu',create_function( '$a', 'return str_replace(" class=\"\"","", $a);'));

Diese zwei Maßnahmen sparen unter Umständen einen ganze Menge Quelltext. Man kann sich jetzt drüber streiten, ob die Einsparung der Datenmenge die längere Scriptlaufzeit aufhebt, aber als Freund sauberen Quellcodes ist mir das allemal lieber.

Die Funktion wp_nav_menus() schicke ich in den Templates überdies noch durch Thomas’ Funktion remove_self_links() um Links zu entfernen die auf die aktuell angezeigte Seite zeigen. Das klappt hoffentlich auch irgendwann mal von Hause aus.

Die Veranstalter haben die Straßensperrungen tabellarisch zusammengefasst was ich nicht sehr praktikabel finde, gerade für Ortsfremde. Ich habe die Sperrungen mal in eine Karte bei Google-Maps eingetragen. Vieleicht hilft es ja dem einen oder anderen, der aus der Innenstadt raus muss (oder rein will). Der Wegverlauf des Halbmarathons ließ sich leider nicht über die Karte legen. (Vieleicht lieg es an dem Beta-Status des Fußgänger-Routenplaners.) Für den öffentlichen Nahverkehr gelten auch einige Einschränkungen.

Alle anwesenden Sachverständigen waren sich dahingehend einig, dass Jugendschutz ein wichtiges Thema sei und dass man sich mehr Sachlichkeit in der Diskussion über das „Wie?“ wünscht. Schon mit dem zweiten Punkt nahm es nicht jeder so genau. So wurden Bedenken, dass durch diese Form des JMStV neue Abmahnansätze geschaffen würden, von Herrn Heine (Medienanstalt ST) flapsig beiseite gewischt. Jeder der eine Internetseite ins Netz stellt, habe sich zu informieren. Abmahnungen gebe es nun mal, damit müsse man leben. „Das Urheberrecht sei für Internetseitenersteller viel schwerer …“, so Heine. Der JMStV macht den Braten also auch nicht mehr Fett. Ähnlich argumentierte Herr Grewing (VPRT), der überzeugt ist, dass Sendezeiten für das Internet bald technisch möglich sind und sich für einen verpflichtenden Einsatz der Filter seitens der Accessprovider aussprach.

Mit etwas handfesteren Aussagen konnte zumindest Frau Braml von der KJM argumentieren. Ihre Kommission habe die bisher verfügbaren Jugendschutzfilter getestet. Das Ergebnis ist hinsichtlich der korrekten Funktion der Filter und des Preises der Programme allerdings unbefriedigend. Aus ihrer Sicht setzt der JMStV dennoch positive Impulse für den Jugendschutz im Sinne der „regulierten Selbstregulierung“. Die praktische Umsetzung (sprich, die Kontrolle auf Entwicklungsbeeinträchtigende Inhalte) kann durch redaktionelle Betreuung von nutzergenerierten Inhalten (auf Nachfrage wenigstens 100 Mitarbeiter auf 10⁶ Nutzer) oder „Beschwerde-Buttons“ erfolgen.

Jürgen Ertelt sprach, wie auch Prof. Dr. Frederrath, die technischen Probleme und vor allem gesellschaftlichen Konsequenzen an, die sich aus diesem JMStV ergeben. Seine Argumente decken sich weitgehend mit den Forderungen des AK-Zensur und lassen sich mit seinen Worten „Technik kann Erziehung nicht ersetzen“ wohl am besten zusammenfassen.

Einen sehr interessanten Beitrag zur Diskussion lieferte Prof. Dr. Kurt Starke, seines Zeichens Soziologe, Jugendforscher und Sexualwissenschaftler, der einen bis dahin völlig unbeachteten Aspekt des JMStV beleuchtete. Die Tatsache, dass der Begriff der „Pornografie“ nicht klar definiert ist öffnet der Willkür „Tür und Tor“. Außerdem erfasst der Passus über „sexuelle Handlungen von, an oder vor unter 18-jährigen“ einen Großteil der Jugendsexualität. Laut Starke gibt es keine Untersuchung, die die Entwicklungsbeeinträchtigung von „Pornografie“ belegen kann. Etwas scheinbar Entwicklungsbeeinträchtigendes mit Altersbeschränkungen zu kennzeichnen schafft aber gerade erst einen Reiz des Verbotenen und wird somit erst recht interessant. Bezüglich des Konsums von Pornografie wird Jugendlichen viel unterstellt, was nicht den Tatsachen entspreche. Wer Jugendliche schützen will, kommt mit einer Strategie der Bevormundung von Eltern und Jugendlichen nicht weit. Ethische Maßstäbe sind sinnvoller als Verbote.

Bisweilen fühlte man sich an die „Zensursula“-Debatte vor knapp einem Jahr erinnert. Ich kann es nachvollziehen, dass Herr Federrath es frustrierend findet, wie Argumente, die mit großem Sachverstand und Geduld aus den Fachrichtungen zusammengetragen werden, immer wieder beiseite Gewischt werden oder schlicht an Vorurteilen und festgefahrenen Meinungen abprallen.

Es bleibt zu hoffen, dass diese Anhörungen bei den Mitgliedern der Regierungsfraktionen berechtigten Zweifel an dem JMStV sähen konnte. Sonst steht uns bald der nächste Versuch, ein gesellschaftliches Problem mit technisch wirkungslosen Mitteln zu lösen, ins Haus, der in dieser Form allenfalls den Rechteverwertern zusagt und einigen Jugendschützern ein gutes Gewissen beschert.

CAPTCHAS

Wer kann's lesen?

Die wohl zuverlässigste Methode um Spam-Bots zu behindern und echte Besucher auf lange Zeit zu vergraulen nennt sich CAPTCHA. Eine in eine Grafik eingebettete Zeichenfolge soll vom Benutzer erkannt und in ein Feld eingegeben werden. Der Vorteil dieser leider sehr verbreiteten Methode besteht lediglich darin, dass der Seitenbetreiber diesen Schutz sehr schnell in seine Seite integrieren kann. Aus der großen Popularität resultiert aber eben auch eine zunehmende Zahl an Programmen, die diese Bilder auf unterschiedlichen Wegen entschlüsseln oder umgehen können. Unnötig zu erwähnen, dass solche Lösungen nicht nur Barrieren aufbauen, sondern auch nerven. Nur wenig besser (aus Sicht der Zugänglichkeit) sind in Klartext formulierte Logikfragen oder Rechenaufgaben, deren Antwort in ein Feld geschrieben wird. (»Warum muss ich hier eingeben, wieviel Beine ein vierbeiniger Tisch hat?«)

Ich halte prinzipiell von Methoden Abstand, in denen sich der Benutzer als Mensch beweisen muss. Die eingangs gestellte Frage sollte man auch so stellen und nicht anders herum!

(Zentrale) schwarze Listen

Ein anderer Ansatz zur automatischen Erkennung von unerwünschtem Spam ist das Anlegen schwarzer Listen um bestimmte Regelmäßigkeiten in Spamkommentaren zu dokumentieren und jeden Kommentar gegen diese Listen abgleichen. Je größer dabei die betrachtete Menge der Kommentare, desto genauer und umfangreicher werden solche Listen. Zentrale Filterangebote wie Akismet werten alle Kommentare der teilnehmenden Websites aus und erstellen so effektive Filter, von denen alle Teilnehmer profitieren. Doch ist mir bei diesem Gedanken etwas unwohl, da die Formulardaten erstmal eine Reise um die halbe Welt antreten um durch die zentralen Server des Unternehmens zu laufen. Dazu kommt, dass nicht behobene falsch-positive Spamerkennungen einen unbedarften Kommentator gleich auf unzähligen anderen Websites ausschließt.

So effektiv und komfortabel Akismet auch sein mag, hier kommt es vorerst nicht zum Einsatz.

Handarbeit

Vorgefertigte Lösungen wie CAPTCHA-Dienste oder Akismet bedienen auch eines: die Bequemlichkeit dauergestresster Webmaster. Allerdings sind beide Lösungen nervig und/oder datenschutzrechtlich zumindest bedenklich. Dennoch habe ich keine Lust täglich zig Spamkommentare zu löschen. Also habe ich mir mit etwas Handarbeit ein eigenes Plugins gezimmert, in dem ich unterschiedliche Methoden zur Erkennung von Bots anwende. Dabei gehe ich von selbst aufgestellten, oder allgemein bekannten Thesen aus um daraus Filtermethoden abzuleiten.

1. Bots sind dumm

   oder zumindest häufig auf populäre Systeme zugeschnitten. Bei komplexeren Formularen mit mehreren obligatorischen Angaben kann eine Kontrolle der einzelnen Angaben auf Korrektheit schon eine menge Unsinn abfangen. Allerdings sollte man die Filter nicht zu streng auslegen. Eine URL muss nicht zwangsläufig mit ›http://‹ beginnen. Ein Name hingegen endet nur äußerst selten auf ›/index.html‹. Fakultative Felder sollten leer bleiben (Spambots können sich oftmals nur schwer bremsen und füllen gerne alles aus), oder eben den Ansprüchen der Logik genügen: Buchstaben z.B. haben in einer Telefonnummer oder Postleitzahl nichts zu suchen. Wem das zu heikel ist, der sucht nach bestimmten Zeichenketten (›http://‹), man kann sich ja mal vertippen.

   Auf vielen WordPress-basierten Seiten ist die Angabe eines Namens und der E-Mailadresse gefordert, wenn man einen Kommentar hinterlassen will. Wahrscheinlich können die Spamprogramme deshalb die Namens-Attribute der Input-Felder lesen. Wir machen es ihnen aber auch einfach: geschätzte 99,9% aller WordPress-Installationen verwenden für die Namens-Attribute ›author‹, ›email‹, ›url‹ und ›comment‹. Ich habe nicht schlecht gestaunt, als das Spamaufkommen hier um gut 90% zurückging, nur weil ich diese Attributwerte durch zufällig generierte Zeichenketten wie ›df4928j‹ ersetzt habe. Die Bots hier verstehen offenbar noch keine Labels.

2. Bots sind schnell

   Auf dieser Seite beträgt die Zeitspanne zwischen Aufruf des Artikels und Eintrag des Kommentars bei automatisiertem Spam im Durchschnitt 2,5 Sekunden. Selbst wenn ein Mensch den gesamten Artikel schon kennt, und einen vorbereiteten Kommentar einfach nur einfügt und absendet, dürfte er bedeutend länger brauchen. Momentan habe ich die Grenze bei 6 Sekunden gesetzt.

3. Bots lesen keine Stylesheets

   Diese Theorie kann man sich zu nutze machen um eine Falle zu platzieren. Ein zufällig platziertes weiteres Formularfeld wird per Stylesheet für alle Parteien aus dem Sichtbereich geschoben bzw. gar nicht mehr angezeigt. Ist das Feld dennoch ausgefüllt, war mit sehr hoher Wahrscheinlichkeit ein Bot am Werk. Wer auf Nummer sicher gehen will, kann hier auch eine Logikfrage platzieren, für den seltenen Fall, dass ein Textbrowser verwendet wird, der kein CSS interpretiert.

Die Kombination dieser Methoden klappt momentan so gut, dass ich auf die Angabe von Name und E-Mail inzwischen verzichten kann und Kommentare auch sofort eingetragen werden können, ohne von mir überprüft zu werden. Schlägt einer der Filter an, wird der Kommentar nicht gänzlich gelöscht, sondern nur als Spam markiert. Notfalls hole ich sie von Hand wieder zurück.

Auf statischen Seiten habe ich auf diesem Weg sehr gute Erfahrungen gemacht. Die Umsetzung als WordPress-Plugin ist noch in der Testphase. Wenn irgendwo Probleme beim Kommentieren auftreten, würde ich mich über eine kurze Problembeschreibung per E-Mail sehr freuen.

Mir ist bewusst, dass auf einer vergleichsweise kleinen Seite wie dieser andere Bedingungen herrschen als auf den großen Blogs und dass der Kampf gegen automatisierten Spam wahrscheinlich bis zum jüngsten Tag andauern wird, da sich auch Spambots weiter entwickeln. Solang ich aber mit etwas Handarbeit auf CAPTCHAS und Akismet verzichten kann, werde ich es auch tun.

Im Großen und Ganzen bin ich ganz zufrieden mit dem Ergebnis. Wenn hier und da noch ein paar Macken auftreten, die werden sicher bald behoben sein. Falls ihr irgendwo noch über rumliegende Farbeimer stolpert, würde ich mich über einen kurzen Hinweis freuen.

Und wie findest Du, lieber Leser, das neue Outfit?

Für diesen Beitrag würde das so aussehen: PHP, WordPress. Kurz und knackig, aber ein ordentlicher Satz lässt sich daraus nicht formulieren, dazu fehlt das „und“ zwischen den beiden (letzten) Stichworten.

Um solche Aufzählungen in einen vernünftigen Satz einbinden zu können habe ich mir folgenden Code-Schnipsel in die functions.php des Themes geschrieben:

/*
*  Ersetzt das letzte Komma durch ein ' und ' 
*/
function mytheme_tag_list($a) {
 
    //wenn mehr als ein link vorhanden ist
    if(substr_count($a,'<a href="') > 1) {
 
        $pattern = '#</a>\s*,\s*<a ([^>]*)>([^<]*)</a>\s?$#';
 
        $replace = '</a> und <a $1>$2</a>';
 
        $a = preg_replace($pattern,$replace,$a);
    }
    return $a;
}
add_filter('the_category','mytheme_tag_list');
add_filter('the_tags','mytheme_tag_list');

In dieser Form greift der reguläre Ausdruck nur Auflistungen heraus, die durch ein Komma (und evtl. Whitespace) getrennt sind. Aufzählungen ohne oder mit anderen Trennzeichen bleiben unberührt.

Nun kann ich formulieren, dass dieser Beitrag die Themen PHP und WordPress behandelt.

Um in PHP eine E-Mail zu versenden reicht theoretisch folgendes Codebeispiel aus:

mail(
         'mustermann@mail.de',
         'Urlaubsgrüße',
         'Hallo Max, Urlaub an der Ostsee ist toll!'
       );

Der Funktion mail() werden drei Parameter übergeben: Empfänger, Betreff und der eigentliche Nachrichtentext. Nun besteht eine E-Mail nicht nur aus diesen drei Informationen. Genauer genommen, setzt sich eine E-Mail, ähnlich wie ein HTML-Dokument aus zwei Teilen zusammen: einem Kopf (Head) und einem Körper (Body). Im Head(er) werden wichtige Informationen über die E-Mail mit gesendet, unter anderem auch die verwendete Zeichenkodierung. Wenn die Zeichenkodierung nicht angegeben wird, muss der Empfänger „raten“, rät er falsch kommt es zur fehlerhaften Darstellung von Umlauten und Sonderzeichen.

Für die Lösung des Problems sind zwei Schritte nötig:

1. muss dafür gesorgt sein, dass die Daten des Formulars in einem bestimmten Zeichenkodierung zum Server gesendet werden und
2. muss diese Zeichenkodierung in der E-Mail angegeben werden.

Die Zeichenkodierung des Formulars

Der Inhalt eines HTML-Formulars wird in der Zeichenkodierung gesendet, in der auch das HTML-Dokument an den Browser gesendet wird. Die zuverlässigste Art, den Browser über die Zeichenkodierung zu informieren ist das entsprechende HTTP-Headerfeld „Content-Type“. Auf dem Apache Webserver geht das recht unkompliziert, in dem man im Wurzelverzeichnis seiner Website die .htaccess-Datei um folgende Zeile ergänzt:

AddDefaultCharset UTF-8

Diese Methode setzt voraus, dass auch alle Text-Dokumente (Skripte, Stylesheets) in dieser Zeichenkodierung vorliegen.

Ob die Zeichenkodierung im HTTP-Header einer Seite gesendet wird, kann man online testen, oder z.B. in Firefox mit verschiedenen Plugins.

Darüber hinaus kann es nicht schaden, die Zeichenkodierung zusätzlich als Meta-Element in den Quelltext des HTML-Dokumentes zu übernehmen:

Eine weitere Möglichkeit bestünde darin, das Formular um das Attribut „accept-charset“ zu erweitern.

<form accept-charset="utf-8">
</form>

In der Regel reicht es jedoch aus, die Zeichenkodierung im HTTP-Header zu senden.

E-Mails versenden mit Köpfchen

Der E-Mail Header, den die Funktion mail() generiert umfasst nur die nötigsten Informationen und  kann durch einen weiteren Parameter beeinflusst werden. Dabei werden die einzelnen Feld-Wert-Paare durch einen Zeilenumbruch (\r\n) voneinander getrennt. Die Zeichenkodierung wird im Feld „Content-Type“ angegeben. Mit dem „MIME-Version“ Feld wird gesagt, dass die E-Mail MIME formatiert vorliegt.

$email_header  = "MIME-Version: 1.0 \r\n";
$email_header .= "Content-Type: text/plain;charset=UTF-8 \r\n";

Die Variable $email_header wird als vierter Parameter der Funktion mail() übergeben:

//E-Mail senden
mail($address, $subject, $content, $email_header);

Damit hat sich der Zeichensalat erledigt. So lange im E-Mailheader keine Sonderzeichen vorkommen, sind Unicodezeichen im Text der E-Mail ab jetzt kein Problem mehr. Wenn aber z.B. der Name und die E-Mailadresse des Absenders in den Header aufgenommen werden, oder der Betreff im Kontaktformular vom Benutzer eingegeben werden kann, dann muss man davon ausgehen, das nicht nur ASCII-Zeichen in den Header gelangen. Aber nur diese sind dort erlaubt.

In dem Fall müssen die Zeichenketten für den Header kodiert werden. Dazu gibt es zwei Möglichkeiten: Base64 und Quoted-printable. Die kodierten Abschnitte werden von der Zeichenfolge =?utf-8?q? eingeleitet und von ?= beendet. Der einleitende Tag gibt die Ursprüngliche Zeichenkodierung (hier UFT-8) und die Kodierungsmethode (q für Quoted-printalbe und b für Base64) an.

Für die Kodierung bedient man sich der PHP-Funktionen base64_encode() für Base64 bzw. imap_8bit() oder quoted_printable_encode() für die Quoted-printable Methode. Allerdings ist die Funktion imap_8bit() an die IMAP-Extention geknüpft und quoted_printable_encode() gibt es erst seit PHP Version 5.3.

Der Betreff der E-Mail würde wie folgt kodiert werden:

$subject = $_POST['subject'];
 
//Quoted-printable
 
$subject = '=?utf-8?q?'.imab_8bit($subject).'?=';
 
//alternativ: Base64
 
$subject = '=?utf-8?b?.base64_encode($subject).'?=';
 
//senden
 
mail($address, $subject, $content, $email_header);

Theoretisch sind beide Varianten legitim, in der Praxis scheinen einige Freemailanbieter noch Probleme mit UTF-8 in der ein oder anderen Methode zu haben. Die Web.de Webmail-Oberfläche z.B. zeigte die dekodierten Betreffzeilen in der Übersicht an, in der Einzelansicht allerdings nicht. Thunderbird und auch Outlook (mobile Version) haben hingegen keine Probleme mit der Dekodierung.

Spätestens wenn die Komplexität der zu sendenene E-Mails über ein simples Kontaktformular hinaus geht, empfielt es sich, vorgefertigte Klassen wie phpmailer zu verwenden. Notwendige Kodierungen werden damit intern abgehandelt und die E-Mail automatisch zusammengefügt.

Die Frage die ich aus den Artikeln und Kommentaren lese: „Darf man erklärte Feinde der Demokratie mit undemokratischen Mitteln bekämpfen?“

Nach Rosa Luxemburg

Früher war ich häufig der Ansicht, man solle um eine Demonstration von Neonazis nicht mehr Wind machen, als unbedingt nötig. Durch gezielt organisierte Gegenaktionen würde man nur unnötige Aufmerksamkeit darauf lenken und polarisieren. Denn nicht selten enden solche Konfrontationen damit, dass auf Krawall gebürstete Linke sich mit der Staatsgewalt in die Haare bekommen. Eine schlechte Presse über „gewaltbereite Autonome“  relativiert dann das eigentliche braune Problem und die stille Zustimmung aus den Wohnzimmern mit den „eigentlich doch friedlichen Nationalen“ gibt es oben drauf.

Zu unseren Grundrechten gehört das Demonstrationsrecht – damit ist auch eine Demonstration der NPD durch das Gesetz legitimiert. Dieses Argument habe ich öfter gelesen, daran gibt es nichts zu drehen und zu wackeln. Die Demokratie lebt davon nicht nach Gutdünken die Freiheit anderer zu beschränken. Eine genehmigte Demonstration zu be- oder verhindern ist eine Ordnungswidrigkeit, entsprechend ist der Aufruf dazu ebenfalls gesetzlich verboten, weswegen die Seite dresden-nazifrei.de kürzlich gesperrt wurde.

Als überzeugter Demokrat und Dresdner steht man vor einer Zwickmühle: man schaut tatenlos zu, wie das braune Unheil durch seine Stadt zieht, oder man stellt sich quer, wissend, dass man anderen die Freiheit nimmt, für die man doch selbst einsteht.

Meine „laissez-faire“-Haltung gegenüber Nazidemos kann in diesem Fall keine Lösung sein. Im vergangenen Jahr wurde Dresden von 6000 Neonazis heimgesucht, dieses Jahr werden es sicher nicht weniger. Viel mehr öffentliche Aufmerksamkeit kann man gar nicht darauf lenken. Offiziell will man der Dresdner Opfer „in Würde gedenken“. Was inoffiziell dahinter steht, kann sich jeder vernunftbegabte Mensch ausmalen: Geschichtsrevision, Verharmlosung der deutschen Kriegsverbrechen und im Endeffekt blanker Rassismus.

Der vom NS-Regime gewollte und begonnene zweite Weltkrieg hat 55 bis 60 Millionen Menschen das Leben gekostet.  Es ist auf eine groteske Art beschämend und abstoßend zugleich, dass die Sympathisanten der faschistischen Ideologie, die zu diesem Krieg  führte, heute immer noch Menschen gegeneinander abgrenzen und Opfer aufzählen. Damit verhöhnten und missbrauchen sie jeden einzelnen Menschen, der in diesem Krieg gestorben ist. Allein der Gedanke daran macht mich wütend und ich kann jeden verstehen, der diesen Aufmarsch aus diesem Grund verhindern will.

Frau Oberbürgermeisterin Orosz ruft alle Dresdner zu „Erinnern und Handeln. Für mein Dresden“ auf. Eine Menschenkette soll symbolisch die Innenstadt vor den Nazis schützen. Immerhin ein gutes Zeichen dafür, dass Dresden nicht einverstanden ist mit dem braunen Pack – wenn genügend Menschen mitmachen. Das ungute Gefühl der scheinbaren Tatenlosigkeit bleibt dabei trotzdem. Ich würde mir eine Aktion der Front Deutscher Äpfel wünschen. Dabei habe ich wenig Hoffnung, dass die Rechten das verstehen, es ist aber eine aktive und intelligente Art des Protests.

Am Ende zählt es als Dresdner zu zeigen, dass wir auf Nazis verzichten können auch wenn man sich nur symbolisch in den Weg stellt. Wie dieser Protest aussieht, muss jeder für sich selbst entscheiden.

Nachtrag 29.01.

Es kommt noch mehr Bewegung in die Sache. Dresden hat Auflagen erlassen nach der die Nazis nur eine Kundgebung, aber kein Aufmarsch durchführen dürfen. Wieder bleibt ein fader Beigeschmack, da doch dafür erst kürzlich das Versammlungsrecht vom Landtag geändert wurde.

Nachtrag  08.02.

Das Verwaltungsgericht Dresden hat entschieden, dass die Einschränkung der Nazidemo unzulässig ist.

Die richtige Antwort

Wenn man eine URL Aufruft, zu der keine passende Ressource gefunden wird, landet man für gewöhnlich auf einer weißen „404 – not found“ Seite, die vom Server automatisch generiert wird. Mit etwas Glück ist diese Seite aber im Design der Website und bietet mögliche Alternativen zum nicht gefundenen Inhalt. In beiden Fällen antwortete der Webserver auf die Anfrage mit dem Statuscode „404“ der besagt: „Es wurde nichts gefunden“.

Ändern sich bei einem Umzug die URLs der Seiten, so landet jeder Aufruf der alten Links in der Sackgasse obwohl die Seite noch existiert. Folgerichtig wäre die korrekte Antwort vom Server: „der gesuchte Inhalt ist jetzt unter einer neuen URL verfügbar“. Der richtige Statuscode für diesen Fall ist „301 – Moved Permanently“.

Einige Seiten sind auch komplett verschwunden. Zum Teil weil sie in andere eingebunden wurden (Kontakt und Impressum können durchaus auf einer Seite unterkommen), andere waren einfach veraltet. Anfragen auf gelöschte Seiten beantwortet man ordnungsgemäß mit dem Statuscode „410 – gone“, der soviel bedeutet wie „Diese Seite ist von uns gegangen“. Somit ist auch gleich dafür gesorgt, dass Google & co. bescheid wissen und ihre Indizes aktualisieren können.

Die Umzugskisten auspacken

Während andernorts noch diskutiert wird, ob WordPress als CMS taugt, setze ich es ein. Nicht zuletzt weil Anpassungen wie diese kinderleicht zu integrieren sind. Um alte URLs ihren neuen zuzuordnen und gelöschte Seiten zu kennzeichnen, ergänze ich die functions.php des eingesetzten Designs um folgende Funktion:

/** umleiten alter Permalinks auf die neuen
*/
function translate_permalinks() {
 
    $_301 = array(
                    '/startseite.html' => '/'
                    '/kontakt.html' => '/kontakt',
                    '/mannschaften.html' => '/mannschaften',
                    '/news.html' => '/aktuell',
                    '/links.html' => '/weblinks',
                    '/impressum.html' => '/kontakt#impressum',
                );
 
    $_410 = array ( '/alt.html',
                    '/javascript/altes_script.js',
                    '/css/altes_stylesheet.css',
                    '/weg.html'
                   );
 
    if(array_key_exists($_SERVER['REQUEST_URI'],$_301)) {
 
        header('Location: '.
                   ($_SERVER['HTTPS'] ?
                          'https' :
                          'http'
                   ) .
                   '://'.$_SERVER['SERVER_NAME'] .
                   $_301[$_SERVER['REQUEST_URI']],
                   true,
                   301);
        exit();
    }
 
    elseif(in_array($_SERVER['REQUEST_URI'],$_410)) {
 
        header(
                  ($_SERVER['SERVER_PROTOCOL'] == 'HTTP/1.1' ?
                        'HTTP/1.1' :
                        'HTTP/1.0')
                   . ' 410 Gone'
                 );
        header('Content-type: text/html;charset=utf-8');
        echo '
<h1>410 - Gone</h1>
Dieses Dokument existiert nicht mehr bei uns.
         Besuch bitte unsere <em>neue</em> Website:
         <a href="http://domain.tld/">http://domain.tld</a>';
        exit();
    }
 
    else {
        return;
    }
}

In dem Array $_301 ordne ich die neuen Links den alten in der Form zu:
/link/zur/alten-datei.html => /neue_datei.
Alle nicht mehr vorhandenen URLs werden in dem Array $_410 lose aufgelistet. Die Elemente beider Arrays werden mit der Request-URI verglichen und im Falle einer Übereinstimmung erfolgt die Weiterleitung bzw. die Antwort mit dem entsprechenden Statuscode.

Der Funktionsaufruf erfolgt am Anfang der functions.php. Je nach Umfang der Website ist das etwas mehr Handarbeit die sich aber lohnt.

Nachtrag:

In den Kommentaren hat mich Thomas darauf hingewiesen, dass es schneller geht, die Umleitungen in die .htaccess-Datei zu schreiben, da so nicht jedesmal das ganze System geladen wird. Wer also auf die Performance achtet, oder ein anderes System als WordPress nimmt, schreibt die Umleitungen und gelöschten Dokumente besser in die .htaccess.

Für diese Zwecke ist die Redirect-Direktive des Moduls „mod_alias“ geeignet. Alle permanenten Umleitungen werden so notiert:

Redirect permanent /alte_seite.html http://domain.tld/neue_seite

Hier muss man darauf achten, dass die URL zur neuen Seite vollständig angegeben werden muss, da Weiterleitungen nicht zwangsläufig auf eine Domain beschränkt sind.

Für gelöschte Dokumente lautet der Eintrag:

Redirect gone /alt.html

Der vollständige Eintrag für die oben behandelten Seiten:

<IfModule mod_alias.c>
Redirect permanent /startseite.html http://domain.tld/
Redirect permanent /kontakt.html http://domain.tld/kontakt
Redirect permanent /mannschaften.html http://domain.tld/mannschaften
Redirect permanent /news.html http://domain.tld/aktuell
Redirect permanent /links.html http://domain.tld/weblinks
Redirect permanent /impressum.html http://domain.tld/kontakt#impressum
 
Redirect gone /alt.html
Redirect gone /javascript
Redirect gone /css
Redirect gone /weg.html
</IfModule>

Mit der Redirect Direktive kann man nicht nur einzelne Dokumente sondern auch Verzeichnisse handhaben, wie im Fall der Stylesheets und der Skripte zu sehen ist.

Damit Anfragen auf die entfernten Dokumente nicht mit einer lieblosen Standardantwort abgespeist werden, kann man noch ein Error-Dokument in der .htaccess anlegen:

ErrorDocument 410 /entfernt.html

Um mit dem schnöden Einheitsbrei zu brechen und diesem Blog ein würdiges Jahresabschlusspost (zu Deutsch: Beitrag) zu verpassen erlaube ich mir einen kritischen Beitrag von Nico Semsrott zu verlinken, einem sehr begabten Nachwuchskomiker, der die Zeichen der Zeit erkannt hat – wir haben nichts mehr zu lachen.

Was fällt der Stadtobrigkeit eigentlich ein? Nächstes Jahr darf ich an den Adventssonntagen nicht mehr shoppen? Es gibt für mich einfach nichts Schöneres als an einem Sonntag sich durch ein Kaufhaus zu drängen, in den Wühltischen zu kramen und sich mit Fastfood zu stopfen um anschließend das nächste Kaufparadies zu entern. Und nun wird es mir mit fadenscheinigen Argumenten verboten.

Ich bin doch ein mündiger Bürger, der selbst entscheiden kann wann er wo sein Geld ausgeben will. Warum soll diese Entscheidung also von Anderen getroffen werden als mir? Es ist ja auch nicht so, dass sonntags niemand arbeiten müsste. Ärzte und Polizisten müssen doch auch ran und ich selbst hab schon Wochenendschichten geschoben, warum sollte es den Verkäufern besser gehen als mir, dem König Kunde? Deren Familien können doch auch schoppen gehen, dann tun sie wenigstens was für die Wirtschaft.

Wo wir gerade dabei sind, die Rechnung ist doch ganz simpel: Max Mustermann gibt jeden Tag 100€ beim shoppen aus. Ergo sind das 100€ mehr Umsatz für den Einzelhandel, wenn Max auch sonntags einkaufen geht. Pro Woche also 16,7% Umsatzsteigerung. Das können wir uns nicht leisten, darauf zu verzichten – gibt es einen besseren Weg aus der Kriese? Auf die Touristenscharen, die Dresden dann davonrennen, kann auch keiner verzichten. Die fahren dann lieber nach Riesa oder Meißen und kaufen Ihre Fernsehgeräte dort. Die obligatorischen Frauenkirchensouvenirs kann man auch im Internet bestellen, da muss man nicht extra herkommen.

Dabei könnte es so entspannt zugehen, wie heute schon auf dem Neustädter Bahnhof. Dort kann ich an allen Feiertagen noch gemütlich und entspannt shoppen gehen. Es ist schon zu oft vorgekommen, dass man den Braten am 25. verrissen hat und die Ersatzgans noch tiefgefroren im Froster lag. Wohl dem, der da zu Weihnachten noch schnell zum Fleischer spurten kann . In dem Sinne,

frohes shoppen!

Hi, I’m Stef.

And I’m Greg.

We’re cool.

We’re from google.

*winkt in die Kammera*

We use wave.

Oh yes, wave ist cool.

E-mail is uncool.

It’s so old

My granny uses e-mail.

Bah, we need some new stuff.

Why?, you ask?

I don’t understand the question, you Greg?

No, but… erm, here ist wave!

It’s totaly new and great.

And new …

Von allem ein Wenig

Nach dem sich die Beiden aus dem Video so große Mühe gegeben haben, die unzähligen Vorteile von Googles neuestem Streich „Google Wave“ anzupreisen, musste ich das auch mal ausprobieren. Also hab ich nach einer Einladung Ausschau gehalten um zum erlesenen Kreis der Tester zu gehören, denn der Dienst befindet sich noch im Teststadium.

Mein erster Eindruck: Google versucht mit Wave die eierlegende Wollmilchsau 2.0 auf die Beine zu stellen. In Wave vereinen sich zentrale Kommunikationsmechanismen, die das Internet (z.T. schon sehr lange) zu bieten hat. Das „Neue“  ist also eher eine Mischung aus Internetforum, Chat  und etwas E-Mail ohne die spezifischen Nachteile der einzelnen Methoden zu verbessern. Im Gegenteil. In einem Forum und bei E-Mail kann ich jeder Nachricht einen Titel bzw. einen Betreff geben. Waves haben keinen Titel. Dafür kann man an einer (oder einem?) Wave mehrere Kontakte teilhaben lassen und sie sogar öffentlich zugänglich machen. Was im ersten Moment sehr praktisch klingt, wird schon bei nur zwei Teilnehmern schnell unübersichtlich, denn jeder kann in Echtzeit in den Nachrichtenverlauf an beliebiger Stelle herein schreiben, sogar die Beiträgen der anderen Adressaten verändern. Eine durchdachte Struktur (optisch wie semantisch) vermisse ich hier sehr. Unter der Haube handelt es sich bei dem Wave Benutzeroberfläche um eine fettige Div-Suppe mit Tabellenwürzung.  Dabei wird beim Einloggen dringend empfohlen, entweder Firefox 3.5, Safari 4 oder den neuesten Google Chrome zu verwenden. Warum also nicht auf HTML 5 setzen, dass eine Vielzahl an Struktur-Elementen bietet, also wie geschaffen wäre für komplexe Dokumentenstrukturen wie Wave?

Überhaupt, Tippen mit Echtzeitübertragung… Jeder der Online ist, sieht die Cursorposition des Teilnehmers, der gerade in der Wave schreibt, jeden Tippfehler, jede falsche oder undurchdachte Formulierung, alles. Sieht mit unter lustig aus, nervt aber wenn man, wie ich, ein bis zwei Anläufe braucht, bis man die richtige Formulierung hat.

Für Windowsnutzer ist Google Wave (zur Zeit) eine reine Webanwendung, d.h. ich kann nur mit dem Browser „waven“, was noch sehr langsam und stockend vor sich geht, selbst mit Firefox 3.5 oder Opera 10 (Googles Hausbrowser Chrome habe ich nicht). Eine Desktopanwendung gibt es wohl nur für Mac-User. Die können dann auch gleich aus iPhoto Bilder per Drag&Drop in ein Wave einfügen. Das kann man mit jedem vernünftigen E-Mailprogramm auch unter Windows.

Natürlich gibt es auch Schnittstellen für Twitter und Blogs. So kann man Waves mit einem Blog „verknüpfen“ um dann von der Wave in das Blog zu schreiben und anders herum.

Schaut man sich das ganze an, wird einem schnell klar, dass wenn sich der Dienst durchsetzt, er sehr ressourcenintensiv werden dürfte. Globale Echtzeitkommunikation mit Konferenzschaltungs-Charme, das braucht Rechenpower. Rechenpower, wie nur Google sie „kostenfrei“ bereit stellen kann.

Kosten und Nutzen

Die Frage nach dem Sinn und Zweck von Google Wave hat sich mir eigentlich gleich zu Anfang gestellt. Ich komme wunderbar mit E-Mail, ICQ und ein paar Internetforen zurecht. Allerdings ist die Frage nach dem „Warum“ im Web 2.0 aussichtslos. Irgendwo werden sich immer neue Bedarfsnischen auftun, die gefüllt werden wollen.  Am Ende muss die Frage nur jeder für sich beantworten können. Für mich bleibt der fade Beigeschmack, dass mit Wave ein riesiger Konzern wie Google noch genauere Profile von seinen Kunden bekommt.

Fazit: Google Wave ist im jetzigen Stadium ein unübersichtliches, zäh zu bedienendes Medium, dessen Mehrwert gegenüber bisher Vorhandenem sich mir nicht erschließt. Wer es selbst einmal probieren möchte,  ich habe noch „Einladungen“ zu vergeben.