Kategorien
Wochenbericht

Wochenbericht 2019.17

  1. Wired Elements 1.0: Hand-Drawn, Sketchy UI Elements for the Web
  2. Building a 3D iDesigner with Vue.js: Designing a Reactive Entity System
  3. Bundesgerichtshof: Unitymedia darf Mietrouter in Hotspots verwandeln
  4. Hertz verklagt Accenture wegen unfertiger neuer Webseite
  5. Shooting Stars Animation with HTML & CSS

Was zum Lachen: IDE Depression

Kategorien
Allgemein Webentwicklung Werkzeuge

Das Ding mit dem m.

OpenCliptart by agomjo

Neulich wurde ich gefragt, was denn diese m.-Seiten bedeuten sollen. Die Antwort an sich ist ja relativ simpel: Es sind speziell für Mobilgeräte optimierte Versionen von großen Websites. Wobei groß ja auch eher eine ungenaue Beschreibung für Websites ist, die diese Möglichkeit einsetzen.
Beispiele der großen Websites:

  • spiegel.de
  • faz.de
  • bmw.de
  • audi.de

Alle diese Seiten werden umgeleitet, wenn man sie mit einem Mobilgerät (ich habe das jetzt mal nur mit einem Nexus 5 überprüft) ansurft. Nicht selten wird auf der Website dann auch Werbung für die App der Seite eingeblendet, aber das ist ein anderes Thema.

Und nachdem Responsive Webdesign (“RWD”) in den letzten Jahren mit Verbreitung der Smartphones immer weiter zugenommen hat, ist es (scheinbar) verwunderlich, dass viele große Marken dieses Prinzip immer noch nicht umgesetzt haben. Oder?

Wann ist eine dedizierte Mobile Site sinnvoll und wann RWD?

Die wichtigsten Gründe für eine dedizierte mobile Website sind:

  1. History (es ist einfacher, eine zweite View auf die Daten zu präsentieren, als komplett neuzumachen)
  2. Einfachheit
  3. Kosten

Die mobile Website läuft komplett parallel zur bisherigen, Inhalts-Struktur und Darstellung können komplett unterschiedlich sein, unter Umständen kann man bei der Mobilseite auf neuere Webtechniken zurückgreifen. Die Mobil-Seite wird nicht mit SEO-Krempel belastet und es werden nur die Inhalte geladen, die man wirklich braucht.

Beipiel: spiegel.de / m-spiegel.de

Die wichtigsten Gründe für eine responsive-Website sind:

  1. Es muss nur ein Design gepflegt werden
  2. Performance
  3. Zukunftssicherheit (keine Browserweichen etc. die irgendwann fehlschlagen)

Die RWD-Seite bietet alle Informationen für alle Displaygrößen und fokussiert sich damit auf den Inhalt mehr als auf das Design. Super für SEO, keine gesplitteten Domains, keine duplicate-Content-Probleme und die User werden nicht umgeleitet, was unter Umständen in mobilen Netzen schon durchaus mal länger dauern könnte.

Beipiel: tagesschau.de / sportschau.de / daserste.de

Natürlich setze ich dabei eine korrekte Umsetzung bei beiden Vorangehensweisen voraus. Letztendlich ist RWD nicht die Lösung aller Probleme, auch wenn ich finde, dass man die Displaygrößen immer im Hinterkopf haben sollte.

 


OpenClipart by agomjo

Kategorien
Webentwicklung

DRM in HTML5

In Sachen DRM bin ich ja grundsätzlich geneigt, jegliche DRM-Techniken abzulehnen. Daher wollte ich ich Alex auch gar nicht wiedersprechen, als er (genau wie ich auch schon) über das möglicherweise kommende HTML5-DRM gerantet hat.

Nun ist seitdem etwas Zeit vergangen und ich habe mir ein paar mehr Gedanken dazu gemacht.

Wenn man davon ausgeht, dass das DRM in HTML5 ein Standard sein soll, der es ermöglicht, Content (z.B. Streaming-Musik oder Filme) “sicher” vor Mitschnitt anzubieten, könnte das durchaus genug Potential bieten um lästigen Brückentechnologien wie Flash und Silverlight endlich den Gar auszumachen. Voraussetzung ist dabei natürlich, dass die Inhalte in möglichst offenen bzw. Plattformübergreifend funktionierenden Formaten übertragen werden.

Wenn ich mit plattformübergreifenden Standards das gleiche erreichen kann, wie aktuell mit Flash oder Silverlight, dann werden auch Nischenplattformen attraktiv. Ich kann auf Linuxrechnern mit einfachsten Mitteln Streaming-Angebote wahrnehmen, die sonst proprietäre Browser-Plugins benötigen. Oder mit BSD. Im Endeffekt: Meine Zielgruppe wächst um vermutlich 5-10% in eine Nische, die in der Regel als “nicht wirtschaftlich” eingeordnet wurde. Bietet dieser Nische die Möglichkeit, Paid Content wahrzunehmen. Kickstarter und andere Crowdfunding-Plattformen haben es gezeigt, dass hier ein Markt ist, der auch Geld auszugeben bereit ist.

Ich persönlich würde mich über eine flashfreie Version von z.B. RDIO oder Spotify mehr freuen als über eine Linux-App dafür. Und um hier mal einen Stallman zu pullen: Mir ist ein standardisiertes DRM, welches allen die Möglichkeit gibt, den Content zu nutzen lieber, als dieser Plugin-Wildwuchs mit vorprogrammierten (sic!) Sicherheitslücken.

[red_box]Lieber wäre mir auch, wenn gar kein DRM eingesetzt würde. Aber ich bin Realist genug, um zu sehen, dass das auf längere Zeit nicht verschwinden wird. Und dann lieber auf diese Weise.[/red_box]

Links

  1. World Wide Web Consortium takes next step with controversial DRM proposal, Defective by Design condemns decision — Free Software Foundation — working together for free software
  2. Tell W3C: We don’t want the Hollyweb | Defective by Design
Kategorien
Betriebssystem Code Webentwicklung

Generische URLs für lokale Entwicklungsumgebungen

Als Webentwickler kennt man das vielleicht: Für das x-te Kundenprojekt legt man eine neuen Ordner in seinem WWW-Root an und fängt an, entweder “localhost/kundenprojekt.de” zu nutzen oder lustige Spielereien mit VirtualHost-Konfigurationen und der Hosts-Datei zu veranstalten (“127.0.0.1 kundenprojekt.de”).

Das muss nicht mehr sein! Zumindest unter Linux, BSD und vermutlich Mac OSX.

Der Apache-Part funktioniert ohne Probleme auch unter Windows, das Problem ist hier das generische Domain-Auflösen. Wenn jemand dafür eine Lösung hat, her damit!

Was brauchen wir?

  • Linux, BSD, Mac OSX, Windows
  • Als Entwicklungswebserver benutzen wir den Apachen
  • Unter Linux/Unix/BSD/OSX wird Dnsmasq installiert
    Unter Ubuntu oder Debian mit “apt-get install dnsmasq” bzw. “aptitude install dnsmasq
  • Unter Windows gibt es das Tool “Acrylic DNS Proxy
  • Dnsmasq / Acrylic ist als primärer DNS-Server eingetragen.

Was macht dieses Dnsmasq eigentlich?

Dnsmasq is a lightweight, easy to configure DNS forwarder and DHCP server.

So weit, so gut. Dnsmasq kann einiges mehr und besonders interessieren wir uns für die Funktion, die in der Manpage mit “–address” beschrieben ist. Sehr unscheinbar, aber das ElDorado für uns. Die Option besagt, dass jede Domain, die in das Muster passt, mit der definierten IP aufgelöst wird.

Dafür legen wir unter Debian/Ubuntu die Datei /etc/dnsmasq.d/localdev.conf an. In diese kommt folgender Inhalt:
address=/localdev/127.0.0.1

Unter Windows bearbeitet man die Datei “AcrylicHosts” und fügt dort die Zeile “127.0.0.1 *.localdev” ein.

Man könnte auch eine beliebige andere TLD nehmen (“erfinden”), z.b. “.dev” oder “.locales-netz-von-chris”.

Damit werden alle Domains, die auf “localdev” enden, auf die lokale IP aufgelöst.

Okay, jetzt kann ich alles mit einer bestimmten Domain auf meinen Server umleiten. Und nun?

Dnsmasq löst nun Domains wie “kunde.localdev” und “kunde2.localdev”, alle auf den lokalen Webserver um.

Normalerweise hätte man dann ja immer noch das Problem, dass man mit den VirtualHost-Konfigs basteln müsste. Hierfür hat Uberspace eine super Lösung präsentiert:

Die Apache-Config wird in der VirtualHost-Direktive erweitert. XAMPP/LAMPP/MAMPP-User müssen diese erst erzeugen.

RewriteEngine On

# If there is a host-specific pseudo-DocumentRoot, use it instead of the default one
RewriteCond %{REQUEST_URI} !^/f?cgi-bin/
RewriteCond /var/www/%{HTTP_HOST} -d
RewriteRule (.*) /var/www/%{HTTP_HOST}/$1

Dieser nette Trick erlaubt folgendes: Wenn ein Verzeichnis existiert, welches den gleichen Namen hat, wie die URL, die aufgerufen wird, wird es als “DocumentRoot” verwendet. Bei der Verwendung von .htaccess-Rewrites innerhalb des Verzeichnisses muss allerdings ein “RewriteBase /” stehen.

Was bedeutet das für die Praxis?

Ich muss in Zukunft nur noch ein Verzeichnis “kunde123.localdev” anlegen und schon kann ich darin loslegen. Ich habe eine Top-Level-Domain und muss am Ende beim Umzug auf die Live-Seite nicht mehr soviel ändern. Im Falle von WordPress muss ich nur beispielsweise noch in der Datenbank das “.localdev” durch “.de” ersetzen und schon kann das Projekt live gehen.

Außerdem ist mein /var/www/ -Verzeichnis dann auch zwangsläufig gut organisiert.

Im Übrigen: eine spezifische Auflösung in der resolv.conf oder der Hosts-Datei hat Vorrang vor der Dnsmasq-Auflösung.

[green_box] Update

Ein Tool für Windows wurde nachgetragen

[/green_box]

[grey_box]
Dieser Eintrag entstand durch eine Verkettung von Inspirationen: Ich habe Alex zum testen von Uberspace inspiriert, deren VirtualHost-Konfiguration hat Alex zum testen von Dnsmasq (Wikipedia) auf seinem Notebook inspiriert und seine Demonstation davon hat mich zu diesem Eintrag inspiriert. Soviel zum Thema “geistiges Eigentum”.
[/grey_box]

Kategorien
Code Webentwicklung

Wie sollte man Prototypen bauen?

Konzept: Von der Skizze zum Prototypen

Wir gehen in diesem Artikel davon aus, dass für ein neues Projekt Skizzen bestehen, die zeigen, wie die fertige (Web-)Anwendung etwa aussehen und sich verhalten soll. Basierend auf diesen Skizzen möchte der Kunde sehen, wie sich das “anfühlt”, wenn man es im Browser bedient. Wir gehen im folgenden davon aus, dass der Prototyp keinerlei Datenverbindungen oder serverseitige Entwicklung benötigt, also ein reiner “Klick-Dummy” ist.

Grundüberlegungen

Bevor die erste Code-Zeile entsteht sollte man sich schon über einige Dinge Gedanken gemacht haben:

  1. Code-Organisation / Ordnerstrukturen
  2. Zu verwendende Libraries und deren Lizenzen

Was davon in der Entwicklung davon übrig bleibt, ist egal, aber ein Plan sollte vorhanden sein. Mit am wichtigsten ist, dass alle “Screens” auf Atomisierbarkeit gecheckt werden:

  • Habe ich oft gleiche Strukturen?
  • Kann ich die kombinieren?

Dabei sind z.B. Dinge wie immer wiederkehrende Dinge wie Tabellen mit gleichem Aufbau. Hier lohnt sich unter Umständen recht schnell der Einsatz einer Templating-Engine wie Handlebarsjs oder Mustache.

Weitere Dinge: Welche Präprozessoren / DRY-Tools benutze ich, z.B. LESS, SASS und/oder Ajax (um Teile der Oberfläche nachzuladen).

Umsetzung: Was sollte bei der Entwicklung des Prototypen beachtet werden?

[red_box]Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle![/red_box]

Man kann es gar nicht oft genug sagen. Jeder nachvollziehbare Schritt ist ein sinnvoller Schritt in die richtige Richtung. Insbesondere, wenn mehrere Personen am gleichen Code arbeiten, ist ein SCM-Tool richtig wichtig.

Der Code sollte dabei im Code selbst gut dokumentiert sein, zusätzliche Dokumentation in einem Wiki oder ähnlichem wäre optimal. Nutzt eine Toolchain wie Grunt.js um Produktionsreifen Code zu erzeugen:

  1. Minifying
  2. Compressing
  3. Entkommentarisierung 😉

Request-Lagging

Wenn im Klick-Dummy Requests simuliert werden, die im Prototyp nicht oder lokal stattfinden, verzögert Sie im Prototypen mit JavaScript-

Diskussion: quick’n’dirty vs. Produktionsreife

Wieviel produktionsreifen Code soll eurer Meinung ein Prototyp enthalten? Werdet euch mit den Kunden einig darüber, was ihr unter einem Prototyp versteht und was der Übergang vom Prototypen zur “live”-Version bedeutet. Je nachdem sollten natürlich auch unterschiedliche Aufwände in den Prototypen gesteckt werden.