Open Web

Hier geht es um Webdesign, Microformats, (X)HTML und CSS, Web2.0, usw.

Posted on
by

Ich war nie ein großer Fan der Twitter Cards, was aber nicht wirklich schlimm ist, da Twitter das Open Graph Protocol als vollwertiges Fallback unterstützt… unterstützt hat…

Seit ein paar Wochen scheint den feinen Herren das Open Graph Protocol aber nicht mehr auszureichen und meinen Links fehlt der schöne, kleine Teaser :(

Zum Glück reicht aber ein Meta-Tag um das ganze wieder zum laufen zu bekommen. Twitter unterstützt verschiedene Arten von Previews, welche über <meta name="twitter:card" content="summary" /> festgelegt werden. Neben summary (für Texte) gibt es auch noch photo für Bilder und player für Audio/Video (die komplette Liste findet ihr hier). Ich würde euch außerdem noch den twitter:creator empfehlen, mit dem ihr auf den Twitter-Account des Autors hinweisen könnt. Für meinen Blog sieht das wie folgt aus:

<meta name="twitter:creator" content="@pfefferle" />
<meta name="twitter:card" content="summary" />

Wenn ihr sicher gehen wollt ob ihr alles richtig gemacht habt, könnt ihr eure Seite mit dem Twitter Card Validator testen.

Den WordPresslern unter euch kann ich außerdem folgende Plugins empfehlen:

  • Open Graph – Keine Settings, kein Know-How, alles vollkommen Idiotensicher.
  • twitter:creator – Setzt zusätzlich die angesprochenen twitter:creator und twitter:card.

…also viel Spaß beim Twitter Cards Boykott ;) .

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.

Posted on
by

Feed Icon…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!

Posted on
by

Pfefferles Open Web

Übrigens… Mein Artikel im aktuellen SCREENGUIDE Magazin war ausschlaggebend für den Blog-Post zu Dezentrale “Walled Gardens”, geht aber noch mehr ins Detail:

[...] Spezifikationen haben wir mittlerweile genug! Es ist an der Zeit, die sozialen Netzwerke von der Idee eines dezentralen Webs zu überzeugen, und mit sozialen Netzwerken meine ich Facebook, Google+ oder StudiVZ. Netzwerke mit einer bestehenden Userbase und keine, die künstlich geschaffen wurden, um zu beweisen, dass „dezentrale“ Kommunikation funktioniert. [...]

…also ab zum Kiosk und kaufen!

Posted on
by

We love icon fonts

Tim Pietrusky hat so ne Art “Google Web Fonts” für Icon-Fonts gebastelt, was alleine natürlich schon einen Blog-Post wert wäre… er hat aber außerdem noch die OpenWeb-Icons eingebaut, was definitiv einen Blog-Post wert ist ;)

Dank Tims “We Love Icon Fonts” lassen sich die Fonts mit folgenden paar Zeilen CSS-Code einbauen:

@import url(http://weloveiconfonts.com/api/?family=openwebicons);

/* openwebicons */
[class*="openwebicons-"]:before {
  font-family: 'OpenWeb Icons', sans-serif;
}

Das Projekt ist übrigens Open Source und Tim würde sich sicherlich über jede Hilfe freuen!

Posted on
by

Diaspora Logo

Diaspora* wurde kaum für “tot” erklärt und schon steht das nächste Projekt in den Startlöchern! Tent.io soll ein protocol for distributed social networking and personal data storage werden. Alles neu, alles anders, alles besser als OStatus, DiSo oder Diaspora*. Aber mal ganz ehrlich… was haben die Diasporas & Co. bisher geschaffen? Ziel war es Facebooks “Walled Gardens” aufzubrechen und was kam wirklich dabei rum? Eine ganze Reihe an dezentralen “Walled Gardens”. Na danke!

Seit Chris Messinas DiSO-Projekt schwärme ich ein wenig für das Thema “Dezentrale Netze” und wie man die Idee am besten technisch umsetzen könnte. Trotz der “Schwärmerei” ist mir aber durchaus bewusst dass das Thema noch nicht wirklich populär ist und kein wirkliches User-Bedürfnis deckt. Das hängt aber unter anderem damit zusammen, dass bisherige Bemühungen (und Diaspora ist ein Vorzeigebeispiel hierfür) rein technischer Natur sind! Aber:

  • “Open” und “Dezentral” sind keine Argumente um sich bei einer neuen Plattform anzumelden (zumindest nicht für die breite Masse).
  • Es ist idiotisch wenn jede Community ihr eigenes “Dezentralisierungsprotokoll” entwickelt… das führt nämlich dazu, dass Diaspora und StatusNET zwar beide dezentral sind, aber nur die eigenen Netzwerke unterstützen.
  • Jedes neue Protokoll (mal abgesehen von OStatus) erfindet das Rad neu anstatt auf bisherigen Formaten aufzubauen. Warum muss alles JSON sein? RSS und Atom kann jedes Blog und mit ein bisschen “Zauberei” reicht das vielleicht schon aus.
  • “Open Source” und die Möglichkeiten das Projekt selber zu hosten überzeugt nur Geeks!

Wenn die großen Netzwerke wie Facebook, Twitter und Google+ sich nicht auf ein einheitliches Protokoll einigen, wird es wohl nichts mit der “dezentralen” Idee! Ich möchte mich in Zukunft für eine Community entscheiden die meinen Interessen und Wertvorstellungen entspricht und nicht von der Mehrheit meiner Freunde abhängig sein. Wenn alle meine Freunde aber bei Facebook sind, bleib ich auch auf einem offenen und dezentralen Diaspora alleine!

Wir brauchen eine Art XMPP oder POP3/SMTP für soziale Interaktionen, unabhängig von einer spezifischen Plattform und trotzdem von allen unterstützt! Und dann haben auch kleine und unabhängige Projekte wie Diaspora und StatusNET wieder eine echte Chance! Die Zeit die bisher in Spezifikationen aller Art fließt sollte dazu genutzt werden, zuerst einmal Facebook und Google von dem Problem zu überzeugen und sie mit ins Boot zu holen.

…das ist übrigens das Thema meiner Kolumne im nächsten Screengui-Magazin. Also kaufen!

Posted on
by

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');

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>

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.org

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')

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.

Posted on
by

HTML5 Semantics BadgeBeim “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.

The http://schema.org/Thing

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)…

rich snippets example

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

Google+ Example

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.

Googles Umgang mit Schema.org

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>

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.