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

Einen Freifunk-Knoten einrichten

Im November richtete ich einen Freifunk-Knoten im Büro 5&30 ein. Bevor ich gleich beschreibe wie ich den Knoten einrichtete, hier noch das kurze ›Freifunk verbindet‹-Video, in dem die Idee von Freifunk gut verständlich erklärt wird:

Einige Male hatte ich schon mit dem Gedanken gespielt einen Freifunk-Knoten einzurichten. Bei meinem letzten ernsthaften Gedanken brach ich das Unterfangen bei der Wahl eines Routers ab. Die Auswahl der Router mit denen ein Freifunk-Knoten erstellt werden kann erschlug mich.

Ende November wollte ich es dann aber wissen. Zugegeben, der Anlass war ein konkreter, für das gemeinsame Essen von Karlsruher_innen und Geflüchteten im NUN wollte ich ein funktionierendes und schnelles WLAN zur Verfügung stellen, und somit hatte ich ein Ziel vor Augen.

Kurz über Twitter nachgefragt, war die Auswahl auf 3–4 Geräte geschrumpft. Diese wurden rasch verglichen, und ich entschied mich für den TP-Link TL-WDR4300, der mir eine angemessene Leistung zu einem guten Preis bot.

Mit dem neuen Router auf dem Tisch öffnete ich erneut die Mitmachen-Seite von Freifunk Karlsruhe. Dort werden sowohl die passenden Firmware-Versionen angeboten, als auch einfache Anleitungen mit deren Hilfe aus einem handelsüblichen Router ein Freifunk-Knoten wird.

Falls sich bis zu diesem Zeitpunkt noch nicht das leise Gefühl ›Ich bin ein Nerd‹ eingestellt hat, tritt es spätestens bei dem Blick auf die Liste der Firmware-Downloads auf. Schnell ist die richtige Firmware gefunden und auf den Rechner geladen.

Mit frisch gefülltem Downloads-Ordner öffnete ich die erste Anleitung zum einspielen der Firmware. Bei mir klappte das Einspielen der Firmware bei Schritt 3 allerdings erst, nachdem ich den Dateinamen von

gluon-ffka-0.2.60~stable20151108-tp-link-tl-wdr4300-v1-sysupgrade.bin

in

gluon-sysupgrade.bin

geändert hatte. Falls Du beim Einspielen ebenfalls ein Problem hast, das Kürzen und Vereinfachen des Dateinamens könnte helfen.

Mit frisch eingespielter Firmware öffnete ich die Anleitung zum Einrichten des Freifunk-Knoten. Diese Anleitung führte ich mindestens fünfmal ohne Erfolg durch, bevor ich in den Expertenmodus wechselte.

Nachdem ich im Expertenmodus ein Passwort für den Knoten erstellt hatte, ließen sich die Schritte der Anleitung wunderbar durchspielen, und der Knoten speicherte diese anschließend brav. Einen Augenblick später erschien er auf der Karte aller Freifunk-Knoten in Karlsruhe. Ich freute mich, und steure seither einen Knoten zum freien und selbstverwalteten Funknetzwerk in Karlsruhe bei.

Freifunk-Knoten Büro 5&30, Karlsruhe

wemakeit wird 4

Am 6. Februar 2016 wird wemakeit, die Crowdfunding-Plattform in deren Entwickler-Team ich arbeite, vier Jahre alt. Den Geburtstag nimmt das Team zum Anlass die tollen Projekte zu feiern, die in den letzten Jahre durch die Crowd möglich wurden. Das Festival wird in Zürich im Club Kaufleuten stattfinden. Zur Finanzierung des Festivals gibt es, wie soll es anders sein, eine Crowdfunding-Kampagne:

Du kannst Dir durch die Unterstützung der Kampagne den Eintritt zum Festival sichern, und bekommst noch einige tolle Extras dazu. Ich werde zum Beispiel einige Tassen Kaffee zubereiten, dessen Genuss Du Dir schon jetzt mit einer Belohnung sichern kannst. Am Besten Du stöberst jetzt direkt in den Belohnungen und unterstützt die Kampagne.

Stylesheets und Skripte neu laden

Es ist gut, dass die Browser Stylesheets und Skripte zwischenspeichernd. Dadurch müssen sie nicht ständig neu geladen werden, was sowohl Datenvolumen als auch Zeit spart. Werden jedoch Änderungen durchgeführt, wünscht sich die Betreiberin der Seite natürlich, dass diese sofort sichtbar werden.

Vor Allem aber sollen die Änderungen direkt beim nächsten Besuch sichtbar sein, und es sollte kein weiterer Arbeitsschritt und keine weitere Interaktion notwendig werden.

Es gibt einige Möglichkeiten dies zu erreichen, ich entschied mich heute dafür beim Einbinden von Stylesheets und Skripten in WordPress den Zeitstempel der letzten Änderung als Version anzuhängen. Dadurch wird den Browsern signalisiert, dass eine neue Version der Datei vorhanden ist und diese geladen werden muss.

Um das zu erreichen habe ich lediglich in der functions.php die jeweiligen Zeilen, in denen die Version übergeben wird, um die Aufnahme von Datum und Uhrzeit der letzten Änderung erweitert:


function this_register_styles(){
  wp_register_style(
    'main-stylesheet', //handle
    get_template_directory_uri() . '/style.css', //source
    null, //no dependencies
    filemtime( get_stylesheet_directory() . '/style.css' ) // use date and time of last modification as version
  );
}

function this_register_scripts() {
  wp_register_script(
    'this-global', //handle
    get_template_directory_uri() . '/assets/js/this-global.js', //source
    array('jquery'), //dependencies
    filemtime( get_template_directory() . '/assets/js/this-global.js' ), // use date and time of last modification as version
    true //run in footer
  );
}

Um eine Versionsnummer basierend auf Datum und Zeit der letzten Änderung zu erzeugen, verwende ich die PHP-Funktion filemtime(), die eben besagtes als UNIX-Timestamp ausgibt.

Auf die Idee kam ich über den alten Eintrag ›Get your WordPress CSS changes noticed immediately!‹ auf mojowill.com, nachdem ich einen anderen Vorschlag von Kip auf stackoverflow.com, für die Anwendung in WordPress, verworfen hatte.

In letzter Zeit stellte ich fest, dass Bloggen für mich immer auch damit zu tun hatte, einen Gedanken festzuhalten, so dass ich ihn später leicht wiederfinden konnte.

Als ich dann in The Web Ahead, Episode 110 – Understanding the Web, Jen Simmons and Jeremy Keith des wunderbaren Podcasts ›The Web Ahead‹ Jen Simmons und Jeremy Keith darüber reden hörte wie gut es sei, den alltäglichen Blick auf die Arbeit im Web zu bloggen, fasste ich den Entschluss dies auch hier wieder des öfteren zu tun.

Übertragung

Transmitting file data

Das Terminal zeichnete heute ein schönes Fenster mit gepunkteten Linien, und die erfolgreiche Übertragung der Daten erfreute mich.