Die heutigen Bloggingtools sind bestenfalls embryonal zu nennen. Sie werden in der nächsten Zeit sowohl einfacher als auch leistungsfähiger und flexibler werden. Ein Ansatz für mehr Flexibilität wäre eine innovative Nutzung von RSS-Feeds (oder Atom-Feeds). Damit würden auch inhaltlich komplett individuell aufgebaute, strukturierte und gestaltete Weblogs für jeden Blogger ermöglichen – ohne eigenen Server und ohne jede Programmierung.
RSS-Feeds, ohne die Weblogs für mich nahezu unbrauchbar wären, wurden in den letzten Jahren vor allem dazu verwendet, über Änderungen an Websites zu informieren. Das ist besonders bei Weblogs wichtig, da diese typischerweise häufig aber unregelmäßig aktualisiert werden Dafür sind RSS-Feeds (oder neuerdings Atom-Feeds) ursprünglich gar nicht gedacht gewesen. Was nicht wirklich ein Problem ist. Technologie findet ihre Anwendung – es muss nicht die ursprünglich intendierte sein. Aber tatsächlich wird es vielleicht bald auch für engagierte Blogger Zeit, umzudenken und den ursprünglichen Zweck von RSS-Feeds (Datenaustausch und „Syndication“ auch für ihre Weblogs zu verwenden ... und dabei den (heutigen) Schwanz mit dem Hund wedeln zu lassen:
Until now, our tools have produced web pages then feeds. I'm thinking we need tools that create feeds and then let us combine them into web pages.Die Idee ist es also: die Seiten von Websites aus mehrere Content-Strömen zusammen zu montieren.
Das klingt zunächst vielleicht komisch und unnötig kompliziert (wobei der „normale Blogger“ davon in der Praxis gar nichts merken muss), mag unter anderem die "Art, wie wir bloggen" und das Aussehen vieler Weblogs über kurz oder lang deutlich ändern – und nebenbei die Art, wie wir mit Computern umgehen.
Im Detail:
Das Zitat "... we need tools that create feeds and then let us combine them into web pages" stammt von Harold Check und wird bei Kottke mal zuende gedacht: Some "Web as platform" noodling:
Taking the weblog example to the extreme, you could use TypePad to write a weblog entry; Flickr to store your photos; store some mp3s (for an mp3 blog) on your ISP-hosted shell account; your events calendar on Upcoming; use iCal to update your personal calendar (which is then stored on your .Mac account); use GMail for email; use TypeKey or Flickr's authentication system to handle identity; outsource your storage/backups to Google or Akamai; you let Feedburner "listen" for new content from all those sources, transform/aggregate/filter it all, and publish it to your Web space; and you manage all this on the Web at each individual Web site or with a Watson-ish desktop client.Das ist eine klasse Idee wenn auch keine ganz neue. Im Prinzip geht es darum, verschiedene Programme und Quellen von Inhalten miteinander zu kombinieren und zu kaskadieren, um daraus etwas Neues, Grösseres nach dem Prinzip "das Ganze ist mehr als die Summe seiner Teile" zu bauen. Das machen heute unter anderem schon die großen Portal-Tools (für öffentliche oder unternehmensinterne Portale). Das Prinzip kennt die Welt aber schon seit den Urzeiten von Unix, Pipes. StdIn und StdOut etc. Das war aber etwas für Techies. (Und bislang sind alle Versuche, „nach Unix“ etwas Ahnliches, Besseres auf anderen Plattformen zu schaffen, gescheitert.) Es könnte aber sein, dass mit RSS-Feeds jetzt zum ersten Mal eine Technologie zur Verfügung steht, die dieses Baukastenprinzip einfach und handhabbar genug macht, das nicht nur die Techies damit umgehen können.
Verbundene Webservices - gute Idee aber hochkompliziert
Das ist prinzipiell auch nahezu identisch zum großen Versprechen der "Webservices", Programmen, die ihre Dienstleistungen über standardisierte Schnittstellen im Internet zu Verfügung stellen und die von anderer Software genutzt werden können, um daraus "größere" Programme zu bauen. Siehe auch A tale of two cultures bei Jon Udell:
It's clear that that the future of the Unix-style pipeline lies with Web services. When the XML messages flowing through that pipeline are also XML documents that users interact with directly, we'll really start to cook with gas.Cooler Ansatz (wenn auch nicht neu; siehe oben). Technisch aber bislang hochkomplex und nach wie vor intensiven Stantardisierungsbemühungen unterworfen (denn erst von allen akzeptierte Standards erlauben es, so etwas reibungslos über die Angebote vieler Hersteller hinweg zusammenzuschrauben).
Dafür unterstützen diese Standards dann aber auch hochkomplexe Interaktionen zwischen den beteiligten Programmen. Daten fließen vor und zurück, ein Programm steuert das Andere. Und die ausgetauschten Daten kommen natürlich in vielen (branchen- und anwendungsspezifischen) Strukturen und Formaten daher. Eine Plattform, die dieses Prinzip, Anwendungen aus Komponenten zusammen zu setzen, die über XML-Datenströme miteinander reden, schon heute sehr gut unterstützt, ist zum Beispiel Cocoon http://cocoon.apache.org/. Aber Warnung: echt was für Geeks nicht für Otto-Normalblogger wie mich.
Und was hat das mit Weblogs zu tun?
Um Webseiten zusammen zu bauen, ist diese Komplexität aber glücklicherweise überflüssig. Hier reicht es, die "von irgendwoher" angelieferten Daten (meist Text), ein bißchen zu filtern, zu massieren, vielleicht zu mischen und umzusortieren, um sie dann zusammen mit ein bisschen ansprechender Formatierung auf die Seite zu blasen.
Aber wieso sollte ich so etwas wollen?
Zum Beispiel, wenn ich über den Standardaufbau der heute üblichen Weblogging-Plattformen hinausgewachsen bin.
Auf der Homepage meines Weblogs (oder meiner persönlichen Site) möchte ich zum Beispiel eigentlich gar nicht immer nur die letzten Einträge sehen. Sondern vielleicht die letzten Einträge aus vielen Kategorien, in ordentliche Päckchen gruppiert. Denn vielleicht habe ich zu einem Thema längere Zeit nichts mehr geschrieben, aber für jemanden, der meine Site besucht, um etwas über mich zu erfahren, ist es vielleicht wichtig, auch diese alten Beiträge zu sehen.
Oder an einem Gemeinschaftsblog arbeiten mehrere Autoren, deren letzte Beträge ich alle nebeneinander auf der Homepage sehen möchte – und zusätzlich vielleicht noch die individuellen "Highlights".
Oder ich will in einer Ecke die letzten (oder ausgewählte) Beiträge von einem Fellow-Blogger, dessen Output ich besonders schätze, sehen.
Und in einer anderen Ecke Termine und Events in der Zukunft – die ich für wichtig halte oder wo ich hin gehen will. Bücher und Musik, die ich gerade „konsumiert“ habe (mit oder ohne Meinung dazu).
Klar, alles das geht schon heute – wenn die Tools ganz speziell für den jeweiligen Zweck ein Feature besitzen (siehe die TypeLists von TypePad) oder ich selbst programmieren kann, um die entsprechenden PlugIns mit ein bisserl eigenem Code zu einer entsprechenden individuellen Software verwursten. Nicht unbedingt massentauglich, dieser Ansatz.
Ein bescheidener Vorschlag für einen "Werkzeugkasten für Weblog-Seiten"
Was ich mir vorstelle, und was mit Services wie Feedburner schon heute beginnt, möglich zu werden, ist zunächst ein Satz simpler Tools. Zum Beispiel:
- Einen Filter, der aus einem Feed nach Einträge nach bestimmten Kriterien (Datum, Kategorie, Keywords etc.) herausfischt und daraus einen neuen Feed macht.
- Einen Splicer, der zwei oder mehr Feeds mischt (hintereinander, nach Reisverschlussprinzip oder wie auch immmer) und daraus einen neuen Feed macht.
- Einen Sorter, der die Einträge in einem Feed nach beliebigen Kriterien sortiert und einen neuen Feed daraus macht.
- Einen Extractor, der aus den Einträgen eines Feeds nur bestimmte Felder entnimmt, diese ggf. noch kürzt (nur Titles, Datumsangaben, Summaries etc.) und daraus einen neuen Feed generiert.
- Einen Renderer, der einen Feed nach xHTML oder HTML konvertiert. Kombiniert mit zugehörigen CSS-Stylesheets wird der Feed so sichtbar.
- Und schließlich den Aggregator oder Composer, der eine Reihe von Feeds nimmt, die der Renderer aufbereitet hat, sie mit einem Seitenrahmen und ein paar zusätzlichen Inhalten anreichert und sie dann (per CSS-Positioning) auf einer Seite anordnet.
Alle diese Tools sind nach meiner Einschätzung durch simple XSLT-Operationen oder ein bisschen Scripting erstellbar. Zusammen wären sie ein sehr mächtiger Baukasten für "Webseiten aus RSS-Feeds".
In der hier vorgestellten simplen Form wäre es vermutlich aus Performance-Gründen am besten, wenn diese Tools alle auf einem Server liefen. Spezialisierte Tools (Analysatoren, Bildbearbeiter und und und ... würden aber einen weiten Markt für PlugIns bzw. Services ermöglichen. Einige davon kostenfrei andere vielleicht kostenpflichtig.
Die Technologie - und ein Teil der Tools - für dieses Modell sind da. Es müßte nur noch jemand die letzten Bausteinchen zusammenfügen. Kann doch nicht so schwierig sein ...
Ad the spanned issue at all - Würde ich gerne in zwei Themenkomplexe zerteilen.
1. Der erste ist die Vision für die Informationsgestaltung und vor allem eine veränderte Aufnahme an sich
2. Der zweite ist die Kombination von Vorhandenem. Tools und Content zusammen auf dem Weg zu erster Vision.
ad 1. Die Vision:
Bei der Diskussion um eine Verlagerung der Informationskomposition macht es imho keinen Sinn noch über Webseiten und die Zusammenstellung von Informationen vieler Webseiten zu weiteren Webseiten zu reden. Der Recipient braucht nicht noch mal die redundante Information an anderer Stelle in anderer Form (als Webseite). Dies würde ein Problem des Internets - der teilweise lädierten Vertrauenswürdigkeit der Information aufgrund unklarer Quellangaben - nur noch verschärfen.
Nehmen wir Quelle und Ziel der Information als Grundlage unserer Betrachtung. Wenn ich als Ziel darauf angewiesen bin, dass sich erst durch Komposition oder Korrelation der Information der Wert ergibt (was Information von Daten unterscheidet), dann muss diese Aktion beim Ziel passieren. Nur so können die notwendigen Schlüssel (Def.: was mit was wie kombinieren und daraus welche Relevanz der Daten ableiten) des Recipienten tatsächlich vollständig bekannt sein.
Es macht daher keinen Sinn diese Informationsaufbereitung auf irgendeiner Quelle (wei einer Webseite) zu tun. Dies hätte nur Sinn, wenn sich die Profile vieler Ziele so überschneiden würden, dass sich die exakt selbe Darstellung ergeben würde.
Wir müssen also in dieser Vision von einer anderen Konstellation ausgehen: Alle Quellen veröffentlichen Metainformationen in öffentlichen Verzeichnissen (wie UDDI oder speziellen Kanälen im Web) und stellen dann die Informationen für das Pull-Verfahren als Feed bereit (idealerweise XML). Die Webseite wäre dann nur noch eine antizipierte und präjudizierte Darstellung für den "unfokussierten - oder sporadischen" Nutzer.
Es gibt dann clientseitig beim Ziel eine geeignete Software (Information Presenter), die
a) in der Lage ist die Schlüssel des Recipienten konfigurierbar zu machen
b) aus einem Feedbackprocess mit dem Recipienten die Schlüssel adaptiv zu optimieren
c) die Metainformationen bekannter Quellen gegen diese Schlüssel zu prüfen
d) bislang unbekannte Quellen zu identifizieren (über die Metainformationsverzeichnisse = alternative Suchmaschinennutzung)
e) die Methode der Darstellung hochdynamisch zu wählen (HTML (warum eigentlich noch?), pur XML, Mindmaps, Office Dokumente, Datenbanken, etc.)
Dies wäre dann eine Art Personal Informer.
Probleme dabei:
- Blogs in der jetzigen Form braucht dann kein Mensch mehr (Provokation-Achtung;-)
- Den Recipienten so zu qualifizieren, dass er den Wechsel zu einer veränderten Informationsaufnahme (nämlich in Eigenverantwortung und nicht fremdgesteuert) schafft, ist schwer. Für die Leute, die die vorgekauten Zusammenstellungen aber eh nur annerven (wie mich) ist das aber sicher eine Wohltat.
ad 2.
Die Funktionale Spezifikation der Elemente finde ich gut.
Filter und Splicer sind Kern der Vision. Der Extractor zusammen mit dem Sorter wären die Komponenten die die Aufgabe der clientseitigen Komposition (die aber natürlich auch in einem Profil bzw. personalisierten Dienst auf einem Server laufen können) übernehmen. Den Sorter kann man mit Algorithem wie Clustering, Kritbinome, qualitative Filtering (die wir zum Teil schon untersucht haben) anreichern.
Den/die Renderer würde ich vollständig dann in den verschiedenen Endgeräten beim Recipienten sehen wollen. Am Anfang kann dies aber gerne auch ein XSL/CSS Webseitengenerierer sein. (Aber prinzipiell kommt da dann eigentlich wieder viel zu viel Mist über die Leitung).
generalissmo:
Ein Ende mit das kann doch nicht so schwierig sein...muss man natürlich mit dann machs doch beantworten;-). Ich schaus mir dann Sonntag mal an. Nein spässken.
Lasst uns dazu ein Whitepaper bauen. Einen Freiwilligen gibt es schon.
Posted by: Dirk Radtke | Wednesday, 18 August 2004 at 10:50
Zwei Freiwillige. Ist doch ne coole Idee für ein ngBlog-Tool.
Posted by: Thomas Schulze | Wednesday, 18 August 2004 at 13:41
Ob Du es glaubst oder nicht, aber Deine Gedanken und obiger Werkzeugkasten geistern mir auch schon lange Zeit im Kopf herum...
Posted by: Pepino | Thursday, 19 August 2004 at 11:46
@Pepino: glaub ich! Dann lass es uns bauen. Ich denke, wir brauchen von diesem Baukasten eh mehrere Versionen, denn einen Teil davon wird man auf enem Server integrieren müssen. Deshalb eine Version für LAMP-Systeme, eine als J2EE, eine .NET ...
Welche baust Du?
Posted by: Markus Breuer | Friday, 20 August 2004 at 07:06
laeuft da jetzt eigentlich etwas in dieser richtung?
Posted by: Gerald | Saturday, 20 November 2004 at 21:51
ich bin nun seit 5 Stunden auf Informationssuche zu RSS und newsfeeds. Ich habe schon so einige Seiten beuscht und bin über die Möglichkeiten erstaunt.
Nur bin ich meiner Aufgabenstellung nicht sehr nahe gekommen. Das Einbinden eines .NET Aggregators. Ich habe die letze halbe Stunde in der UCD Sektion gelesen (sehr interessant =) und bin irgendwie hier gelandet. Und nun schliesse ich mich der Frage von Gerald an ^^
Eine interessante Seite.
Posted by: Freund | Thursday, 02 December 2004 at 10:59
es läuft was ... aber langsamer als erhofft und geplant, sonst hätte man hier längst mehr darüber lesen können.
vielleicht sind andere schneller, was auch kein problem wäre, weil ich diese tools einfach - für andere projekte - haben will, je eher desto lieber.
Posted by: Markus Breuer | Thursday, 02 December 2004 at 17:01
So habe ich RSS noch gar nicht gesehen. Jetzt verstehe ich auch die Freude in dem Microsoft Video über die Art der RSS-Integration in Longhorn. Das sind ja eigentlich genau die Dinge, die Sie hier vorstellen.
Posted by: André Fiebig | Friday, 08 July 2005 at 14:14
"Wofür RSS-Feed wirklich gut sind"
Automatisierter Content-Klau.
"Die Idee ist es also: die Seiten von Websites aus mehrere Content-Strömen zusammen zu montieren."
Gut, aber was haben die Content-Provider davon? Wieso sollte ich meinen wertvollen Content irgendeiner Site geben die damit ein Vermögen macht? Womit verdiene *ich* dann?
Posted by: Jörg | Sunday, 10 December 2006 at 13:15