Kategorie: Open Web

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

  • So, nachdem sich doch einiges bei Optimus[1] und Operator[2] geändert hat, hab ich auch mal mein Optimus User Script auf den neusten Stand gebracht.

    Änderungen seit der letzten Version:

    • URL von document.commandDispatcher.focusedWindow.document.URL auf semanticObject.node.ownerDocument.URL umgestellt.
    • Support für hAudio und hListing hinzugefügt

    Den Download findet ihr hier: Optimus User Script

    [1] Optimus ist ein Microformats-Parser auf Basis von XSLT.
    [2] Operator ist ein Firefox-Addon zum visualisieren und verarbeiten von Microformats.

  • Wer den Parser der SocialGraph API einmal testen will, um z.B. zu sehen welche Links einer Seite schon vom Google-Index erfasst wurden, dem bietet Google eine einfache Parser Testing API.

    As a testing and debugging aid, the Social Graph API includes an API to run any document against the Social Graph API’s internal parser to see what it would’ve parsed, had Googlebot actually crawled it.

    Und für faule Menschen wie mich gibts von Google auch gleich noch ein Greasemonkey script dazu 🙂

    Ich glaube der Schmiermaxe und ich werden noch richtig dicke Freunde!

  • Optimus Transformer hat ne ganze Menge neuer Features spendiert bekommen, unter anderem auch Support für zwei der neueren Microformats hListing und hAudio.

    Alle neuen Features:

    • support of nested microformats
    • support of multiple includes
    • support of nested includes
    • support of anchor (you can use URL like http://example.com#my-vcard to narrow the target)
    • support of @couldbe attribute (internal feature, now item in hreview, for example, could be vcard or vevent)
    • hfeed now is optional
    • support for vcalendar
    • fix for text spacing
    • fix for empty tags in output
    • hListing support
    • hAudio support
    • general performance improvement
    • add RSS as an output format
    • rewrite validator from scratch
    • better UTF-8 support

    Das ist mittlerweile ne ganz stattliche Liste an unterstützten Mikroformaten, wenn jetzt nur noch alle Optimus-Ähnlichen-Services ein einheitliches JSON-Format zurückgeben würden…

    …und ich sollte mich definitiv mal etwas mehr mit XSLT beschäftigen!

  • Albert de Klein beschreibt in seinem Artikel „Monkeyformats“ (und einigen Anwendungsbeispielen), dass man mit Hilfe von Greasemonkey, Webseiten nachträglich und relativ einfach mit Microformats auszeichnen kann.

    […] These client-side microformats work well with the Operator add-on and let you do microformatish things with websites that do not yet support microformats but might prove very useful as microformat examples. […] (via)

    Das Prinzip wirkt zwar auf den ersten Blick etwas umständlich, erspart einem aber letztendlich eine ganze Reihe an Arbeit. Microformats sind wohldefinierte Formate für die es schon eine ganzen Reihe an Programme und Services (z.B. Operator) gibt, die man mit Hilfe der Monkeyformats-Idee auch relativ einfach auf eigentlich „unsemantische“ Seiten anwenden kann.

    Funktionsweise

    greasemonkey-installation.jpg

    Nach der Installation einfach auf die entsprechende URL aufrufen (hier im Beispiel: www.thephonebook.bt.com) und schon wird aus einer normalen Webseite:

    without-greasemonkey.jpg

    …ein semantisches Feuerwerk 😉

    with-greasemonkey.jpg

    Um die Userscripts einfach finden zu können, sind alle mit „monkeyformats“ ge-tagged. Leider funktioniert das einzige Script für einen Deutschen Service (DasTelefonbuch.de) nicht so richtig.

  • Man sollte doch meinen, dass bei einer Beschränkung auf 140 Zeichen nicht sehr viele Varianten möglich sind, strukturiert zu twittern…

    Schade 😉

    • microrevie.ws: @hreview Some Great Band; really exciting but too loud ****
    • LouderVoice: Review 5 A-Team season 2:awesome action series
    • Nanoformats-Bot: rate:1:Epic movie or rate:5:http://www.twitter.com/

    Schade dass es die Nanoformats nicht zum Standard geschafft haben bzw. einfach ignoriert werden…

  • Das hCardMapper WordPress Plugin hat jetzt sein eigenes Repository bei WordPress.org.

  • Wie in meinem letzten Post über den hCardMapper beschrieben, war es in der Tat nicht möglich den Microformats-Parser/Proxy ohne weitere Probleme auszutauschen. Die generierten JSON Formate der einzelnen Parser (ufXtract, hKit, mofo) unterscheiden sich an einigen Stellen zu sehr um sie alle gleich behandeln zu können. Soweit zur schlechten Nachricht…

    Die gute Nachricht ist, dass sich Gordon Oheim (der Macher des hCardMappers) nochmal alle JSON Formate vorgenommen und eine neue Version gebastelt hat:

    v0.94 – Added better support for JSON returned by Optimus, ufXtract and hKit.

    Der Mapper sollte also mit mofo, Optimus, ufXtract and hKit problemlos funktionieren.

    Die nächste tolle Nachricht ist, dass Gordon auch auf einen kleinen Änderungswunsch von mir sofort eingegangen ist, so dass wir euch jetzt eine hCardMapper Edition von dem WordPress hCard-Commenting Plugin anbieten können :).

    Download: hCardMapper for WordPress v0.1 hCardMapper bei WordPress.org

    Wenn ihr immer die aktuelle Version haben wollt, hier ist der Link zum SVN.

    Ich hab das Plugin auch mal auf notizBlog aktiviert und würde mich über euer Feedback freuen. Macht es Sinn über das Admin-Menü zwischen beiden Versionen (hCard-Commenting und hCardMapper-Commenting) zu wechseln?

    Ein dickes Danke nochmal an Gordon für seine tolle und schnelle Arbeit… tolles Script.

  • Um auf die im HTML-Quellcode verwendeten Microformats hinweisen zu können, wurden vom Microformats-Team jetzt einheitliche Profile URIs veröffentlicht. Berücksichtigt wurden alle non-draft Microformats (Stand: März 2008) ausgenommen XOXO und XMDP:

    SpecificationProfile(s)
    geo http://purl.org/uF/geo/0.9/
    hAtom http://purl.org/uF/hAtom/0.1/
    hCalendar http://purl.org/uF/hCalendar/1.0/
    hCard http://www.w3.org/2006/03/hcard or http://purl.org/uF/hCard/1.0/
    hResume http://microformats.org/wiki/hresume-profile
    rel-license http://purl.org/uF/rel-license/1.0/
    rel-nofollow http://purl.org/uF/rel-nofollow/1.0/
    rel-tag http://purl.org/uF/rel-tag/1.0/
    VoteLinks http://purl.org/uF/VoteLinks/1.0/
    XFN http://gmpg.org/xfn/11

    Eine komplette Übersicht findet man auch über purl.org/uF/2008/03/ oder im Microformats Wiki.

    Diese URIs können, gemäß der W3C namespace policy <head /> der HTML Datei angegeben werden. Beispiel:

    <head profile="http://www.ietf.org/rfc/rfc2731.txt
                   http://www.w3.org/2006/03/hcard
                   http://purl.org/uF/hAtom/0.1/">Code-Sprache: HTML, XML (xml)

    Quelle: ‘This Week in Microformats’ für März.

  • …oder How to use hCards to fill in forms.

    hCardMapper ist eine JavaScript-Klasse (basierend auf Prototype) um Kontakt- oder Profil-Formulare mit Hilfe einer hCard automatisch zu füllen, ähnlich wie bei bragster.com oder getsatisfaction.com.

    Das schöne an hCardMapper ist seine flexible Struktur. Die JavaScript Klasse ist so aufgebaut, dass sie eigentlich Microformats-Parser unabhängig funktionieren sollte, da sie die Daten über einen „Proxy“ abfrägt. Die einzige Vorgabe ist, dass dieser Proxy eine JSON formatierte hCard (jCard) zurückgibt. Das Problematische an dieser Variante ist, dass jeder Parser unterschiedliche Ergebnisse liefert… ich werde es heute abend mal mit dem hKit-Parser testen.

    Ein weiter Vorteil ist die Formular-Unabhängige Programmierung die es ermöglicht, das Script auch problemlos auf vorhandene Formulare anzuwenden. Über mappnings werden die hCard-Attribute den entsprechenden Formular-Felder zugeordnet.

    Event.observe(window, 'load', function() {
      hcr = new com.omniacomputing.HCardMapper({
        register: true,
        proxy: '/hcardmapper/hcard?uri=',
        insertBelowEl: 'hcr-hook',
        mappings: {
          given_name: 'first',
          family_name: 'last',
          tel: {tel: 'phone', work: 'phone', cell:'phone'},
          email: 'email',
          org: {org: 'company', organization_name: 'company'},
          url: 'website',
          street_address: 'street',
          postal_code: 'zip',
          locality: 'town' 
        }
      })
    });Code-Sprache: JavaScript (javascript)

    Quelle: http://lib.omnia-computing.de/hcardmapper

    Tolle Idee, mal schau’n wie gut das Script mit den (oben schon erwähnten) unterschiedlichen Verarbeitungsweisen der Parser umgeht…

  • Anfang Februar habe ich einen interessanten Bericht über „How portable is your Skype data?“ von Phil Wolff gelesen. Der Artikel befasst sich mit der Daten-Portabilität von Nicht-Web-Applikationen am Beispiel von Skype. Leider wird diese Art des Datenaustauschs (z.B. zwischen Desktop-Anwendungen und Web-Anwendungen) auch von DataPortability.org noch nicht ausreichend behandelt und es fehlen Formate die diese Art von Austausch ermöglichen (APML mal ausgenommen).

    Genau diesen Bericht müssen auch Microsoft und Google gelesen haben bevor beide diesen Monat ihre Contacts-APIs veröffentlichten 🙂

    Nach den Beschreibungen von Google:

    • Import a user’s Google contacts into their web or desktop application
    • Export their application’s contact list to Google
    • Write sync applications for mobile devices or popular, desktop-based contact management applications

    …und Microsoft:

    To tackle the issue of contact data portability it is important to reconcile the larger issue of data ownership. Who owns the data, like email addresses in a Windows Live Hotmail address book? We firmly believe that we are simply stewards of customers’ data and that customers should be able to choose how they control and share their data. We think customers should be able to share their data in the most safe and secure way possible, but historically this openness has been achieved largely through a mechanism called “screen-scraping,” which unduly puts customers at risk for phishing attacks, identity fraud, and spam. Now with the Windows Live Contacts API, we have provided an alternative to “screen-scraping” that is equally open but unequivocally safer and more secure for customers.

    …könnte man fast meinen, dass die Hürde des Datenaustauschs zwischen Desktop-Anwendungen und Web-Anwendungen überwunden wäre.

    Nicht ganz… Leider basieren beide Systeme „noch“ auf proprietären Webservices und müssen unterschiedlich angesprochen werden, was eine Menge zusätzlichen Entwicklungsaufwand bedeutet. Die wesentlich bessere Lösung wäre natürlich eine einheitliche Contacts-API oder wie Carsten Pötter meint:

    Of course, it was great if a more open protocol like OAuth was used, but the announcement might encourage more social networks and other corporations to pursue similar steps.

    Immerhin gehören die Social-Network-Anti-Patterns durch diese Entwicklungen hoffentlich bald der Vergangenheit an…