<link rel="alternate" type="application/rss+xml" title="RSS-Feed von Alp Uçkan’s Website" href="http://alp-uckan.net/blog/feed/" />
die dafür sorgen sollen, dass RSS-Aggregatoren den Feed einer Seite selbstständig finden. Gestern habe ich diese Links zum ersten Mal genutzt, als ich auf ein neu aufgesetztes KDE-System (mit Kontact, aKregator etc.) mit RSS-Feeds füttern wollte. Der KDE-Browser bringt (wie einige andere browserbasierte RSS-Reader und -Plugins) eine sog. 2-Klick-Abonniermöglichkeit mit.
Die RSS-Autoerkennungslinks resultieren bei der Konqueror/aKregator-Kombi also in ein kleines orangenes RSS-Icon am rechten unteren Browserfenster, weches beim Anklicken sämtliche im <head>-Bereich eingepflanzte RSS-Autoerkennunglinks offenbart.
Ein Klick auf den entsprechenden Feed und er landet im aKregator (dem KDE-Standard-RSS-Reader). Bequeme Sache eigentlich. Wenn da nicht wieder wir Autoren wären, die einfach die Voreinstellung unserer Blog-Tools so belassen, wie sie sind. Usabilitologisch gesehen gibt es auch hier gute und nervige Arten diese Autoerkennungslinks zu setzen. Was nervt ist z.B. zwischen verschiedenen RSS-Arten ein und desselben Contents auswählen zu müssen. In Zeiten, wo fast alle RSS-Reader sämtlich Formate von 0.91 bis 2.0 und Atom beherrschen, ist diese Formatvielfalt relativ irrelevant (für mich als User).
Per Autoerkennung gar keinen RSS-Feed zu finden und ihn 'per Hand' suchen und Copy&Pasten zu müssen ist noch nerviger. Da habe ich echt 'ne Sekunde gezögert und überlegt, ob es der Content überhaupt wert ist, nach seinem Feed zu suchen. Was auch nicht so elegant ist, ist die Aufteilung in reine Blogeintrags- und Kommentarfeeds. [Bevor einer fragt wieso und warum: Es gibt seit langem schon das wfw:commentRSS-Element und RSS-Reader, die vormachen, wie man dieses Element, welches auch standardmäßig in Wordpress-2.0-Feeds existiert, vernünftig interpretiert]
Bequem sind aber nach Inhalt sortierte Feeds, oder solche, die nur einen einzigen Feed in der Autoerkennung präsentieren.
Auf jedenfall hab ich daraus meine Lehren gezogen und bei meiner Site die alternativen Feedformate aus dem <head>-Bereich entfernt und sie durch contentbezogene Feeds ersetzt.
Dabei sollte man natürlich immer den Hauptfeed an erster Stelle stehen haben, da einige Aggregatoren nur den ersten Autoerkennungslink interpretieren und die restlichen ignorieren.
Ich weiss, dass diese Art der Verwendung des rel="alternate"-Attributs nicht unbedingt W3C-konform im Sinne der Semantik ist. Dort steht nämlich
Alternate
W3C, Basic HTML data types, Link types
Designates substitute versions for the document in which the link occurs. When used together with the lang attribute, it implies a translated version of the document. When used together with the media attribute, it implies a version designed for a different medium (or media).
Alternate beschreibt wohl nur alternative Formate der Seite, in die der Link eingebettet ist. Es ist demnach also nicht korrekt Feeds aufzuführen, die Alternativen zu anderen Contentseiten darstellen. Aber ... pffft ... so obrigkeitshörig und standardverliebt bin ich auch nicht, als dass ich deswegen eine vernünftige Usability-Maßnahme in die Tonne trete. Oder fällt jemandem ein Fallbeispiel ein, bei dem ich und meine Leser deswegen Nachteile haben? Wenn ja, lausche ich interessiert zu. Wenn nicht ... dann wird der Standard halt mal kurz gebäugt.
Defined tags for this entry: RSS
1
1stpixel: in Wordpress-2.0-Feeds existiert
wo ? HABEN ! ichhab nur wp1.6, whar wohl bloss ein tippfehler, oder ???
2
alp: Kein Tippfehler, wfw:commentsRSS ist im RSS2.0-Template von WP ab Version 1.5 drin. Auch in deinem Feed.
3
1stpixel: hhmmmmmm kleines missverständnis meinerseits:
ich las:
Wordpress-2.0-Feeds
... und dachte an Wordpress 2.0 ... und da dachte ich, da fliegt irgenwo ein WP 2er kandidat rum, und den wollte ich natürlich betrachten, dass du dich auf den feed bezogst hab' ich geflissentlich übersehen ... sorry, wer lesen kann ist klar im vorteil