WordPress seems to support basic IndieWeb-Comments out of the box!
in reply to @eschnou.com
Hier geht es um Webdesign, Microformats, (X)HTML und CSS, Web2.0, usw.
WordPress seems to support basic IndieWeb-Comments out of the box!
in reply to @eschnou.com
In particular, we think login should be personal and minimal first, social later [and] Users, not Sites, should choose their Identity Provider
Users don’t like social login
Soziale Netzwerke spiegeln meistens einen Lebensabschnitt und spielen nur eine begrenzte Zeit eine wichtige Rolle. Man wird älter, Interessen ändern sich, man wechselt das Netzwerk. Stellt euch vor ihr wärt bis an euer Lebensende an MySpace gebunden, nur weil ihr euch überall mit dem in die Jahre gekommen Netzwerk angemeldet habt.

…ich hab's ja bisher immer verbummelt oder verpasst:
Aber jetzt, wo Google seinen Reader dicht macht, kann ich's endlich auch mal schreiben: RSS ist tot!
Nach dreimonatiger Wartezeit bzw. dreimonatigem Reviewprozess hat es mein erstes und einziges WordPress-Theme endlich in das WordPress-Theme-Directory geschafft! Juhu!
Würde mich freuen wenn ihr es mal ausprobiert oder als Basis für eure eigenen Themes benutzt. Feedback ist wie immer erwünscht… hier oder auf Github…
Ich habe in den letzten Monaten eine Menge über Web Intents gelesen und ich finde immer noch dass der Webmonkey die Thematik bisher am treffendsten beschrieben hat:
In practice Web Intents work a bit like
mailto:links, defining an action and then passing it along to the browser, which allows the user to choose how to handle the action. The difference is that instead of opening a desktop app, Web Intents connect to web services.
Der Vergleich ist simple und ich habe mir die Frage gestellt: Wieso nicht einfach wirklich unterschiedliche Schemes für die jeweiligen Anforderungen definieren? Eine App kann beim Browser anmelden dass sie share:// oder subscribe:// unterstützt und bei einem Klick auf einen entsprechenden Link, öffnet sich (statt der E-Mail App) eben die entsprechende Web-App.
…vor kurzem hab ich dann mal ein wenig mit Superfeedrs msgboy herumgespielt und entdeckt dass es bei HTML5 wirklich Custom-Schemes gibt die man frei definieren kann!
Mit folgendem Befehl kann man beim Browser einen eigenen Protocol-Handler setzen:
navigator.registerProtocolHandler('web+share', 'http://spread.ly/?url=%s', 'Spread.ly');Code-Sprache: JavaScript (javascript)
Alle neuen Schemes sollten mit "web+" beginnen, ausnahmen sind schon bestehende Schemes, wie z.B. "mailto", "mms", "nntp", "rtsp" oder "webcal".
Der passende a-Tag zum oben genannten Beispiel müsste also folgendermaßen aussehen:
<a href="web+share:http://pfefferle.org">Share this Page</a>Code-Sprache: HTML, XML (xml)
Klickt ein User den Link, wird einfach das %s vom Handler mit dem href ersetzt und aufgerufen:
http://spread.ly/?url=web+share:http://pfefferle.orgCode-Sprache: JavaScript (javascript)
Bisher war ich ja ein großer Web Intents Fan (und bin es auch immer noch), aber für solche simplen Aktionen wie "Share", "Like", "Subscribe" oder "Follow" reicht doch ein simples Custom-Scheme vollkommen aus. Kein unnötiges JavaScript (mal abgesehen vom Registrieren des Handlers), nur ein wenig HTML. Großartig!
Protocol-Handler lassen sich übrigens auch abhängig vom Mime-Type setzen:
navigator.registerContentHandler('application/atom+xml', 'http://www.google.com/ig/add?feedurl=%s', 'Google Reader')Code-Sprache: JavaScript (javascript)
Bei allen Web-Dokumenten mit dem Mime-Type application/atom+xml sollte der Browser jetzt nachfragen ob er die URL mit dem Google-Reader öffnen soll.

Beim „basteln“ an SemPress, meinem ersten WordPress Theme, habe ich das erste Mal praktische Erfahrungen mit Schema.org gesammelt und mir sind vor allem zwei Dinge klar geworden: 1. Warum Schema.org nach einer Art „Vererbungs“-Prinzip aufgebaut ist und 2. Wie Google mit Schema.org umgeht.
Das „einfachste“ Schema ist ein „Thing“ und hat folgende Attribute:
description | TEXT | A short description of the item. |
|---|---|---|
image | URL | URL of an image of the item. |
name | TEXT | The name of the item. |
url | URL | URL of the item. |
Da alle anderen Objekte auf dem „Thing“ aufbauen, kann man davon ausgehen dass man mind. auf diese vier Eigenschaften zugreifen kann und genau das ist der ganze Sinn hinter dieser Struktur.
Vor allem Google setzt massiv auf Schema.org, sei es beim Einsatz in der Suche (über die sogenannten Rich-Snippets)…

…oder beim Anreichern der, über Google+ oder den +1 Button geteilten Links.

Um das Parsen der Webseiten (zumindest für diese eher einfachen Ausgaben) auf ein Minimum zu reduzieren, ist die Grundstruktur immer gleich und alles darüber hinaus ist reine Kür. Wahrscheinlich werden aber 90% aller Anwendungen mit Titel (name), Beschreibung, Bild und URL auskommen.
Wer seine Seite mit Schema.org auszeichnen möchte, sollte vor allem eines Beachten: Google+ (wahrscheinlich aber auch alle anderen Google Produkte) interpretiert immer das erste im Quellcode verwendete Schema!
Bei meiner ersten Implementierung von Schema.org habe ich mich etwas zu sehr an RSS bzw. Atom orientiert und folgenden Aufbau gewählt: Ein umschließendes Objekt um den Blog zu beschreiben und ein oder mehrere referenzierte Artikel.
<body itemscope itemtype="http://schema.org/Blog">
...
<header id="branding" role="banner">
<hgroup>
<h1 id="site-title" itemprop="name"><?php bloginfo( 'name' ); ?></h1>
<h2 id="site-description" itemprop="description"><?php bloginfo( 'description' ); ?></h2>
</hgroup>
</header>
...
<article itemprop="blogPost" itemscope itemtype="http://schema.org/BlogPosting">
...
</article>
<article itemprop="blogPost" itemscope itemtype="http://schema.org/BlogPosting">
...
</article>
...
</body>Code-Sprache: HTML, XML (xml)
Egal ob es jetzt um mehrere Artikel (Startseite) oder nur einen Artikel (Post oder Page) gehandelt hat.
Das hat bei Google+ dazu geführt, dass die notizBlog-Links immer mit dem Titel, der Beschreibung und dem Bild des Blogs und nicht mit denen des Artikels verknüpft wurden. Es ist also gerade für Blogs wichtig, dass das Blog-Schema nur auf den Übersichtsseiten benutzt wird und die Einzelansichten lediglich mit „http://schema.org/BlogPosting“ bzw. „http://schema.org/WebPage“ ausgezeichnet werden.

(Kleiner Nachtrag zu der „OAuth ist tot“ Kolumne in der SCREENGUIDE Ausgabe 15 um zu zeigen, warum gerade das W3C auch für Community Formate durchaus nützlich sein kann)
Vor ein paar Wochen kam eine E-Mail mit der Bitte, an einer Umfrage zu den W3C Community and Business Groups teilzunehmen und das hat mich daran erinnert, dass ich mich bisher noch gar nicht zu dem Thema geäußert habe… das hole ich hiermit kurz nach!
Ich beschäftige mich ja jetzt schon eine ganze Weile mit dem Web und seinen diversen Formaten, Standards, Techniken, Spezifikationen usw. usf. Leider ist das Web aber ziemlich vergänglich und eine Menge guter Ideen und Formate sind, aus Mangel an Interesse, mangelndem Durchhaltevermögen, nicht genug Ruhm oder einfach nur aus kurzfristigen „Publicity“ Interessen wieder spurlos verschwunden.
Hier ein paar Beispiele:
…um nur einige zu nennen. Ob jetzt alle Projekte gut waren, darüber lässt sich streiten, aber es ist auf alle Fälle schade dass sie mittlerweile gar nicht mehr erreichbar sind. Viele Ideen waren vielleicht zu früh gedacht oder das Problem, das sie versuchten zu beheben, war einfach noch nicht groß genug. Oftmals braucht es vielleicht einfach nur ein wenig mehr Zeit! Lange Rede, kurzer Sinn: Die W3C Communities bieten genau für diese Community Formate die ideale Plattform:
A W3C Community Group is an open forum, without fees, where Web developers and other stakeholders develop specifications, hold discussions, develop test suites, and connect with W3C’s international community of Web experts. Community Groups may produce Specifications; these are not standards-track documents but may become input to the standards process. For instance, a Community Group might gather to work on a new technical specification, or convene to have discussions about a tutorial for an existing specification.
W3C FAQ
Auch wenn aus den Formaten kein „Standard“ werden sollte, so sind sie beim W3C doch besser aufgehoben und HOFFENTLICH auch für längere Zeit erreichbar! Gerade Junge Projekte wie „Unhosted Web“ oder „Federated Social Web“ scheinen die W3C Communities gut anzunehmen und auch Facebook forciert eine „Mobile Web“ Gruppe (die jetzt vielleicht nicht mehr so aktiv betrieben wird ;)).
Vielleicht macht sich jemand ja mal die Mühe und zieht zumindest die MicroID und die Portability Policy um!