Mittwoch, 30. Mai 2007

Tags und Labels vs. Outliner und Ordner

In zahlreichen Web-2.0-Anwendungen ordnen Anwender ihre Daten nicht mehr in ein explorer-artiges Ordnersystem ein, sondern versehen Datensätze nur noch mit mehr oder weniger spontan vergebenen Schlüsselwörtern (im Fach-Slang als Tags oder Labels bezeichnet) und vielleicht noch ein paar Worten Kurzbeschreibungstext. Bestes Beispiel sind Social-Bookmark-Services wie del.icio.us, Mister Wong oder Google Bookmarks. Gerade die Bookmarks sind auch insofern ein Paradebeispiel, als hierbei die Konzepte frontal aufeinander treffen. Während nämlich in allen modernen Browsern die Bookmark/Favoritenverwaltung nach wie vor ordner-orientiert ist, setzen die web-basierten Services auf die flache, stichwortbasierte Ablagestruktur.

Wer nun denkt, dass die Gründe bei den Webanwendungen programmiertechnischer Natur sind, irrt. Es gibt genügend Code-Bibliotheken zur Realisierung von Baumstrukturen, auch im Bereich von Webanwendungen. Die Gründe sind eher konzeptioneller, ideologischer Natur. RSS-Blogger Siegfried Hirsch hat bereits vor zwei Jahren einen lesenswerten Artikel zu dem Thema geschrieben: Google läßt Hierarchien aussterben.

Ein wichtiger Gedanke beim Paradigmenwechsel in der Datenablage ist die Überlegung, dass Anwender nicht mehr entscheiden müssen sollen, wo sie ihre Daten einordnen, und beim Wiederauffinden sollen sie nicht mehr die Erinnerung abrufen müssen, wo genau sie welche Daten eingeordnet haben. Stattdessen übernimmt eine schnelle Volltextsuche das Wiederauffinden. Eine Volltextsuche, die so überragend schnell ist, dass sie mit dem Anspruch auftritt, jegliches Schubladendenken durch kreatives Chaosdenken ersetzen zu wollen.

Für Anwender, die mit Unix- oder DOS-basierten Verzeichnis- und Dateistrukturen, mit dem Windows-Explorer, mit Microsoft Outlook und anderen baumartig strukturierten Datenrepräsentationen „aufgewachsen“ sind, ist das Konzept der reinen Verstichwortung von Daten zunächst befremdlich. Tatsächlich werden sich solche Anwender anfänglich schwerer damit tun, solchermaßen abgelegte Daten schnell wiederzufinden. Doch wie so vieles ist auch das Taggen Übungssache. Mit der Zeit lernt man, in Stichwörtern und Kurzbeschreibungen alle Wörter und Ausdrücke unterzubringen, die man mit den so abgelegten Daten verbindet. Das Suchen ist dann ein Kinderspiel: einfach spontan ein Stichwort eingeben, und blitzschnell wird alles aufgelistet, was diesem Stichwort zugeordnet ist, oder wo dieses Stichwort im Namen, Titel, in den Stichwörtern oder der Kurzbeschreibung vorkommt.

Argumentiert wird gegen die Abschaffung der Hierarchien bei der Datenablage vor allem damit, dass intuitives Suchen den meisten Menschen stärker entgegen kommt als archivarisches Schubladendenken. Allerdings hat es auch für die Verwendung von Baumstrukturen immer glühende Verfechter gegeben. Gliederungseditoren (englisch: Outliner) unterstützen bewusst dabei, Inhalte in eine selbst entworfene Hierarchie einzuordnen. Nicht zufällig haben Outliner bereits eine lange Tradition. Auch viele Websites setzen eine hierarchisch organisierte Navigation ein, um dem Anwender eine klarere Vorstellung des Gesamtangebots zu vermitteln. Der Hintergedanke dabei ist, dass Menschen sich in der Regel gut merken können, wo etwas eingeordnet ist.

Der Kampf der Paradigmen hat auch mit dem zu tun, was wir im Rahmen unserer Hypertext-Serie unter dem Titel Suchen und Stöbern behandelt haben. Suchen setzt voraus, dass man weiß, wonach man suchen will. Stöbern setzt voraus, dass man bereit ist, sich auf eine angebotene Struktur einzulassen. Vermutlich haben beide Paradigmen ihre Berechtigung. Und vielleicht werden auch die Konzept-Entwickler von Webanwendungen irgendwann anerkennen müssen, dass Einseitigkeit immer eine falsche Ideologisierung ist.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Tags und Labels vs. Outliner und Ordner: Ich bekenne mich als hierarchiephil!


Dienstag, 29. Mai 2007

Hypertext (5): Orientierungsmittel für Hypertext

siehe auch:
(1): Text und Linearität
(2): Computer und Hypertext
(3): Inhaltseinheiten und Verlinkung
(4): Suchen und Stöbern


Lost in Hyperspace

Beim Stöbern in den Inhalten eines Hypertextangebots besteht leicht die Gefahr, sich vom Hundertsten ins Tausendste zu verirren. Angenommen, eine Startseite enthält einige Verweise zu Seiten über Ortschaften. Man klickt eine der Seiten an. In den Inhalten zur Ortschaft klickt man auf einen Link zu einem Fürsten, in dessen Gemarkung die Ortschaft einst fiel. In den Inhalten zu dem Fürsten klickt man auf einen Link zu einer Hygienevorrichtung, die im Schloss dieses Fürsten bereits installiert war, was zu der damaligen Zeit alles andere als selbstverständlich war. In den Inhalten zu der Hygienevorrichtung klickt man auf einen Link zu einer Krankheit, die durch die Einführung dieser Hygienevorrichtung weitgehend besiegt werden konnte.

Man kann also sehr weit und interdisziplinär herumkommen, wenn man beim Hypertext-Stöbern spontan Verweisen folgt. Dies passt zu der Beobachtung, dass nur wenige Gedankenschritte nötig sind, um von einem beliebigen Gedanken zu einem beliebigen anderen Gedanken eine logisch sinnvolle Verbindung zu schaffen. Im obigen Beispiel genügen drei Links, um eine logisch nachvollziehbare Brücke zwischen einer Ortschaft und einer längst ausgerotteten Krankheit herzustellen. Als kognitiver Prozess betrachtet, ist so etwas durchaus bemerkenswert und faszinierend (Stichwort Serendipity). Aus Sicht des betroffenen Anwenders kann eine solche Gedankendrift jedoch auch als unerwünschte Ablenkung vom ursprünglichen Interesse empfunden werden. Solange in einer solchen Situation genügend Angebote existieren, über die der Anwender leicht zurückfindet oder sich anders orientieren kann, wird sich die Negativ-Empfindung vermutlich in Grenzen halten. Fehlen solche Angebote jedoch, tritt das sogenannte Lost-in-Hyperspace-Gefühl ein („verloren im Hyperspace“).

Stöbern in Hypertext lädt also zum Driften ein. Erfreuliche Mehrwerteffekte („Serendipity-Effekte“), die dabei auftreten können, sind nicht planbar. Unerfreuliche Lost-in-Hyperspace-Gefühle sind jedoch vermeidbar. Die Mittel dazu werden teilweise von der verwendeten Hypertext-Software bereitgestellt. Anbieter von Hypertext-Inhalten können jedoch ebenfalls entscheidend dazu beitragen, dass keine Lost-in-Hyperspace-Gefühle auftreten.

Hilfen zur Rück- und Neuorientierung

Ein Web-Browser ist Hypertext-Software für Anwender. Das kommt schon in bekannten Produktnamen wie Navigator oder Explorer zum Ausdruck. Das ganze Web und seine Technologien sind ebenfalls auf Hypertext ausgelegt. Im Web und in Web-Browsern sind daher auch typische software-seitige Mittel zur Rück- und Neuorientierung in Hypertexten vorgesehen. Diese Mittel sind jedoch keine neue Erfindungen, die erst durch das Web entstanden. Auch Hypertext-Software im Vor-Webzeitalter kannte bereits vergleichbare Mittel.

Backtracking/Historie

Im griechischen Mythos war es der Ariadnefaden, der Theseus wieder aus dem Labyrinth des Minotaurus heraushalf. Wer heute mit einem Web-Browser surft, zieht mit jedem neuen Seitenaufruf ebenfalls einen Ariadnefaden hinter sich her. Wenn man sich im Hyperspace verirrt, ist die Liste der bereits besuchten Seiten häufig ein willkommener Rettungsanker.

Die einfachste Form ist das schrittweise Zurückorientieren, Backtracking genannt. Nicht von ungefähr bezeichnet der Begriff im Englischen eine algorithmische Problemlösungsmethode. Auch dem Menschen kommt diese Methode entgegen. Moderne Browser bieten dazu in ihrer Werkzeugleiste eine Schaltfläche („Back-Button“) an. Durch wiederholtes Betätigen werden die zuvor besuchten Webseiten wieder angezeigt. Da die Browser deren Inhalte meistens in einem Cache gespeichert haben, müssen sie nicht einmal mehr aus dem Web übertragen werden, sondern sind sofort präsent. Eine interessante Ergänzung in diesem Zusammenhang ist die Geschwisterschaltfläche „Forward-Button“. Diese Funktion ist dann verfügbar, wenn ein Backtracking gestartet wurde. Sie ermöglicht das erneute Vorwärtsblättern, also gewissermaßen ein Backtracking zum Backtracking.

Während einfaches Backtracking dem Anwender hilft, um aus Hypertext-Sackgassen schnell und intuitiv wieder herauszufinden, dient die Historie bereits besuchter Inhalte eher der gezielten Neuorientierung. Moderne Browser machen die gespeicherte Historie über eine Sidebar, über Menüs oder über einen separaten Dialog zugänglich. Der Anwender kann sich die Titel gespeicherter Inhalte nach Besuchszeit oder nach Kriterien wie Domain-Namen sortieren lassen. Wie viele Daten oder welcher Zeitraum in der Historie gespeichert wird, ist einstellbar. Der Anwender kann die gesamte Historie außerdem jederzeit löschen.

Lesezeichen/Bookmarks/Favoriten

Ein Sachbuch ohne Inhaltsverzeichnis würde von den meisten Lesern mit gutem Recht als schwer zugänglich empfunden. Das Bedürfnis, sich über ein Inhaltsverzeichnis zu orientieren, besteht bei Hypertext-Inhalten ebenso. Für umfangreiche Hypertext-Angebote kann es jedoch nicht „das eine“ Inhaltsverzeichnis geben. Zur Grundausstattung einer ordentlichen Hypertext-Software gehört daher die Möglichkeit, sich ein eigenes, auf persönliche Interessen zugeschnittenes Inhaltsverzeichnis einzurichten.

Lesezeichen, Bookmarks oder auch Favoriten, wie sie je nach Software genannt werden, bestehen als Dateneinheit aus mindestens zwei Feldern: der Adresse eines Hypertext-Inhalts, und einem Titel, unter dem der Eintrag aufgelistet wird. Einige moderne Browser erlauben es darüber hinaus, Kurzbeschreibungen zu den Einträgen zu bearbeiten.

Da die meisten Anwender in der Praxis sehr schnell sehr viele Lesezeichen setzen, würde eine einfache Liste bald unübersichtlich. Deshalb werden die Lesezeichen heute in aller Regel in frei bearbeitbaren Verzeichnissstrukturen gespeichert, ähnlich wie Dateien im Verzeichnisbaum eines Datenträgers. Durch die Speicherform einer Verzeichnisstruktur lässt sich die Lesezeichenfunktion bei ordentlicher Verzeichnispflege tatsächlich wie ein persönliches Inhaltsverzeichnis nutzen. Für die meisten Web-Anwender ist das Lesezeichenverzeichnis ihres Browsers längst zum Standardinstrument geworden, um sich im Web zu orientieren. Ein Lesezeichenverzeichnis bewahrt auch vor Lost-in-Hyperspace-Gefühlen, da es jederzeit eine für den Anwender vertraute Möglichkeit der Neuorientierung bietet.

Da Lesezeichen mit dem Konnotat „hier halte ich mich gerne auf“ (daher auch die Bezeichnung „Favoriten“ im Internet Explorer) besetzt sind, sind sie nicht nur für den Benutzer interessant, der das Lesezeichen gesetzt hat. Webangebote wie del.icio.us oder basieren auf der Idee, dass Benutzer ihre Lesezeichen einfach online speichern. Der Anreiz für die Benutzer besteht darin, dass sie bei dieser Speicherart von überall auf ihre Lesezeichen zugreifen können. Aus dem gemeinsamen Pool aller Lesezeichen entsteht eine Art Web-Verzeichnis. Neben Titel, Zieladresse und Kurzbeschreibung erhalten die Lesezeichen dabei außerdem sogenannte Labels oder Tags, also Stichwörter. Indem alle Benutzer davon Gebrauch machen, wird Gemeinschaftliches Indexieren betrieben.

Verzeichnisse, Feeds und Software-Agenten

Wie gut ein persönliches Lesezeichenverzeichnis ist, hängt davon ab, wie viel der Anwender, der es pflegt, im Inhaltsangebot bereits entdeckt hat. Ein Lesezeichenverzeichnis dokumentiert letztlich immer, was der Anwender bereits kennt. Ebenso wichtig sind jedoch inhaltliche Übersichtsformen, die der Anwender nicht selber pflegt, und die ihm neue, bislang unbekannte Inhalte erschließen helfen.

Die klassische Form „allgemeingültiger“ Web-Inhaltsverzeichnisse repräsentierten in den Anfangsjahren des Webanbieter wie Yahoo. Eine frühere Version der Yahoo-Startseite zeugt noch vom ursprünglichen Charakter eines allgemeinen Linkverzeichnisses. Die gegenwärtige Version der gleichen Seite zeigt dagegen, dass dieser Anspruch aufgegeben wurde. Auch ehemals in diesem Bereich konkurrierende Services wie Excite, Lycos oder Web.de haben sich längst davon verabschiedet, primär ein allgemeines Verzeichnis für andere Inhalte zu sein. Die Gründe dafür sind vielfältig. Einerseits sind all diese Services kommerziell orientiert und mussten nach Wegen suchen, um profitabel zu sein. Weitere Gründe für das Sterben der klassischen, redaktionell gepflegten Web-Verzeichnisse ist die schiere Masse an Inhalten im Web, das häufige Wechseln von Inhalten zu anderen Domains, sowie Pseudo-Inhalte, die beispielsweise nur Wikipedia-Inhalte kopieren.

Vielversprechender sind aus gegenwärtiger Sicht Inhaltsübersichten, die nicht mehr redaktionell zustande kommen, sondern durch Software-Prozesse. Ein Beispiel für diese Repräsentationsform sind die immer erfolgreicher werdenden Newsfeeds (RSS- oder Atom-Feeds). Die Aktivität des Anwenders beschränkt sich bei Newsfeeds darauf, News-Kanäle zu Themen, die ihn interessieren, zu abonnieren. Die Schlagzeilen und manchmal auch Anlesertexte der News eines abonnierten Kanals bekommt der Anwender dann automatisch und aktuell aufgelistet.

Die nächste Ausbaustufe auf dem Weg zu generierten Inhaltsübersichten sind Software-Agenten. Während die Crawler, Spider und Robots großer Suchmaschinen bereits ausgereifte Typen dieser Software-Gattung sind, führen Software-Agenten, die von Endanwendern gestartet werden, noch eher ein Schattendasein. Es ist jedoch absehbar, dass sich dies ändern wird.

Generierte Inhaltsübersichten lassen sich ähnlich wie Lesezeichenverzeichnisse in die Benutzeroberfläche eines Browsers integrieren. Sie bieten dem Anwender ein weiteres, ebenso wichtiges Mittel zur Rück- und Neuorientierung wie die persönlichen Lesezeichen.

Homepages/Startseiten

In den Anfängen des Web hatten vor allem Universitätsangehörige Zugang zum Web. Viele von ihnen hatten zugleich auch die Möglichkeit, auf den Universitätsservern unterhalb eines persönlichen Verzeichnisses eine eigene Homepage zu speichern. Obwohl diese Homepages öffentlich zugänglich waren, dienten sie in vielen Fällen nur dazu, persönliche Links ähnlich wie in Lesezeichenverzeichnissen zu sammeln. Nicht wenige Benutzer legten im Inhalt ihrer Homepage einfach den HTML-Inhalt der vom damals dominanten Netscape-Browser generierten Datei bookmarks.html ab. Im Browser als Startseite eingestellt, ermöglichten sie dem Homepage-Besitzer über den „Home-Button“, der wie der Back-Button zum Ur-Repertoire aller Web-Browser gehört, die schnelle Neuorientierung über eine vertraute Startseite.

Auch heute noch haben zahlreiche Anwender eine persönliche Startseite im Browser eingestellt. In Firmen und Organisationen ist das meistens die Einstiegsseite des Intranets. Wieder andere Anwender nutzen personalisierte Startseiten bei Services wie Netvibes, Google oder GMX als persönliche Startseite. Manch einer baut sich auch seine eigene lokale Homepage oder landet beim Start auf den Home-Button im Familien- oder Wohngemeinschafts-Wiki.

Eine persönliche Startseite im Browser kann also alles Mögliche sein. Doch sie will mit Bedacht gewählt sein. Denn der Klick auf den Home-Button ist bei drohendem Lost-in-Hyperspace-Gefühl oft die spontane Panikreaktion, weil der Anwender dadurch sofort wieder in seiner vertrauten Umgebung landet. Die Startseite und das unmittelbar daran angeschlossene Angebot tragen also wesentlich dazu bei, was ein Anwender vom Web zu sehen bekommt, und wie er sich im Web orientiert.

Verweise

Hypertext-Software wie etwa moderne Web-Browser bieten eine Menge Funktionen an, die dem Anwender jederzeit eine Neu- oder Rückorientierung ermöglichen. Innerhalb eines Hypertextangebots darf ein Anwender jedoch auch erwarten, dass projektinterne Möglichkeiten zur Neu- und Rückorientierung angeboten werden. Der Schlüssel dazu sind projektinterne Verweise (Hyperlinks), die eine bestimmte Funktion übernehmen.

Navigationsverweise

Navigationsverweise sind Verweise, die sich in unterschiedlichen Inhaltseinheiten wiederholen und dadurch aus Sicht des Anwenders „zuverlässig verfügbar“ sind. In der Regel wird eine Navigation aus einer Reihe von Verweisen gebildet. Das Verweis-Set einer Navigation ist als eigener Block vom eigentlichen Inhalt einer Inhaltseinheit gut erkennbar getrennt. Die darin enthaltenen Links stehen nicht im Kontext der gerade aufgerufenen Inhaltseinheit, sondern im Kontext des gesamten Hypertextangebots.

Im Ur-Konzept von Hypertext sind Navigationslinks nicht vorgesehen. Dort gibt es nur Inhalte und Links zu anderen Inhalten, also reine Assoziation zwischen Inhalten. Dieses Konzept ist jedoch zu radikal und überfordert die Anwender. Das Konzept der Inhalts-Navigation zusätzlich zu den rein assoziativen, kontextabhängigen Links im Inhalt hat sich in der Hypertext-Praxis als erfolgreicher erwiesen.

Die Hypertext-Praxis, besonders die mittlerweile zahlreich gesammelte Praxis bei Webseiten, hat auch verschiedene Arten von Navigationen hervorgebracht. So lassen sich beispielsweise statische Navigationen und dynamische Navigationen unterscheiden. Statische Navigationen bestehen aus immer den gleichen Verweisen in der gleichen Anordnung. Dynamische Navigationen haben zwar einen wiedererkennbaren Aufbau, doch können die angebotenen Verweisziele wechseln. Statische Navigationen eignen sich als Hauptnavigation, um zentrale Übersichten jederzeit aufrufen zu können. Dynamische Navigationen treten dagegen in Formen wie dem sogenannten Breadcrumb-Pfad („Brotkrümelpfad“), in Form von Vor/Zurückblätter-Leisten oder in Form spezieller Listen (dem Inhalt zugeordnete Kategorien, oder „andere Inhalte, die hierhin verlinken“).

Auf modernen Websites sind Navigationen längst nicht mehr wegzudenken. Obwohl sie technisch nicht anders als assoziative Verweise im Text realisiert werden, haben sie auf den Anwender eine völlig andere Wirkung. Zur Kunst des guten Webdesigns gehört deshalb auch, dem Anwender Navigationsbereiche als solche deutlich erkennbar zu machen. Die Navigation gibt ihm Halt und hilft ihm, sich eine Vorstellung vom Gesamtangebot der Website zu machen.

Verweise im Inhalt

Auch Verweise im Inhalt lassen sich so anordnen oder gestalten, dass sie dem Anwender mehr Orientierung bieten. So hat sich die erkennbare Unterscheidung von Links zu externen Zielen und Links zu projektinternen Zielen als sinnvoll erwiesen. Gerade weil moderne Websites sehr unterschiedlich gestaltet sind, zwingt ein externer Link den Anwender in der Regel zu einer kompletten Neuorientierung. Das ist er zwar beim Surfen im Web gewohnt, aber dennoch profitiert er davon, wenn er bereits vor dem spontanen Ausführen eines Links darüber in Kenntnis gesetzt wird, dass das Verweisziel vermutlich eine Neuorientierung erfordert. Das Gleiche gilt für Verweise, die zu Inhalten führen, die nicht im Browser angezeigt werden können, sondern für die der Browser eine externe Anwendung starten muss, oder die er nur zum Download anbieten kann.

Problematisch ist weiterhin eine zu starke Anhäufung von Verweisen mitten im Text. Es stört das Textverständnis immens, wenn jedes zweite Wort eines Satzes anklickbar ist. Eine mögliche Lösung besteht darin, die Verweise in einen vom Text separierten, aber immer noch in seiner Nähe platzierten Bereich auszulagern.


Freitag, 25. Mai 2007

Studie zur Online-Werbung

Mit Werbung vollgemüllte Webseiten mag niemand, und noch weniger mögen Webanwender Seiten, deren Inhalte erst mal von großformatigen Werbe-Layern überdeckt werden. Gegen leicht erkennbare Formen von Werbung, wie Banner in Standardgrößen oder Popup-Fenster sind die meisten Anwender ohnehin längst gerüstet, indem sie Browser oder Zusatz-Tools verwenden, die dafür sorgen, dass solche Werbung gar nicht erst angezeigt wird. Wer Werbung auf Webseiten schaltet, weiß auch, dass die Klickraten seit Jahren immer stärker zurückgehen. Die Anwender haben einfach gelernt, nicht gedankenlos auf alles zu klicken, was bunt und auffällig ist.

Google probiert mit AdSense einen anderen Weg aus: möglichst dezente, textbasierte und thematisch zum jeweiligen Inhalt passende Werbung soll Verärgerung auf der Anwenderseite und zu hohe Streuung aus Sicht der Werbetreibenden vermeiden. Doch nun berichtet ein Telepolis-Artikel mit dem provokanten Titel Je mehr Online-Werbung, desto besser über eine amerikanische Studie zum Thema. Xiang Fang (Oklahoma State University), Surendra Singh (University of Kansas) und Rohini Ahluwalia (University of Minnesota) wollen herausgefunden haben, dass Werbung um so besser wirkt, je weniger sie bewusst wahrgenommen wird, und je häufiger sie auf diese Weise von der bewussten Aufmerksamkeit missachtet wird.

Nun ist das eigentlich keine besonders neue Erkenntnis. Dass Werbung nicht aufs Bewusstsein zielt, ist ein alter Hut, und dass von Immerwiederwerbung mehr hängen bleibt als von Einmalwerbung, ebenfalls. Neu ist eher, dass damit auch behauptet wird, Klickraten seien gar kein geeignetes Instrument zur Messung für den Erfolg von Werbung. Im Grunde würden also langweilige 100 mal 100 Pixel-Flächen genügen, die gar nicht als Link fungieren, und die einfach nur immer die gleichen langweiligen Sprüche, Symbole und Markennamen transportieren, und das aber, egal wohin im Web man kommt.

Anwender sollten ja gar nicht auf die Werbung achten, Werbende müssten sich nicht viel Neues einfallen lassen, und Anbieter von Webseiten müssten sich nicht mehr um Klickraten bemühen. Eine praktische Rechnung, die da mit akademischer Absicherung aufgehen soll. Das Ganze würde dann ziemlich genau so aussehen wie bei Telepolis selbst in der rechten Layout-Spalte, die mir eigentlich jetzt gerade erst aufgefallen ist ...


Montag, 21. Mai 2007

All good things

Alle guten Dinge gibt es völlig frei zugänglich — bei YouTube. Wer es nicht glaubt, suche beispielsweise mal nach Pop-Abräumerin Nelly Furtado / „all good things“ und staune. Von offiziellen Videos bis hin zu Live-Mittschnitten und iTunes-Sessions reicht das Repertoire allein zu diesem einen Song. Den Hit hat ja wohl jeder schon mal gehört, und ob man ihn nun mag oder nicht, ist eigentlich egal. Denn mit anderen Hits und bekannten Musikern funktioniert das bei YouTube genauso. Und beileibe nicht nur mit aktuellen oder früheren Hits. Egal ob man auf Krautrock mit Guru Guru steht oder nach einem von der Plattenindustrie längst vergessenen Songwriter wie Stephen Bishop sucht — YouTube überrascht immer wieder.

Da drängt sich natürlich die Frage auf, wie legal das alles ist. Eine geeignete Lektüre dazu ist vielleicht der Telepolis-Artikel Napster, Audiogalaxy, Soulseek, YouTube. Dort heißt es: „Wer in Deutschland etwas zu sagen hat, der sagt es im Zweifelsfall lieber dort, wo deutsche Abmahnanwälte keinen Zugriff haben – das gilt für Blogs ebenso wie für Musikwerke in Video-Plattformen. Die amerikanische Rechtslage gewährt nämlich aufgrund der Fair Use Doktrin nicht nur bezüglich der Legalität von Mashups, sondern auch für das Einstellen von Clips allgemein wesentlich mehr Freiraum als die deutsche. Von daher überrascht es nicht, dass YouTube auch hierzulande die unangefochtene Nummer Eins ist und dass MyVideo ebenso wie Clipfish hauptsächlich Anhängsel von Formaten ihrer Sender blieben.

So etwas wie Fair Use mag das deutsche Recht wohl niemandem unterstellen — da geht man lieber gleich von böswilligen Betrugsabsichten und Urheberrechtsverletzungen aus. Doch wieder mal sehen wir ein Beispiel dafür, wie sich im Internet dank seiner Internationalität stets die freizügigste Variante durchsetzt. Allenfalls mit Web-Zensur ist diese Gesetzmäßigkeit verhinderbar. Derzeit wird staatliche Web-Zensur vorwiegend noch aus politischen Gründen verordnet. Doch wenn sich Industrien in ihren gewohnten Rechten („kauf zuerst und guck dann was drin ist“) bedroht sehen, könnte der Druck auf Regierungen wachsen, Web-Zensur auch aus zivilrechtlichen Gründen zu betreiben. Sollte Nelly Furtado also Recht behalten mit der traurigen Frage „why do all good things come to an end?“, oder sind wir letztlich doch auf dem langsamen und für Medien- und Plattenkonzerne sicher schwierigen Weg dahin, dass Musik, Bücher, Fachartikel und andere Inhalte mit Schöpfungshöhe nicht mehr ihre Domaine sind?

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
zum Blog-Eintrag: all-good-things


Samstag, 19. Mai 2007

Das Web aus Sicht von Google

So sieht es angeblich aus, das Web aus Sicht von Google. Zumindest berichtet dies das Google Operating System Blog im Eintrag The World Wide Web, as Seen by Google.

Sonderlich unbekannt wirkt das Schaubild eigentlich nicht. Vielleicht, weil es irgendwie an Eiskristalle oder Fraktale erinnert?

Bei genauerem Nachdenken ist die Grafik aber doch recht schief. Denn eigentlich schwebt Google ja nicht wie ein altbackener Gottvater über dem Netz, sondern ist ein Teil davon. Will sagen: auch Google sieht das Web nicht anders als ein Web-User, sondern nur mit viel gewaltigerer Datengefräßigkeit und mit notorischem Desinteresse am Verweilen, wie es Crawler halt so an sich haben. Demnach müsste es also irgendwo eine alles ermöglichende Sonne auf der Grafik geben, die erst einmal ihre Strahlen aussendet — das Ego von Google nämlich.

Etwas anders würde die Sache bei neueren Fütterungskonzepten für Suchmaschinen aussehen, also etwa bei Social-Bookmark-Services wie Mr. Wong oder Delicio.us, oder bei Services, die mit Hyperlink-Symbionten operieren, also etwa snap.com. Bei solchen Services wäre das Web aus ihrer Sicht eher etwas, von woher Strahlen kommend eintreffen und in einem anderen Winkel am eigenen Korpus abprallen — natürlich nicht, ohne von der eigenen Suchdatenbank erfasst worden zu sein.

Die Vogelperspektivenbilder vom Netz jedenfalls, auf denen dieses wie das Finale eines Feuerwerks oder wie ein sichtbar gemachtes Knäuel aus Synapsen und Verbindungskanälen aussieht — solche Bilder sind eigentlich nur für „Außernetzische“.


Freitag, 18. Mai 2007

Tutorial: Ajax (5)

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?


Ein einfacher Ajax-Kernel

Die Ajax-Schnittstelle selbst ist vergleichsweise überschaubar. Das XML-HTTP-Objekt lässt sich, wie bereits beschrieben, mit einer kleinen Browserweiche zuverlässig in allen modernen Browsern initialisieren. Die Aufgabe des Objekts besteht darin, HTTP-Requests an den Webserver abzusetzen und nachfolgende HTTP-Responses vom Webserver zu empfangen. Es bietet sich daher an, diese Aufgabe in eine kleine, wiederverwendbare Code-Bibliothek (die wir den „Ajax-Kernel“ nennen wollen) zu packen.

Die Funktionen

Für unsere einfachen Beispiele und für viele Anwendungsfälle in der Praxis genügt der nachfolgend vorgestellte Ajax-Kernel. Je nach Aufgabenstellung können komplexere Varianten dieses Kernels erforderlich werden. Beispielsweise dann, wenn POST-Daten über die Ajax-Schnittstelle an den Webserver übertragen werden sollen (unser Beispiel-Kernel sendet nur GET-Requests).

Eine Möglichkeit besteht darin, den nachfolgenden Code in einer eigenen JavaScript-Datei zu speichern – nennen wir sie ajax.js:

var httpRequest = false;
var noResult = "Kein Ergebnis";

// ===================================

function doHttpRequest(url, outputId) {
   httpRequest = false;
   if(window.XMLHttpRequest)  // Mozilla, Safari,...
       httpRequest = new XMLHttpRequest();
   else if(window.ActiveXObject) { // IE
       try {
           httpRequest = new ActiveXObject("Msxml2.XMLHTTP");
    }
       catch (e) {
           try {
               httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
     }
           catch (e) {}
       }
   }
   if(!httpRequest) 
      return false;
   httpRequest.onreadystatechange = function() {
      if(httpRequest.readyState == 4) {
         if(httpRequest.status == 200) 
            handleHttpResponse(httpRequest.responseText, outputId);
       else
          return false;
         }
    else
       return false;
   } 
   httpRequest.open('get', url, true);
   httpRequest.send(null);
}


function handleHttpResponse(content, outputId) {
   if(!document.getElementById)
      return false;
   if(!document.getElementById(outputId))
   return false;
   if(content == "FALSE")
      document.getElementById(outputId).innerHTML = noResult;
   else
      document.getElementById(outputId).innerHTML = content;
} 

Um die Funktionsweise des XML-HTTP-Objekts zu verstehen, ist es allerdings wichtig, entscheidende Details aus diesem Code zu verstehen.

Der Code besteht aus zwei Funktionen:

  • Die Funktion doHttpRequest() ist die zentrale Steuerfunktion. Sie wird von anderem JavaScript-Code, der den Ajax-Kernel verwenden möchte, aufgerufen.
  • Die Funktion handleHttpResponse() ist eine interne Funktion, die nur von doHttpRequest() aufgerufen wird.

Zu Beginn des Ajax-Kernels werden ferner zwei globale Variablen definiert:

  • Die Variable httpRequest speichert eine Instanz des XML-HTTP-Objekts. Sie wird mit dem booleschen Wert false initialisiert.
  • Die Variable noResult wird mit einem Text initialisiert, der ausgegeben werden soll, wenn eine Ajax-Operation keine Daten vom Server erhält.

Die Funktion doHTTPRequest()

Die Funktion doHTTPRequest() erwartet zwei Parameter:

  • url ist die vollständige URL-Adresse eines Scripts auf dem Webserver, das über Ajax aufgerufen werden soll. Dieses Script — es kann sich beispielsweise um ein PHP-Script handeln — kann beispielsweise Daten aus einer Datenbank auslesen, in HTML-Form aufbereiten und diesen aufbereiteten HTML-Code zurückgeben.
  • output_id ist der id-Attributwert eines HTML-Elements im aktuell im Browser angezeigten HTML-Dokument. In dieses Element wird der HTML-Code, den das mit url bezeichnete Script erzeugt, dynamisch eingebaut — und genau dadurch entsteht der Effekt, den Ajax ausmacht.

Den ersten Teil der Funktion doHTTPRequest() kennen Sie bereits. Mittels einer geeigneten Browser-Weiche wird eine Instanz des XML-HTTP-Objekts erzeugt, was praktisch in allen modernen Browsern gelingt.

Der neue Teil beginnt mit httpRequest.onreadystatechange = function(). Allein dieses Konstrukt ist jedoch sehr erklärungsbedürftig.

onreadystatechange sieht aus wie eine Eigenschaft des XML-HTTP-Objekts. Das Präfix on... signalisiert jedoch, dass es sich um einen Event-Handler handelt, also um ein Ereignis, bei dessen Eintreffen etwas Bestimmtes geschehen soll. Deshalb wird dieser Eigenschaft auch kein einfacher Wert wie eine Zahl oder eine Zeichenkette zugewiesen, sondern eine Prozedur, die bei Eintreffen des Ereignisses ausgeführt werden soll. Die Prozedur wird eingeschlossen in:

   httpRequest.onreadystatechange = function() {
      // hier der Code der Prozedur
   }

Mit function() wird eine unbenannte Funktion aufgerufen, die man sich als eine mehrfach aufrufbare Subroutine innerhalb der Funktion doHTTPRequest() vorstellen muss. In unserem Fall lautet der Code innerhalb der Prozedur:

      if(httpRequest.readyState == 4) {
         if(httpRequest.status == 200) 
            handleHttpResponse(httpRequest.responseText, outputId);
       else
          return false;
         }
    else
       return false;

readyState ist eine „echte“ Eigenschaft des XML-HTTP-Objekts. In der Eigenschaft wird in Form eines Integer-Werts gespeichert, in welcher Phase sich eine aktuelle, vom XML-HTTP-Objekt gestartete HTTP-Kommunikation befindet. Mögliche Werte sind 0 bis 4. Eine vollständige HTTP-Kommunikation durchläuft nacheinander alle fünf Werte:
0 ist einfach der Anfangswert.
1 bedeutet, dass die HTTP-Verbindung zum Webserver erfolgreich zustande kam.
2 bedeutet, dass der HTTP-Request vollständig übertragen wurde.
3 bedeutet, dass die HTTP-Header der Server-Antwort empfangen wurden.
4 bedeutet, dass die Server-Antwort komplett übertragen wurde.

Der Event-Handler onreadystatechange bewirkt, dass bei jeder Änderung des Werts von readyState die Prozedur, die onreadystatechange zugewiesen ist, erneut ausgeführt wird. Innerhalb der Prozedur könnten wir also auf jede genannte Phase der HTTP-Kommunikation mit Script-Code reagieren. Im Beispiel reagieren wir jedoch nur auf die letzte Phase, nämlich mit if(httpRequest.readyState == 4). Die übrigen Phasen werden durch durch else return false ignoriert.

Wenn readyState den Wert 4 hat, ist also die HTTP-Kommunikation abgeschlossen und der Webserver hat seine Antwort auf eine Anfrage gesendet. Um die Antwort auszuwerten, ist es zweckmäßig, zunächst den HTTP-Statuscode der Server-Antwort auszulesen. Dieser ist in der Eigenschaft status des XML-HTTP-Objekts gespeichert. In unserem Beispiel erwarten wir für den „Gutfall“ den HTTP-Status-Code 200. Dieser Code bedeutet, dass der Server den HTTP-Request erfolgreich bearbeiten konnte und die angeforderten Daten senden konnte.

Auf den HTTP-Status-Code 200 reagieren wir mit einem Aufruf der zweiten Funktion unseres Ajax-Kernels: handleHTTPResponse(), auf die wir weiter unten noch näher eingehen werden. Der Funktion werden zwei Parameter übergeben, nämlich die vom Webserver erhaltenen Nutzdaten, sowie den id-Attributwert eines Elements im aktuell angezeigten HTML-Dokument, innerhalb dessen die Daten ausgegeben werden sollen. Was letzteres betrifft, so reichen wir den Parameter outputId einfach durch.

Die eigentlichen Daten übergeben wir mit einer weiteren Eigenschaft des XML-HTTP-Objekts, nämlich httpRequest.responseText. Diese speichert die vom Web­server erhaltenen Nutzdaten als normale Zeichenkette. Wenn also beispielsweise ein über Ajax aufgerufenes PHP-Script auf dem Server HTML-Code generiert und zurückgibt, ist in der Objekteigenschaft responseText dieser HTML-Code enthalten.

Die beiden letzten Anweisungen der Funktion doHttpRequest() sind einigermaßen verständlich. Mit httpRequest.open('get', url, true) wird die Methode open() des XML-HTTP-Objekts aufgerufen. Diese Methode setzt einen HTTP-Request an den Server ab. Als erster Parameter wird die Request-Methode angegeben. In unserem Fall ist das die GET-Methode. Der zweite Parameter übergibt die URL-Adresse, an die der HTTP-Request gehen soll. Der dritte Parameter ist ein true-false-Wert. Wenn auf true gesetzt (was auch die Default-Einstellung ist), wird die JavaScript-Funktion weiter ausgeführt, auch wenn noch keine Server-Antwort vorliegt. Wenn auf false gesetzt, wartet JavaScript mit der Ausführung der weiteren Anweisungen so lange, bis die Server-Antwort vorliegt. Die Funktion ist also in unserem Fall eigentlich längst beendet, wenn die Antwortdaten vom Webserver eintreffen. Um sie dennoch abzufangen, haben wir zuvor die Ereignisbehandlung für onreadystatechange definiert.

Mit httpRequest.send(null) wird dem Server mitgeteilt, dass außer dem Request selber kein Daten an den Server gesendet werden. Falls dem aufzurufenden Script auf dem Server Daten übergeben werden sollen, können Sie anstelle von null einen Query-String übergeben, der nach den dafür üblichen Regeln aufgebaut ist, also z.B.:

httpRequest.send("name=value&another_name=another_value");

Die Funktion handleHttpResponse()

Die Funktion handleHttpResponse() erwartet zwei Parameter:

  • content ist eine beliebige Zeichenkette, die Text bzw. HTML-Code enthalten sollte.
  • output_id ist der id-Attributwert eines HTML-Elements im aktuell im Browser angezeigten HTML-Dokument. In dieses Element wird der HTML-Code, der mit content übergeben wird, dynamisch eingebaut.

Die Funktion dient wie schon erwähnt nur als Subroutine für die Ajax-Kernel-Hauptfunktion doHTTPRequest(). Beim Parameter content besteht zusätzlich die Möglichkeit, anstelle einer Zeichenkette den Booleschen Wert false zu übergeben. In diesem Fall setzt die Funktion als Inhalt des mit outputId bezeichneten Elements den Inhalt der globalen Variablen noResult ein, die zu Beginn des Kernel-Scripts initialisiert wurde.


Mittwoch, 16. Mai 2007

Bloggen lernen

Mit etwas spekulativer Zahlenkunst hat Popkulturjunkie Jens Schröder in seinem Blog-Eintrag wie viele deutschsprachige blogs gibt es? neulich etwa 70 Millionen Blogs weltweit und etwa 600.000 deutschsprachige Blogs ausgemacht, von denen etwa 27.000 regelmäßig gepflegt werden. Wie auch immer die tatsächlichen Zahlen lauten mögen: immer mehr Zeitgenossen wagen sich selbst daran, ein Weblog zu führen. Und von denen, die sich nicht so recht trauen, zögern nur deshalb viele, weil sie nicht so recht wissen, wie und wo sie mit dem Bloggen anfangen sollen, was es zu beachten gibt, wie man beachtet wird, was man alles kennen sollte usw.

Ein praxisorientierter Anlaufpunkt für Fragende ist die Weblog FAQ von Stefan Bucher. Auf einer einzigen Webseite lassen sich natürlich nicht alle Aspekte der Blogosphäre erschöpfend behandeln. Doch welcher gewillte Einsteiger will schon Erschöpfendes und Erschlagendes? Wichtige Fragen werden in der Weblog FAQ jedenfalls erst einmal beantwortet, und eine bewältigbare Menge Links zu weiteren Informationsquellen ist inklusive.

Wer lieber etwas theoretischer an die Sache herangehen möchte, kann dazu durchaus den Weblog-Artikel von Wikipedia als Startrampe verwenden. Der Artikel enthält nicht nur zahlreiche Wikipedia-interne Links zu spezielleren Aspekten des Bloggens, sondern auch eine überschaubare, gut sortierte Liste mit Weblinks. Darunter auch Links zu Artikeln namhafter Publikationsorgane, die sich mit dem Bloggen auseinandersetzen.

Der willige Einsteiger und der neugierige Skeptiker erfahren aus all diesen Quellen, dass Bloggen extrem angesagt ist, dass man entweder bei einem Fremd-Hoster sofort mit dem Bloggen anfangen oder auf eigenem Webspace unter eigener Domain eine Weblog-Software installieren kann. Das gängige Fach-Chinesisch wie Permalink, Trackback oder Blogroll wird erläutert, und auch Tipps zum richtigen Verhalten innerhalb der Blogosphäre kommen nicht zu kurz.

Ein Aspekt wird allerdings gerne verschwiegen: die erforderliche Ausdauer. Ein Blog ist ähnlich bedürftig wie ein Tamagotchi. Es will über einen langen Zeitraum hinweg gefüttert und gereinigt werden, darf auch mal ruhen und verlangt dann aber plötzlich wieder die ganze Aufmerksamkeit. In dem eingangs erwähnten Zahlenspiel von Jens Schröder spricht das Verhältnis von 27.000 regelmäßig gepflegten gegenüber 600.000 jemals eingetragenen Blogs eine deutliche Sprache. Nicht einmal 5% aller irgendwo erreichbaren Blogs sind demnach als lebendig zu betrachten.

Wenn Sie sich also mit dem Gedanken ans Bloggen tragen und die Einsamkeit des Langstreckenläufers atmen, dann mögen Ihnen die folgenden Links vielleicht noch weitere Erkenntnisse mit auf den Weg geben:

lernen und lehren mit Weblogs: Bloggen Sie auch?
Ausführliches und anschaulich vermitteltes Wissen rund ums Bloggen in deutscher Sprache.

So vielseitig sind Weblogs: Bloggen für „Noch-Nicht-Blogger“
Eine Einführung in die Welt des Bloggens von der bekannten Content-Schmiede akademie.de

Abseits.de: Weblogs
Prall gefülltes Informationspaket rund ums Bloggen, gespickt mit zahlreichen weiterführenden Links


Dienstag, 15. Mai 2007

Hypertext (4): Suchen und Stöbern

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


Information Retrieval: an Informationen kommen

Der Ausdruck Information Retrieval bedeutet aus Anbietersicht die Art, wie Information zugänglich gemacht werden soll, und aus Anwendersicht die Art, wie Information zugänglich ist. Im Prinzip lassen sich dabei zwei grundsätzliche Verfahrensweisen unterscheiden: die eine ist das gezielte Suchen nach bestimmten Daten oder einer bestimmten Information, und die andere ist das Stöbern in einem Informationsangebot.

Die klassische Datenverwaltung setzt beim Information Retrieval eher auf das Suchen. Größere herkömmliche Anwendungen, egal ob in Versicherungen oder beim Arbeitsamt, bieten ihren Anwendern typischerweise mehr oder weniger ausgefeilte Suchmasken an. Aus den Eingaben der Maske wird eine Abfrage der Datenbank erzeugt. Die Datenbank sendet eine Ergebnismenge an gefundenen Daten zurück. Diese Ergebnisse werden dem Anwender angezeigt.

Hypertext unterstützt von Haus aus eher das Stöbern. Nicht zufällig lautet das englische Wort für Stöbern to browse. Die Standard-Zugangssoftware für das World Wide Web, also die Web-Browser, sind also namentlich Stöberprogramme.

Vor- und Nachteile von Suchen und Stöbern

Die Vor- und Nachteile beider Formen des Information Retrieval hängen in erster Linie vom jeweils verfolgten Ziel ab. Suchen ohne einsteigendes Informationsangebot ist dann von Vorteil, wenn man genau weiß, wonach man sucht. Wer am kommenden Freitag mit der Bahn von Hamburg nach München fahren will und eine Zugverbindung sucht, dem ist mit einem geeigneten Suchformular am schnellsten geholfen. Stöbern ist dagegen von Vorteil, wenn man nur ungefähr weiß, wonach man sucht. Wer einen Ausflug plant und noch nicht so recht weiß wohin, dem hilft kein Suchformular. In solchen Fällen ist es besser, über ein hinführendes Informationsangebot auf Entdeckungsreise nach Angeboten zu gehen.

Nun können suchorientierte Angebote durchaus helfen, ungefähre Vorstellungen zu präzisieren. Wer im Web eine Partnerbörse aufsucht, kann über zahlreiche Multiple-Choice-Fragen Eigenschaften und Vorlieben seines Wunschpartners zusammenklicken und so die Ergebnismenge eingrenzen. Dennoch ist man bei suchorientierten Angeboten von der eigentlichen Information zunächst einmal abgeschirmt. Erst eine wohlformulierte Suche fördert eine Ergebnismenge aus dem eigentlichen Inhalt zu Tage. An der Formulierung der Suche führt kein Weg vorbei. Dazu sind Dialoge mit dem Anwender erforderlich, die meistens als Formulare realisiert sind.

Stöbern führt dagegen oft zu ganz anderen Ergebnissen bei dem, was ein Anwender am Ende auswählt, konsumiert oder tut. In Web-Angeboten, die zum Stöbern einladen, wählt man zwanglos einen Einstieg und lässt sich ebenso zwanglos durch weitere Links leiten. Durch ein paar Links gelangt man zu konkreter Information. Diese wiederum enthält diverse Links zu anderer Information. Oder man orientiert sich neu. Jedenfalls befindet man sich schnell mitten im Informationsangebot. Man ist nicht getrennt von der eigentlichen Information, doch dafür droht schnell der Überblick verloren zu gehen. Das Mindeste, was man in einer solchen Situation benötigt, ist eine Navigation. Sie ermöglicht die Neuorientierung beim Stöbern.

Keine der beiden Formen des Information Retrieval ist also der Königsweg. Festzuhalten bleibt, dass die Software-Gattung der Datenbank Management Systeme (DBMS) das Paradigma des Suchens geprägt haben, während Hypertext das Paradigma des Stöberns geprägt hat.

Verschwimmende Grenzen

Im Web kommen die Paradigmen von Suchen und Stöbern häufig zusammen. Die meisten größeren Webprojekte bieten Anwendern sowohl einen stöbernden als auch einen suchenden Zugang an. Allerdings wird eine der beiden Zugangsformen meistens optisch deutlich favorisiert. Viele Websites von Zeitungen, großen Firmen oder Organisationen laden den Besucher primär eher zum Stöbern ein, da die Optik aus direkten Inhalten wie aktuellen News auf der Startseite und einer oder mehreren Navigationsleisten besteht. Dennoch wird — oft nicht auf den ersten Blick sichtbar — in aller Regel auch ein kleines Suchfeld angeboten, das eine Volltextsuche im Informationsangebot ermöglicht. Andere Projekte wiederum begreifen sich primär als suchorientiert, bieten aber zusätzlich noch eine Art Linkverzeichnis an, um Anwendern, die einen stöbernden Einstieg bevorzugen, entgegenzukommen.

Datenkonzept
Brainstorming für ein Datenhaltungskonzept — Quelle: Wikimedia

Viele Informationsangebote haben durchaus den Wunsch, Anwendern beide Formen des Information Retrievals gleichberechtigt anzubieten. in der Praxis ist das jedoch oft nicht so einfach. Der Grund dafür ist, dass die Entscheidung darüber, wie ein Angebot Informationen zugänglich macht, häufig schon im Vorfeld getroffen wird — nämlich beim Daten-Design. Aus Anbietersicht ist es deshalb wichtig, sich mit der Art, wie Informationsdaten gespeichert werden, eingehend auseinander zu setzen. Angenommen, die Nutzdaten einer Website werden in einer relationalen Datenbank gehalten. Dort gibt es beispielsweise Datenbanktabellen für Philosophen, philosophische Begriffe und Definitionen von Philosophien zu philosophischen Begriffen. In solchen Relationen ist jedoch nirgendwo festgehalten, was eine Inhaltseinheit sein soll, also etwa eine Webseite. Ein Web-Frontend könnte zwar das bequeme Durchsuchen der Datenbank ermöglichen. Doch aus den gespeicherten Daten lässt sich weder eine Navigation erzeugen noch ein Set an durchstöberbaren Webseiten. Die Inhalte einer Inhaltseinheit können durchaus dynamisch aus einer Datenbank erzeugt werden. Doch um einen stöbernden Zugang anzubieten, muss in den Datenstrukturen der Datenbank bereits das druchstöberbare Webseitenangebot abgebildet werden — in welcher Form auch immer.


Freitag, 11. Mai 2007

Neues von der Zukunft von HTML

Unter dem Titel Weiterentwicklung von HTML kommt voran ist im SELFHTML Weblog ein Beitrag erschienen, der den aktuellen Stand der Diskussionen rund um die Zukunft von HTML zusammenfasst. Auch andere Magazine berichten immer mal wieder über das Thema, so etwa der Golem-Beitrag W3C nimmt die Weiterentwicklung von HTML wieder auf.

Interessant ist, dass nun offenbar versucht wird, die drohende Spaltung zwischen W3-Konsortium und WHATWG zu vermeiden (wir berichteten). Die offene HTML-Arbeitsgruppe des W3-Konsortiums plant dem Blog-Beitrag zufolge, Teile der unter dem Code-Namen HTML 5 gehandelten Vorschläge der WHATWG in ein W3-gesegnetes HTML 5 zu übernehmen. Ein wichtiger Auslöser dazu war wohl dieses Mailinglisten-Posting von David Baron (Mozilla Foundation). Allerdings gibt es offenbar durchaus konträre Standpunkte innerhalb der offenen HTML-Arbeitsgruppe des W3-Konsortiums, sodass die letzte Entscheidung noch nicht gefallen ist.

Endlosdiskussionen kann sich die offene Arbeitsgruppe allerdings nicht erlauben. „The HTML working group has not yet begun working on a specification. While we wait for the work in the HTML working group to start, we are continuing on our work on the WHATWG specs.“ Diese Aussage auf der Startseite der WHATWG darf durchaus als Wink mit dem Zaunpfahl verstanden werden, binnen einer angemessenen Frist zu einer klaren Entscheidung in Sachen HTML zu kommen.

Hintergrund der Querelen sind vor allem die Vorstellungen des W3-Konsortiums zum propagierten Nachfolgerstandard XHTML 2.0, der zum einen in vielen Punkten nicht mehr rückwärtskompatibel zu herkömmlichem HTML und XHTML 1.x ist, und der andererseits etliche Wünsche an HTML, die im Laufe der Jahre in der Praxis entstanden sind, nicht berücksichtigt. Der Entwurf der WHATWG orientiert sich dagegen bewusst an diesen Wünschen aus der Praxis. Dazu gehören beispielsweise verbesserte HTML-Formulare im Hinblick auf die immer zahlreicher werdenden Webanwendungen, mehr Klarheit beim Einbetten von Multimedia oder die HTML-seitige Unterstützung der Ajax-Schnittstelle.


Donnerstag, 10. Mai 2007

Was ist eigentlich Identitätsmanagement?

„Als Identitätsmanagement (IM) wird der zielgerichtete und bewusste Umgang mit Identität, Anonymität und Pseudonymität bezeichnet.“ So formuliert es der Wikipedia-Artikel zum entsprechenden Begriff.

Identität im Internet ist für zahlreiche Menschen wesentlich vielschichtiger als im „RealLife“. Denn im Internet ist es viel einfacher, anonym zu bleiben oder zumindest unter einem Pseudonym aufzutreten. Dass sich mit kriminalistischen Mitteln die meisten Datenspuren auf einen konkreten Internetzugang zurückführen lassen, spielt dabei keine Rolle. Denn Anonymität und Pseudonymität spielen sich in aller Regel nicht in der Zone strafbarer Handlungen ab, sondern im Bereich des frei gestaltbaren eigenen Auftretens.

Ein angestellter Programmierer, der nicht möchte, dass sein Arbeitgeber von einem Programmierproblem erfährt, postet das Problem in einem Fachforum unter einem Pseudonym. Wer in einem Forum Rat bei einem familiären Problem sucht, ohne dass Sozial- und Jugendamt gleich Indizien sammeln können, tut ebenfalls gut daran, ein Pseudonym zu benutzen. Nun verlangen viele Services im Web, etwa entsprechende Fachforen, eine Registrierung mit E-Mail-Kontrolle. Um dem Web-Anbieter gegenüber anonym zu bleiben, bietet es sich an, sich irgendwo bei Hotmail, Yahoo, Google, GMX oder dergleichen eine kostenlose gültige Mailadresse einzurichten, die nichts mit dem eigenen Namen zu tun hat. Schon viele aktive Web-Benutzer haben sich solche Zweit- und Dritt-Mailadressen nur zu dem Zweck eingerichtet, um gegenüber Services, die eine Mailadresse erfordern, anonym zu bleiben — und an dieser Praxis ist absolut nichts Verwerfliches. Auch das Verwischen von Herkunftsspuren mittels Anonymizern wird von nicht wenigen Web-Benutzern verwendet.

Auf der anderen Seite beklagen Datenschützer, dass viele Netzaktivisten nicht nur sorglos, sondern geradezu provokativ fahrlässig Daten-Exhibitionismus betreiben — so etwa Peter Schaar im ntv-Beitrag „Elektronischer Exhibitionismus“: Versäumnisse beim Datenschutz. In der Tat verlocken viele neuere Mitmachangebote im Web zur Preisgabe persönlicher Daten, Einstellungen und damit einhergehend auch weniger charmanterer Seiten der eigenen Person.

Doch was ist denn nun wahr? Wird zu viel oder zu wenig Anonymität betrieben? Die Antwort lautet: weder noch. Und es sind nicht nur zwei Lager von Menschen (verkrampfte Paniker und schamlose Exhibitionisten), die sich da gegenüber stehen. Es sind häufig multiple Netz-Identitäten ein und derselben Person. Jemand hat beispielsweise ein völlig seriöses Profil bei Xing, unter echtem Namen ein relativ lockeres Auftreten in einem Interessens-Forum für Motorrad-Freaks und eine sorgfältig gepflegte Pseudo-Identität in einem Erotik-Chatraum. Im Grunde ist das nicht anders als im übrigen Leben auch. Jeder spielt Rollen: Geschäftspartner und Ehepartner, wilder Feten-Clown und gläubiger Gottesdienstbesucher. Jeder Mensch lernt mehr oder weniger gut, die verschiedenen Rollen seines Lebens zu spielen.

Während Rollen im Alltag jedoch häufig unwiderruflich sind (Eltern-Sein, Geldverdienen-Müssen, mit Krankheit leben), hat man im Internet eher die Wahl zwischen verschiedenen Identitäten. Dazu kommt bei der Internet-Kommunikation, dass man von den Vor- und Nachteilen direkter Fremdwahrnehmung befreit ist. Menschen leben hier durch ihre Äußerungen, und man kann intensiv kommunizieren, ohne zu wissen, wie das Gegenüber aussieht, wie alt es ist, welchen Eindruck seine Kleidung macht usw. Es ist im Netz viel einfacher, von einem Ort zu verschwinden und seine Zelte an einem anderen Ort aufzuschlagen. Eine gewisse Leichtigkeit haftet den Rollen an, die man online spielt. Eine Leichtigkeit, die von Kritikern als Unverbindlichkeit ausgelegt wird und von Befürwortern als neuartige Freiheit bei der Gestaltung der eigenen Persönlichkeit.

Zu Unverbindlichkeit und Unstetigkeit führt die größere Wahlfreiheit bei der Identitätsfindung im Internet dann, wenn diese Wahlfreiheit unreflektiert abläuft. Wer sich dagegen bewusst Gedanken macht darüber, welche Identitäten er wünscht und aufbauen will, profitiert von dem großen Gestaltungsspielraum. Identitätsmanagement im Internet ist das bewusste Planen und reflektierte Entscheiden, an welchen Orten im Netz man wie auftreten möchte. Dazu gehört auch die Entscheidung darüber, wo man als reale Person auftritt, und wo man unter einem Pseudonym agieren will. Beides ist völlig legitim — sturen Verfechtern der Realname-Ideologie sei die Pseudonymitäts-FAQ fürs Usenet ans Herz gelegt.

Eine Identität kann man jedoch nur als solche erleben, wenn man sie konsequent durchzieht und ihr über einen längeren Zeitraum treu bleibt. Flatterhaftes Wechseln von einer Identität zur nächsten ist für die Entwicklung der eigenen Persönlichkeit nutzlos. Zur Wahlfreiheit bei der Identitätsfindung gehört indessen auch, „Test-Identitäten“ aufzubauen. So kann es durchaus spannend und für die eigene Erfahrung förderlich sein, mal irgendwo den ungeliebten Advocatus diaboli zu spielen, oder sich bewusst in eine Rolle zu versetzen, die man sonst eigentlich hasst, mit der man sich aber aus irgendwelchen Gründen auseinandersetzen muss oder will. Das kann allerdings auch schiefgehen. Ein Familienvater, der sich in einem Gothic-Zirkel versucht, aber seinen hoffnungslos bildungsbürgerlichen Wortschatz nicht verleugnen kann, wird vermutlich schnell scheitern. Gerade im Einnehmen „entfernter“ Rollen liegt die größte Herausforderung — und für manch verhinderten Schauspieler der größte Reiz.

Und wo ist die Grenze zum bösartigen Identitätsschwindel? Böse Onkels, die authentisch chatten können wie Zehnjährige und versuchen, virtuelle Doktorspiele anzuzetteln oder echte Adressen und Dates zu ergattern, haben die Grenze zweifellos überschritten. Dass es diese Grenze gibt und dass sie überschritten werden kann, ist jedoch kein Gegenargument gegen bewusste Identitätsgestaltung im Netz, genausowenig, wie die Tatsache, dass es sexuelle Verbrechen gibt, ein Argument gegen Sex ist. Bewusste Identitätsgestaltung läuft im moralischen Gesamtrahmen einer Person ab, und wenn dieser nicht gestört oder zerstört ist, wird auch eine „gewählte Identität“ nicht seinen Rahmen sprengen.

Identität ist das was in sich ruht und aus sich selbst heraus wirkt. Klingt nach Esoterik-Geschwafel und Kaffee-Werbung, wird aber von namhaften Philosophen bestätigt. Entsprechend faszinierend ist die freie Identitätswahl. Es ist die freie Wahl fester Kraftpunkte im Leben. Identitätsmanagement ist also alles andere als einfach, und es ist auch kein typisches Thema für „Internet-Business 2.0“. Identitätsmanagement im Internet ist Persönlichkeitsentfaltung im Rahmen einer ungewohnten Freiheit.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Zum Blog-Eintrag: Was ist eigentlich Identitätsmanagement?


Dienstag, 8. Mai 2007

Mehr Hypertext mit Hyperwords

Wie wir in unserer Hypertext-Einführung bereits gelernt haben, besteht das entscheidende Merkmal von Hypertext eigentlich darin, dass dem Benutzer verwandte oder weiterführende Inhalte zu einer aktuellen Inhaltseinheit direkt verfügbar gemacht werden. Das klassische Mittel dazu ist der Hyperlink. Wohlgemerkt — das klassische Mittel, aber längst nicht mehr das einzige. Eine spannende Erweiterung für den Firefox-Browser mit dem Namen Hyperwords sorgt für deutlich mehr Hypertext-Feeling beim Browsen.

Langes und breites Erklären können wir uns ersparen, denn das YouTube-Video zu Hyperwords demonstriert die Funktionsweise der Erweiterung. Sie reagiert auf das Selektieren von Text im Browser. Über ein Kontextmenü stellt die Erweiterung dann etliche Möglichkeiten zur Verfügung, den selektierten Text als Input für Services im Web zu nutzen. Der selektierte Text kann so beispielsweise als Input für Google (auch Google Maps), Technorati, Wikipedia, Amazon, EBay, delicio.us, und viele andere Services genutzt werden. Über entsprechende Services lässt sich selektierter Text auch von einer Sprache in eine andere übersetzen. Der Clou dabei: zu übersetzender Text wird direkt im Original-Layout in der angezeigten Webseite durch den übersetzten Text ersetzt. Auch Seiten-Informationen, z.B. Whois-Informationen, Versionen-Informationen entsprechend der Internet Wayback Machine, DNS-Informationen, PageRank, HTML-Quelltext des ausgewählten Textes und vieles andere lässt sich direkt übers Kontextmenü abrufen. Ausgewählter Text lässt sich ferner ins eigene Blog einfügen, in eine Datei kopieren oder ausdrucken. Es dauert sicher eine ganze Weile, um der Erweiterung ihr volles Potential zu entlocken, doch der Lohn ist ein möglicherweise völlig neues Hypertext-Gefühl beim Surfen im Web.

Zahlreiche Einstellmöglichkeiten runden das Tool ab. Eine deutschsprachige Oberfläche gibt es bislang nicht, doch bei wachsender Installationszahl wird die Erweiterung über kurz oder lang sicherlich internationalisiert. Firefox-Benutzer können die Hyperwords-Erweiterung sofort aktivieren.


Freie klassische Musik in MP3-Form auf musikethos.org

Es soll ja Leute geben, die zwischendurch auch mal oder sogar vorzugsweise Musik aus vor-elektronischer Zeit hören, Musik von sogenannten klassischen Komponisten, oder auch aus dem Jazz-Bereich, von der es keine Originalaufnahmen gibt, sondern die von gegenwärtigen Musikern interpretiert werden. Das große Geld ist damit ohnehin nicht zu holen, wenn man von einigen wenigen Szene-Stars der großen Konzert-Szene absieht. Die meisten jungen Musiker sind jedenfalls eine idealistische Grundeinstellung längst gewohnt. Tausende von Stunden haben sie häufig investiert, um aus ihrer Klarinette oder ihrem Violoncello jene Feinheiten herauszukitzeln, die das Hören klassischer Musik erst zum Genuss macht. Ihr größter Wunsch ist es eigentlich, überhaupt Gehör zu finden.

Was liegt also näher, als solche Musik frei übers Internet zu vertreiben? Das Urheberrecht der gespielten Werke selbst ist normalerweise abgelaufen, und die Rechte an der individuellen musikalischen Interpretation liegen bei den ausführenden Musikern. Denen steht es frei, dafür auch mal Lizenzformen wie Creative Commons zu wählen. Genau das passiert beim Portal Musikethos.org. Dort wartet eine momentan noch überschaubare, doch hoffentlich noch wachsende Anzahl an freien MP3-Downloads. Die MP3-Qualität der Aufnahmen ist durchweg gut bis sehr gut (mindestens 160 Kbyts/s Bitrate). Die Aufnahmequalität selbst ist natürlich immer nur so gut wie es Equipment und Kunst der Aufnahmetechnik zuließen. Vielleicht also kein Wiedergabe-Futter für sündhaft teuere High-End-Anlagen, aber fürs Hören über PC, Kleinanlage, im Auto oder auf einem mobilen MP3-Player reicht die Qualität allemal.

Das Projekt Musikethos.org wird von einer Gesellschaft namens Musica Etica association betrieben, die im August 2006 von den beiden in Perugia (Italien) lebenden Zeitgenossen Giuseppe Mazziotti und Davide Berretta gegründet wurde. Zwar hat das Projekt durch einige anfängliche Reviews eine gewisse Beachtung erfahren, doch die große Anerkennung fehlt noch. Vielleicht können Blog-Beiträge wie auf netzwelt.de oder jetzt hier dazu beitragen, das Musikethos.org-Projekt noch ein klein wenig bekannter zu machen.

Und für Faule noch ein paar direkte Hörproben (kleiner Tipp: direkt anhören über das snap-Preview-Symbol hinter den Links):

  • Paul Agricole Genin: Introduzione e Polacca for saxophone and piano (Introduction)
    Disecheis Duo
    MP3, 160 Kbyte/s, 2'51", 3,3 MByte
  • Johann Sebastian Bach: Concerto in D minor BWV 1052 for piano and orchestra (Allegro)
    Stefano Micheletti - piano, Orchestra Sinfonica di Perugia, Giuliano Silveri (conductor)
    MP3, 160 Kbyte/s, 8'37", 10,3 MByte
  • Cristiano Arcelli: Net or Net
    Cristiano Arcelli - saxophone, Giovanni Guidi - piano, Francesco Ponticelli - double bass, Carlo Marchionni - drums
    MP3, 160 Kbyte/s, 3'17", 3,9 MByte

Sonntag, 6. Mai 2007

Dagegen muss protestiert werden!

Der Heise-Ticker meldet: Urteil bestätigt uneingeschränkte Haftung für Forenbetreiber. Hintergrund ist ein Verfahren, das vom Betreiber des Super-Nature Forums, Martin Geuß, geführt wurde.

Um diesen üblen Fehltritt der Gerichtsbarkeit zu ermessen, sollte sich niemand entgehen lassen, den Urteilstext zu lesen. Und dann an alle Services denken, die direktes Publizieren durch Benutzer ermöglichen. Von Wikipedia über Mr. Wong bis hin zu sämtlichen Blogs mit Kommentarfunktion und Fachforen stehen diesem Urteil zufolge praktisch alle Anbieter mit einem Bein im Gefängnis. Denn sie machen sich nicht erst strafbar, wenn sie nach Kenntnisnahme etwa eines volksverhetzenden oder beleidigenden Benutzerbeitrags nicht reagieren, sondern ab dem Moment, wo der Beitrag online ist.

Der einzig wirksame Schutz dagegen ist eine Redaktionskontrolle, also ein persönliches Prüfen aller Benutzerbeiträge vor dem Veröffentlichen. Aus Benutzersicht ist das jedoch so prickelnd wie das Ziehen einer Wartenummer im Arbeitsamt. Nein, das darf sich die Internet-Gemeinde nicht gefallen lassen. Gegen dieses Urteil muss protestiert werden! Deshalb bitte weitersagen und aufklären!

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Forenbetreiber haften uneingeschränkt


Tutorial: Ajax (4)

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?


Welche Nachteile hat Ajax?

Bei allem Mehrwert, den Ajax dem Benutzer einer Webanwendung bieten kann, sollen jedoch die Nachteile nicht verschwiegen werden. Folgende Probleme treten im Zusammenhang mit Ajax auf:

  • Die Grenzen zwischen URL-Adressen und Seitenzuständen verschwimmen:
    Eine Webseite zeichnet sich dadurch aus, dass sie eine feste URL-Adresse hat. Wenn eine Webseite intensiv mit Ajax arbeitet, kann es jedoch passieren, dass der Benutzer lange Zeit gar keine neue Seite mit eigener URL-Adresse nachfordert. Stattdessen setzt ihm JavaScript neue Inhalte und Seitenzustände direkt in den bestehenden HTML-Code ein. Da so erzeugte Inhalte und Seitenzustände aber keine eigene URL-Adresse haben, lassen sie sich nicht als Bookmark/Favorit abspreichern, und andere Webseiten können keine direkten Links („Deeplinks“) auf solche Inhalte setzen. Die Vor- und Zurück-Funktion des Browsers, die das Bewegen in der Historie besuchter Seiten ermöglicht, funktioniert ebenfalls nicht mehr wie erwartet. Denn diese Funktion springt immer nur zum Anfangszustand einer Seite. Auch Suchmaschinen-Robots werden in aller Regel nur den Anfangszustand einer Seite indexieren und weitere, über Ajax ermittelbare Seiteninhalte ignorieren.
  • Ajax ist nur mit aktiviertem JavaScript verfügbar:
    Per Voreinstellung ist JavaScript in allen modernen Browsern aktiviert. Weil JavaScript jedoch nach dem Boom der Anfangsjahre etwas in Verruf geraten war, nutzten viele Anwender die Möglichkeit, JavaScript zu deaktivieren. Viele nervige Popup-Fenster, hinderliche Effekten und sonstiges Blendwerk ließen sich auf diese Weise unterdrücken. Wer das auch heute noch tut, wird von Inhalten, die nur über Ajax ermittelt werden, erst gar nichts sehen. Gleiches gilt für Anwender, die aus technischen oder körperlichen Gründen Browser-Lösungen in reinen Textumgebungen verwenden. Solche Browser unterstützen in aller Regel auch kein JavaScript. Inhalte, die nur über Ajax ermittelbar sind, bleiben also unzugänglich.
  • Die Server-Belastung kann sehr hoch werden:
    Wenn Anwenderaktionen wie Mausklicks oder gar Mouseover-Ereignisse jedesmal eine HTTP-Kommunikation auslösen, entsteht viel zusätzliche HTTP-Kommunikation zwischen Client und Server. Der Client, also der Browser des Anwenders, wird dadurch nicht nennenswert belastet, um so mehr jedoch der Webserver, der möglicherweise für viele gleichzeitige Benutzer die Ajax-bedingte HTTP-Kommunikation abwickeln muss. Eine Ajax-intensive Webanwendung, die von vielen Besuchern gleichzeitig genutzt wird, kann einen Webserver durchaus in die Knie zwingen. Das gilt insbesondere für Anwendungen, bei denen eigentlich ein Server-Push, also eine vom Server gestartete Kommunikation sinnvoll wäre, wie etwa bei einem Chat. Da es im HTTP-Protokoll jedoch keinen Server-Push gibt, muss der Client, also JavaScript, in kurzen Zeitintervallen immer wieder beim Server nachfragen.
  • Wartezeit bis HTTP-Antwort kann Anwendungen lahm erscheinen lassen:
    Wenn ein Anwender in seinem Browser eine neue Webseite aufruft, weiß er, dass es einen oder ein paar Momente dauern kann, bis alle Daten angezeigt werden können. Eine Webanwendung, die mit Ajax Daten „nachlädt“, muss ebenfalls einen oder ein paar Momente auf Antwort warten. Ein Anwender, der nichts von Ajax weiß (und welcher Normalanwender muss das schon wissen?), bekommt in solchen Fällen den Eindruck, als ob die Webanwendung sehr zäh reagiert. Er klickt auf einen Button und muss möglicherweise mehrere Sekunden warten, bis das Ergebnis des ausgelösten Ereignisses sichtbar wird. Dies widerspricht seiner Erfahrung, wonach einmal geladene Webseiten sich im Speicher des eigenen Browsers befinden und sehr schnell reagieren.

Einige dieser Probleme sind allerdings durchaus lösbar. Eine Webanwendung kann beispielsweise so konzipiert werden, um GET-Parameter zu erkennen, über die sich direkt Inhalte und Seitenzustände ansprechen lassen, die sonst erst durch Ajax-Aktionen zustande kommen. Bei Wartezeiten, verursacht durch Ajax-HTTP-Anforderungen im Hintergrund, kann dem Anwender ein bekanntes Warte-Symbol (z.B. eine Sanduhr) angezeigt werden.

Was die Verfügbarkeit von JavaScript betrifft, so müssen Webentwickler eine Grundsatzentscheidung treffen. Entweder man macht die Aktivierung von JavaScript einfach zur Bedingung, oder man versucht, Ajax nur für Mehrwert-Funktionen eingesetzt werden (z.B. Tabellensortierung), wobei eine Grundfunktionionalität (z.B. Tabelle, die nicht sortierbar ist) gewährleistet ist. Vor allem Websites, die den Charakter einer Web­anwendung haben, mit der Benutzer etwas bearbeiten können, haben durchaus das Recht, die Aktivierung von JavaScript zur Bedingung zu machen. Bei gewöhnlichen Webseiten ist dagegen eher die Lösung angebracht, Ajax nur für Mehrwert-Funktionalität einzusetzen.

Wie sicher ist Ajax?

JavaScripts mit Ajax stoßen Scripts an, die auf einem Webserver laufen, also beispielsweise PHP-Scripts. Das serverseitige Script muss sich dazu in der „Document Root“ des Webservers befinden, also in jenem Verzeichnisbereich, der über URLs adressierbar ist. Das klingt gefährlich. Doch letztlich passiert dabei nichts anderes, als wenn ein Anwender die URL-Adresse eines solchen Scripts auf dem Webserver selbst in die Adresszeile seines Browsers eingibt, oder wenn er sich selbst ein HTML-Formular bastelt, das ein solches Script beim Absenden aufruft und ihm Daten übermittelt. Es liegt in all diesen Fällen an der serverseitigen Programmierung, dafür zu sorgen, dass über GET-Parameter oder POST-Daten keine ungewollten oder schädlichen Aktionen auf dem Server ausgelöst werden.

Das Sicherheitskonzept von Ajax geht jedoch noch einen Schritt weiter. Es sieht vor, dass ein JavaScript, welches das XML-HTTP-Objekt einsetzt, vom gleichen Webserver kommen muss wie das serverseitige Script, das es aufruft. Es ist also nicht möglich, durch ein selbstgebasteltes JavaScript via Ajax ein serverseitiges Script auf einem beliebigen Webserver zu starten.

Ajax-Fehlermeldung im Firefox-Browser
Fehlermeldung in der JavaScript-Konsole des Firefox-Browsers beim Versuch eines JavaScripts, einen HTTP-Request an eine fremde Domain zu senden

Im Klartext bedeutet das: Ein Benutzer muss in seinem Browser zunächst eine Webseite auf einem Webserver aufrufen. Diese Webseite enthält ein JavaScript mit Ajax-Code. Das Script wird zusammen mit der Webseite an den Browser des Anwenders übertragen. Das Script mit dem Ajax-Code kann nun HTTP-Requests absenden, jedoch nur zu dem Webserver (genauer: zu der Domain), von welcher die Webseite mitsamt dem Script an den Browser übertragen wurde.

Als Website-Betreiber müssen Sie entweder ein eigenes JavaScript mit ausliefern, das serverseitige Scripts auf der eigenen Domain aufrufen kann. Oder Sie binden ein JavaScript von einer fremden Domain ein, das jedoch nur serverseitige Scripts auf der Domain aufrufen kann, von der es ausgeliefert wird.

Wie sicher eine Ajax-basierte Web-Umgebung ist, bleibt also daran hängen, wie sicher die serverseitige Programmierung ist, welche Ajax-Anfragen verarbeitet. Ein PHP-Script etwa, das ungeprüft Daten, die aus GET- oder POST-Parametern stammen, in ein MySQL-Statement einbaut und die Daten in eine Datenbank schreibt, stellt ein hohes Sicherheitsrisiko dar. Dieses Risiko kann jedoch ebensowenig der Ajax-Schnittstelle angelastet werden wie der Programmiersprache PHP. Es liegt allein an der Sorgfalt der serverseitigen Programmierung, mit Input-Daten so umzugehen, dass daraus keine Gefahr entstehen kann.


Freitag, 4. Mai 2007

snap.com Kontext-Links

Seit Ende Februar werden im Webkompetenz-Blog externe Links automatisch mit einem Postfix-Symbol versehen. Dahinter steckt der Preview-Service von snap.com (wir berichteten im Beitrag Verlinken mit snap.com). Zumindest seit die Möglichkeit besteht, das Preview-Popup nur dann anzuzeigen, wenn der Anwender die Maus über das Symbol bewegt, und nicht bei jedem mouseover über dem Verweistext, ist der Service dezent genug, um Anwender nicht durch unerwünschte Effekte zu vergraulen.

Nun ist ja snap.com zunächst einmal eine neuartige Suchmaschine, die ihren Datenbestand nicht mehr durch klassische Such-Robots nährt, sondern eben dadurch, dass Website-Anbieter den Preview-Service nutzen und externe Links setzen. Dieses unkonventionelle, aber durchaus erfolgreiche Konzept erzeugt also einen Datenbestand, der darauf basiert, was Anbieter von Web-Inhalten an anderen Anbietern von Web-Inhalten für verlinkenswert halten. Falls snap.com also beispielsweise (wider Erwarten) den Artikel Snap.com - a Google Alternative? bislang noch nicht in seinem Datenbestand hatte, so wird sich das mit diesem Blogbeitrag hier ändern, nämlich dann, sobald jemand das Symbol hinter dem Link zu besagtem Artikel mit der Maus überfährt.

Da die Previews also das primäre Werkzeug für snap.com sind, um den Datenbestand der Suchmaschine zu füttern, ist es gar nicht verwunderlich, wenn versucht wird, diesen Service immer weiter zu verbessern. Eine der neuesten Neuerungen ist, dass einige Previews nicht mehr die oft nichtssagenden Thumbnail-Vorschau-Screenshots verlinkter Seiten zeigen, sondern lesbaren Text. Das gilt beispielsweise für Links zu Wikipedia. Beispiel: Was Wikipedia über Webcrawler weiß, darüber kann man ganz locker plaudern, denn wer Probleme mit einem Terminus technicus wie „Webcrawler“ hat, erhält über die Preview-Funktion der Links erste Hilfe.

Nicht nur bei Links zu Wikipedia, sondern auch bei solchen zu einigen anderen bedeutenden Inhaltsanbietern funktioniert die inhaltliche Detailvorschau. So etwa bei der Internet Movie Database. Als Beispiel ein Link zum Film Spiderman 3. Ebenfalls funktionieren soll die Spezialvorschau bei Direktlinks zu Fotos auf flickr.com. Als Beispiel ein Link auf das Spiderman-3-Poster. Weitere Details sind übrigens dem Artikel Snap.com Introduces Contextual Widgets zu entnehmen, und in der hauseigenen FAQ demonstriert snap.com weitere Beispiele. Sogar komplette YouTube-Videos lassen sich in den Previews abspielen.

Es gehört nicht viel Phantasie dazu sich auszumalen, wie das weitergeht. So könnten beispielsweise Mikroformate auf Zielseiten erkannt und in Previews wiedergegeben werden. Anstelle der klassischen Vorschau-Screenshots könnten nach Benutzerwunsch auch Whois-Informationen zum Betreiber der verlinkten Seite angezeigt werden. Die Idee jedenfalls hat ihren Weg gefunden und wird ihn weiterverfolgen. Das Einzige, womit ich persönlich überhaupt nichts anfangen kann, ist die eigentliche Suche von snap.com. Hässliche Oberfläche, häufig unbefriedigende Suchergebnisse, übelstes Frameset-Gefrickel. Solange das alles so bleibt, wird Google wohl von snap.com wenig zu befürchten haben, aller innovativen Konzepte zum Trotz.


Donnerstag, 3. Mai 2007

Abkehr vom Kopierschutz?

Musik mit Kopierschutz ist wie Sex mit Tauchanzügen, meinen viele, und das nicht zu Unrecht. Käufer herkömmlicher Tonträger sind über Jahrzehnte daran gewöhnt worden, dass man mit einer einmal erworbenen CD, Platte, MusicCassette usw. machen kann was man will — auch wenn es auf den Covern und Inlets immer schon wichtige Hinweise gab, die unerlaubtes Aufführen, Vervielfältigen usw. verboten.

Was früher jedoch gar nicht kontrollierbar war, ist dank des digitalen Kopierschutzes schlichtweg nicht mehr möglich. Und der Dschungel der Kopierschutzvarianten ist verwirrend. Dazu kommt, dass viele Musikfreunde schlichtweg erbost sind darüber, dass sich eine gekaufte Datei möglicherweise nicht auf einen mobilden MP3-Player übertragen lässt, oder nicht mehr, weil die Anzahl maximaler Kopien erschöpft ist.

Wie der Focus vor einiger Zeit in einem Artikel mit dem Titel Plattenfirmen setzen auf MP3 berichtet, bieten große Plattenfirmen mittlerweile testweise Musik im MP3-Format an. Wenige Wochen später etwa ist im Focus selbst vom EMI-Konzern die Rede: EMI schafft Kopierschutz ab. Auch andernorts, etwa in der Welt, wird diese Nachricht aufgegriffen ( Das Ende vom Lied).

Grund für die neue Offenheit der Plattenfirmen ist jedoch weniger der Wunsch des Kunden nach frei kopierbaren Musikdateien als vielmehr ein Monopolist, der den Musikmarkt immer stärker reguliert: Apple's iTunes. Mit 2 Milliarden online verkaufter Songs ist Apple zu einem marktbeherrschenden Händler geworden. iTunes-Musikmaterial ist mit einem System namens FairPlay kopiergeschützt und kann nur auf iTunes-kompatiblen Geräten wiedergegeben werden. Dadurch kontrolliert Apple den Preismarkt, was den Musik-Konzernen ein Dorn im Auge ist.

Man darf gespannt also sein, ob der Online-Musikmarkt doch noch dem ganzen Thema Kopierschutz abschwört. Ich gehöre jedenfalls auch zu den Kauf-Verweigerern von Musikdateien, für die ich eine bestimmte Soft- oder gar Hardware benötige, und die ich nicht mal eben irgendwoandershin kopieren kann.

Diskussionen zu diesem Eintrag im Webkompetenz-Forum:
Zum Blog-Eintrag:Abkehr vom Kopierschutz?