Kategorie: Webdevelopment

Clean install für den Mac automatisieren

Beim Thema clean install, angeregt durch macOS development environment from scratch, habe ich nochmal ein paar lose Enden eines Git zusammengerafft, die hier auf meinem Schreibtisch noch rumlagen. Denn vor dem Konfigurieren eines neuen Mac steht das ewige Programme suchen und installieren, buh! Das geht natürlich auch einfacher…

Bei der Neuinstallation eines Rechners, in meinem Fall natürlich eines Apple Rechners, vor allem aber auch bei Neuanschaffung steht man immer vor dem zeitraubenden Problem, die Softwareumgebung, die man gewohnt ist, wieder-/herzustellen. Was hier das Einspielen aus Backups oder Migrationsassistenten an convienience bringt, geht oft dadurch verloren, dass man Leichen miterbt, die man auf dem neuen Rechner eigentlich nicht im Keller haben will. Was muss man also für ein wirkliches clean install tun?

  • Zunächst mal muss man wissen, welche Software man eigentlich nutzt. Das ist bei den großen täglich verwendeten Programmen natürlich kein Problem, aber wie hieß gleich noch dieses Colorpicker-Tool, dass man nur zweimal im Halbjahr aufruft? Vielleicht will man außerdem auch einen standardisierten Rechner für neue Kollegen bereitstellen, dann gibt es in diesem Sinne gar keine History…
  • Dann muss man die ausgewählten Programme installieren. Das kann man peu à peu machen, immer wenn man ein Tool braucht: installieren, einrichten und dann erst nutzen. Oder man macht es in einem Arbeitsgang, beide Versionen benötigen viel Zeit.
  • Schließlich müssen alle Programme konfiguriert werden, Seriennummer herausgesucht und eingegeben werden, die Arbeitsumgebung eingerichtet werden usw.

Zumindest die ersten beiden Arbeitsgänge kann man am Mac heutzutage glücklicherweise automatisieren. Die Recherche, was man denn überhaupt installieren will ist dabei natürlich ein wichtiger Punkt. Hier verlasse ich mich auf den Paketmanager Hoembrew, dessen Erweiterung Brew Bundler und die Möglichkeit den Mac Appstore via API von der Kommandozeile aus zu bedienen. Alle drei Programme gehören heutzutage auf jeden Mac. Eine Liste von mit brew installierten Systemprogrammen und Desktop-Apps, sowie der aus dem Appstore heruntergeladenen Programmen, lässt sich mit dem Bundler per brew bundler dump erstellen. Das entstandene Brewfile ist schonmal ein guter Ausgangspunkt. Sowas sieht dann so aus:

cask_args appdir: '/Applications'

tap 'caskroom/cask'
tap 'homebrew/binary'
tap 'homebrew/boneyard'
tap 'homebrew/bundle'
tap 'homebrew/core'
tap 'homebrew/versions'

brew 'mas'
brew 'wget'
brew 'youtube-dl'
brew 'zsh'
brew 'zsh-completions'
brew 'zsh-syntax-highlighting'

cask 'tower'
cask 'transmit'
cask 'vagrant'
cask 'virtualbox'

mas 'iA Writer', id: 775737590
mas 'Airmail 3', id: 918858936
Lisitng 1: Beispiel für ein Brewfile

Mithilfe von brew search und brew cask search findet man weitere Programme, die man auch händisch dieser Liste hinzufügen kann. Irgendwann hat man die Liste der ultimativen Standardprogramme und derer Abhängigkeiten zusammen. Mit einem beherzten brew bundle kann man diese dann entweder installieren oder auch allesamt installieren (oder bereits installierte updaten).

Die Installation auf einem leeren Rechner selbst kann man getrost einem Shellscript überlassen, das auch gleich die Xcode-Tools holt und am Ende oh-my-zsh installiert etc.…

#!/bin/sh
echo Install xcodeutils…
xcode-select --install
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew tap Homebrew/bundle
brew bundle
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
Listing 2: Verkürzte Version eines Installationsscripts

All das oben genannte und ein klein wenig mehr, habe ich mal in diesem Git-Repository zusammengesteckt, mit dessen Hilfe ich meinen Rechner installiert habe. Danach muss man seine Programme natürlich noch konfigurieren. Viel Spaß…

Foto: alejandroescamilla auf Unsplash.

2017: UX verbessern!

Das Jahr ist noch jung, Zeit für die guten Vorsätze. Ich persönlich habe mich da zurück gehalten, ich habe mit mir genug Erfahrung, ich brauche andere Anlässe als einen Jahreswechsel, um an mir zu arbeiten. Aber für uns alle habe ich uns etwas vorgenommen, ist das nicht nett?

Hiermit rufe ich 2017 als das Jahr der UX-Verbesserung aus und der Abschaffung jener dark patterns, die uns nun schon seit Jahren auf den Zeiger gehen.

Keiner mag sie, aber alle haben sie.

Ich rede hier von den dark ux patterns, needy design patterns und einfachen Tricks, die auf Webseiten angewendet werden, um den Nutzer zu bestimmten Aktionen zu bewegen oder ihn davon abzuhalten. Und ab und an lenken wir den Nutzer auch einfach nur vom eigentlichen Inhalt der Seite ab. Was wir damit machen? Die Verweildauer erhöhen, bestimmte Seiten im Angebot promoten, das Wiederanzeigen von Werbung triggern, Statistiken schönen, uns in die eigene Tasche lügen. In Ausnahmefällen erfüllen wir damit auch EU-Normen. Der Wahnsinn kennt keine Grenzen.

Was sind die Folgen?

Keine Frage, schlechte User Experience funktioniert immer wieder. Das zeigen wahrscheinlich auch die Zahlen. Aber das ist leider nur scheinbar so: denn miese Tricks führen letztlich dazu, dass die Glaubwürdigkeit insgesamt leidet, bis der Nutzer eben nicht mehr wieder kommt. Und irgendwann dreht sich der Wind auch, so gesehen bei Adobe Flash. Das war auch mal sehr hip und hat super funktioniert…

Was ist zu tun

Ich weiß, ihr könnt das jetzt nicht alles von hier auf jetzt abschalten. Aber das Jahr ist ja lang. Da kann man schon einiges tun:

  1. Aufklären: dark UX patterns identifizieren und bekannt machen. Sprecht Eure Produktentwickler, Projektmanager oder Chefs an und zeigt ihnen wo die Probleme liegen.
  2. Alternativen aufzeigen: es gibt immer eine bessere Lösung als einen Modaldialog, also zeigt diese Wege auf und bietet sie an. Zeigt auf, dass gutes UX die Glaubwürdigkeit erhöht, vor allem in einer Zeit, in der die Mitbewerber noch miese Tricks benutzen.
  3. Strategien entwickeln: Lasst uns absprechen und uns gegenseitig Hilfen an die Hand geben. Schreibt Artikel mit guten Lösungen. Verlinkt gute Artikel. Fragen klären: wo können verlorene Ad-Impressions wieder hereingeholt werden? Wie beweist man, dass wir Recht haben?

Jetzt wisst ihr Bescheid…

… los geht’s. 😉

Couchblog und AMP

Dieser Artikel über AMP1, Google May Be Stealing Your Mobile Traffic, erstaunt mich ein wenig, weil er trotz seiner naiven Herangehensweise an das Thema, ziemliche Diskussionen ausgelöst hat. Andererseits, naiv ist ja irgendwie genau mein Weg, wie ich mich dem Thema bisher genähert habe, also irgendwo auch genau richtig für mich.

Zunächst mal glaube ich nicht, dass Google mit AMP traffic stiehlt. Natürlich läuft der Datenverkehr über Googles Cache und schlägt so nicht auf dem hauseigenen Server auf, aber gezählt wird er, wenn man ihn zählt, als eigene views, pageipressions, visits, whatsoever. Falls einen das groß artiginteressiert. Das ist aber der große Vorwurf des Artikels, man rufe AMP-Artikel auf und sei dann dort in einem dead end gefangen und könne als einzige Möglichkeit zurück zur Google-Suche. Das mag so sein, wenn man einfach das WordPress-Plugin installiert und einschaltet und sich nicht weiter darum kümmert, was an AMP-HTML dabei heraus kommt. Wir haben AMP für ZEIT ONLINE implementiert und das war mehr Arbeit, als ein Plugin einzuschalten. Wir liefern eine spezielle Version unsere (responsiven) Seite aus, die, so gut es geht, die AMP-Erweiterungen nutzt, also spezielle Adtags, Imagetags und so weiter nutzt. Das WordPress-Plugin versucht die Standard-Wordpress-Elemente automatisch in AMP umzusetzen und macht das erstaunlich gut. Trotzdem kann es natürlich sein, bspw. bei selbstgestrickten Templates, dass der Ergebnis nicht so ist, wie man möchte. Das mag ein dead end produzieren, das ist dann aber eher nicht AMPs Schuld.

Ich habe mich bisher um meine AMP-Seiten auch überhaupt nicht gekümmert, wie sie aussehen sieht man hier. Warum ich mich noch nicht darum gekümmert habe: im Moment läuft da für mich noch nicht wirklich etwas. Derzeit gibt’s AMP-Ergebnisse im Grunde nur in Google-News und in einer speziellen Box, da läuft in der Regel nur Medienverkehr, bei ZEIT ONLINE hat das durchaus Bedeutung, für das Couchblog heisst das bisher no amp in the moment. Eine geplante flächendeckende Einführung in Suchergebnissen ist zumindest international noch nicht fertig umgesetzt, aber für das Jahresende angekündigt. Insofern hat es für mich noch keine Relevanz.

Was mich wirklich in Sachen AMP ein wenig nervt, ist was auch in diesem Kommentar eines AMP-Entwicklers nochmal durchscheint, nämlich dass AMPs ja auch an anderen Stellen als nur der Google Suche erscheinen könnten, bspw. in Twitter oder Pinterest. Twitter ist seit den ersten AMP-Tagen immer mal wieder genannt worden, ausser in twitter moments ist davon aber weit und breit nichts zu sehen. Das ist gelinde gesagt sehr schade, weil mit höherer Verbreitung der AMP natürlich auch das Ansehen steigen würde und sich zeigen würde, dass es um mehr geht, als Content für die Google Suche zur Verfügung zu stellen. Dabei sind AMP, wenn sie sich verbreiten, einerseits eine wundervolle und vor allem offene Alternative zu Facebook Instant Articles, andererseits ein guter Satz Daumenschrauben, die Google mit dem Suchtraffic als Pfand den krankhaft langsamen Newswebseiten anlegen kann. Zusammengenommen ein guter Schritt in Richtung schnelleres Web.

Bild: William Bout

Update: Nach längerem Test habe ich die AMP-Unterstützung wieder dran gegeben.

  1. AMP, Accelerated Mobile Pages, ist ein Projekt, das Google angestossen hat (es ist open source), um das mobile Wen schneller zu machen. In der Hauptsache besteht es aus einem eingeschränkten HTML-Satz, vordefinierten Javascripten und einem fetten Caching ↩

Javascriptökologie

Schön, selten habe ich über einen satiren Beitrag über das javascript ecosystem, die Javascriptökologie mithin, so gelacht, wie über How it feels to learn javascript in 2016. Und ebenso selten habe ich mich zumindest so gut teilverstanden gefühlt, wie bei Bastian Allgeiers Gedanken dazu. Mit diesen beiden Links könnte dieser Artikel nun enden, aber hey…

Selbst habe ich natürlich auch ein paar Gedanken dazu. Zunächst mal gefällt mir Allgeiers Musikinstrumenteanalogie total gut. Ich bin selbst Quereinsteiger, habe mir das meiste selbst beigebracht und lerne jeden Tag neue Dinge dazu, auch noch nach 20 Jahren. Ich spiele allerdings kein Instrument, wenn man mal Technics 1210 nicht als Instrument rechnet. Aber das mit den Instrumenten ist ja auch persönliche Präferenz. Die Wahl eines Programmieransatzes, einer Library, oder auch schon einer Architektur ist aber nur in einem Teilaspekt Sache der persönlichen Entscheidung.

Natürlich soll jeder das Programmieren, was ihm am besten passt, womit er am besten leben kann, womit es ihm am meisten Spaß macht. Mir scheint diese einfache Aussage aber meist nur auf den Einzelkämpfer zu zutreffen, der keine Rücksicht auf sein Team nehmen muss. Wäre ja lustig, wenn in unserem Team Moritz alles in React, Anika alles in Angular, Thomas alles in jQuery und Tobias alles in plain vanilla javascript schreiben würde. Und ich mach dann die code reviews, oder was?! Aber natürlich kann man auch in einem Team, mit viel Diskussion, immer wieder und nochmal, herausfinden, was die Technologie ist, die für das Team am besten passt. Mit kleinen Scharmützeln zwischendurch.

Dann ist das aber leider immer noch nicht die Entscheidungsgrundlage, welche Frameworks, Libraries oder Toolsets einzusetzen sind. Der wichtigste Punkt nämlich ist und das fehlt mir in all den Diskussionen immer wieder, was für die zu erledigende Aufgabe eben das richtige oder passende Tool ist. Ob ein Framework hip, cool oder square ist, spielt da nur eine sehr untergeordnete Rolle und oft leider ebenso, ob alle Lust haben es zu benutzen. Und kommt mir nicht mit einer Komfortzone.

Jetzt gleich zu Argument Nummer eins: die machen doch alle das gleiche, da kann man nach Präferenz gehen. Nein stimmt nicht. Denn auch wenn alle Frameworks möglicherweise ähnliche Ziele verfolgen, sind sie ja eben nicht gleich. Und das zeigt der satirische Artikel von Jose Aguinaga ganz hervorragend: alle bringen eine Hölle von Abhängigkeiten mit sich. Ein Ast im Entscheidungsbaum mag ja bspw. aber sein, wie diese Abhängigkeiten eines Frameworks aussehen und wie stabil diese sind. Und vielleicht schaut auch mal wer, ob es da Sublibraries ohne Sinn und Verstand gibt. Hier failen viele, wenn man zum Beispiel langlebige, stabile Produkte bauen will, mit einer Mindestlebensdauer von vier bis fünf Jahren.

Bei ZEIT ONLINE haben wir im Relaunch 2015 unsere Architektur versucht so zu bauen, dass man einzelne Teile leicht austauschen kann, damit wir eben nicht auf Abhängigkeiten festgenagelt sind. Trotzdem haben wir dann danach erstaunlich wenig buzzwordgetriebene Entwicklung gemacht, sondern sind im Grunde beim alten Handwerkszeug (including the j-word) geblieben. Das liegt natürlich hauptsächlich daran, dass wir eine content getriebene Website sind, keine One-Page-App. Und das wir auf so veraltete Dinge wie progressive enhancement oder auch einfach acessibility achten wollen. Aber eben auch daran, dass wir einiges an Erfahrung bei den Architekturentscheidungen zusammengetragen haben und uns bei maximaler Entscheidungsmöglichkeiten nicht maximal abhängig von irgendetwas machen wollten, dass morgen vielleicht schon wieder unmaintainded ist.

Update: Addi Osmani dazu.[Via.]

Bild: Markus Spiske

Schneller sein und länger bleiben

Die Washington Post ist dabei ihre so called mobile experience auf eine progressive webapp umzustellen und wird dadurch lightning fast, wie sie selbst schreiben. Und ja, die Website wird dadurch tatsächlich sehr schnell.

Einer der ersten Nutzerkommentare dazu lautet jedoch:

I never recognized a problem with loading speed. What I do recognize is my vision going blurry after looking at it for about 10 minutes or more. That absolutely deters me from reading articles on it.

Vielleicht eine sehr subjektive Aussage, eine Mindermeinung, ist mir gar nicht so aufgefallen. Trotzdem sehr überraschend in dem Zusammenhang.

Und das deckt sich irgendwie mit meiner Erfahrung. Na klar, schnellere Webseiten klicken besser, wissen wir alle, die Absprungsraten nach zwei Sekunden sind astronomisch und so weiter und so fort. Die Websitenutzer entscheiden solche Dinge aber ausschließlich mit den Füßen, will sagen: durch wegbleiben. Das ist die eine Kohorte der Nutzer. Die schnell da, schnell wieder weg Nutzer. Man will ja nicht wie ein Werbefritze klingen, aber: die schnellen User haben (noch) keine Beziehung zur Website. Sie müssen erst konvergiert werden. Und hier ist Schnelligkeit nur ein Punkt, im Grunde erstmal nur jener, der die Auswahl möglichst groß macht.

Was dann aber folgt, dürfen wir nicht aus den Augen verlieren. Irgendwo zwischen Geschwindigkeitsrausch und Werbeverschreckung muss Platz bleiben, den Nutzer vom schnellen Vorbeisurfer zu einem regelmäßigen Nutzer zu machen. Dafür ist natürlich vor allem der Inhalt einer Website verantwortlich, dass der Nutzer also das findet, was er sucht. Aber auch hier haben wir als Webentwickler es in der Hand, an den Reglern zu drehen: Lesbarkeit, Struktur, Informationsarchitektur, Funktionalität bei hoher Zugänglichkeit, es gibt so viele Dinge, die man ausser Geschwindigkeit und minimalistischem Design richtig machen kann und muss. Bitte nicht vergessen: there is more to web than speed.

Foto: Steven Wei