Reaktionen sichtbar machen

Der Austausch über Blogartikel steht für mich schon immer im Mittelpunkt. In den Artikeln werden Ideen, Gedanken und Erfahrungen beschrieben, diese stehen jedoch nicht nur für sich selbst, sondern werden von den Reaktionen der Leserinnen und Leser ergänzt. Anfangs wurde engagiert kommentiert. Durch Twitter und Facebook fand schließlich der Austausch meist auf den entsprechenden Plattformen statt, und beschränkte sich in vielen Fällen auf den Ausdruck des Gefallens. Viele Kommentarspalten blieben leer, und die Artikel wirkten leblos. Die Reaktionen darauf war im Blog selbst nicht sichtbar. Social-Buttons mit ihren Tracking-Skripten stellten für mich keine Lösung dieses Problems dar. Den Austausch über die Inhalte verwandeln sie in Zahlen, die Qualität desselben bleibt jedoch weiterhin verborgen. Einen Mehrwert für das Blog und dessen Community stellen sie nicht dar, sondern dienen vor allem den Plattformen als Datenlieferanten.

Bereits vor einigen Jahren erfuhr ich von der IndieWeb-Bewegung, die vernetzte Inhalte sichtbar machen wollte, den Zugriff auf die eigenen Daten betonte und an vielen Stellen interessante Projekte hervorbrachte. In diesem Zusammenhang las ich bei Jeremy Keith über Webmentions.

Die Annahme über zu wenig Wissen und Zeit zu verfügen um mich selbst an die Implementation von Webmentions zu machen, führte dazu diesen Bereich ruhen zu lassen, und schließlich nichts dergleichen zu unternehmen. Erst als ich im Nachklang der Smashing Conference in Freiburg den Artikel »Implementing Webmentions« von Drew McLellan las, fasste ich den Entschluss die Reaktionen auf Inhalte in Blogs endlich wieder sichtbar zu machen.

Da ich gerade an ein paar Projekten arbeite die auf WordPress basieren und ich meine eigenen Blogs ebenfalls damit betreibe, widme ich mich an dieser Stelle der Implemantation von Webmention in mit WordPress betriebene und selbst gehostete Blogs.

Was ist zu tun?

Um Webmention mit WordPress zu benutzen sind vier Schritte nötig.

  1. Installation des Webmention-Plugins
  2. Installation des Plugins für Semantic-Linkbacks
  3. Social-Media-Profile via Bridgy mit dem Blog verbinden
  4. Das eigene Comment-Template anpassen

Das Webmention-Plugin

Das Webmention-Plugins von Matthias Pfefferle erweitert die Diskussion-Einstellung eines WordPress-Blogs, und legt die Grundlage dafür, dass ein Blog Webmentions senden und empfangen kann.

Nachdem das Plugin heruntergeladen, installiert und aktiviert ist stehen unter Einstellungen > Diskussion ein paar weitere Einstellungen zur Verfügung. Achte auch darauf, dass die allererste Einstellung »Versuche, jedes in Beiträgen verlinkte Weblog zu benachrichtigen« ausgewählt ist.

Unter Webmention Settings befinden sich vier Checkboxen und eine Auswahl mit deren Hilfe sich das Verhalten der Webmentions einstellen lassen.

Das Plugin für Semantic-Linkbacks

Das Plugin für Semantic-Linkbacks bietet die Möglichkeit die empfangenen Webmentions je nach Typ unterschiedlich zu behandeln. Es weist den empfangenen Erwähnungen einen entsprechenden Typ – beispielsweise Like, Repost oder Mention – zu, der als Filter und für die Styles zur Verfügung steht.

Eine Übersicht der Einstellungen bringt dieses Plugin nicht mit, es verrichtet seine Dienste sobald es aktiviert ist. Im IndieWeb-Wiki erfährst Du etwas über die Möglichkeiten die zugewiesenen Typen in Deinem Theme zu verwenden. Wie ich die Typen verwende beschreibe ich etwas später in diesem Artikel.

Update 15.10.2017:
Seit Version 3.5.0 unterstützt dieses Plugin die Darstellung von Likes, Mentions und Reposts in eigenen Listen. Dadurch wurde die Anpassung meines Comment-Template obsolet.

Brücken bauen

Der Dienst Bridgy baut die Brücken zwischen Deinen Social-Media-Profilen und Deinem Blog. Er überwacht die verbundenen Social-Media-Profile und sendet Erwähnungen ans Blog. Deine Social-Media-Profile müssen öffentlich sein und die URL Deines Blogs muss dort hinterlegt sein. Wichtig ist auch, dass die Post öffentlich sind, nur so können sie von Bridgy ausgelesen werden.

Auf brid.gy wählst Du also die Social-Media-Kanäle aus über die Du Erwähnungen empfangen möchtest. Sobald Du Bridgy den Zugriff auf Deine Profile gestattet hast, beginnt es damit alle 30 Minuten nachzusehen ob es dort eine Erwähnung Deines Blogs gibt. Wird es fündig sendet es die Erwähnung als Kommentar an Dein Blog.

Das Comments-Template

Um die Erwähnungen zu Bündeln habe ich mein Comments-Template und das Stylesheet etwas angepasst. Zur Anpassung meines Comment-Templates habe ich mich an diesem Code von Michael Bishop orientiert. Mein aktuelles Comments-Template kannst Du in diesem Gist ansehen.

Likes und Reposts sammle ich in einer Liste und verlinke lediglich die Profilbilder mit den jeweiligen Accounts. Danach gebe ich eine Liste der Kommentare aus – in dieser Liste erscheinen bei mir Antworten von Twitter, Kommentare von Facebook und die klassischen Kommentare. In einer Liste unter den Kommentare gebe ich Erwähnungen des Artikels in anderen Blogs aus.

Verbesserungen

Bei meinen ersten Schritten mit Webmention sehe ich Verbesserungspotential in den folgenden Punkten:

  • Links auf den Namen der Autor_inn_en korrigieren
  • Baumstruktur der Kommentare darstellen
  • Profilbilder optimieren und auf den eigenen Server speichern
  • Den Callback der manuellen Webmention-Eingabe optimieren

Ich freue mich von Euch zu hören wenn Ihr Ideen habt wie einer dieser Punkte gelöst werden kann, aber auch wenn Euch noch weitere Verbesserungen einfallen.

Benson Coffee

Den Kaffee von Benjamin Pozsgai wählte eine internationale Jury zum besten des Wettbewerbs und machte ihn zum Deutschen Röstmeister. Als solcher vertritt er Deutschland diesen Winter bei der Weltmeisterschaft in China.

Um auch bei der Weltmeisterschaft die Kaffees optimal zu rösten, bereitet er sich gerade gründlich vor. In den geplanten Trainingseinheiten wird er sorgfältig ausgewählte Kaffees rösten, und dabei auf die Besonderheiten der Bohnen achten um das Beste aus ihnen herauszuholen.

Benjamin Pozsgai hat ein Konzept erarbeitet, das vielen Kaffeeinteressierten die Möglichkeit gibt Teil der Vorbereitungen auf die Weltmeisterschaft zu werden: Das Benson Coffee Abo. Für das Abo wird nach jeder Trainingseinheit die beste Röstung ausgewählt und an die Abonnenten verschickt. Wer auf hochwertige Kaffees steht hat mit diesem Abo die Möglichkeit fünf ganz besondere Kaffees zu bekommen, und sollte sich diese Gelegenheit nicht entgehen lassen.

Bildschirmfoto der Webseite von Benson Coffee – Benjamin Pozsgai

Ich hatte die Möglichkeit für Benson Coffee meine Begeisterung für Kaffee und Webdesign zu verbinden. Auf diesem Weg entstand eine Webseite die über die Vorbereitungen zur Weltmeisterschaft informiert und über die das Kaffeabo bezogen werden kann.

Wer sich das Abo nochmals von Benjamin Pozsgai erklären lassen möchte kann das mit diesem Video tun:

Projektbeteiligung

Die Corporate Identity für Benson Coffee wurde von Marc Böttler entwickelt.

Meine Aufgabe bestand darin das Konzept der Webseite auszuarbeiten. Die Corporate Identity auf ein Interface Design zu übertragen und schließlich die Webseite mit integriertem Webshop und Blog umzusetzen.

Die Vorteile von SVG nutzen

Skalierbare Vektor Grafiken (SVG) bevorzuge ich schon seit längerem zur Darstellung von Logos und Icons in Webseiten. Sie bringen eine ganze Reihe von Vorteilen mit, die ich nicht mehr missen möchte.

Die Hauptvorteile von SVG werden direkt in ihrem Namen ausgedrückt. Es handelt sich dabei um Vektorgrafiken die verlustlos skalieren und auf allen Ausgabegeräten gestochen scharf dargestellt werden. Da es sich bei SVG um Vektorgrafiken auf Codebasis handelt, lassen sie sich sehr gut optimieren und versionieren, können mit CSS und JavaScript angesprochen werden, verstehen Media-Queries und sind darüberhinaus noch für den barrierearmen Einsatz geeignet.

Laut caniuse.com können etwas mehr als 97% der Browser SVG darstellen. Deshalb ist in vielen Anwendungsbereichen – beispielsweise wenn sie als Icon einen Text ergänzen – kein Ersatz erforderlich. Da ich SVG auch für Logos einsetze, muss sichergestellt sein dass die Grafik immer erscheint.

Um alle Vorteile von SVG nutzen zu können, müssen diese direkt im HTML eingebunden werden. Um darüber hinaus noch den Zwischenspeicher der Browser nutzen zu können, lade ich sie als erstes Element im body und binde sie über use an den entsprechenden Stellen der Webseite ein.

Die Vorteile von SVG nutzen

Um zu demonstrieren wie SVG meiner Ansicht nach optimal genutzt werden habe ich eine kleine Liste mit Links zu meinen Social-Media-Profilen erstellt. Vielleicht ist jetzt ein guter Zeitpunkt die Demo und den Code in einem neuen Tab zu öffnen. Die Links zum jeweiligen Profil werden durch das Logo der Plattform dargestellt. Um die Serveranfragen so gering wie möglich zu halten, fasse ich alle Logos in einer Datei (Spritesheet/Sprite) zusammen.

Das SVG-Sprite sieht folgendermaßen aus:

<svg xmlns="http://www.w3.org/2000/svg" display="none" height="0" width="0">
  <symbol id="twitter" viewBox="0 0 512 512">
    <path fill="currentColor" d="m456 133c-14 7-31 11-47 13 17-10 30-27 37-46-15 10-34 16-52 20-61-62-157-7-141 75-68-3-129-35-169-85-22 37-11 86 26 109-13 0-26-4-37-9 0 39 28 72 65 80-12 3-25 4-37 2 10 33 41 57 77 57-42 30-77 38-122 34 170 111 378-32 359-208 16-11 30-25 41-42z"/>
  </symbol>
  <symbol id="instagram" viewBox="0 0 512 512">
    <path fill="currentColor" d="m256 152c-52-1-100 43-103 95a103 103 0 0 0 200 43 104 104 0 0 0 -97-138zm0 169c-40 2-74-40-65-79 7-40 54-65 91-48 36 14 52 63 31 95a66 66 0 0 1 -57 32zm131-171c1 20-27 31-41 16-14-14-3-41 17-40 13 0 24 11 24 24z"/>
    <path fill="currentColor" d="m424 89c-25-27-64-35-100-33-54 0-109-1-164 1-43 2-85 31-98 73-10 32-5 66-6 98 0 42-1 84 1 126 3 46 37 87 81 98 30 7 62 3 92 4 42 0 83 1 124-1 44-3 85-33 96-76 9-32 5-64 6-97 0-41 1-83-1-125-2-25-13-50-31-68zm-3 250c1 35-23 70-57 77-28 5-56 2-83 3-40-1-80 1-120-1-32-2-61-26-66-58-4-28-1-57-2-86 1-38-1-76 1-114 2-32 26-60 58-65 29-4 59-1 88-2 38 0 76-1 113 1 33 2 62 29 66 62 3 30 1 61 2 92z"/>
  </symbol>
  <symbol id="facebook" viewBox="0 0 512 512">
    <path fill="currentColor" d="m287 456v-182h61l9-72h-70v-45c0-21 6-35 35-35h38v-63c-7-1-29-3-55-3-54 0-91 33-91 94v52h-62v72h62v182z"/>
  </symbol>
</svg>

Das jeweilige Logo befindet sich innerhalb eines symbol welches mit der entsprechenden ID versehen ist und über die viewBox die Zeichenfläche vorgibt innerhalb der die Pfadangaben gedeutet werden. Wird dieses Sprite als erstes Element im body eingefügt, lässt sich das jeweilige Symbol mit den folgenden Zeilen einbinden:

<svg class="social-icon">
  <use xlink:href="#twitter"></use>
</svg>

Ich binde das Sprite im body ein, da alle Version des Internet Explorer und ältere WebKit-Browser extern eingebundenen SVG nicht unterstützen. Das symbol lässt sich direkt über seine ID ansprechen, und muss nicht wie in CSS durch die Position angesteuert werden.

Bevor ich das Sprite einbinde, überprüfe ich ob der Browser in der Lage ist direkt eingebundene SVG darzustellen:

var supportsSvg = function() {
    var div = document.createElement("div");
    div.innerHTML = "<svg/>";
    return (div.firstChild && div.firstChild.namespaceURI) === "http://www.w3.org/2000/svg";
};

Um das Sprite per Ajax zum body hinzuzufügen übernehme ich die Funktion von Chris Coyer:

function getSVG() {
    var ajax = new XMLHttpRequest();
    ajax.open("GET", "./assets/images/sprite.svg", true);
    ajax.responseType = "document";
    ajax.onload = function() {
        document.body.insertBefore(ajax.responseXML.documentElement, document.body.childNodes[0]);
    };
    ajax.send();
};

Kann der Browser mit direkt eingebundenen SVG umgehen, passe ich die Klasse entsprechend an und füge ich das Sprite mittels Ajax als erstes Element zum body hinzu:

if (supportsSvg()) {
    document.documentElement.className += " svg";
    getSVG();
} else {
    document.documentElement.className += " no-svg";
};

Das Sprite ist nun eingebunden, und die Symbole erscheinen an den gewünschten Stellen. Die Links zu den Profilen habe ich wie buttons gestaltet und möchte die Hintergrundfarbe und die Farbe des Icons kontrollieren. Dazu verwende ich folgende CSS-Deklarationen:

a .social-icon,
a:visited .social-icon {
  background-color: rgb(51, 51, 51);
  border-radius: 15%;
  color: rgb(255, 255, 255);
  display: block;
  height: 2.75rem;
  padding: 0.1875rem;
  width: 2.75rem;
  transition: background-color 0.3s ease-out,
    color 0.3s ease-out;
}

a:hover .social-icon,
a:focus .social-icon {
  background-color: rgb(0, 153, 0);
  color: rgb(250, 250, 250);
}

Momentan sind die Links sowohl von funktionierendem JavaScript und der SVG-Unterstützung des Browsers abhängig. Für den Fall, dass entweder das eine oder das andere nicht zur Verfügung steht benötige ich einen Ersatz. Als Ersatz biete ich ein PNG-Sprite an welches ich als Hintergrundbild lade und über die Position des Hintergrunds jeweils das entsprechende Icon anzeige. Dieses Sprite enthält dieselben Icons auf transparentem Hintergrund. Da ich dem html die entsprechenden Klassen mitgebe könnte ich den Ersatz folgendermaßen einbinden:

.no-js .social-icon,
.no-svg .social-icon {
  background-image: url("./assets/images/sprite.png");
  background-repeat: no-repeat;
}

.no-js .social--twitter .social-icon,
.no-svg .social--twitter .social-icon {
  background-position: 0 0;
}

.no-js .social--instagram .social-icon,
.no-svg .social--instagram .social-icon {
  background-position: -3.125rem 0;
}

.no-js .social--facebook .social-icon,
.no-svg .social--facebook .social-icon {
  background-position: -6.25rem 0;
}

Da ich die Klasse no-js meinem Template mitgebe, führt diese Methode dazu, dass die Browser bei jedem Aufruf auch das PNG-Sprite laden, da mein Script die Klasse no-js erst dann mit js ersetzt wenn das DOM geladen ist. Ich möchte allerdings nur das Sprite laden welches auch tatsächlich verwendet wird.

Um den doppelten Download des Sprites zu umgehen entferne ich den Selektor .no-js .social-icon aus meinem Stylesheet, und füge ihn innerhalb eines noscript dem head meines Templates hinzu.

<noscript>
    <style>
        /* TODO: keep sprite in sync with .no-svg .social-icon */
        .no-js .social-icon {
            background-image: url("./assets/images/sprite.png");
        }
    </style>
</noscript>

Wichtig ist, dass die Sprite-Referenz jederzeit synchron ist. Um dies nicht zu vergessen versehe ich die entsprechenden Stelle mit einem Kommentar. Solange sich Name und Ort des Sprites nicht ändern dürfte es an dieser Stelle jedoch zu keinem Problem kommen.

Die Vorteile von SVG lassen sich meiner Ansicht nach auf diese Weise ideal nutzen. Auch wenn die Funktionalität eines PNG-Sprites nicht exakt einem SVG-Sprite entspricht, bleibt der Wiedererkennungswert erhalten, und die notwendigen Informationen stehen allen Nutzer_inn_en der Webseite zur Verfügung.

Verwendete Ressourcen:

Alles auf einen Blick

Meine Hilfsmittel

Meine Hilfsmittel

Konzept

Um meine Ideen und Gedanken zu konkretisieren helfen mir Stifte, Papier und Schere. Daher befinden sich in meiner unmittelbaren Nähe immer ein paar Stifte, etwas Papier (lose und gebunden) und eine Schere. Meistens greife ich bei der Erstellung eines Konzepts zu meinem iPad und erstelle mit Paper Skizzen des Interfaces und der Interaktionen. Diese Skizzen lassen sich später leicht in andere Programme übertragen.

Schreiben

Kein Konzept und keine Zeile Code entsteht ohne einen guten Editor. Seit einer Weile schreibe ich meinen gesamten Code mit Atom, dem Editor von Github. Neben einigen hilfreichen Erweiterungen bringt Atom auch eine übersichtliche Hervorhebung der Änderungen zur letzten eingecheckten Version mit.

Die meisten Texte schreibe ich in Markdown und verwende dafür iA Writer. Ich habe diesen Editor seit der ersten Version auf allen meinen Geräten und habe mittels iCloud-Synchronisierung die Möglichkeit in den unterschiedlichsten Situationen daran weiter zu arbeiten. Selbst meine Aufgabenliste verwalte ich mit iA Writer.

Grafik

Während früher Photoshop eine wichtige Rolle bei der Entstehung eines grafischen Interfaces spielte, ist bei mir heute wesentlich öfter Sketch oder Illustrator geöffnet. Bei Illustrator gefallen mir vor Allem die Entwicklungen im Zusammenhang mit der Bearbeitung und Ausgabe von SVGs.

Lokale Prozesse

Ich entwickle komplett lokal, weshalb ein stabiler lokaler Server nicht fehlen darf. Dafür steht mir MAMP Pro zur Seite. Durch die Verwendung von Sass und Coffee Script benötige ich CodeKit, das mir den Code kompiliert, komprimiert und das gesamte Projekt schließlich in einem Build-Ordner zur Verfügung stellt. Die Browser-Synchronisierung nach jedem Speichervorgang möchte ich nicht mehr missen.

Zur Komprimierung von Bildern, die nicht innerhalb eines CodeKit-Projektes liegen, verwende ich ImageOptim, und freue mich über diese einfache Möglichkeit grafisch zuverlässige Bildkompression auf dem Rechner zu haben.

Veröffentlichung

Zur Versionierung der Projekte an denen ich arbeite verwendete ich bis vor Kurzem ausschließlich Tower. Seitdem ich das Buch ›Git for Humans‹ von David Demaree gelesen habe, verstehe ich Git besser, und ziehe in den meisten Fällen das Terminal vor. Ich habe sowohl bei GitHub als auch bei BitBucket diverse Verzeichnisse.

Meine eigenen Seiten liegen seit einiger Zeit bei Uberspace. Mit den Servern dort kommuniziere ich entweder mit dem Terminal per SSH oder via SFTP mit Transmit.

Zur Verwaltung von MySQL-Datenbanken verwende ich Sequel Pro. Gerade für den Import und Export von größeren Datenbanken ist diese App unverzichtbar.

Zeiterfassung

Meine Arbeitszeit erfasse ich mit Timings. Rechnungen und Angebote erstelle ich auf der Basis der erfassten Zeiten mit Numbers.

Lokaler Server

Seit Februar darf ich einem Grafiker, dessen Arbeit ich sehr schätze, einen Workshop zum Designprozess im Browser geben.

Wir folgen dabei der mobile-first-Philosophie, die auf Luke Wroblewski zurückgeht, und entwickeln daher ein Interface unter besonderer Berücksichtigung des mobilen Kontexts. Daraus ergibt sich die Notwendigkeit direkt auf einem Smartphone testen zu können.

Test on real Devices

Um eine lokale Datei auch im Browser des Smartphones auszugeben, benötigen wir den Zugriff auf das Verzeichnis in dem unser Projekt liegt. Im macOS sind dafür einige Möglichkeiten vorgesehen. Sehr gut geht es mit dem einfachen HTTP Request Handler von Python. Dieser antwortet auf HTTP-Anfragen mit Dateien aus dem aktuellen und den darunterliegenden Verzeichnissen.

Im Zusammenhang des Workshops habe ich folgende Anleitung geschrieben, mit deren Hilfe ein lokaler Server auf dem Mac genutzt werden kann.

Und so geht’s:

  1. Du öffnest das Projektverzeichnis im Finder, und startest das Terminal.

  2. Im Terminal wechselst Du in das Projektverzeichnis indem Du cd – change directory – eingibst und per Maus den Ordner ins Terminal ziehst. In der Zeile steht nun der Pfad zu Deinem Projektverzeichnis, den Wechsel bestätigst Du mit [Enter]. Nun befindet sich das Terminal im korrekten Verzeichnis.

  3. Den HTTP Request Handler startest Du in diesem Verzeichnis durch folgende Eingabe:

    python -m SimpleHTTPServer 8000

    SimpleHTTPServer wurde in Python 3 durch http.server ersetzt. Falls diese Eingabe bei Dir einen Fehler wirft, kannst Du über python --version die bei Dir verwendete Python-Version anzeigen. Wenn bei Dir eine Python 3 Version im Einsatz ist, startest Du den einfachen lokalen Server mit folgender Eingabe:

    python -m http.server 8000

    und bestätigst mit [Enter]. Das Terminal antwortet mit Serving HTTP on 0.0.0.0 port 8000 ..., und das Verzeichnis ist bereit auf Anfragen eines Browsers zu antworten.

  4. In die Adresszeile des Browsers tippst du die IP-Adresse Deines Macs gefolgt von der Portnummer, über die Deine Anfrage beantwortet wird: XX.XX.XX.XX:8000. Die IP-Adresse findest Du in den Netzwerkeinstellungen.

    Alternativ dazu kannst Du auch den Netzwerknamen Deines Rechners gefolgt von dem local-Hinweis verwenden, den Netzwerknamen erfährst Du in den Freigabeeinstellungen: mein-mac.local:8000.

  5. Um den HTTP Request Handler zu beenden gibst Du im Terminal [Ctrl]+c ein. Der Prozess wird abgebrochen, und es besteht keine Verbindung mehr vom Browser zum Projektverzeichnis.

Auf diese Weise kannst Du von allen Browsern, die Zugriff auf das Netzwerk haben in dem sich Dein Mac befindet, auf Dein Projekt zugreifen. Ohne ein weiteres Programm zu installieren bietet Dir Dein Mac damit die Möglichkeit Prototypen in allen möglichen Verzeichnissen zu testen. Dafür musst Du lediglich die oben aufgeführten Schritte durchgehen.

Video Thumbnails

Wenn ich ein Video von YouTube oder Vimeo teile, möchte ich dazu immer das passende Thumbnail verwenden, daher habe ich auch weiterhin Bedarf nach einem Tool welches mir dieses Bild möglichst einfach und schnell zur Verfügung stellt.

Im Juni 2012 veröffentlichte ich mein erstes Tool über video.depone.eu, mit dem es möglich war durch die Eingabe der Vimeo-ID eines Videos das entsprechende Thumbnail zu bekommen. Wurde aber das Thumbnail eines Videos gebraucht, das auf Youtube gehostet war, musste ein anderes Formular verwendet werden.

Dieses Tool war im Einsatz bis ich meinen Hosting-Anbieter wechselte. Nach dem Wechsel zögerte ich es direkt weiter zu betreiben, da sich die API von Youtube geändert hatte, und es somit nur noch teilweise funktionierte. Darüber hinaus wollte ich es gerne vereinfachen. Die Abfrage für Thumbnails sollte über ein Formular erfolgen, egal ob das Video bei Vimeo oder Youtube gehostet war. Und ich wollte es möglich machen, dass die gesamte URL des Videos ins Formular kopieren werden konnte.

Das Ziel war also gesteckt. Ich wollte das Tool vereinfachen und für die Abfrage der Thumbnails reines JavaScript verwenden. Die Frage nach dem richtigen Zeitpunkt war jedoch noch offen … als ich letzte Woche krankheitsbedingt eine Pause einlegen musste, bot sich die Gelegenheit die notwendigen Zeilen Code zu schreiben.

Für die Kommunikation mit der API von Vimeo hatte ich bisher nur Beispiele gefunden, die jQuery erfordern. Da mein kleines Tool unter 10kB liegt, erschien mir die Nutzung eines Frameworks mit 80kB als unangemessen, und so machte ich mich auf die Suche nach einer funktionierenden Abfrage der API mit reinem JavaScript. Um mit der API von Vimeo zu sprechen war ich dankbar um die Entwicklerseite von Mozilla und JS Bin, wo ich den Stand meines Wissens direkt testen konnte, die erfolgreiche Abfrage befindet sich in diesem Bin.

Und so nahm das überarbeitete Tool langsam Gestalt an:

Get Thumbnail of a Video

Den Code stelle ich in diesem Repository auf GitHub zur Verfügung. Auf diese Weise ist sichtbar wie es funktioniert, andere können direkt zum Code Ideen, Wünsche und Rückmeldungen abgeben und darauf aufbauen.

Ich habe das Tool auch deswegen auf GitHub veröffentlicht um es weiter zu entwickeln und hübscher zu machen. Momentan fehlen vor Allem noch Fehlermeldungen, die auf die Ursache aufmerksam machen, weshalb eine Abfrage nicht geklappt hat. Meine Idee, das Thumbnail eines Videos per Copy & Paste und einen Klick zu bekommt erfüllt es.

Feedback könnt ihr mir gerne als Kommentar, Nachricht oder per Twitter zukommen lassen.

Feeds

Anfang Dezember fragte ich im Anschluss an einen kurzen Austausch auf Twitter in die Runde wer Feeds benutzt. Mich interessierte ob und wie sie benutzt werden. Dass diese Stichprobe keine belastbaren Daten liefern würde, war mir klar, dennoch interessierte es mich einen Blick darauf zu werfen in welche Richtung der Trend weisen würde.

Ich leitete die Umfrage mit einer geschlossenen Frage ein, und machte es denen die keine Feeds nutzen einfach schnell fertig zu werden:

Nutzung von Feeds

Der Blick auf das Ergebnis dieser Frage überraschte mich. Ich nutze im weiteren Sinne zwar die Feeds von Twitter und Instagram, habe aber keine Blogs oder Zeitungen abonniert. Von den 35 Personen, die antworteten gaben nur vier an keine Feeds abonniert zu haben. Die Abos der anderen verteilen sich auf folgende Angebote:

Blogs – 28
Podcasts – 18
Nachrichten – 11
Bilder – 6

Mehr als die Hälfte der Antwortenden hat über 50 Feeds abonniert. Journalismus, Religion, Design, Politik, Musik, Kunst und Webentwicklung sind die Themen, die am Häufigsten ausgewählt wurden. Der berufliche Hintergrund des größten Teils der Antwortenden liegt im Bereich Design, Webentwicklung und Religion.

Dieser kurze Einblick erinnerte mich wieder daran, dass es weiterhin sinnvoll ist die Möglichkeit anzubieten Inhalte auch per Feed abonnieren zu können.

Designing for Touch

In seinem Buch Designing for Touch teilt Josh Clark sein Wissen über den Umgang mit Touch-Devices. Um mir den Inhalt des Buches besser merken zu können, nahm ich mir heute vor zu jedem Kapitel einen kurzen Abschnitt aufzuschreiben.

Webseiten befinden sich im Browser, und sind daher mit einer App innerhalb eines Emulators zu vergleichen. Der Browser gibt einige Interaktionen vor und nimmt ein paar Entscheidungen über die Platzierung von wichtigen Elementen vorweg, da er selbst mit einer Adress- und Werkzeugleiste daherkommt, und immer schon einen gewissen Platz auf dem Display einnimmt. Da ich mich hauptsächlich mit Webseiten beschäftige, stelle ich diesen Aspekt voran.

Eine physische Schnittstelle: Darstellung der Inhalte und die Interaktion mit denselben teilen sich einen Bereich. Die Trennung von Darstellungsbereich und Eingabegeräte, die bei der Computernutzung üblich ist, entfällt. Daher muss darauf geachtet werden, wie sich die unterschiedlichen Ansprüche das Touch-Display teilen. Inhalte sollten durch die Interaktion nicht verdeckt werden. Um das Verdecken der Inhalte zu vermeiden, sollten sie sich stets über wichtigen Interaktionselementen befinden. Clark führt im ersten Kapitel darüberhinaus noch einige sehr gute Beobachtungen dazu an, wie die unterschiedlichen Touch-Devices gehalten werden, und welche Bereiche jeweils gut zu erreichen sind. Dieser Teil des Kapitels erschien auch auf A List Apart.

Designing for Touch, Josh Clark

Der unzuverlässige Bildschirm: Die Bedienung mit den Fingern ist wesentlich ungenauer als mit der Maus oder einem Stift, daher sollte die Interaktion so robust wie möglich sein. Als Faustregel für Interaktionselemente empfiehlt Clark eine Mindestgröße von 44 Pixeln. Sollen diese Elemente am Bildschirmrand oder direkt nebeneinander angeordnet werden, sollte ein Abstand von 13 Pixeln eingehalten werden, oder aber die Elemente entsprechend größer ausfallen. Für die Bemaßung der Elemente empfiehlt er rem, und falls ältere Browser unterstützt werden sollen Pixel als Fallback.

Schnelle Interaktion: Das Erfassen der Inhalte und die Interaktion damit sollte schnellst möglich geschehen. Zum Stichwort ›Progressive Disclosure‹ habe ich kürzlich schon etwas geschrieben. Bei der Interaktion kommt es nicht nur auf die Anzahl der Taps an, sondern vielmehr darauf, dass die einzelnen Schritte sinnvoll sind, ›Quality Tap‹ ist das entsprechende Stichworte. Die meisten Geräte bieten heute eine Vielzahl von Daten an, um den Nutzer_innen das bestmögliche Erlebnis zu ermöglichen ist es wichtig nur die absolut notwendigen Daten abzufragen, und die vorhandenen Daten so effektiv wie möglich zu verarbeiten.

Gesten sind die Short-Cuts der Touch-Devices. Hier ist noch viel Entwicklungspotential, gerade auch dafür, dass die Interaktionen auf den unterschiedlichen Geräten zum gewünschten Ergebnis führen. Clark empfiehlt sofern möglich click zu verwenden, und Gesten als Erweiterung zu nutzen. Es ist wichtig zu wissen welche Gesten bereits im System verwendet werden, und wo die Unterschiede zwischen den Systemen liegen. Durch die Verwendung von Gestern sollten die Nutzer_innen nicht verwirrt werden. Es gibt Möglichkeiten Pointer-Events, Touch-Events und click zu unterstützen, beginnt man diese jedoch selbst zu definieren und die übliche Integration zu umgehen, muss die gesamte Geste selbst definiert werden.

Entdeckung: Die Bedienung der Webseite sollte möglichst selbsterklärend sein. Die App sollte sich so verhalten wie die Nutzer_innen es erwarten. Er führt den Begriff ›Skeuomorphic Design‹ weiter und zeigt auf, wie wichtig es ist, dass die Interaktion zur Erscheinung des Elements passt (looks like = acts like). Es ist kein Problem, wenn eine Interaktion erklärt werden muss, davor sollen Designer_innen nicht zurück schrecken. Um das Erlebnis der Nutzer_innen bestmöglich zu gestalten, empfiehlt er sich ein Beispiel an Spiele-Entwicklern zu nehmen. In Spielen wird im Sinne des Coachings während der Nutzung erklärt, die Nutzer_innen werden begleitet und es werden immer wieder weiterführende Erklärungen eingeblendet. Erklärungen erscheinen immer genau dann wenn sie benötigt werden, und helfen den Nutzer_innen dabei die Geheimnisse des Spiels/der Webseite zu erfassen und belohnen sie auf diese Weise.

Touch-Devices bringen die Inhalte näher zu den Nutzer_innen, sie halten diese sprichwörtlich in Händen. Die Interaktion geschieht weitaus direkter als per Tastatur und Maus. Daher sollten Designer_innen diese Herausforderungen gerne annehmen und Wege des naheliegenden Umgangs mit den Inhalten suchen und weiterentwickeln.

Video in animiertes Gif konvertieren

convert-to-gif – Ein Skript um Videos in animierte Gifs zu konvertieren

Bascht hat ein Ruby-Skript geschrieben mit dem sich spielerisch Videos in animierte Gifs konvertieren lassen. Es heißt convert-to-gif und wird über die Konsole bedient.

Da die Konvertierung über die Konsole abgewickelt wird, öffnest Du diese am Besten direkt, und wechselst als erstes in den Downloads-Ordner.

$ cd ~/Downloads

Dann lädst Du das Skript mit folgendem Befehl herunter:

$ curl -O https://raw.githubusercontent.com/bascht/dotfiles-public/master/home/bin/convert-to-gif

und machst es ausführbar

chmod +x convert-to-gif

und verschiebst es in ein geeignetes Verzeichnis.

$ sudo mv convert-to-gif /usr/local/bin

Nun ist das Skript ausführbar und liegt im richtigen Verzeichnis.

Um ein Video zu konvertieren benötigt es ImageMagick und ffmpeg. Bevor Du eines dieser Tools installierst, testest Du am Besten kurz ob schon eine Version davon bei Dir läuft:

ImageMagick

$ convert -version

ffmpeg

$ ffmpeg -version

Falls die Tools auf Deinem System fehlen, kannst Du sie leicht mit Homebrew installieren:

$ brew install imagemagick
$ brew install ffmpeg

Nun hast Du alle notwendigen Vorbereitungen getroffen und kannst Dein Video in ein animiertes gif konvertieren. Das machst Du mit folgender Befehl:

$ convert-to-gif Dateiname [Breite] [FPS]

Der erste Parameter den Du an das Skript übergibst ist der direkte Pfad zur Datei die Du konvertieren möchtest. Ich ziehe dafür den Film direkt in die Konsole. Der zweite Parameter bezeichnet die Bereite der Datei, die Du ohne Einheit einträgst. Und als Drittes kannst Du die Framerate festlegen. Dieser Wert beeinflusst zum Einen die Flüssigkeit der Animation aber auch die Dateigröße.

Parameter zwei und drei sind optional. Trägst Du dafür keinen Wert ein, verwendet das Skript die Standardwerte 400 und 10. Es erzeugt dann ein animiertes gif mit einer Breite von 400 Pixeln und 10 FPS.

convert-to-gif, ein Skript von @bascht um Videos in animierte Gifs zu konvertieren

Die richtigen Inhalte anzeigen

Josh Clark schreibt in Designing for Touch darüber wie wichtig es ist, den Nutzer_innen die richtige Inhalte zum richtigen Zeitpunkt anzubieten. Am Beispiel von E-Mail-Programmen und Wetter-Apps erklärt er die Grundlagen von progressive Disclosure.

Die meisten E-Mail-Programme bieten Absender, Betreff und eine Vorschau der Nachricht an. Die Nutzer_innen entscheiden auf dieser Grundlage, ob sie die Nachricht öffnen um sie zu lesen und weiter zu bearbeiten, oder ob sie dies zu einem späteren Zeitpunkt tun.

Progressive Disclosure

Wetter-Apps verfahren ähnlich, sie bieten meist die grundsätzlichen Informationen zum Wetter mit einer Visualisierung und etwas Text an. Für die meisten Nutzer_innen genügt diese Information, diejenigen die mehr erfahren wollen finden weiterführende Informationen nach einer Interaktion.

Die Entscheidung welche Inhalte zu welchem Zeitpunkt angeboten werden, erscheint mir als ein wichtiger Schritt in der Entwicklung von Webseiten und Programmen. Wenn wir diese so treffen, dass die Nutzer_innen auf sinnvolle Weise zu den gewünschten Inhalten gelangen, erleben alle Beteiligten aufs Neue, dass gutes Design unsichtbar ist.

„Progressive disclosure favors clarity over density, so the trade-off is that you add extra taps to access the most detailed information. That’s okay. Creating faster interfaces isn’t always about reducing the number of interactions; it’s the quality that counts.“

Josh Clark, Designing for Touch. A Book Apart