Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zum Archiv und den Kategorien

Eine Screenshot-App - wozu soll das gut sein?

Samstag, 27. Mai 2017

Ein Screenshot vom iPhone - nichts einfacher als das. (Home-Button und Ausschalter gleichzeitig drücken, falls es jemand nicht weiß.)
Dafür extra eine App?
Ja. Wenn man, wozu auch immer, die ganze Webseite in voller Länge fotografieren will.

Hinweis: Den Demo-Screenshot hier kann man nicht nur Scrollen, sondern durch Antippen auch in voller Höhe sehen; wenn auch vermutlich verkleinert, es sei denn, ihr habt einen Monitor mit 3000 px Höhe ;-)

iTunes Link: Awesome Screenshot for Safari
Übrigens: Es gibt die App auch für den Mac.


Responsive Formulare - automatisches Zoomen beim Betreten vermeiden

Montag, 22. Mai 2017

Da hat man sich redlich Mühe gegeben, Formulare responsive zu gestalten. Auf dem Smartphone / iPhone sieht das Ergebnis auch bestens aus.

Screenshot 1
Ein Kontaktformular, optimiert für die Darstellungen auf einem Smartphone-Monitor

Nach dem Antippen eines Formularfeldes aber:

Screenshot 2
Nach dem Antippen eines Formularfelds öffnet sich die Bildschirmtastatur, und die Anzeige wird automatisch gezoomt, so dass sie auf dem Bildschirm nicht mehr zur Gänze sichtbar ist

Was passiert da? Wie kann man diesen unschönen Effekt vermeiden?
iOS oder Android versuchen, die Eingabefelder mit einer Mindestschriftgröße darzustellen. Falls diese Mindestgröße nicht vorgegeben ist (per CSS), dann kommt es zu diesem Zoom-Effekt.
Abhilfe? Ins CSS:
input, textarea {font-face:16px}
So einfach kann es sein - wenn man's weiß.


E-Privacy-Verordnung

Montag, 8. Mai 2017

Aus der EU-Cookie-Richtlinie wird die E-Privacy-Verordnung
(Google-Suche nach E-Privacy-Verordnung)
Inkrafttreten der Verordnung ist geplant für Mai 2018. Und, anders als bisher die Richtlinie, wird eine EU-Verordnung sofort mit Inkrafttreten für alle Länder verbindlich.
Der Entwurf der Verordnung (Kommentar zum Entwurf) sieht u.a. vor, dass

  1. Ein Opt-out oder "Take it or leave" nicht mehr genügt. Vielmehr ist eine bewusste Zustimmung des Besuchers (Opt-in) erforderlich.
  2. Seitenanbieter ein im Browser gesetztes Do not Track (DNT) respektieren müssen.

Beide Forderungen erfüllt meine Lösung bereits heute. Ich dürfte auf alle Fälle auf der sicheren Seite liegen.

Screenshot vom iPhone
Der "Cookie-Hinweis" auf Smartphones, mit der Wahl zwischen "Bitte keine Analyse" und "Kein Problem, ich stimme zu".

tl;dr weiterlesen…


Ein einfacher Slider - nur mit CSS

Sonntag, 7. Mai 2017

Horizontale Slider gibt es wie Sand am Meer. Meist steckt dahinter eine mehr oder weniger schwergewichtige JavaScript-Bibliothek.
Was aber, wenn man nur zwei (oder einige) Bilder horizontal Scrollen will, ohne gleich mit Kanonen auf Spatzen zu schießen? Und natürlich soll das auch auf Touchscreens per Wischgeste funktionieren.


Ja, es geht auch mit ganz wenig CSS:

<div style="width: 180px; white-space: nowrap; overflow-y: hidden; overflow-x: scroll; -webkit-overflow-scrolling: touch;">
<img style="display: inline; width:100%;" src ="Pfad/image1.jpg" alt="Webcam 1" />
<img style="display: inline; width:100%;" src ="Pfad/image2.jpg" alt="Webcam 2" />
</div>

Anm.: Die CSS-Deklarationen kann man natürlich auch auslagern.

Fertig!

Dank an benfrain.com


Styleswitcher

Sonntag, 5. März 2017

Die Möglichkeit, eine Website mit unterschiedlichen Designs/Styles darzustellen, ist - zu Recht? - aus der Mode gekommen. Viel wichtiger ist heute, die Site auf allen Monitorgrößen korrekt und benutzbar zu gestalten.
RWD (Responsive Web Design).

Da ich aber vor Urzeiten mal einen sogenannten Styleswitcher in meine Site eingebaut habe, müssen die verschiedenen Stile natürlich auch gepflegt werden.
Genau das hab' ich jetzt mal mit dem Stil Leonardo getan. (Es war überfällig.)

Screenshot
Mein Blog, wie es sich nach Auswahl des Stils "Leonardo" präsentiert

HTML validieren - Hunderte von Seiten in einem Rutsch

Donnerstag, 9. Februar 2017

Wer Wert auf valides HTML legt, und seine Seiten regelmäßig validiert, hat sicher Verwendung für ein Werkzeug, das 500 Seiten in einem Durchlauf validiert.

Der WDG HTML Validator kann das. Besser gesagt: Er konnte es. Leider ist er für HTML5 unbrauchbar.

Aber es gibt ein neues Tool: Den Bulk W3C Validator

Einziges Manko: Das Tool erfordert die Eingabe aller zu prüfenden Seiten in Form einer Liste. Wie diese Liste erzeugen, muss jeder für seine persönlichen Verhältnisse selbst herausfinden.
Ich verwende für diesen Zweck die Sitemap, die ich ohnehin täglich automatisch per Cronjob erstelle.

Nachtrag 15.02.2017

Ich muss meine Empfehlung leider revidieren. Das Tool zeigt in vielen Fällen "grün", obwohl Seiten mehr oder weniger gravierende Fehler aufweisen. So werden z. B. auch nicht existierende Seiten, die korrekt einen Error 404 auswerfen, als valide gekennzeichnet.
Der Support reagiert leider auch nicht.
Schade.


Der wdwjs-Audio-Player auf dem Galaxy S3

Donnerstag, 2. Februar 2017

Ein Screencast meines aktuellsten Audio-Players auf einem Samsung Galaxy S3.
Mehr gibt es dazu eigentlich nicht zu sagen.
Doch: Hier ist die Projektseite: wdwjs_player_of.php


Zeit zur Umstellung auf utf-8

Sonntag, 25. Dezember 2016

Es gibt doch tatsächlich immer noch Webworker, die ihre Seiten noch nicht als utf-8 ausliefern. Aber früher oder später stolpert jeder über dieses Thema. So geschehen kürzlich bei einer befreundeten Bloggerin.
Der Hosting Provider teilte mit, dass - wieder einmal - neue PHP Versionen verfügbar sind. Eine gute Gelegenheit, endlich die eingesetzte total veraltete, und möglicherweise unsichere PHP Version durch eine aktuellere zu ersetzen? Keine Affäre, das im Kundenmenü umzustellen. Die Wahl fiel auf PHP 5.6. Und im ersten Moment sah auch alles gut aus. Bis auf vereinzelte � (Fragezeichen) im Text. weiterlesen…


Google legalisiert Downloads

Sonntag, 23. Oktober 2016

Nein! So weit ist es (noch) nicht. Aber ein neues Feature des Google Chrome Browsers (ab Version 55) lädt quasi dazu ein, alle im Web verfügbaren Medien (Audio, Video) auf die eigene Festplatte zu laden:

Screenshot
Der Medienplayer des Chrome Browsers Version 55+ zeigt einen Download Button, wenn ein Standard HTML5 <audio> bzw. <video> Tag in eine Webseite eingebunden ist.

Grundsätzlich ändert sich dadurch nichts. Auch bisher galt: Was auf dem eigenen Rechner abgespielt wird, ob Video oder Audio, kann auch abgespeichert werden. Mit mehr oder weniger Aufwand. Aber diesen Aufwand verringert Google mit dem allgegenwärtigen Download Button praktisch gegen Null.
Sicher will nicht jeder Webseitenbetreiber diese "Aufforderung zum Download" auf seiner eigenen Website.
Ob Google damit der Idee hinter dem HTML5 Standard <audio> bzw. <video> einen Gefallen tut.
Mit entsprechend Aufwand lässt sich natürlich eine Player ohne diesen Download-Button bauen. Siehe mein wdwjs-Player.
Beobachtung am Rande: In seinem eigenen Player auf YouTube zeigt Google den Download Button nicht. Inkonsequenz? Oder welcher Plan steckt wohl dahinter?


Das Erstellungsdatum von Webseiten oder Blogartikeln

Donnerstag, 6. Oktober 2016

Wenn ich im Web recherchiere, gezielt eine bestimmte Information suche, will ich wissen, wie aktuell die Treffer sind. Oder eben, dass sie möglicherweise veraltet sind. Ich will im Artikel, am liebsten im Kopf, eine Information finden wie

Sonntag, 17. Januar 2016 - Letzte Änderung: 03.08.2016

Alternativen sind beispielsweise Angaben wie

Diese Seite wurde zuletzt vor 2 Monaten aktualisiert.

oder notfalls eine Kenntlichmachung im URL nach dem Muster vieler Blogsysteme:

https://webdesign.weisshart.de/blog/2016/10/02/push-benachrichtigung-von-php-an-smartphones/

Genau diese Information über die Aktualität einer Seite nutzt nun anscheinend Google, um ältere Seiten weniger prominent in den Suchtreffern zu listen. Der SEO Experte SISTRIX nennt das "slowly kill your content on Google" und versteht diese Überschrift natürlich als Warnung, als Empfehlung an Webmaster, derlei Angaben über die Aktualität von Content tunlichst zu unterlassen.

Ich schreibe meine Seiten schon immer für Menschen, und nicht für Suchmaschinen. Und ich finde es total Ok, dass Google auch die Aktualität von Seiten in den SERP berücksichtigt. Aktuellere Treffer weiter oben in den Suchergebnissen. Richtig. Genau so will ich, dass meine Seiten gelistet werden. Alles andere ist Missbrauch, ist böse.


Push Benachrichtigung von PHP an Smartphones

Sonntag, 2. Oktober 2016

Die Aufgabe:

Eine Website soll im Anschluss an eine bestimmte Aktion (Beispiel: User betritt einen Support-Chat) eine Push Benachrichtigung ans Smartphone senden.

Eine Lösungsmöglichkeit:

Man schickt per PHP eine Nachricht an einen Messenger, und lässt diesen die Push Benachrichtigung erledigen.
Als Messenger hierfür bietet sich Telegram an. Telegram bietet, anders als beispielsweise WhatsApp, eigens zu diesem Zweck eine Bot API.

Screenshot
Die Push Meldung auf dem iPhone:
"[Uhrzeit] [Username] hat den Chat betreten."

Eine kurze Anleitung zur Einrichtung eines Telegram Bots

tl;dr weiterlesen…


Browser werden immer besser

Mittwoch, 28. September 2016

Moderne Browser - in Verbindung mit CSS3 - ersparen dem Webworker immer mehr Arbeit.

Aktuelles Beispiel:
position:sticky

Die Aufgabenstellung:

Ein bestimmtes Element einer Webseite - typischerweise eine Navigation - soll immer sichtbar, und damit nutzbar - sein. Bisher erforderte diese Aufgabenstellung den Einsatz von JavaScript plus CSS. Und beides musste sehr genau aufeinander abgestimmt werden. Probleme mit unterschiedlichen Monitorgrößen (Stichwort RWD) waren vorprogrammiert.
Ein Beispiel mit der bisher nötigen Technik zeigt diese Demo

"position:sticky" erledigt nun diese Aufgabe mit einer einzigen CSS Anweisung. Auf intelligente Weise.

Browser Unterstützung:

  • Unterstützt wird "position:sticky" von allen modernen Browsern.
  • Wie nicht anders zu erwarten: Microsoft-Produkte kennen das Feature nicht.
  • Im Chrome-Browser muss dazu unter chrome://flags "experimental Web Platform features" enabled werden.
  • Schön, dass iOS das Feature unterstützt. Gerade auf iPads kann das sehr hilfreich sein.

Eine Anmerkung: Einen ähnlichen Effekt kann man natürlich auch mit position:fixed erreichen. Allerdings ist position:fixed bei weitem nicht so flexibel. Es fixiert einen Bereich immer in Relation zum Viewport, also zum Browserfenster. Im schlimmsten Fall kann position fixed dazu führen, dass Elemente nicht mehr sichtbar/nutzbar sind. Nämlich dann, wenn der fixierte Bereich größer ist als das Browserfenster. Wenn es sich um eine Navigation handelt, dann wäre das der GAU!
position:sticky fixiert in Relation zum übergeordneten Container, und greift nur, wenn es benötigt wird. Die Fixierung wird bei Bedarf durch Scrollen aufgehoben. Das Risiko einer nicht nutzbaren Navigation wird dadurch zuverlässig vermieden.

Wenn dein Browser das Feature unterstützt (und das Browserfenster klein genug gezogen wird), dann kannst du die Funktion hier auf der Seite in Aktion sehen. Und wenn nicht: dann ist die Navigation natürlich dennoch nutzbar.

Nachtrag 16.10.2016

Im aktuellen Chrome Version 54 mit "experimental Web Platform features" enabled, und ebenso Opera, ist die Umsetzung von position:sticky leider buggy. Na ja, es heißt dort ja auch zu Recht "experimental".
Aber es gibt Abhilfe: Ein Polyfill namens stickyfill.js als jQuery-Plugin. stickyfill bei Github
Alles, was es dazu braucht:

<script src="/scripts/stickyfill.min.js"></script>
 
<script>
$('#menuwrapper').Stickyfill();
</script>

Und damit klappt's jetzt auch auf IE 9+ und Edge.


Noch mehr Komfort beim Copy & Paste

Samstag, 3. September 2016

Eine weitere Komfortsteigerung nach dem 1-Klick-Markieren hat Opera im Köcher (derzeit nur in der Developer Branch V. 41 zu bewundern Version 40+):

Screencast: Opera zeigt sofort nach dem Markieren einen Button zum Kopieren (und Suchen).

Sehr pfiffig!

(PS: Der Suchen-Button öffnet übrigens eine Suche nach dem markierten Text mit der Standardsuchmaschine.)


Code automatisch markieren zum copy & paste

Donnerstag, 1. September 2016

Die Darstellung von Codeschnipseln auf meiner Site habe ich in letzter Zeit ja in mehreren Schritten optimiert. (Hoffentlich verbessert, und nicht verschlimmbessert.)

  1. Den Container mit dem Codeschnipsel scrollbar machen
  2. Die Scrollbar permanent sichtbar machen
  3. Zeilen abwechselnd einfärben

Jetzt ein weiterer Schritt zu Verbesserung der Usability:

Den ganzen Codeschnipsel mit einem Klick markieren zum copy & paste

Folgende Anweisung im CSS bewirkt das (im Beispiel für das <code> Element:
code {
-webkit-user-select: all;
-moz-user-select: all;
user-select: all;
}

Das funktioniert in fast allen modernen Browsern. (Crome 53+, Firefox 43+, Safari 9+, Opera)
Ältere Browser, die das Feature nicht unterstützen, ignorieren die CSS Angabe einfach.


Ich will meine Scrollbar sehen

Mittwoch, 24. August 2016

Das Problem:

Fast alle aktuellen Browser verbergen Scrollbars nach kurzer Zeit, wenn nicht gescrollt wird. Für Ästheten eine feine Sache. Und auch kein Problem, wenn es um die Scrollbars für den Viewport, also für die ganze Seite geht. Der User weiß aus Erfahrung, dass er scrollen kann und muss, um Inhalte "below the fold" zu sehen.
Wenn aber einzelne Seitenelemente (z. B. divs) übergroße Inhalte besitzen, die nur durch Scrollen in Gänze sichtbar werden (CSS: overflow:auto/scroll), dann kann das ein entscheidendes Usability Problem darstellen; Weil der User nicht ohne weiteres erwartet, dass er diesen Bereich scrollen kann / muss.
IE / Edge machen, wie so oft, eine Ausnahme. Diesmal zum Besseren. Sie blenden per default die Scrollbars nicht aus.

Die Lösung:

weiterlesen…


Stockfotos Creative Commons Zero

Freitag, 5. August 2016

Stockfotos kann man als Webworker nie genug haben.
Schön, wenn die Fotos unter CC0 1.0 (Creative Commons Zero) angeboten werden. Unsplash.com bietet so etwas.

Als nette Zugabe: Die Suchfunktion.


Komfort für Tastaturnutzer

Sonntag, 24. Juli 2016

Blinde Menschen, die mit einem Screen Reader surfen, haben gegenüber sehenden Tastaturnutzern — also Surfern, die aus welchem Grund auch immer keine Maus benutzen können — seit jeher einen Vorteil: Sie können mit Hilfe ihres Screen Readers verschiedene Elemente auf der Seite direkt anspringen. Z. B. alle Überschriften auf der Seite.
Tastaturnutzern ist dieser Komfort verwehrt. Navigieren mit der Tastatur bedeutet: mit der Tabulator-Taste mühsam von Link zu Link springen. Mit viel Glück besitzt eine Website wenigstens einen oder mehrere Skiplinks, um mit der Tastatur direkt zu wichtigen Inhalten zu navigieren.

Aber Besserung ist in Reichweite. Das PayPal Accessibility Team und die University of Illinois stellen ein geniales Script zur Verfügung, das den einfachen Skiplink zu einer komfortablen Navigationshilfe erweitert: SkipTo.js

Das Skript kann praktisch ohne Konfiguration "out of the box" benutzt werden. Wobei "out of the box" heißt: Einbinden der externen JavaScript-Datei ins HTML, also eine Zeile HTML:
<script type="text/javascript" src="https://paypal.github.io/skipto/downloads/js/SkipTo.min.js"></script>

Das Skript ist hier auf meiner Site in Aktion.
Der Aufruf erfolgt entweder unmittelbar nach dem Laden der Seite mit der Tab-Taste und Enter, oder, von überall auf der Seite, mit einem Tastaturkürzel:

  • Microsoft Internet Explorer – ALT+0(Null).
  • Mozilla Firefox – ALT+SHIFT+0 (Windows) oder CONTROL+ALT+0 (Mac OS).
  • Google Chrome – CONTROL+ALT+0 (Windows) oder CONTROL+OPTION+0 (Mac OS).
  • Safari – CONTROL+0 (Windows) oder CONTROL+OPTION+0 (Mac OS).

Nachtrag 25.07.2016

Für Smartphones habe ich SkipTo deaktiviert. Da auf diesen Geräten typischerweise keine Tastatur zur Navigation genutzt wird.

Nachtrag 28.07.2016

SkipTo ist jetzt auch vor Screen Reader Nutzern versteckt. Weil das Script in Verbindung mit einem aktiven Screen Reader zu unvorhersehbarem Verhalten bis zum Absturz des Browsers führt. (Das ist übrigens keine Diskriminierung von blinden Seitenbesuchern; Screen Reader Nutzern stehen ohnehin weit umfangreichere Navigationshilfen zur Verfügung.)


Mit CSS ein Symbol (Wasserzeichen) über ein Bild legen

Donnerstag, 21. Juli 2016

Nachtrag 24.05.2017:
Die im Folgenden beschriebene Technik habe ich durch eine einfache CSS-Angabe ersetzt: cursor: zoom-in

Dass Bilder auf Webseiten per Mausklick vergrößert werden können, zeige ich mit einem Lupensymbol in der rechten unteren Ecke des Vorschaubildes an. (Die Technik zur Vergrößerung ist nicht Themas dieses Beitrags. Ich mache das mit Fancybox oder Photoswipe).

Demobild
Hinweis: Dieses Demobild wird bei Mausklick nicht vergrößert. Es soll lediglich das eingeblendete Lupensymbol gezeigt werden.

Diese Lupensymbol könnte man natürlich mit einem Bildbearbeitungsprogramm einfügen.
Eleganter geht es aber mit HTML, und einigen Zeilen CSS.

Das Lupensymbol wird dazu im HTML als img mit der Klasse "after" eingesetzt, und beide (Vorschaubild und Lupensymbol) in ein Element (z. B. span) mit der Klasse "over" eingeschlossen. Der HTML Code sieht dann — vereinfacht, ohne den Code zur Anzeige des vergrößerten Bildes — so aus:

<span class="over">
<img src="pfad_zum_Vorschaubild.jpg" alt="Demobild">
<img span class="after" src="pfad_zum_Lupensymbol.png" alt="" />
</span>

Und das CSS dazu:

.over {
position: relative;
display:inline-block;
}
.over .after {
position: absolute;
bottom: 5px;
right: 5px;
}

Eventuell möchte man das Lupensymbol auch noch per CSS stylen:

img.after {width:20px height:auto;opacity:.8; …}


Lightbox Alternativen angetestet

Donnerstag, 7. Juli 2016

Menschen in einer Bildergalerie
Foto: deviantart.com Lizenz: CC Attribution-Share Alike 3.0.

Eine Bildergalerie braucht man immer wieder. Seit jeher benutze ich Fancybox als Galerie-Script, als Lightbox-Alternative.
Weil es:

  • valides HTML erzeugt,
  • relativ schlank und
  • einigermaßen barrierefrei ist.

Im Laufe der Jahre sind aber doch immer mehr Schwächen aufgetaucht:

  • Fancybox 1 (letzte Version 1.3.4) wird seit 2011 nicht mehr weiter entwickelt. Vermutlich (und verständlich), weil der Entwickler wohl die (kostenpflichtige) Version 2 bevorzugt behandelt.
  • Fancybox 1.3.4 arbeitet mit aktuellen Versionen von jQuery nur noch, wenn zusätzlich das Migrationstool jquery-migrate.js geladen wird.
  • Barrierefreiheit: Der (unvermeidbare, aber für blinde Menschen nutzlose) Link zum Vergrößern der Bilder irritiert Screen Reader Nutzer.

Ich habe mich daher nach Alternativen umgeschaut. Klar, Lightbox-Alternativen gibt es wie Sand am Meer. Ich bin einfach mal einer Empfehlung von Matthias Mees gefolgt:

  1. Magnific Popup von Dmitry Semenov, und
  2. PhotoSwipe vom gleichen Entwickler

Für die beiden Scripte, sowie für Fancybox habe ich jeweils eine Demo-Seite erstellt. Ich habe die Einstellungen jeweils so gewählt, dass der optische Eindruck in allen drei Demos möglichst identisch ist. Vor allem habe ich die Scripte in mein übliches Layout eingebaut, um eventuelle Unverträglichkeiten mit anderen Scripten zu testen.

Die Demos:

Fazit

PhotoSwipe hat das Zeug zum “Testsieger”. Unabhängig von jQuery, perfektes Look & Feel auf Touchscreens und kleinen Smartphone-Monitoren. Zudem: Bildunterschriften / Bildbeschreibungen perfekt umsetzbar. Sowohl für sehende, als auch blinde Nutzer.

PS: Es gibt natürlich auch “handgemachte” Lösungen, die wirklich alle Wünsche bezüglich Barrierefreiheit erfüllen. Die blinde Bloggerin Eva Papst präsentiert auf Ihrer Website Bilder mit Bildbeschreibungen.


Countdown zum Reload

Freitag, 24. Juni 2016

Die Seite sms2web.php mit dem Ticker kann nach einer konfigurierbaren Mindestzeit neu geladen werden, um die Anzeige des Tickers zu aktualisieren.
Die bis zum möglichen Reload verbleibende Zeit wird angezeigt.

tl;dr Weil ich danach gefragt wurde, hier eine Gebrauchsanweisung für Interessierte: weiterlesen…


Und jetzt das Zwangs-EU-Cookie

Sonntag, 19. Juni 2016

Screenshot
Ein - scheinbar - ganz üblicher Cookie Hinweis
"Dieser Blog benutzt Cookies. Wenn Sie die Website weiter nutzen, stimmen Sie der Verwendung von Cookies zu."

tl;dr Wer vom Thema EU-Cookie-Hinweis ausreichend genervt ist, braucht ab hier nicht mehr weiter zu lesen. weiterlesen…


Der Cookie Warnung Irrsinn - die Vierte

Dienstag, 14. Juni 2016

Man hört nicht mehr viel über den EU-Cookie-Hinweis. Die Gemüter haben sich anscheinend beruhigt. Wer dieses geniale Browser-Addon noch nicht einsetzt, hat sich entweder an die diversen Hinweise gewöhnt, oder er klickt resigniert auf "Zustimmen".

Screenshot
Ein typischer Hinweis, wie er auf vielen Websites zu finden ist.
Wenn Sie Cookies akzeptieren, können wir Ihnen die bestmögliche Erfahrung auf dieser Website bieten. Akzeptieren - Mehr Informationen"

Was sagt mir dieser Hinweis jetzt?
Was ist die "bestmögliche Erfahrung", und was wäre wohl eine "weniger gute Erfahrung"?
Was genau passiert, wenn ich auf "Akzeptieren" klicke? Und was, wenn ich nicht klicke? Ich befürchte, der einzige Unterschied besteht darin, dass nach einem Klick der nervende Hinweis verschwindet, mein Besuch auf der Site aber so oder so von Google & Co. getrackt wird.
Eine Möglichkeit, dies zu verhindern, einen Button "Ablehnen" sehe ich nicht.
weiterlesen…


IndieWeb - die Zweite (und Letzte?)

Sonntag, 29. Mai 2016

IndieWeb — im ersten Moment klang das so, als ob es etwas für mich wäre.

Logo Indie Web Camp

Bild: Indie Web Camp

Die Prinzipien des IndieWeb:

Your content is yours
When you post something on the web, it should belong to you, not a corporation. Too many companies have gone out of business and lost all of their users’ data. By joining the IndieWeb, your content stays yours and in your control.

You are better connected
Your articles and status messages can go to all services, not just one, allowing you to engage with everyone. Even replies and likes on other services can come back to your site so they’re all in one place.

You are in control
You can post anything you want, in any format you want, with no one monitoring you. In addition, you share simple readable links such as example.com/ideas. These links are permanent and will always work.

Quelle: https://indiewebcamp.com/

Bei genauerer Betrachtung der Werkzeuge und Schritte, die zur Umsetzung dieser Prinzipien erforderlich sind, bleibt jedoch nur Ernüchterung. Hinter großen Worten stecken überwiegend nur Selbstverständlichkeiten:

(Quelle: https://indiewebcamp.com/Getting_Started)

  • Get a personal domain — Hab' ich: webdesign.weisshart.de ✔︎
  • Get a place for your content — Hab' ich ✔︎
  • Set up your home page and web sign-in — Erledigt ✔︎
  • Set up your authorship information — Na ja, wer lesen kann, findet auch das auf meinen Seiten. ✔︎
  • Publish content on your domain — Erledigt ✔︎
  • Add microformats to your content — Wozu?
  • Publish (on your) Own Site, Syndicate Elsewhere — Mach' ich. Mit einer Besonderheit: Ich entscheide von Fall zu Fall, was ich "elsewhere" veröffentlichen will, und wo. Und dabei wird es auch bleiben.✔︎
  • Port old silo content to your site — Das musste ich einmal machen. Als Posterous schloss. Und einmal ist genug. Deshalb beherzige ich seitdem das erste Prinzip des IndieWeb: "Your content is yours"
  • Set up a personal URL shortener — Hab' ich auch: w7t.de ✔︎

Fazit:

Entweder ich bin bereits Indie, oder ich hab' da etwas nicht verstanden?


DNT - Do Not Track

Mittwoch, 18. Mai 2016

Do Not Track (DNT; engl. für „nicht verfolgen“) ist ein HTTP-Header-Feld und signalisiert einer Website oder Webanwendung den Wunsch, dass diese über die Aktivitäten des Besuchers kein Nutzungsprofil erstellt.

Quelle: Wikipedia

Bild: Hugh D'Andrade

Hm? Das wäre doch die saubere Lösung für das Problem, über das ich unter der Überschrift "Cookie Warnung Irrsinn" mehrmals geschrieben habe. Wenn, ja wenn Webseitenbetreiber den gesetzten DNT entsprechend respektieren würden. (Noch einfacher und sauberer wäre es, wenn Google Analytics & Co es täten.)

Nichts jedoch hindert mich, es auf meiner Site zu tun. Gesagt - getan. Wer im Browser DNT aktiviert hat, wird von Google Analytics nicht getrackt, und bleibt auch vom Cookie Hinweis verschont.


Futter für die doofen Bots

Samstag, 14. Mai 2016

Ständig versuchen alle möglichen Bots, mein Wordpress zu hacken. Dazu rufen sie zuerst einmal die Datei wp-login.php auf. Die gibt es bei mir aber nicht. Aus eben diesem Grund. Das einzige, was es gibt, sind Einträge in mein Error-Log über die vergeblichen Versuche.
Weil aber die Bots ihre Versuche nicht einstellen, stelle ich sie ab sofort eben zufrieden. Mit einer Datei namens wp-login.php, die genau folgenden Inhalt hat:
Hey, Spambot, go home and fuck you!
Stinkefinger


Mal sehen, vielleicht fällt mir ja auch noch eine pfiffige Weiterleitung ein, die ich dort einbauen könnte.


Sichere Websites mit Zertifikat

Sonntag, 17. April 2016

Auf ungesicherte / nicht zertifizierte Websites kommen zunehmend schwere Zeiten zu. TLS/SSL/HTTPS ist die Zukunft.
So fordert z. B. die bayerische Datenschutz-Aufsichtsbehörde gemäß § 9 BDSG bei der Übermittlung personenbezogener Daten den Einsatz dem Stand der Technik entsprechender Verschlüsselungstechnik.
"Übermittlung personenbezogener Daten", das ist bereits der Fall, wenn es ein Kontaktformular auf der Site gibt.

Aber auch Google & Co. fordern und fördern sichere Sites.
So sieht eine nicht gesicherte Website bereits heute im Google Chrome Browser aus:

Screenshot
Das Schloss-Symbol in der Adressleiste, das eine korrekt zertifizierte Website kennzeichnet, ist ausgegraut und mit einem "X" gekennzeichnet. "https" ist durchgestrichen.

Zumindest bei Google ist die Zertifizierung bereits ein Rankingfaktor.


Accessibility Club 2016 im Rahmen der Nürnberg Web Week

Mittwoch, 13. April 2016

Die doch relativ weite Anfahrt hat sich gelohnt.
Der Accessibility Club am 12. April 2016 bei tollwerk in Nürnberg war klein, aber fein. Danke an Joschi Kuphal für die Orga, an die Sessiongeber für die Vorträge, und an die Teilnehmer für anregende Gespräche am Rande.

Zwei besondere Dinge habe ich für mich mitgenommen:

  1. ally.js von Rodney Rehm, und
  2. Was ist das IndieWeb?

weiterlesen…


Zeilen abwechselnd färben mit CSS

Freitag, 8. April 2016

Die Zeilen einer Liste oder Tabelle abwechseln färben, um die Lesbarkeit zu verbessern. Tausendfach im Netz zu sehen. Wird üblicherweise mittels CSS3 :nth-child() Selector gelöst. Und funktioniert. Allerdings nur, wenn jede Zeile in einem eigenen HTML Element steht. Also beispielsweise einem Listenelement oder einer Tabellenzeile.
Es geht aber auch mit Fließtext. Oder — und diesen Anwendungsfall werde ich beschreiben — in einem mittels <pre> oder <code> vorformatierten Abschnitt. Letzteres setze ich ein, wenn ich Codesnippets hier im Blog zeige.

Das CSS:

Das folgende Codesnippet ist gleichzeitig die Demo :-)

code {
/* Allgemeine Angaben, um Codesnippets preformatted darzustellen */
white-space: pre;
display:block;
overflow-x:auto;
font-family:Courier,serif;
font-size: 1rem;
margin:1em 0;
border:1px dashed;
-moz-tab-size:3;
tab-size:3;
line-height:1.5rem;
padding: 1.5rem .5rem;

/* jetzt die abwechselnde Einfärbung der Zeilen */
background: linear-gradient(
to bottom,
#fff,
#fff 50%,
#eee 50%,
#eee
);
background-size: 100% 3rem;
}

/* Das Codesnippet beim Fokussieren mit der Maus (oder Tastatur) hervorheben */
code:focus, code:hover {
background: linear-gradient(
to bottom,
#fff,
#fff 50%,
#edd 50%,
#edd
);
background-size: 100% 3rem;
overflow-x:scroll;
}

Hinweise

  • Funktioniert in allen aktuellen Browsern (IE ab 10), auch iPhone und iPad, also iOS, sowie Android.
  • tab-size:3; bzw . -moz-tab-size:3; definiert die Einrückung. (Nicht IE bzw. Edge)

Fullscreen Videos auf iPhone automatisch schließen

Sonntag, 3. April 2016

Von YouTube lernen. Ja, das ist möglich.
Doch der Reihe nach:
Das HTML5 <video> Element erzeugt Videos, die auf der Webseite eingebettet sind. Nach dem Betätigen des Startbuttons laufen die Videos innerhalb der Seite.
Nicht so auf dem iPhone. Dort werden alle Videos automatisch und zwangsweise als Vollbild dargestellt. Auf den relativ kleinen Bildschirmen macht das Sinn.
Unschön ist allerdings, dass nach dem Beenden des Videos das Vollbild mit den Bedienungselementen geöffnet bleibt. Man muss also manuell auf den Link "Fertig" oder das Symbol zum Verkleinern rechts unten tippen, um zur aufrufenden Webseite zurückzukehren.
Das ist nervig, und kann irritierend sein. Ein Zustand, der vom Betriebssystem automatisch hergestellt wird, sollte auch automatisch beendet werden, wenn die Voraussetzung nicht mehr gegeben ist.

Dass es auch besser geht, zeigt YouTube. Eingebettete YouTube-Videos werden natürlich auf iPhones ebenfalls als Vollbild dargestellt; aber nach dem Beenden schließt sich das Vollbild automatisch, und die aufrufende Seite wird wieder angezeigt.

Ich hab' mal ein paar Zeilen JavaScript geschrieben, um das meines Erachtens korrekte Verhalten auch bei HTML5 <video> Elementen zu erreichen. Die folgende Funktion bewirkt das automatische Beenden des Vollbildmodus' am Ende des Videos.

function CloseVideo() {
if (navigator.platform.match(/iPhone|iPod|Android/)) {
var e = document.getElementsByTagName('video').length;
for (var i = 0; i <= e; i++) {
document.getElementsByTagName('video')[i].webkitExitFullscreen();
}
}
}

Aufruf der Funktion im <video> Element mit onended=CloseVideo() im <video> Element, also z. B.:
<video controls onended=CloseVideo() ...

Demo z. B. auf der Seite webdesign.weisshart.de/homelink.php


Codesnippets auf Smartphone präsentieren

Sonntag, 27. März 2016

Die korrekte Darstellung von Codesnippets auf dem Desktop muss einigen Forderungen gerecht werden:

  • Zur besseren Lesbarkeit des Codes sollten Einrückungen wie im Editor dargestellt werden.
  • Der Code sollte zur Darstellung nicht umgebrochen werden.
  • Aus diesen beiden Forderungen ergibt sich häufig eine Breite, die über den verfügbaren Raum hinausläuft.
  • Mögliche Lösung: Eine Box, die unabhängig vom restlichen Seiteninhalt gescrollt werden kann.

Erstaunlicherweise funktioniert so eine Lösung sogar auf dem Smartphones, wie folgender Screencast vom iPhone zeigt:

Ab 0:20 wird gezeigt, wie der Kasten mit dem Code mit dem Finger gescrollt werden kann.

Der Code:

Das Codesnippet wird in ein <code> Tag gepackt.
Dazu folgendes CSS:

code {
white-space: pre;
overflow:auto;
display:block;
border:1px dashed;
}


Das HTML5 picture Element - jetzt von allen aktuellen Browsern unterstützt

Freitag, 25. März 2016

iOS 9.3 - die beste Nachricht, und niemand berichtet darüber, niemanden scheint das zu interessieren:
iOS 9.3 unterstützt das HTML5 picture Element. :-)

Demo:

Hier der Alternativtext für Screen Reader - nur ein Alternativtext für alle Größen!
Dunst über einem stillen See
Bild: http://unsplash.com/

Damit wird das picture Element von ALLEN aktuellen Browsern unterstützt.
www.caniuse.com/#search=picture
Ein großer Schritt für RWD (Responsive Web Design).
Ich bin versucht, das ab sofort einzusetzen, und dem IE nur noch zu liefern, was ihm zusteht: ein Fallback img src in Einheitsgröße.

Wenn du oben das folgende Bild siehst, dann unterstützt dein Browser das picture Element (noch) nicht:
Fehlerbild

Hier der Quellcode zu obiger Demo:

<picture>
<source media="(max-width: 639px)" srcset="images/flashlight_240.jpg" >
<source media="(min-width: 640px)" srcset="images/flashlight_600.jpg">
<!– fallback if picture is not supported –>
<img src="images/picture_not_supported.png" alt="Hier der Alternativtext für Screen Reader - nur ein Alternativtext für alle Größen!">
</picture>

Nachtrag 26.03.2016

Das hätte ich jetzt wirklich nicht erwartet: picture kann sogar zusammen mit Fancybox verwendet werden.


Google Analytics rechtssicher einsetzen

Dienstag, 22. März 2016

Google Analytics ist seit Jahren im Visier der Datenschützer. Und gleichzeitig das beliebteste Analysetool überhaupt.
Ein aktuelles Urteil des Landgerichts Hamburg (Az. 312 O 127/16) hat wieder einmal in Erinnerung gebracht, welcher Aufwand seitens des Webseitenbetreibers erforderlich ist, um das Risiko kostspieliger Abmahnungen zu vermeiden.
Die gute Nachricht:
Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit listet klar die Anforderungen auf:

  • Webseitenbetreiber müssen den von Google vorbereiteten Vertrag zur Auftragsdatenverarbeitung schriftlich abschließen. Diesen Vertrag erhalten Sie unter http://www.google.com/analytics/terms/de.pdf.
  • Webseitenbetreiber müssen die Nutzer Ihrer Website in Ihrer Datenschutzerklärung über die Verarbeitung personenbezogener Daten im Rahmen von Google Analytics aufklären und auf die Widerspruchsmöglichkeiten gegen die Erfassung durch Google Analytics hinweisen. Hierbei sollte möglichst auf die entsprechende Seite „http://tools.google.com/dlpage/gaoptout?hl=de“ verlinkt werden.
  • Webseitenbetreiber müssen durch entsprechende Einstellungen im Google Analytics-Programmcode Google mit der Kürzung der IP-Adressen beauftragen. Dazu ist auf jeder Internetseite mit Analytics-Einbindung der Trackingcode um die Funktion „_anonymizeIp()“ zu ergänzen.

Quelle: www.delegedata.de


Endlich verschlüsselt SSL/TLS/https

Sonntag, 20. März 2016

Meine Site wird ab sofort gesichert / verschlüsselt ausgeliefert. SSL/TLS/https

Screenshot
Im Browser wird vor der Adresse ein grünes Schloss angezeigt, als Zeichen für korrekte Verschlüsselung.

Die inzwischen fast 12 Jahre alte Site ist damit zumindest "unter der Motorhaube" jetzt auf dem aktuellen Stand der Technik. (Ja, ich weiß; das Design ist alles andere als modern.)

Die "Tuningmaßnahmen" im Zeitverlauf:

  • RWD (Responsive Web Design), früher: Layout für Handys/PDAs — gibt's bei mir schon lange.
  • HTML5 seit 2014.
    In der Folge alle Multimedia-Inhalte (Audio, Video) ohne Flash.
  • UTF-8 seit April 2015
  • und jetzt SSL/TLS

Das "Tuning" gilt selbstverständlich auch für alle von mir angebotenen Tools (Chat, Suchscript usw.). Auch diese Tools können mit HTML5, UTF-8, RWD und SSL/https, sowie ohne Flash. Letzteres ist Voraussetzung für die Nutzung auf Tablets und Smartphones mit iOS oder Android.

Eine Einschränkung, die ich gerne in Kauf nehme: Mit dem IE8 unter WindowsXP ist webdesign.weisshart.de leider nicht mehr erreichbar.


Google Webfonts und SSL

Freitag, 18. März 2016

Webfonts von Google kann man ganz einfach direkt von font.googleapis.com einbinden, ohne sie auf dem eigenen Server zu installieren.

<link href='http://fonts.googleapis.com/css?family=NamedesFonts' rel='stylesheet' type='text/css'>

Heute hat mein — zugegebenermaßen sehr restriktiv konfigurierter — Firefox sich plötzlich geweigert, solcherweise eingebundene Fonts zu benutzen.

Screenshot
So sollte es aussehen: Eine mit Webfonts gestylte Überschrift.
Screenshot
Wenn der Webfont nicht verfügbar ist, wird schlimmstenfalls das Layout zerschossen. Hier durch einen unerwünschten Zeilenumbruch.

Die Lösung war dann doch relativ schnell gefunden: Einfach googleapis.com per SSL aufrufen. Also:

<link href='https://fonts.googleapis.com/css?family=NamedesFonts' rel='stylesheet' type='text/css'>

Vielleicht hilft der Hinweis dem einen oder anderen Webworker.

NB:
Ich hab' bei der Gelegenheit auch gleich andere Zugriffe auf googleapis.com auf SSL umgestellt. Z. B. jQuery


AMP Accelerated Mobile Pages Project

Donnerstag, 17. März 2016

Google startet AMP [englisch] (Accelerated Mobile Pages Project)
Die Absicht dahinter: Seiten, die schnell laden. Auch und vor allem auf mobilen Geräten. Gut.
Und wenn Google so etwas macht, dann muss man es wohl ernst nehmen.

Mein erster Eindruck: Die Seiten scheinen im iPhone wirklich schnell zu laden.

Screenshot
Die Startseite des Projekts

Bei näherem Hinschauen zeigen sich leider einige "Besonderheiten":

  • Um zu testen, ob eine Seite schlank ist, und schnell lädt, gibt es ein allgemein anerkanntes Tool. Webpagetest.org.
    Dieses Tool zeigt leider mobil 747 kB für eine Seite. Das meiste davon JavaScript. Die Seite selbst besteht nur aus Text, und einem eingebundenen YouTube Video. Dafür braucht es keine 747 kB. Das lässt sich mit max. 200 kB lösen.
    JavaScript async laden macht zwar die Seite möglicherweise schnell, belastet aber dennoch mein Volumenbudget. Aufgabe leider nicht gelöst!
  • Die mobile Seite scheint kein Navigationsmenü zu besitzen! Erst Rumprobieren führt zufällig zum Ergebnis: Man muss auf dem Smartphone nach links wischen, um das Menü zu zeigen. In meinen Augen ein Usability Gau.
  • Die Seiten sind nicht valide. Daran ändert sich auch nichts, wenn man einen speziellen Validator entwickelt. Was soll denn der Unfug? Wenn meine Seiten nicht valides HTML beinhalten, dann entwickle ich einfach ein Werkzeug, das sagt, sie seien dennoch valide.
  • Mit der Barrierefreiheit der Seiten scheint es auch nicht sehr weit her zu sein. Zumindest zeigen alle meine Testwerkzeuge mehr oder weniger Fehler. In wie weit die vielen ungültigen HTML Tags die Zugänglichkeit mit Assistiven Technologien beeinträchtigen, müsste noch speziell getestet werden.

HTML5 Audio Wiedergabegeschwindigkeit

Mittwoch, 24. Februar 2016

Ein Grund mehr, für die Präsentation von Audios im Web das native HTML5 Audio-Tag zu verwenden, und nicht irgendwelche proprietären Player:

Screenshot
Das Kontextmenü mit Auswahl der Wiedergabegeschwindigkeit von 0,5x bis 2x

Im Firefox kann mit einem Rechtsklick auf den Player die Wiedergabegeschwindigkeit von Zeitlupe (0,5 fache) bis doppelte Geschwindigkeit gewählt werden. Der Player versucht dabei, die Tonhöhe nicht zu ändern. Der aus analogen Wiedergabegeräten (Plattenspieler) bekannte Micky Maus Effekt wird verhindert.
Das macht diese Technik z. B. für Podcasts interessant.

Ähnliche Beiträge:


Der Cookie Warnung Irrsinn - die Dritte

Sonntag, 24. Januar 2016

Es ist etwas ruhiger geworden um den EU Cookie Warnung Irrsinn. Mit etwas Glück verläuft das Thema ebenso im Sand wie zuletzt die unausgegorene Novellierung des Jugendmedienschutz-Staatsvertrags.

Weil man rund um EU-Regulierungen aber nie sicher sein kann, bereite ich mich weiterhin auf den Ernstfall vor. Der Ernstfall, das heißt für mich: Eine Vorschrift auch auf Kundenseiten bei Bedarf möglichst schnell, und vor allem sinnvoll umsetzen.

Screenshot
2 Buttons am Seitenfuß: "Akzeptieren" und "Cookie ablehnen"

Ich habe daher die Cookie-Warnung auf meiner Site um ein Opt-out erweitert. Das Opt-out ersetzt Hinweise wie

Durch die Benutzung erkären Sie sich mit dem Setzen von Tracking-Cookies einverstanden.

Unfug! Wenn ich nicht getrackt werden will, dann muss ich die Site verlassen?

Mit dem Opt-out hingegen kann der Besucher kann durch Klicken eines Buttons das Tracking seines Besuchs durch Google Analytics unterbinden, aber dennoch die Site weiterhin nutzen. Alternativ kann er durch Klicken auf den Button "Akzeptieren" das Tracking zulassen, den Hinweis aber ausblenden. Und, last but not least, kann er den Hinweis auch einfach ignorieren.

Ich bin neugierig, wie viele Besucher das Opt-out wählen. Die Statistik wird es zeigen.

Eine denkbare Alternative wäre ein Opt-in. Der Besucher muss explizit dem Tracking zustimmen, darf aber auch bei Ablehnung nicht an der Benutzung der Site gehindert werden.


Responsive Images via ImageEngine

Montag, 18. Januar 2016

Responsive Images sind die größte offene Herausforderung des Responsive Web Design (RWD). Welchen Sinn macht es, per CSS die Darstellung einer Webseite an die kleinen Smartphone-Monitore anzupassen, und dann mehrere 100 kB schwere Bilder per Mobilfunk zu übertragen, und lediglich die Darstellung für den kleinen Monitor anzupassen?

Es gibt mehrere Techniken, die das mobile Datenvolumen des Besuchers schonen, und nur die wirklich benötigte Größe einer Bilddatei zu übertragen. Alle sind mit mehr oder weniger Aufwand verbunden.

Einen neuen Ansatz wählt ImageEngine. Eine Art intelligenter Proxy für Bilder.

Beispiel

Eine Bilddatei, die im Original mit 230 kB auf dem Server liegt, wird von ImageEngine responsive gemacht, und "wiegt" mobil gerade mal noch schlanke 20 kB.

Screenshot
Typografie von Albrecht Dürer: Albertvs Dvrervs Nvrembergensis pictor hvivs aetatis celeberrimus, versus è Germanica lingua in Latinam …
Bild: Getty

Von ImageEngine gibt es eine kostenlose Version mit max. 5 GB Datenvolumen pro Monat. Die Einrichtung dauert nur Minuten. Bei Mehrbedarf wird's allerdings richtig teuer.
Zum anderen gilt meine Zurückhaltung, was Abhängigkeit von externen Diensten angeht. Das Ausfallrisiko für die eigene Website steigt mit jedem externen Dienst, von dem man sich abhängig macht. Für ImageEngine sehe ich momentan kein Fallback.


Sitemap - Sinnvoll oder nutzlos?

Montag, 11. Januar 2016

Darstellung der Verlinkung von Seiten untereinander
Symbolische Darstellung der Verlinkung von Seiten untereinander.
Grafik: Wikipedia OgreBot CC BY-SA 3.0

Jede Website muss eine Sitemap besitzen. Bereits 1996 hat der Usability-Papst Jakob Nielsen diese Forderung aufgestellt. Folglich hatte auch meine Site eine. Damit sie auch die Strukur meiner Site wiedergab, hatte ich sie manuell erstellt — und fast nie gepflegt . (Asche auf mein Haupt!)
Ob jemals ein Besucher sie genutzt hat, bezweifle ich.

Unabhängig von dieser, eigentlich für Besucher gedachten, Sitemap, gibt es natürlich auch eine sitemap.xml für Google. Diese Sitemap wird täglich per cronjob automatisch erstellt mit dem Tool von xml-sitemaps.com und automatisch an Google übergeben.

Warum nicht die aktuelle, vollständige sitemap.xml (derzeit 848 Seiten gelistet) dazu verwenden, auch die auf der Site veröffentlichte Sitemap stets aktuell zu halten?
Gesagt — getan: Ein Script von #! code musste ich nur wenig anpassen, um eine ansehnliche HTML-Sitemap zu erzeugen. Natürlich ebenfalls per cronjob täglich aktualisiert.

Gut. Eine richtige Sitemap ist das jetzt zwar nicht. Weil sie keinerlei hierarchische Struktur widerspiegelt. Vielmehr handelt es sich einfach um eine Auflistung aller Seiten mit kurzer Inhaltsangabe (aus dem description-Tag übernommen).

Wozu das Ganze also? Auch diese "Sitemap" wird Besuchern genau so wenig helfen wie die alte. Aber mir hilft sie! Als Hilfsmittel zur Fehlersuche. Allerhand Unsauberkeiten, Dateileichen u. ä. konnte ich beim Überfliegen "meiner" Sitemap bereits erkennen und korrigieren.


RWD und YouTube einbetten

Montag, 23. November 2015

YouTube Videos einbetten ist nicht schwer. YouTube selbst stellt ja den Code dafür unter "Teilen" - "Einbetten" bereit:
<iframe width="560" height="315" src="https://www.youtube.com/embed/xxx" frameborder="0" allowfullscreen></iframe>
Das Problem dabei: Die hart codierten Abmessungen verbieten sich in einem Responsive Design (RWD). Die maximale Breite ließe sich mit CSS iframe {max-width:100%;} responsive machen. Aber die Höhe? Das für Bilder gebräuchliche height:auto; funktioniert leider nicht.

Die Lösung:

Das iframe wird in ein zusätzliches Div gepackt:

<div class="yt">
<iframe width="560" height="315" src="https://www.youtube.com/embed/xxx" allowfullscreen></iframe>
</div>

und ins CSS:

.yt {
position: relative;
padding-bottom: 56.25%; /* proportion value to aspect ratio 16:9 (9 / 16 = 0.5625 or 56.25%) */
height: 0;
overflow: hidden;
}
 
.yt iframe {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
border:none;
}

Danke an A List Apart

Demo:

Nachtrag 24.11.2015

Nein, CSS-Tricks hat sicher nicht bei mir abgeschrieben. Sondern die Sache mit der proportionalen Skalierung von beliebigen Inhalten noch weiter gefasst. (Englisch)


RWD und umfließender Text

Freitag, 20. November 2015

Bilder von Text umfließen lassen — mit CSS float kein Problem:

Screenshot 1
Text umfließt mehrere Bilder. Hässlicher Leerraum wird dadurch vermieden.

Auf Tablets, Smartphones und unterschiedlichsten Monitorgrößen kann sich jedoch ein hässlicher Effekt ergeben.

Screenshot 2
Der für den Text verfügbare Platz wird so schmal, dass nur noch ein Wort pro Zeile angezeigt wird.

Diesen Effekt zu vermeiden, ist gar nicht so trivial. CSS min-width für den umfließenden Text scheitert. Lange Zeit habe ich mir damit beholfen, zwischen die ersten Wörter des floatenden Textes mehrere &nbsp;s einzufügen. Sehr unästhetisch. Seit ich automatische Tennung (hyphens) für Fließtexte verwende, genügte selbst das nicht mehr.

Meine Lösung:
Vor den floatenden Text kommt ein <div class="minwidth"></div>
und ins CSS:
.minwidth {min-width:10em;overflow:hidden;}

Wenn neben dem Bild weniger als 10em Platz verfügbar ist, wird das Div — und damit auch der folgende Text — unter das Bild geschoben. Problem gelöst.

Aber ein leeres Div manuell ins Markup einfügen, um das Layout zu retten. Das ist ja schon wieder "bäh".

An dieser Stelle kommt die Allzweckwaffe jQuery zum Einsatz.

$(function() {
$('.toolthumb').after('<div class="minwidth"></div>');
});

fügt nach jedem Element mit der Klasse toolthumb (also nach all meinen zu umfließenden Bildern) das obige Div ins DOM ein.
Problem gelöst. Ohne zusätzliches Markup, und vor allem, ohne dass ich in jedem einzelnen Fall dran denken müsste.


RWD ist gar nicht schwer

Montag, 16. November 2015

… und sogar nachträglich machbar. Wenn das Desktop-Layout sauber strukturiert ist.
Ein Beispiel gefällig:

Das Navigationsmenü auf www.backis-welt.de befindet sich im Quellcode nach dem Inhalt, also am Ende der Seite. Per CSS float wird es rechtsbündig dargestellt:

Screenshot Desktop Seite
Die "normale" Darstellung der Seite auf Desktop-PC und Notebook. Das Navigationsmenü wird in der rechten Spalte dargestellt.

Für die Darstellung auf Smartphones ist dieses Layout natürlich nicht geeignet.
Einige wenige Zeilen CSS verhindern das floating. Die Naviation wird, wie im Quellcode vorgegeben, am Ende der Seite dargestellt.
Der Sprunglink "Zum Wegweiser" (zur Navigation) — der auf PC und Notebook versteckt ist, und dort nur sichtbar wird, wenn er mit der Tab-Taste angesprungen wird (CSS: focus) — wird für die mobile Ansicht permanent dargestellt. Das ist notwendig, weil es auf Smartphones keine Tab-Taste gibt.
Anstelle des (Hamburger-)Menü-Buttons, der ein Menü einblendet, erfüllt hier also ein seiteninterner Sprunglink zur Navigation den Zweck.

Screenshot 1 iPhone
Die Darstellung auf dem Smartphone. Der Sprunglink zur Navigation "Zum Wegweiser" oben.
Screenshot 2 iPhone
Die Navigation wird für das Smartphone per CSS auf Seitenbreite vergrößert.

Der CSS-Code, der all dies ermöglicht, umfasst im Prinzip nur wenig Zeilen:

@media only screen and (max-width: 680px) {
 
/* Angaben zurücksetzen, Elemente auf 100% Breite einstellen: */
body,#main,#kopf,#inhalt, #navi, #kopf {border:0;margin:0;padding:0;box-sizing:border-box;width:100%;max-width:100%;}
 
/* Querformat-Darstellung auf Smartphones */
body { -webkit-text-size-adjust:none;font-size:100%;}
 
img {max-width:97%; height:auto;}
#navi ul {margin-left:0 !important}
#navi li {margin:5px 0 !important}
 
/* Skiplink positionieren */
.skip a {left:1em;top: 7em}
 
}


EU Cookie Richtlinie

Donnerstag, 22. Oktober 2015

Der Hinweis auf den Einsatz von Cookies — kürzlich von mir noch als Cookie Warnung Irrsinn bezeichnet — wird anscheinend über kurz oder lang zwingend.
Siehe diesen Artikel im I LAW iT-Blog
Weil ich keine Lust habe, mich mit einer Abmahnung herumzuärgern, hab' ich in den sauren Apfel gebissen, und meine Website mit so einem Monstrum "verziert".

Screenshot vom iPhone
Die mobile Startseite von webdesign.weisshart.de mit dem Cookie-Hinweis am Seitenfuß

Folgende Bedingungen stellte ich mir selbst:

  • Kein Opt-in, sondern ein Hinweis auf die Datenschutzerklärung, wo die Opt-out-Möglichkeiten beschrieben werden.
  • Seitenaufbau darf nicht verlangsamt werden.
  • Keine fremde Ressource, d. h. kein zusätzlicher HTTP-Request.
  • Möglichst wenig Belästigung für den Besucher.

Die Lösung:

Ein einziger Codeschnipsel, den ich nach der Seitenüberschrift eingefügt habe:

<?php
if (!isset($_COOKIE['eu-cookie-irrsinn'])) {
$ablauf = (time() + (365 * 24 * 60 * 60)) * 1000;
echo '
<div id="eu-cookie-irrsinn" style="hier CSS für das div">
<p style="hier CSS für den Text">
Hier der angezeigte Text <a href="datenschutz.php">Weitere Infos</a>
</p>
<button style="hier CSS für den OK-Button"
onclick="document.cookie=\'eu-cookie-irrsinn=accepted; expires=\'+(new Date('.$ablauf.')).toGMTString();this.parentNode.parentNode.removeChild(this.parentNode);">
OK<dfn> &mdash; hier klicken um diese Anzeige dauerhaft zu verbergen.</dfn></button>
</div>
';
}
?>

Meine CSS-Angaben für das div:

style="background-color:#f1f1f1; opacity: .9; font-size: .9em; width:100%; position:fixed; bottom:0; left:0; z-index:100; border-top: 1px solid #aaa"

Damit wird der Hinweis am Seitenende fixiert. Wichtig insbesondere für die mobile Ansicht, um wenigstens den Seitenkopf nicht zu verstecken.
Warum Inline-CSS? Um sicherzustellen, dass der Hinweis nicht aufgrund einer race condition ungestylt angezeigt wird.

PageSpeed Insights zeigt, dass ich die Vorgabe "Seite darf nicht langsamer werden" einhalten konnte.

Nachtrag 24.01.2016

Wer sich, wie ich, nicht über diesen Irrsinn ärgern will: Es gibt ein Browser-Addon dagegen: I don't care about cookies — und Ruhe ist.


Die RWD-Lüge - Betrug am Kunden die Zweite

Freitag, 9. Oktober 2015

Ich bin für die zwangsweise Einführung eines Hinweisschildes auf Webseiten:

Verbotsschild 6 MB

Dieses Schild sollte VOR! dem Laden bestimmter Seiten aufgerufen werden, wenn versucht wird, solche Seiten im Mobilfunknetz zu öffnen.

Hintergrund:
Es gibt immer noch Seiten — oder sollte ich sagen, immer mehr Seiten — die "responsiv" zwar die Anzeige an kleine Monitore anpassen, aber unendlich viele Daten laden, die zur Anzeige auf dem Smartphone gar nicht benötigt werden. In einem aktuellen Fall sind das 6 (in Worten sechs) Megabyte, die mein mobiles Datenvolumen belasten, um ein Bild und etwas Text anzuzeigen.

Warum machen Webworker so etwas? Gedankenlosigkeit? Schlamperei? Oder Unvermögen?
PageSpeed Insights und ähnliche kostenlose Tools sind bereits erfunden.

Screenshot PageSpeed Insights
PageSpeed Insights zeigt für die mobile Seite 15 von 100 möglichen Punkten für die Geschwindigkeit.

Die zunehmende Verbreitung von LTE macht die Sache nicht besser, sondern schlechter! Die Besucher merken wegen der hohen Download-Geschwindigkeit gar nicht, dass ihr teueres mobiles Datenvolumen unnütz verbraten wird. Nur die Provider freuen sich, dass sie immer größere Pakete verkaufen können.


Let's encrypt

Dienstag, 15. September 2015

Lass uns verschlüsseln! Sichere Verbindung mittels SSL/TSL-Verschlüsselung ist auf dem Vormarsch.

Google ja hat schon vor längerer Zeit angekündigt, dass die Nutzung eines SSL-Zertifikates ein Ranking-Faktor ist.
Auch wenn sicher nicht jedes private Blog ein SSL-Zertifikat braucht; spätestens wenn es ans Kommentieren geht, kann Verschlüsselung nicht falsch sein.
Nun kosten SSL-Zertifikate je nach Anbieter eine ordentliche Stange Geld. Für den genannten privaten Blogger kann das durchaus eine Hürde darstellen. Zum anderen stellt das Einrichten eines Zertifikats für den Betreiber einer kleinen Webpräsenz wohl auch eine technische Herausforderung dar.
Schön, dass es jemanden gibt, der diese Hürden niedriger legen will:

Screenshot
Let's Encrypt is a new Certificate Authority: It's free, automated, and open. Arriving Q4 2015

Let’s Encrypt hat sich zum Ziel gesetzt, kostenfreie, sichere und leicht ausstellbare Zertifikate für die Öffentlichkeit bereitzustellen – und dies möglichst einfach und automatisiert.
Gesposored wird das Projekt u. A. von Mozilla, Cisco, Akamai, EFF, Automattic und IdenTrust.
Ich hab' mich mal für das im 4. Quartal 2015 startende Beta-Programm angemeldet.

PS: webdesign.weisshart.de ist seit kurzem auch SSL-verschlüsselt erreichbar.

(Ausnahme: sms2web)

20.10.2015: Nächster Schritt für Let's Encrypt: Webbrowser vertrauen Zertifikaten

Die Zertifizierungsstelle IdenTrust hat die Zwischen-CAs von Let's Encrypt unterschrieben. Mitte November soll die Ausstellung von Zertifikaten für die Allgemeinheit beginnen.

Ab sofort vertrauen alle großen Webbrowser den beiden Zwischen-CAs Let's Encrypt Authority X1 und Let's Encrypt Authority X2. Denn neben Let's Encrypt hat nun auch die Zertifizierungsstelle IdenTrust die CAs unterschrieben (cross-sign).


Der Cookie Warnung Irrsinn

Freitag, 11. September 2015

Auf immer mehr Websites treffe ich auf diese hirnrissige Cookie Warnung:

Screenshot
Diese Webseite verwendet Cookies. Cookies werden zur Benutzerführung und Webanalyse verwendet und helfen dabei, diese Webseite besser zu machen.
Auf dem Smartphone nimmt der Hinweis zwei Drittel des Bildschirms in Anspruch.

" … helfen dabei, diese Webseite besser zu machen"? WTF? Was ist denn gut daran, wenn ich erst einmal klicken muss, um überhaupt zu sehen, wie gut die Website jetzt schon ist? Und ob der arme Jimdo-Webseitenbastler überhaupt weiß, was Webanalyse ist, und wie er mit Webanalyse die Website besser machen soll?

Ja, ich weiß. Diesen Unfug produziert in diesem Fall Jimdo. Und womit? Mit Recht. Mit der unklaren Rechtslage nämlich. Eine Google Suche nach "cookie warnung" zeigt die unklare Rechtslage auf, mit der Webworker konfrontiert sind.

Liebe EU: Bitte beschäftigt euch doch lieber wieder mit dem Krümmungsradius von Gurken, oder ähnlichen Themen, von denen ihr was versteht.

Die Nutzer wissen sich ohnehin längst anders zu behelfen: Cookies werden — manuell oder automatisch mit entsprechenden Browser-Addons — am Ende der Sitzung gelöscht, und sind damit sinnlos.
Werbetracker werden geblockt. Was bleibt, ist die unnütze und nervige Warnung, die jedesmal weggeklickt werden muss.

Nachtrag 21.10.2015

Ja, ich weiß, seit heute gibt es diesen "irrsinnigen" Hinweis auch auf diesen Seiten. (Ich weiß, weil ich das selbst "verbrochen" habe.) Ausführliche Erklärung incl. Code Snippets folgt.

Nachtrag 24.01.2016

Das beste Browser-Addon gegen den Irrsinn: I don't care about cookies


Mobiles Design aufgehübscht

Mittwoch, 9. September 2015

Mobile Seiten müssen schlank sein. Aber sie dürfen natürlich gerne auch hübsch sein.
Ich hab' mir vorgenommen, beides gleichzeitig zu realisieren; und zu diesem Zweck eine Slideshow mit Schmuckbildern auf der (mobilen) Startseite eingefügt. Zu sehen, wenn meine Site mit einem Smartphone aufgerufen wird, oder im folgenden Video.

(Bitte jetzt keine Kommentare zur "Schönheit" der Site. Schönheit liegt bekanntlich im Auge des Betrachters.)

Realisiert ist diese Slideshow mit CSS3, also ohne JavaScript. Der CSS-Code ist leider nicht ganz trivial. Hier ein Tutorial.
Aber der Verzicht auf JavaScript, in Verbindung mit optimierten Bildern, macht die Angelegenheit natürlich schlank. Die Startseite kommt immer noch mit ca. 80 kB aus.

PS:
Falls es interessiert, wie das Video, der Screencast vom iPhone, entstanden ist:
Auf dem Mac geht das ohne spezielle Apps, einfach mit dem ohnehin installierten Quick Time Player.

PPS:
Einige der Fotos kommen von unsplash.com. Free (do whatever you want) high-resolution photos.


Schnell, schneller, am schnellsten

Dienstag, 4. August 2015

Responsive Webdesign bedeutet nicht automatisch mobile-friendly.
Quelle: Internet

Na, ist doch meine Rede! Mobile-friendly heißt erstens schlank, zweitens schlank, und drittens schlank.

Wasser predigen … aber auch Wasser trinken!

Nach zahlreichen Ratschlägen, Artikeln und Blogposts über die Notwendigkeit, Webseiten schlank zu halten — zumindest für mobile Geräte — musste ich mich doch auch über meine eigene Site hermachen. Alle Empfehlungen zum Verschlanken angewandt, aber Google PageSpeed Insight war nicht wirklich zufrieden. Die mobile Version von webdesign.weisshart.de konnte Google nur ein müdes "70/100" für die Geschwindigkeit entlocken.

Gut, nach einigen Stunden Recherche und Tests sieht das jetzt schon besser aus:

Screenshot PageSpeed Insights
webdesign.weisshart.de nach der Optimierung: 98 von 100 für Geschwindigkeit, 100 von 100 für Nutzererfahrung

PageSpeed Insights von webdesign weisshart

tl;dr: nur Speed-Freaks lesen hier weiter: weiterlesen…


Responsive Web Design - Anzeige ist nicht alles

Samstag, 25. Juli 2015

Es ist kein Hexenwerk, eine Website mittels CSS und media queries auch auf kleinen Monitoren wie z. B. Smartphones ordentlich anzuzeigen. Jedes halbwegs brauchbare CMS hat dies heute schon "eingebaut".
Aber "ordentlich anzeigen" ist nur die halbe Miete.
Gestern hatte ich ein Gespräch mit einem Neu-iPhone-User. Er war hocherfreut über die Geschwindigkeit des LTE-Netzes, und wie schnell er jetzt auch unterwegs praktisch jede Website aufrufen kann. Allerdings: nach wenigen Tagen war sein inklusives Datenvolumen aufgebraucht.
Die Erklärung ist recht einfach: Kaum ein Anbieter macht sich die Mühe, seinen responsiven Webauftritt auch hinsichtlich des (mobil) zu übertragenden Datenvolumens zu optimieren. Da werden Bilder mit mehreren hundert kB übertragen, und auf dem Smartphone dann nur 320 px breit, oder möglicherweise gar nicht angezeigt.

Auf letzteren Fall möchte ich hier detailliert eingehen, und zwar an einem Beispiel auf meiner eigenen Site:
Die Artikelübersicht beinhaltet 34 Vorschaubilder. Jedes für sich zwar klein, und hinsichtlich der Dateigröße bereits optimiert (von wenigen kB bis max. 56 kB). Keines dieser Bilder wird beim erstmaligen Aufruf auf dem Smartphone ohne Scrollen ("above the fold") angezeigt. Die komplette Seite "wiegt" aber ca. 650 kB, und diese 650 kB werden bereits beim Aufruf der Seite übertragen, auch wenn der Betrachter gar nicht scrollt, also die vielen Bilder gar nicht sieht.
Nein, sie "werden" nicht! Sie "würden" nur übertragen, wenn ich nicht Unveil einsetzen würde.
Mit wenigen Zeilen Code schrumpft dieses geniale Tool die Seite beim ersten Aufruf auf 71 kB. Und Bilder werden erst bei Bedarf, d. h. beim Scrollen, nachgeladen. Das geschieht, ohne dass der Besucher etwas davon bemerkt.
Vielleicht straft Google irgendwann auch den unnützen Bandbreitenverbrauch ab. Dann würde der eine oder andere Webworker (SEO-Spezialist) ganz schnell zu der beschriebenen und ähnlichen Techniken greifen.

Nachtrag 27.07.2015

Wegen einer Besonderheit in iOS — Unveil triggert erst, d.h. Bilder "above the fold" werden erst angezeigt, wenn der User den Monitor des Geräts berührt — mache ich Bilder "above the fold" statisch. Auch auf Kosten von ein paar kB.


Der Nu Html Checker

Montag, 20. Juli 2015

Ob's schon jemand bemerkt hat?
Sicher doch: Alle meine Kollegen checken doch regelmäßig ihre Arbeit auf Standardkonformität mit dem W3C Markup Validator. Der W3C Validator ist allerdings ein wenig in die Jahre gekommen. Das letzte Update ist vom März 2012. Das passt irgendwie nicht zur rasanten Weiterentwicklung von Webtechniken. Erwähnt sei hier nur die (Quasi-)Verabschiedung von HTML5. Der W3C Validator hat daher schon lange empfohlen, zur Validierung von HTML5-Seiten den Nu Validator zu verwenden. Weil der Nu Validator aktiv weiterentwickelt und ständig an neue Standards angepasst wird.
Seit kurzem nun wird beim Aufruf des W3C Markup Validators automatisch auf den Nu Html Checker umgeleitet, wenn ein HTML5 Dokument gecheckt werden soll.


Homepage erstellen - wie anno 1995

Sonntag, 19. Juli 2015

Heute kam per E-Mail eine Anfrage um Verlinkung herein. Der Anfrager hat mein Tutorial "Deine erste Homepage" entdeckt. Das ist an sich kaum erwähnenswert. (In 99% der Fälle entsorge ich solche Anfragen von "SEO-Spezialisten" mit einem Klick.)

Wie auch immer: das Thema des angepriesenen E-Books: "Homepage erstellen", hat mich dazu bewogen, einen schnellen Blick drauf zu werfen, und das PDF kurz auf Barrierefreiheit abzuklopfen.

Meine Werkzeuge zum Schnelltest von PDFs:

Und tatsächlich: Das PDF ist strukturiert, und mit Screen Reader gut lesbar.

Doch jetzt zum Thema "lesbar":

Sowohl das PDF, als auch die Site selbst sind offenbar mit irgendeinem Tool erstellt, das wohl automatisch auf bestimmte Keywords optimierte Texte erzeugt. Lesbar ist das Ergebnis nicht wirklich. Und sinnvoll noch weniger.

Leseprobe (zur Erinnerung: Thema "Homepage erstellen"):

Ein Bild mit einer Höhe von 250 und einer Breite von 100 Pixeln wird also mit dem Tag eingefügt.

oder:

Ein Link ist ein HTML-Element, das sich aus einem -Tag sowie einem Inhalt zusammensetzt. Ein einfacher Link sieht also so aus: Inhalt.

Absolut unverständlich! Das automatisch erstellte Produkt hat anscheinend vor mir noch nie jemand gelesen. (Hinweis: Es handelt sich nicht um ein Darstellungsproblem, sondern dieser Unsinn steht so im Quellcode.)

Aber es geht noch schlimmer:

Tabellen wurden in HTML ursprünglich eingeführt, um den Inhalt der Seite, also den Text sowie die Bilder und Grafiken, übersichtlich darstellen zu können. Mittlerweile haben sich HTML-Tabellen jedoch zu einem grundlegenden Element des eigentlichen Designs der Internetseite entwickelt und werden nicht nur zur Strukturierung des Inhalts, sondern auch zu Erstellen des Seitenlayouts eingesetzt. Wer sich also das Ziel gesetzt hat, die eigene Homepage von Hand mit HTML zu erstellen, sollte sich genau mit HTML-Tabellen, ihrer Funktion sowie den dazugehörigen Attributen auseinandersetzen.

Die 1990er Jahre lassen grüßen! Ich kann nur hoffen, dass dieser Unfug nicht in falsche Hände gerät.
Ach ja, ich sollte doch einen Link setzen: www. homepage-erstellen.de


Nochmal: Kein Flash

Zufällig habe ich in den Tiefen meiner Site noch ein kleines Flash-Filmchen entdeckt, das meiner Aktion "Kein Flash" bis heute entkommen ist:
Das 14-Sekunden-Filmchen zeigt den animierten Link zur Startseite im Logo meiner Seiten.

Natürlich habe ich den Lapsus korrigiert, und den Flash-Film durch HTML5 video ersetzt.
Ganze 3 Zeilen Code sind dafür nötig, wie hier beschrieben.

Webworker können sich ja mal das Code-Ungeheuer anschauen, das nötig war, um den Flash-Film barrierefrei einzubinden:
weiterlesen…


user-scalable=yes

Sonntag, 28. Juni 2015

Responsive Web Design RWD und Barrierefreiheit: Das sollte nun wirklich kein Widerspruch sein; ganz im Gegenteil. Leider gibt es immer noch und immer wieder "Designer", denen ihr — "gephotoshoptes?" — Design so wichtig erscheint, dass sie den dummen User hindern, es durch Zoomen zu verunstalten.
Wie das geht? Ganz einfach:

<meta name="viewport" content="width=device-width, maximum-scale=1.0, minimum-scale=1.0, initial-scale=1.0" >

in den Header.
Der Meta-Tag "viewport" ist schon richtig und wichtig, um mobile Geräte anzuweisen, den Inhalt entsprechend der Bildschirmgröße richtig zu skalieren.
Aber

maximum-scale=1.0, minimum-scale=1.0

Was soll das? Auch Laien leuchtet anhand der sprechenden Syntax sofort ein, dass damit jeglicher Versuch des Users, den Seiteninhalt zu zoomen, vereitelt werden soll.

Warum macht so etwas eine Agentur, die für sich in Anspruch nimmt:

Darüber hinaus spielen auch Aspekte wie die barrierefreie Nutzbarkeit Ihres Webangebots, die responsive und adaptive Darstellung Ihres Designs auf Endgeräten mit unterschiedlicher Bildschirmauflösung (Smartphone, Tablet) … eine zentrale Rolle im Gestaltungsprozess.

Unwissenheit? Gedankenlosigkeit? Schlamperei?

Dabei wäre es so einfach:

Screenshot
Mit "Pinch" (zwei Finger auseinanderziehen) kann der User jedes Detail einer Webseite nach Bedarf zoomen — wenn der "Webdesigner" das nicht mutwillig unterbindet.

<meta name="viewport" content="width=device-width, user-scalable=yes, initial-scale=1" />

Also

user-scalable=yes

Und alles ist gut.


RSS Feed und Smartphones / Tablets

Dienstag, 23. Juni 2015

RSS Feeds sind (zu Unrecht) etwas aus der Mode gekommen. Ich vermute die Ursache in der Tatsache, dass sich nie ein Standard für die Anzeige von RSS Feeds etabliert hat, dass jeder Browser das anders handhabt, dass eine Unzahl von Programmen, Apps u. Ä. mit unterschiedlichsten Features im Umlauf sind, aber auch oft genug Services ihren Dienst quittieren.
Erinnert sei an den Google Reader, der vor einiger Zeit ohne Vorankündigung eingestellt wurde. Oder an das Hin und Her mit der Art, wie RSS Feeds in verschiedenen Browsern behandelt wurden und werden.

Ich habe daher schon immer einen direkten Link zum xml file des Feeds auf den entsprechenden Seiten eingebaut.



Firefox zeigt den Feed damit ordentlich an. Auch der Internet Explorer. Chrome und Opera (die Webkit-Engine) können offensichtlich mit einem xml file gar nichts anfangen, und zeigen den Quelltext. DerSafari-Browser wiederum behandelt Feeds wie Social Media Links, und zeigt sie — nach längerem Gefummel — in einer Seitenleiste an.

Da wohl (hoffentlich) die meisten Surfer die Eigenarten ihres Lieblingsbrowsers einigermaßen kennen, belasse ich es vorläufig bei dem Link.

Ganz schlimm wird es dann aber in Smartphones und Tablets. Nachdem mein iPhone den RSS Feed partout mit der Podcast App Instacast anzeigen wollte, und den Link aus Wordpress, der sich hinter einer .php Dateiendung (anstelle von .xml) versteckt, gar als PDF (!?), habe ich mich kurzerhand entschieden den Link zum RSS Feed auf Smartphones und Tablets nicht mehr anzuzeigen. (siehe Kommentare)


Wieviel kostet eine Website

Freitag, 24. April 2015

Anfrage:

Ich möchte meine [Produkte] online auf einer Website anbieten und möchte gerne wissen, was so eine Website bei Ihnen kostet? Die Seite soll barrierefrei sein.

Ohne den Nachsatz "… barrierefrei" wäre diese Anfrage der Löschtaste zum Opfer gefallen.
In diesem Fall habe ich geantwortet, bin kurz auf meine Expertise zum Thema Barrierefreiheit eingegangen, und habe einen – sehr moderaten – Mindestpreis genannt.

Die Absage kam erwartungsgemäß postwendend. "… übersteigt bei Weitem meine Vorstellungen."
So weit nicht weiter erwähnenswert.
In diesem speziellen Fall habe ich aber nachgefragt, was denn die Vorstellungen wären; und darauf – wider Erwarten – sogar eine Antwort erhalten:

Mir wurde jemand empfohlen, der es für 15 Euro im Monat einrichtet.

Ein-Euro-Schein


Google fordert Responsive Web Design

Freitag, 17. April 2015

Der Suchmaschinenriese Google fordert zunehmend Responsive Web Design RWD, also Seiten, die auch auf den kleinen Monitoren von Smartphones optimal bedienbar sind.

Screenshot Smartphone
Wenn eine Suche auf mobilen Geräten ausgeführt wird, dann werden Treffer, die mobile optimiert sind, bereits heute speziell gekennzeichnet: "Für Mobilgeräte"

Google hat angekündigt, Seiten, die für Mobilgeräte optimiert sind, in Zukunft generell besser zu platzieren.

Zitat Google Webmaster Blog:

Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results.

Je nachdem, wie groß die Abhängigkeit des eigenen Geschäfts von guten Platzierungen in den Suchergebnissen ist, kann also eine alte, nicht für Mobilgeräte optimierte Website echtes Geld kosten. Es wird also langsam Zeit, seine eigene Site darauf zu überprüfen, ob sie Googles Wohlwollen findet.
Webworker nutzen hierfür die Google Webmaster-Tools. Aber auch ohne Webmaster-Tools ist eine erste Kontrolle für jedermann möglich:
Google selbst bietet auf der Seite www.google.com/webmasters/tools/mobile-friendly/ einen Schnelltest auf Optimierung für Mobilgeräte.

Screenshot
Einfach die zu testende Adresse eingeben - fertig!

Facebook (und andere Sites) ohne Flash

Mittwoch, 15. April 2015

Ich geb's ja zu: Ich mache schon den einen oder anderen Klimmzug, um Flash von meinem MacBook zu verbannen. Siehe diese diversen Artikel über flashloses Leben.
Wir schreiben das Jahr 2015, und HTML5 Video ist bereits erfunden. Dennoch gibt es immer noch Spezialisten, die Flash anscheinend für unentbehrlich halten. Facebook gehört dazu, aber auch die Süddeutsche Zeitung. Beide stellen Ihre Videos zwar auch im HTML5-Format zur Verfügung, aber eben nur für Smartphones und Tablets. Klar, man will ja schließlich auch auf diesen Geräten verfügbar sein.
Aber ein Desktop oder Notebook ohne Flash? Das gibt es doch gar nicht?
Doch. Gibt es!
Nun könnten die Entwickler der o.g. Seiten ja einfach prüfen, ob Flash auf einem System verfügbar ist, und bei negativer Abfrage das entprechende HTML5-Video anbieten. (Was machen diese Leute eigentlich beruflich?)

Gut, dann muss ich eben selbst Hand anlegen.

1. Schritt:

Ich gaukle den betreffenden Sites einfach vor, ein iPad zu sein. Das geht, indem man der Site einen entsprechenden User Agent vorgaukelt. Das Firefox Addon User Agent Switcher erledigt das. Vielleicht muss man ein wenig mit verschiedenen User Agents experimentieren. Smartphone-User Agents eignen sich eher weniger, weil sie häufig auch noch ein für kleine Monitore optimiertes Design erzwingen.
Wenn man einen passenden User Agent gefunden hat, dann muss man eben jedesmal, wenn eine Site partout Flash-Videos an Stelle von HTML5-Videos ausliefern will, den User Agent wechseln.

Weil das auf Dauer eher lästig ist, taucht über kurz oder lang die Frage auf, ob man den Wechsel des User Agents nicht automatisch "per site" erledigen kann.
Man kann!

2. Schritt:

Die Lösung findet sich auf superuser.com: Die beiden Firefox Addons User-Agent JS Fixer und User Agent Site Switcher machen es möglich. Ja, man braucht beide. Aber nur letzterer taucht als Icon im Browser auf. Wenn die Site, die mit dem "passenden" User Agent versehen werden soll, im Browser offen ist, den User Agent Site Switcher aufrufen, und dort nur noch den passenden User Agent eintragen.
Und woher weiß ich, was der passende User Agent ist? Genau dazu ist Schritt 1 erforderlich. In diesem Addon die Edit-Funktion aufrufen, und den dort eingetragenen User Agent kopieren.

Klingt etwas kompliziert, aber die Mühe lohnt sich. Zumindest für so merkwürdige Zeitgenossen wie mich, die partout kein Flash auf dem Macbook wollen.


Keine Entwicklung mehr für IE 8

Sonntag, 5. April 2015

Logo IE 8Ich habe bis heute versucht, auch den Internet Explorer 8 noch bei der Entwicklung (Webseiten, Skripte) zu berücksichtigen. Trotz der allgegenwärtigen — und berechtigten — Aufforderung, doch bitte einen aktuellen Browser zu verwenden.
Es gab eine Benutzergruppe, deren Aversion gegen Upgrades ich zu respektieren versuchte. Screen Reader User, die noch Windows XP auf Ihrem Rechner hatten.
Heute habe ich den IE 8, den ich bisher zu Testzwecken in einer Virtuellen Maschine installiert hatte, gelöscht.
Das bedeutet nun nicht, dass meine Webseiten und Skripte unter IE 8 nicht mehr laufen. Es bedeutet lediglich, dass ich nicht mehr testen kann, ob es eventuell zu Darstellungsfehlern im IE kommt.
Klar, dass im Laufe der Zeit auch alle meine Webseiten und Skripte um die diversen IE 8-Hacks bereinigt werden.


Responsive Webdesign: Schriftgröße an Viewport anpassen

Samstag, 4. April 2015

Nicht sehr bekannt ist die Möglichkeit, per CSS die Schriftgröße an den Viewport anzupassen. Die Einheit lautet einfach vw (viewport width). Im Rahmen von Responsive Web Design RWD kann das bei bedächtigem Einsatz schon mal Sinn machen.

Im folgenden Beispiel ist ein Absatz mit font-size: 4vw ausgezeichnet. In der Praxis wird man so etwas wohl hauptsächlich mit Überschriften machen wollen.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Um das Beispiel in Aktion zu sehen, einfach die Größe des Browserfensters verändern.
(Das Beispiel ist für die Ansicht auf Desktop-Monitoren konfiguriert. Auf dem Smartphone ist es wenig "beeindruckend"; Auch und vor allem, weil man die Größe des Browserfensters auf Smartphones nicht ohne weiteres ändern kann.)

Eine detaillierte Beschreibung findet sich bei treehouse.
Und weil der treehouse-Artikel schon etwas betagt ist, hier die Browserunterstützung.


Die RWD-Lüge - Betrug am Kunden

Donnerstag, 12. März 2015

Web-Agenturen, die Responsive Web Design RWD für teueres Geld verkaufen, ziehen häufig den Besuchern der RWD-Website das Geld aus der Tasche. Den Grund dafür habe ich schon mehrfach thematisiert: Die Seiten werden zwar für die kleinen Displays von mobilen Geräten angepasst, aber dennoch auch im Mobilfunknetz Daten übertragen, die auf Smartphones gar nicht benötigt werden.
Ein Beispiel: (Ich erlaube mir die Wahl dieses Beispiels, weil die für das Beispiel zuständige Agentur explizit für RWD wirbt, z. B. in einem Kommentar in meinem Artikel.)
Jeder Aufruf der (fast 3 MB schweren) Startseite von pluswork.ag im mobilen Netz kostet ca. 0,30 €.

0,30 € mag nicht dramatisch erscheinen, aber es summiert sich, und freut die Mobilfunkprovider. Und manch einer, der hin und wieder mobil surft, wundert sich, wie schnell sein im Tarif enthaltenes Datenvolumen verbraucht ist.

Dass es besser geht, zeige ich mit meiner Demo. Der Besuch dieser Seite im Mobilfunknetz kostet nur 1 Cent.

Wer selbst testen will: webpagetest.org, dort den Test mit einem Smartphone durchführen, und in den Ergebnissen auf das $-Zeichen in der Spalte Costs klicken.

Screenshot
Die Ergebnisse von webpagetest.org (Ausschnitt)

CSS float und RWD

Dienstag, 3. März 2015

Die CSS-Eigenschaft float wird gerne eingesetzt, um Bilder von Text umfließen zu lassen. So weit, so gut.
Auf kleinen Bildschirmen kommt es jedoch häufig zu einem unerwünschten Layout-Problem:

Screenshot
Der Text "Lorem ipsum dolor sit amet" besteht aus kurzen Wörtern, und wird wunschgemäß neben dem (gefloateten) Bild angezeigt. Das Wort "consetitur" jedoch ist länger als der verfügbare Raum, und wird unter das gefloatete Bild geschoben.

tl;dr: Nur Webworker, die eine Lösung für das gezeigte Problem suchen, lesen ab hier weiter:
weiterlesen…


Deppenlink 2.0

Samstag, 7. Februar 2015

Der "Deppenlink" (bei Google, und meine Erklärung dazu) ist auch nach mehr als 25 Jahren Webdesign noch nicht ausgestorben. Immer noch gibt es Content Management Systeme (CMS), die ganz selbstverständlich Deppenlinks erzeugen. Wordpress sei hier stellvertretend genannt.
Etwas neuer ist der "Deppenlink 2.0". Der "nach oben"-Button macht auf langen Seiten eventuell Sinn. Aber nicht, wenn es gar nichts nach oben zu scrollen gibt:

Screenshot
Eine Seite, die so klein ist, dass sie auch auf kleinen Monitoren vollständig ohne Scrollen dargestellt wird.

Ich gebe zu: Es erfordert etwas Aufwand, den "Deppenlink 2.0" zu vermeiden. Aber wenn, wie im oben gezeigten Beispiel, 522 kB nur für JavaScript (darunter auch jQuery) eingesetzt werden, dann liegt es wohl nicht an Unfähigkeit der Entwickler, sondern eher an Gedankenlosigkeit.

Anmerkung: Der zweite auf dem Screenshot gezeigte Deppenlink — ein Button zum Sortieren, wo es nichts zu sortieren gibt — unterstreicht nur meine obige Aussage.


Hintergrundmusik auf Webseiten - reloaded

Samstag, 31. Januar 2015

Hintergrundmusik auf Webseiten — ja, das gibt es immer noch hier und dort.
Bereits 2009 habe ich zu diesem Thema gebloggt, und ein kleines Script erstellt, damit, wenn schon, die "Hintergrunddudelei" wenigstens erst vom Besucher gestartet werden muss.

Dieses Script basierte damals noch auf Flash. Eine Technik, die im Jahr 2015 nun wirklich nicht mehr nötig ist.
Ich habe das Script daher auf HTML5, und damit von Flash unabhängig, geändert.


Videos im Web - eine schöne Anwendung

Donnerstag, 15. Januar 2015

Für einen Kameramann, der sich auf professionelle Zeitrafferaufnahmen von Natur (Pflanzen, Insekten usw.) spezialisiert hat, durfte ich die Website neu erstellen.

Die Herausforderung dabei: Im Laufe der Zeit sollen bis zu 1000 Video-Clips präsentiert werden. Das Hochladen dieser Datenmenge muss natürlich der Inhaber der Website selbst erledigen. Ich habe daher ein Script erstellt, das aus den Dateien auf dem Server die entsprechenden Vorschauseiten erstellt, und auch die Präsentation der Videos selbst ohne manuelles Zutun erledigt.

Die Videos werden selbstverständlich ohne Flash, mit dem zeitgemäßen <video>-Element von HTML5 dargestellt. Die Dateien werden im MPEG-4/H.264 Video Format bereitgestellt, ein Format, das inzwischen von fast allen Browsern unterstützt wird, sowie zusätzlich im WebM Format. Letzteres wird lediglich noch für Firefox Versionen vor 35.0 und älter auf OSX und Linux-Systemen benötigt, und ist wohl bald verzichtbar.

Der Internet Explorer Version 8, der noch kein HTML5 kann, erhält als Fallback einen Link zum Download, bzw. zum Abspielen des Videos auf einem installierten Player.

Alle aktuellen Tablets und Smartphones mit iOS oder Android Betriebssystem können die "HTML5"-Videos abspielen.
Eine Besonderheit gibt es unter iOS und Android: Weder Autostart, noch das Vorladen der Videos werden unterstützt. Mit der nachvollziehbaren Begründung, das Datenvolumen von mobilen Nutzern erst dann zu belasten, wenn eine manuelle Eingabe erfolgt. Dies führt leider unvermeidbar dazu, dass der Start der Videos auf diesen Systemen deutlich verzögert wird.
Um auf Tablets während der Wartezeit nicht nur eine schwarzes Bild zu zeigen, wird daher zu jedem Clip ein Standbild gezeigt, das aus dem ersten Frame des Clips erzeugt wurde. (Das canvas-Attribut des video-Elements ist hierfür zuständig.)

Eine weitere Herausforderung:
Die Videos sollten an Hand von Stichwörtern durchsuchbar sein.
Die Lösung:
Zu jedem Video-Clip wird eine Textdatei mit entsprechenden Stichwörtern hinterlegt. Meine Suchfunktion wurde entsprechend angepasst: Durchsucht werden die Textdateien, zur Anzeige kommt aber nicht der gefundene Text, sondern das jeweilige Vorschaubild mit zusätzlichen Angaben —Name, Clip-Nummer usw. Das Ergebnis einer Suche ist im Design identisch mit der Anzeige der nach Kategorien unterteilten Clip-Archive.

Um die Seiten so schlank wie möglich zu halten, werden die Vorschaubilder auf dem Server auf kleinstmögliche Dateigröße umgerechnet. Das "Gewicht" der Seiten kann also nicht durch (versehentlich) zu große hochgeladene Bilder ungünstig beeinflusst werden. Bei dieser Gelegenheit werden die Vorschaubilder auch gleich noch mit dem Lupensymbol, das die Möglichkeit der Vergrößerung symbolisiert, versehen.
Ergebnis: Ein Clip-Archiv mit beispielsweise 28 Clips kommt mit ca. 400 kB aus. Erfrischend in Zeiten von 3 MB+ Monsterseiten.

Nachtrag 18.01.2015:
Auf einem Smartphone (Android One) wiegt die gleiche Seite sogar nur 174 kB. RESS macht's möglich.

Für die "Vergrößerung" und die Präsentation der Videos sorgt (auf Desktop und Tablets) Fancybox, eine Lightbox-Variante, die ich bevorzuge, u. a. auch weil sie Screen Reader-Nutzer am wenigsten stört.
Ja, ich weiß, blinde Menschen sind nicht die Zielgruppe dieser Site, aber das ist für mich kein Argument, auf Barrierefreiheit a priori zu verzichten. Daher war es nur naheliegend, auch hier wieder "mein" barrierefreies responsives Dropdown-Menü einzusetzen.


Accesskeys - eine Technik, die sich überholt hat

Sonntag, 11. Januar 2015

Accesskeys, die den Zugriff per Tastatur auf bestimmte Seiten und Inhalte einer Website erleichtern sollten, waren lange Zeit ein fester Bestandteil von barrierefreien Webseiten.
Auch auf meinen Seiten wurde diese Technik eingesetzt.
Ich habe mich entschieden, die Accesskeys nach vielen Jahren von meinen Seiten zu entfernen.

Begründung:

  • Es gab nie einen Standard. Das hatte zur Folge, dass jede Site ihre eigenen Accesskeys definierte. Seitenbesucher mussten also erst einmal herausfinden, welche Accesskeys auf einer bestimmten Site gelten, und sich diese — für jede Site unterschiedlichen — Keys merken.
  • Accesskeys können zu Konflikten mit Tastaturkombis führen, die im Betriebsystem oder im Browser des Benutzers wirksam sind. Dies können sogar vom Benutzer individuell konfigurierte Tastaturkombis sein. Es gibt also keine Tastenkombination, die sicher konfliktfrei arbeitet.
  • Nutzer von Screen Readern wurden gerne als Zielgruppe genannt. Gerade diese Personengruppe hat bessere, universell verwendbare Techniken, um auf Webseiten zu schnell navigieren.

Wozu braucht der Mensch Flash - Statusupdate

Montag, 29. Dezember 2014

Vor knapp 2 Monaten hab' ich Flash im Firefox deaktiviert, um zu sehen, ob das Leben ohne Flash — und ohne hochdrehenden Lüfter — lebenswert ist.
Damals habe ich auch 3 Baustellen benannt, die ich selbst "flashfrei" machen müsste, um glaubhaft zu sein:

  1. Videos auf Kundenseiten
  2. Der Yahoo! - Player, den ich u. a. in meinem Blog als Audio-Player verwende(te).
  3. Das in meinem Chat eingebundene Radio

Diese veröffentlichte Aufstellung hat wohl meinen Ehrgeiz geweckt.

Alles erledigt:

Screenshot
Der HTML5 audio-Player mit einigen Stationen, im Chat eingebettet.
  1. Kundenvideos werden in HTML5 mit dem video-Element erstellt. Mit einigen Buttons aufgepeppt, um die Steuerung des Videos auch mit der Tastatur zu ermöglichen.
  2. Im Blog und auf anderen eigenen Seiten wird das HTML5 audio-Element verwendet.
  3. Im Chat gibt es anstelle des eingebundenen Flash-Players von radio.de jetzt alternativ meine eigene Entwicklung. Erstaunlicherweise lassen sich mit dem HTML5 audio-Element nämlich auch Streams abspielen.

Erreicht habe ich nicht nur die Befriedigung meines Ehrgeizes, sondern auch ein ganz klein wenig mehr Barrierefreiheit im Web. Ich muss gestehen, dass ich "nicht unstolz" bin.

Nachtrag 31.01.2015

Es gab noch 2 Baustellen, die es galt, "flashfrei" zu machen:

  1. Der mp3-Player. Der Player ist zwar nach wie vor verfügbar. Aber ich gebe dem HTML5 Audio- und Radio-Player die Präferenz.
  2. Ein Uralt-Tool: Hintergrundmusik wird jetzt ebenfalls "flashfrei" angeboten.

Das HTML5 audio Element - wieder einmal

Samstag, 27. Dezember 2014

Die Unterstützung von HTML5 im Allgemeinen, und des audio-Elements im Besonderen, durch Browser ist ständig im Fluss — zum Besseren!
Inzwischen unterstützt auch der aktuelle Opera-Browser im audio-Element das .mp3-Format. Das erleichtert den Einsatz des audio-Elements erheblich. Die Bereitstellung der Audiodateien im alternativen .ogg-Format, die bisher erforderlich war, um auch Opera-Browser zu bedienen, kann damit endgültig unterbleiben.

Eine nette Anwendung, die davon profitiert: Mein Audioplayer. Barrierefrei, funktioniert in allen aktuellen Browsern (auch iOS), und leicht individuell konfigurierbar.

Diesen Player stelle ich kostenlos zur Verfügung. Download auf dieser Seite: audio_tag.php.


Entspannt Lesen

Donnerstag, 18. Dezember 2014

Eva Papst führt, mit viel Liebe zum Detail, seit Jahren ihre Website aus-meiner-feder.at. Heute würden viele diese Website wohl als Blog bezeichnen; was die Sache nur zum Teil trifft.

Eva Papst, selbst blind, legt großen Wert darauf, dass ihre Leserschaft, keineswegs ausschließlich blinde oder sehbehinderte Menschen, auch optisch ansprechende und vor allem leicht zu lesende Seiten vorgesetzt bekommen. Seit einiger Zeit hat sie mir die Verantwortung für das Design ihrer Site übertragen, eine Aufgabe, die sie selbst aus nachvollziehbaren Gründen nicht erledigen kann.
Absolute Priorität hat dabei, dem Leser entspanntes Lesen zu ermöglichen, damit er sich auf die Inhalte konzentrieren kann. Im Zuge dieser Prioritätensetzung kam vor einiger Zeit neben dem Stil "dunkel", mit dem die Website ursprünglich online gegangen war, ein zweiter Seitenstil "hell" hinzu. Der dunkle Stil setzte helle Schrift auf dunklen Hintergrund, eine Darstellung, die zwar von manchen (auch sehbehinderten) Menschen als leichter lesbar empfunden wird, von anderen aber, vor allem bei längerem Lesen, als ermüdend.

Screenshot 1
Der Styleswitcher, das Auswahlmenü für den Seitenstil, auf der Desktop-Ansicht von "Aus meiner Feder"

Die zunehmende Nutzung mobiler Geräte macht natürlich auch vor Eva Papsts "Blog" nicht halt. Prinzipiell waren die Seiten zwar immer schon auch mit Smartphones zugänglich. Korrekte Technik — valides HTML und CSS — sorgten dafür. Aber eben nur prinzipiell. Das für Desktop-Monitore gestaltete Layout führte dazu, dass die Texte auf Smartphones nur mit Zoomen und ständigem Links-/Rechts-Scrollen lesbar waren.
Ein interessanter Aspekt in diesem Zusammenhang: Für Eva Papst selbst und ihre blinden Leser, die ein iPhone und den Screen Reader Voice Over benutzen, waren die Seiten auch auf dem iPhone ohne Einschränkungen lesbar und bedienbar. Dem Screen Reader ist es nämlich egal, wie winzig die Schrift auf dem Monitor dargestellt wird.

Nach dieser Vorrede: Ein mobiles Design musste her. Und es ist gut geworden, darf ich nicht ohne einen gewissen Stolz sagen.

Nachtrag: Eva Papst bloggt über die "Nachrüst-Aktion".

Screenshot 2
Die Startseite von Aus meiner Feder auf dem iPhone. Links oben der "Hamburger Button" zum Auf- und Zuklappen des Navigationsmenüs

Das Konzept des mobilen Layouts von "Aus meiner Feder" — für Interessierte

weiterlesen…


Chance verpasst?

Freitag, 28. November 2014

Ein spannendes Experiment: Krautreporter

Zitat:

Krautreporter ist eine Community, die Journalismus im Netz ermöglichen möchte. Dafür nehmen wir uns Zeit — zum Recherchieren, Experimentieren, Diskutieren und natürlich zum Lesen.

Krautreporter hat per Crowdfunding über 1 Mio € Startkapital gesammelt. 90.000 € davon wurden für die Website (Software und Design) aufgewendet. Ein stolzes Budget.

Ja, die Website macht tatsächlich etwas her. Wenn, ja wenn man nicht

  • mobil bei geringer verfügbarer Bandbreite lesen will, oder
  • wegen einer Sehbehinderung auf einen Screen Reader angewiesen ist.

Was ist da schief gelaufen?

  • RWD (Responsive Web Design) ist heutzutage ein Muss für jede Agentur, die ein Projekt als zeitgemäß verkaufen will.
    Leider haben die Macher zwar berücksichtigt, dass Smartphones und Tablets über kleine Monitore verfügen. Aber auch an Smartphones Seiten mit bis zu 6 MB Gewicht auszuliefern, wovon lediglich 15 kB auf Text, also auf den Inhalt, entfallen? Smartphones werden nicht ausschließlich im WLAN oder mit LTE eingesetzt!
    Dabei wäre es mit etwas gutem Willen durchaus möglich, die Inhalte mobil-friendy anzubieten. Ich habe erst kürzlich einen Artikel zu diesem Thema verfasst.
  • Ganz schlechte Karten haben blinde und sehbehinderte Menschen, die Krautreporter mit Hilfe eines Screen Readers lesen wollen. Ohne auf Details einzugehen, darf ich hier stellvertretend 2 Fehler erwähnen, die es Screen Readern schwer machen, die Seiten korrekt wiederzugeben, und blinden und sehbehinderten Lesern, sich auf den Seiten zu orientieren:
    1. Die Seiten sind mit technischen Fehlern gespickt, und
    2. semantisch nicht bzw. sehr mangelhaft strukturiert (z. B. h2 für das Artikeldatum, aber keinerlei Gliederung der Artikel selbst durch Zwischenüberschriften).

Die Probleme lassen sich natürlich beheben. Leichter, und vor allem kostengünsiger wäre es allerdings gewesen, bereits in der Konzeptions- und Umsetzungsphase sowohl die Barrierefreiheit, als auch die mobile Nutzung entsprechend zu berücksichtigen.


Wie finde ich den passenden Webhoster für mein Projekt?

Donnerstag, 20. November 2014

Aus gegebenem Anlass — so sagt man wohl — und weil immer wieder danach gefragt wird, darf ich die Frage hier (wieder einmal) beantworten. Nein, nicht mit der Nennung eines bestimmten Webhosters, sondern mit einer Beschreibung über die richtige Herangehensweise.

Einen Webhoster wählt man nicht alle Tage aus. Die Zusammenarbeit soll schließlich über viele Jahre halten. Daher ist eine systematische Vorgehensweise nötig.

Ich habe vor einiger Zeit schon einmal einen Artikel zu diesem Thema geschrieben, und darf die wesentlichen Kriterien bei der Wahl hier noch einmal beispielhaft aufführen:

  • Features
    • Verfügbarer Speicher
    • Traffic
    • Anzahl möglicher E-Mail-Accounts
    • Welche tdl (Top Level Domains) sind verfügbar?
    • FTP-Zugänge
    • Installierte Software
    • Cronjobs
    • SSL-Proxy
    • SSH-Zugriff
    • DNS Einstellungen
    • Viren/Spamfilter
    • … usw. usf.
  • Server-Verfügbarkeit (Historie)
  • Backup: Werden die Daten auf dem Server gesichert, für den Fall eines Hard- oder Softwareschadens?
  • Hotline / Service
    • Telefonisch - 7 Tage / 24 Stunden?
    • per E-Mail - Bearbeitungsdauer?
    • Brauche ich eventuell Support für eigene Scripte? Falls ja: Preis?
    • Wie schnell wird auf Probleme reagiert? Sind Techniker 24/7 verfügbar?

Zum Glück gibt es Portale, die einen objektiven und neutralen Vergleich von Webhostern ermöglichen. Beispielhaft möchte ich hier webhostingvergleich24.com nennen. (Dort gibt es übrigens auch einen umfangreichen Fragenkatalog, der wesentlich mehr Kriterien als die oben genannten umfasst.)
Das Wichtigste jedoch sind detaillierte Tests und Erfahrungsberichte über die einzelnen Hoster.

Verschaffe dir also einen Überblick über den Markt, über die unterschiedlichen angebotenen Leistungen, lese Tests und Kundenbeurteilungen, und suche den für dich passenden Anbieter aus.
Falsch wäre es meines Erachtens, nur ein einziges Kriterium zur Entscheidung heranzuziehen, etwa die im Supportforum gestellte Frage, ob der Betrieb eines Chat erlaubt ist. Deine Anforderungen werden möglicherweise im Laufe der Zeit umfangreicher. Vielleicht kommt später einmal ein Blog dazu, oder sogar eine ausgewachsene Webpräsenz. Auch dann soll dein Webhoster noch zu dir passen.

Zuletzt darf ich mich noch selbst aus meinem Supportforum zitieren:

Wenn du eine Vorauswahl getroffen hast, dann kontaktiere den Hoster deiner Wahl und stelle eine konkrete Frage. Aus der Reaktion auf deine Frage kannst du möglicherweise schon erkennen, ob dieser Hoster für eine langjährige Zusammenarbeit in Frage kommt, ob die "Wellenlänge" stimmt. Kam als Antwort nur eine halbautomatisch aus Textbausteinen zusammengestellte E-Mail? Oder wurde speziell auf dein Anliegen eingegangen?


Wozu braucht der Mensch Flash - ein Versuch

Dienstag, 4. November 2014

Flash — das waren doch die coolen Webseiten, wo sich was bewegte. Und Filme im Internet.
Apples Steve Job hat Flash zu Recht vor langer Zeit bereits auf den Index gesetzt. Auf meinen iPhones und -Pads gibt es kein Flash. Und ich hab's dort bisher noch nicht vermisst. Auf dem MacBook aber ist Flash natürlich noch installiert. Unüberhörbar, wenn der Lüfter hochdreht, und "unüberfühlbar", wenn die Oberschenkel langsam aufgeheizt werden.

Dabei gibt es doch längst HTML5 und das video-Tag.

Was spricht eigentlich dagegen, einmal zu testen, ob die Welt ohne Flash lebenswert ist?

Mein Arbeitspferd für das Web ist Firefox. Dort kann man unter Extras — Add-ons — Plugins Flash ganz einfach deaktivieren. Ich verwende im ersten Schritt die Option "Nachfragen, ob aktiviert werden soll". Ich will (noch) wissen, was mir alles entgeht.

Screenshot
"Adobe Flash aktivieren" wird angezeigt, wenn ein Flash Video aufgerufen wird, aber Flash deaktiviert ist.

Und jetzt?

  • YouTube?
    Kein Problem. Youtube kann HTML5. Unter Umständen ist es einmalig erforderlich, den HTML5-Videoplayer zu aktivieren.
  • Facebook?
    Eingebettete Videos laufen nicht mehr. Vermutlich ist das eher eine Wohltat als ein Problem.
    Jedoch: Facebook weiß sehr wohl, dass man Videos auch ohne Flash schauen kann. Die iOS-App beweist es. Also warum nicht auch auf dem Desktop?
  • Twitter?
    ditto!

Jetzt kommt's aber dicker:

Ob ich wohl die Konsequenz aufbringe, alle diese Flash-Anwendungen zu eliminieren?
Man wird sehen.


HTML5 veröffentlicht

Montag, 3. November 2014

HTML5 hat jetzt den Status "Recommendation", und ist damit De-facto-Norm. Am 28.10.2014 hat das World Wide Web Consortium nach mehr als 6 Jahren Entwicklungszeit die Spezifikation der Hypertext Markup Language 5 veröffentlicht.

Das HTML5 Logo
Bild: Wikipedia

HTML, das ist die Sprache des Web, die (Auszeichnungs-)Sprache, in der Webseiten geschrieben (nein, nicht programmiert) werden.
HTML5 erweitert den Vorgänger HTML 4.01 um viele neue Elemente, und ermöglicht eine bessere, sinnfälligere Strukturierung von Webseiten.

HTML5 ist eine Obermenge von HTML 4.01; anders ausgedrückt: Praktisch alle Elemente von HTML 4.01 sind auch in HTML5 enthalten.
Diese scheinbar akademische Feststellung hat ganz praktische Konsequenzen: Der Umstieg auf HTML5 kann "sanft" erfolgen. Es genügt im ersten Schritt, ein vorhandenes HTML 4.01 Dokument mit der Dokumenttypangabe <!DOCTYPE html> zu versehen, und schon hat man ein gültiges HTML5 Dokument.

Anschließend kann man all die schönen und nützlichen neuen Möglichkeiten von HTML5 nutzen, z. B.:

  • Natives audio und video. Auf Sicht werden damit Erweiterungen wie Flash, Silverlight usw. entbehrlich.
    Ein praktisches Beispiel mit dem audio-Tag.
  • Strukturierende Elemente: section, nav, article, aside, header und footer, anstelle "nichtssagender" div-Elemente. Assistive Techniken, z. B. Screen Reader, nutzen diese Elemente heute bereits um die Seitenstruktur zu verdeutlichen, und die Navigation zu erleichtern.
  • Beim input-Element können Entwickler genauere Vorgaben machen, welche Eingabewerte zulässig sind. So sind etwa Datumstypen oder Schieberegler für Zahlen vorgesehen.

Nicht alle Browser unterstützen bereits alle Möglichkeiten von HTML5. Im Einzelfall kann man auf caniuse.com nachschlagen und entscheiden, ob und welche Elemente man nutzen kann / will. So wird z. B. der Input-Typ date von den Schwergewichten IE und Firefox gar nicht unterstützt, das audio-Element hingegen von allen modernen Browsern.

Mein Fazit:

HTML5 ist eine feine Sache, ohne Nachteile. Viele neue Möglichkeiten, Verbesserung der Barrierefreiheit, z. B. Entfall von Flash, Verbesserung der Orientierung auf einer Seite, usw.


Telefonieren - Direktwahl aus der Webseite

Mittwoch, 22. Oktober 2014

Telefonnummern finden sich wohl auf jeder Website. Zumindest auf impressumpflichtigen Websites die Telefonnummer des Seitenbetreibers. Dort hoffentlich nicht als Bild, sondern in Textform. Weil ersteres nicht nur sehbehinderte Nutzer ausschließt, sondern auch die formalen Anforderung an ein rechtssicheres Impressum nicht erfüllt, und im schlimmsten Fall zu einer Abmahnung führen kann.

So weit, so gut.

Seit dem Siegeszug von Smartphones und Tablets ist die Nutzung von Telefonnummern auf Webseiten sehr komfortabel. Viele Geräte erkennen selbständig, dass eine Ziffernfoge eine Telefonnummer sein könnte, und machen aus dieser Ziffernfolge automatisch einen Link, der die auf dem Gerät installierte Telefonapp aufruft. Sehr komfortabel.
Man kann es den Geräten auch leichter machen, und gleichzeitig die Darstellung der Telefonnummer frei gestalten, wenn man das URL-Schema "tel" verwendet.

Tel.: +49 171 - 8319084

Die Spezifikation zum URL-Schema "tel": RFC 3966

Solchermaßen eingebundene Telefonnummern ermöglichen unter Umständen auch das komfortable Telefonieren vom Desktop-Computern aus. Sie rufen, falls vorhanden, eine installierte VOIP-Software auf, oder nutzen auf Macs mit dem aktuellen Betriebssystem Yosemite die Telefonfunktion des iPhone.


Responsive Webdesign und Tabellen

Samstag, 11. Oktober 2014

Tabellen — nein, natürlich keine Layouttabellen! sondern Datentabellen — und kleine Monitore: das ist eine echte Herausforderung. Die Standardtechniken des RWD (Responsive Web Design) helfen hier nicht weiter.
Natürlich kann man auf Smartphones pinchen (zoomen). Unterstellt, der Webworker hat das nicht per meta-Tag unterbunden, was ohnehin ganz schlechter Stil ist. Aber die Übersicht über die Tabelle, die Zuordnung der Tabellenzellen zu den jeweiligen Köpfen geht dabei schnell verloren.
Es gibt fertige Lösungen, die zumeist auf JavaScript und CSS basieren. Keine dieser Lösungen passte so richtig auf meinen Fall:

Screenshot Desktop
Die Preisliste einer Pension. In der Desktop-Version der Webseite passen die 4 Spalten gut ins Layout.

Die gewählte Lösung: Nur die Kopfspalte und jeweils eine Datenspalte anzeigen.

Screenshot 2 iPhone
Beim Aufruf der Preisliste mit dem Smartphone wird zuerst einmal abgefragt, für welche von 3 Saisonzeiten die Tabelle angezeigt werden soll.
Screenshot 3 iPhone
Eine Kopfspalte und eine Datenspalte können auf dem kleinen Monitor in normaler Schriftgröße ohne Scrollen angezeigt werden. Zusätzlich wird noch auf die Details zu den einzelnen Tabellenzeilen verzichtet. Die Details sind in den verlinkten Detailseiten nachzulesen.

Die Umsetzung in Stichworten:

  • Media Queries reichen (leider) nicht. Ich frage per PHP den User Agent ab.
  • Falls der User Agennt ein Smartphone ist, wird per PHP das Auswahlmenü ein-, und die Tabelle erst einmal ausgeblendet.
  • Je nach gewählter Option (Saison) wird nach Absenden des Formulars (onChange="this.form.submit()") die Tabelle mit der gewählten Spalte angezeigt, und die beiden anderen Spalten per CSS verborgen.

Die RWD-Lüge - Betrug am Kunden

Mittwoch, 24. September 2014

Warum werben Agenturen mit RWD (Responsive Web Design) mit folgender Aussage:

Smartphones und Tablet PCs bringen ein paar weitere Anforderungen an ein gutes Responsive Design mit: … eventuell weniger Datenrate (von Unterwegs über 3G oder EDGE)

und liefern dann Webseiten ab, die mein mobiles Datenvolumen mit 2,7 MB belastet. Alleine für die Startseite. Wenn ich nicht nach mehrminütigem Warten auf den Seitenaufbau die Lust verliere.
Ich nenne das Betrug am Kunden, der den Mangel nicht nachvollziehen kann. Denn selbst wenn er seine eigene Website zum Test unterwegs mit dem Smartphone aufruft, lädt er höchstwahrscheinlich die Seiten blitzschnell aus dem Cache seines Smartphones, weil er sie vorher zuhause im WLAN schon einmal geladen hat. Seine Kunden erleben jedoch, was ich erlebte. Die beworbene, und teuer bezahlte Tauglichkeit der neuen Website für das mobile Web steht nur auf dem Papier.

Der phantastische Online-Dienst WebPagetest zeigt das Übel in aller Deutlichkeit:

Screenshot
Die Ergebnisse eines Tests mit WebPagetest:
Tabellarisch werden die wichtigsten Kenndaten aufgelistet, darunter ein Balkendiagramm, das die Ladezeit der einzelnen Seitenelemente darstellt. Rechts eine Vorschau der getesteten Seite.
Screenshot
Die wichtigsten Kenndaten:
  • Load Time: 34,496 Sek.
  • Bytes: 2.733 kB

Der Knackpunkt dabei: Auch an mobile Geräte werden Seiteninhalte geschickt, die auf dem kleinen Bildschirm keinen Sinn machen — viele Scripts zum Beispiel — , und zum größten Teil auch gar nicht benötigt werden, wie z. B. riesige Hintergrundgrafiken

Nein, dieses Beispiel ist kein Einzelfall. Sondern die Regel.
Um es noch deutlicher zu Sagen: Mir ist keine einzige Website bekannt, die das Datenvolumen für mobile Nutzung ordentlich optimiert. RWD, das Neu-Anordnen der Seitenelement für kleine Bildschirme, genügt eben nicht, um Seiten wirklich tauglich zu machen für mobile Nutzung.

Dabei wurde doch AWD (Adaptive Web Design) bereits erfunden!


Was muss ein Webdesigner bei der Auswahl eines Webhosters beachten.

Mittwoch, 17. September 2014

Webworker müssen bei der Auswahl eines Webhosters einiges beachten. Der eigene Server auf der ausgedienten Windows-Kiste reicht vielleicht zum Betrieb einer Gaming-Community. Für diesen Fall tut es möglicherweise auch einer der vielen Anbieter von kostenlosem Webspace. Auch im Falle einer "Anfänger-Homepage" kann man beim Webspace-Hosting ruhig aufs Geld schauen.
Aber sobald es an das Hosting von "seriösen", z. B. Unternehmens-Websites geht, steigen die Anforderungen an den Hoster.

Auf der Hand liegt die Frage: Webhosting, oder eigener Server? Wenn Server: Root-Server oder Managed Server?
Diese Entscheidung wird die Performance der gehosteten Site(s) erheblich beeinflussen. Aber das ist natürlich auch eine Kostenfrage.
Servermietpreise liegen mindestens beim zehnfachen von Webhosting-Paketen.

Relativ einfach ist es, die angebotenen Features mit den eigenen Bedürfnissen abzugleichen. Jeder seriöse Hoster bietet auf seiner Website eine (mehr oder weniger übersichtliche) Liste verfügbarer Features.

Features (Beispiele)

  • Verfügbarer Speicher
  • Traffic
  • Anzahl möglicher E-Mail-Accounts
  • Welche tdl (Top Level Domains) sind verfügbar?
  • FTP-Zugänge
  • Installierte Software
  • Cronjobs
  • SSL-Proxy
  • SSH-Zugriff
  • DNS Einstellungen
  • Viren/Spamfilter
  • … usw. usf.

Server-Verfügbarkeit (Historie)

100% Verfügbarkeit gibt es nicht. Aber auch 99,9% können einen nervösen Webmaster beunruhigen, wenn die 0,1% ausgerechnet dann zutreffen, wenn gerade eine dringende änderung durchzuführen ist.
Die meisten Hoster bieten hier Verfügbarkeitsstatistiken zum Vergleich an.

Das wichtigste Auswahlkriterium aber ist leider auch am schwierigsten zu fassen: Der Service.

Software

  • Wie aktuell werden Aktualisierungen der Serversoftware (Apache, PHP, MySQL usw.) durchgeführt?
  • Werden Updates rechtzeitig vorab angekündigt?
  • Werden neue Versionen vorab zum Test eigener Scripte zur Verfügung gestellt?

Backup

  • Welche Daten werden wie häufig und wie lange gesichert?
  • Was passiert bei einem Hardware-/Software-Crash im Rechenzentrum?

Hotline / Service

  • Telefonisch - 7 Tage / 24 Stunden?
  • per E-Mail - Bearbeitungsdauer?
  • Brauche ich eventuell Support für eigene Scripte? Falls ja: Preis?
  • und wieder schwer greifbar: Wie schnell wird auf Probleme reagiert? Sind Techniker 24/7 verfügbar?

Auswahl

Welche Kriterien besonders wichtig, und welche weniger wichtig sind, wird fallweise sehr unterschiedlich sein. Ein Vergleich von Webhosting-Angeboten, z. B. bei Netzsieger.de kann bei Auswahl und Entscheidung hilfreich sein. Auch Beurteilungen / Rezensionen durch Kunden können helfen.


Adaptive Web Design vs. Responsive Web Design - die Zweite

Montag, 8. September 2014

Im vorhergehenden Artikel hab' ich mich selbst gelobt, wie gut ich doch Websites für mobile Geräte optimieren kann.
Aber um welche Website es sich handelt, sollte ich doch noch verraten: Ein 5 Jahre altes Projekt relaunched.

Und vor allem sollte ich kurz erwähnen, wie es gelungen ist, eine 1,3 MB schwere Webseite auf 100 kB zu schrumpfen.
www.webpagetest.org

Mit Media Queries, dem Schweizer Messer des RWD (Responsive Web Design) geht das nämlich nicht. Vielmehr musste ich auf eine alte, etwas in Verruf geratene Technik zurück greifen: User Agent Sniffing.
Warum?
Media Queries können zwar für eine auf das jeweilige Gerät optimierte Darstellung sorgen. Aber sie können nicht verhindern, dass Daten vom Server geladen werden, die für eine mobile Ansicht gar nicht nötig sind. In unserem Beispiel sind das vor allem jQuery & Co.
Mit User Agent Sniffing stelle ich schon auf dem Server fest, ob ein mobiles Gerät auf die Site zugreift, und PHP sorgt dafür, dass bestimmte Inhalte gar nicht erst zu mobilen Geräten geschickt werden.

Auf html5-mobile.de gibt es eine schöne Sammlung der wichtigsten mobilen User Agents.
Diese User Agents werden in ein Array namens $agents gepackt, und etwa folgendermaßen abgefragt (PHP):

for ($i=0; $i<count($agents); $i++) {
if (isset($_SERVER["HTTP_USER_AGENT"])
&& strpos($_SERVER["HTTP_USER_AGENT"], $agents[$i]) !== false) {
$sitestyle = "mobile";
}
}

Die relevanten Daten, z. B. jquery.js, werden dann nur zum Client geschickt, wenn es sich NICHT um ein mobiles Gerät handelt.

if ($sitestyle != "mobile" ) {
echo'
<script src="jquery.min.js"></script>

Natürlich muss Sorge getragen werden, dass die Seiten konsistent bleiben. D. h. beispielsweise eben nicht auf jQuery zugegriffen wird, wenn es nicht verfügbar ist. Wie schon mehrfach erwähnt, bedeutet das Handarbeit. Und vor allem immer wieder testen. Mit verschiedenen Tools, aber natürlich auch mit echten Geräten.


Adaptive Web Design vs. Responsive Web Design

So. ich bin mir selbst untreu geworden. Ich habe meine erste Website mit mehr als 1 MB für die Startseite online gestellt. Exakt 1.35 MB. Der Wunsch des Kunden war mir Befehl. Es mussten einfach wechselnde Hintergrundbilder sein.

Screenshot
Der Screenshot zeigt die Webseite. Links die Bereichsnavigation mit der Box für Aktelles
Screenshot
Der Screenshot zeigt die Webseite, nachdem der Inhalt ausgeblendet wurde, um nur das Hintergrundbild anzuzeigen. Ein Feature der Website.

Schön und gut. Mit einem schnellen Internet.

Aber was ist mit den ca. 20 % Besuchern (gemessen), die das Angebot mobil nutzen?
Gut. Sie bekommen eine mobile Version mit 100 kB, also gerade mal 8 % des Gewichts der Standardseite angeboten. Dafür gibt es für mobile Nutzer zusätzliche Features, die mobil, und nur mobil Sinn machen. Z. B. Direktlinks zu Navigationsapps, die ggf. auf dem Smartphone installiert sind.

Screenshot iPhone
Auf dem mobilen Bildschirm wird zuerst einmal das Wichtigste gezeigt, nämlich die Last Minute Angebote, die auf der Standardansicht in der seitlichen Navigationsleiste eingebunden sind.

Nein. Das ist keine Seite, die speziell für mobile Nutzung erstellt wurde. Sondern RWD (Responsive Web Design) weiter gedacht. Also AWD (Adaptive Web Design). Was nicht benötigt wird, wird für die mobile Nutzung auch nicht vom Server geladen. Das geht weit über RWD, Responsive Images und ähnliches hinaus. Ein wenig Handarbeit ist dazu allerdings erforderlich. Ich kenne zumindest kein CMS, das ähnliches leistet.


Eine App - um jeden Preis - für jeden Sch***

Mittwoch, 3. September 2014

Eine App muss her! Hat ja die Konkurrenz auch.
Aber halt! Muss wirklich?

Nein. Da ist in den letzten Jahren etwas gewaltig schief gelaufen.

Warum etwa muss, für dickes Geld, zur Anzeige einer Wettervorhersage eine App für iOS, eine für Android, und eine für Windows entwickelt und gepflegt werden?
Warum muss ich mir für diesen Zweck einige MB downloaden und meinen kostbaren Speicherplatz damit füllen?
Wieso kann ich mir die Wetterprognose nicht auf einer — natürlich responsiven — Webseite anschauen?
(Doch, ich kann: wetter.de beweist es.)

Screenshot iPhone
wetter.de auf dem iPhone Safari-Browser

Klar, auch ich habe inzwischen 5 verschiedene Wetterapps installiert, mit zusammen 70 MB. Wofür habe ich mir schließlich ein Smartphone mit 64 MB Speicher gekauft. (Der Browser der mir die oben genannte Website wetter.de anzeigt, wiegt übrigens nur 4,7 MB!) Und das Icon, das ich mir als Shortcut zu wetter.de auf den Homescreen gelegt habe, ist mindestens so schön wie die Icons der Wetter-Apps.

Screenshot iPhone
Der Ordner mit den Wetter-Apps. Rechts unten das Icon mit dem Shortlink zu wetter.de im Safari-Browser

Und online muss ich für die Abfrage der Wetterprognose ohnehin sein. Wozu also eine App, wenn's mit einer Website auch geht?

Da läuft was schief!

Nun gut, Wetter ist die eine Sache. Ich könnte x andere Beispiele zitieren. Etwa die Gemeinde in der Urlaubsregion XYZ, die viel Geld zum Fenster raus geworfen hat für eine App, die letztlich nur einen Bruchteil der Informationen liefert, die ohnehin auf der Website zu finden sind, und keinerlei Mehrwert. Wer wird sich wohl diese App installieren, nachdem er die Websites der Urlaubsregion durchstöbert hat, und am Ende auf die berühmten Buttons "App im iTunes Store", "Google Play" usw. gestoßen ist. Aber "alle andern haben auch eine App. Also brauchen auch wir eine App."

Klar, es gibt auch Beispiele für sinnvolle Apps. GPS-Signale für eine Navi-App auszuwerten, damit wäre HTML wohl überfordert. Und nur navigieren, wenn ich Online-Zugriff auf Kartenmaterial habe, ist auch nicht gerade das Gelbe vom Ei.

Aber die hundertste Editor-App ist bestimmt nicht nötig. Eine pfiffige Web-App, die Zugriff auf die Cloud hat zur Ablage von Dokumenten, und die begrenzt Daten auf dem Gerät zwischenspeichern kann, sollte mit HTML5 machbar sein. Browser und Betriebssystem müssten solche intelligenten Lösungen unterstützen.

Neuer Anlauf: Ein FTP-Programm. Das geht doch nur mit einer App. Dafür macht eine App doch sicher Sinn? Um unterwegs mal schnell einen Fehler in einer Datei auf dem Server zu korrigieren. Oder etwa doch nicht? Es gibt webbasierte FTP-Clients. Und für die schnelle änderungen, die unterwegs mal nötig wird, sollte das doch auch im mobilen Browser möglich sein.

Screenshot iPhone
net2ftp.com bietet einen webbasierten FTP-Client. Die Site ist responsive, und auch mit dem Smartphone bedienbar.

Quod erat demonstrandum.

Ich prognostiziere mal, dass es diesbezüglich in einigen Jahren eine Rückkehr zur Vernunft geben wird.


Social Plugins - Facebook, Twitter und Google

Mittwoch, 20. August 2014

Nicht mehr ganz neu: Datenschützer mögen die Art nicht, wie die sozialen Dienste Facebook, Twitter und Google+ das Nutzerverhalten ausspionieren, wenn und sobald auf einer Seite die bekannten "Like"- und "Teilen"-Buttons eingebaut sind. (Ich mag das übrigens auch nicht.)
perun.net hat dazu gebloggt. Und auch gleich noch eine elegante Lösung publiziert: Statische Social Buttons. Elegant, schlanker Code, und vor allem: ich konnte den Code lesen, und verstehen, was dort passiert, bzw. nicht passiert. Klar, das ich die Lösung übernommen habe.

Leider funktioniert diese Lösung seit einiger Zeit nicht mehr. Facebook hat mal wieder was kaputtgeändert. Die sharer.php funktioniert nicht mehr. Und ich habe keine Lust, die aufwändige, auf stackoverflow beschriebene Lösung einzubauen. Weil ich mir ausrechnen kann, wann Facebook die API wieder kaputtändert.

Also zurück zur 2-Klick Lösung von heise.de.
jQuery Plug-In socialshareprivacy — Dokumentation

Egal, wie der aktuelle Stand bzgl. Datenschutz ist: Mir ist damit wohler, als mit den Standardbuttons. Ich will nicht, dass die Besucher meiner Seiten ausgeschnüffelt werden.

Ein Bild kann ich mir ersparen. Der geneigte Leser sieht es in diesem Artikel. Natürlich nur, wenn er den Artikel selbst aufruft, und nicht eine Übersichtsseite, Kategorie o. ä.


Audio- und Videoplayer barrierefrei

Samstag, 2. August 2014

Das Thema barrierefreie Audio- und Videoplayer beschäftigt mich seit langer Zeit. Ich habe zu diesem Thema im Laufe von Jahren eine Vielzahl von Artikeln und Demos verfasst.

Es sieht fast so aus, als ob die Suche ein Ende hätte. HTML5 und Terrill Thomsons Able Player sei Dank.
Auf obiger Übersichtsseite werden eine Reihe von Demos verlinkt, mit allen denkbaren Optionen. Ich möchte folgende zwei Beispiele hervorheben:

Terrill Thomsons Able Player stellt alles in den Schatten, was ich gerne als „der beste bisher“ bezeichnet habe. Der Player ist Open Source und steht unter der freien MIT-Lizenz.
Able Player bei GitHub

Kollegen: Verwenden! Nicht nur blinde, seh- oder hörbehinderte Menschen werden es euch danken.

Nachtrag 01.09.2016:

Nachdem zwischenzeitlich alle relevanten Browser natives HTML5 unterstützen, halte ich persönlich den Einsatz des Able Players in den weitaus meisten Fällen für überflüssig, weil der Einbau zu aufwendig ist. HTML5 audio oder HTML5 video sollten fast immer genügen.


Speed

Samstag, 19. Juli 2014

Ich bin ein Speed-Freak. So lange ich „Web“ denken kann.
Aus den Zeiten von 56 kB Modems stammt mein Streben, zumindest die Startseite jeden Webauftritts so klein wie möglich zu gestalten. Ursprünglich war meine Zielmarke 50 kB.
Aus dieser Zeit stammt auch die Aussage

Wenn sich eine Seite nicht in 8 Sekunden aufbaut, klicken 30% der Besucher wieder weg.

Aus dieser Zeit stammt auch mein eigener Webauftritt. Mit gerade mal 64 kB für die Startseite. Ich gebe ja zu: Die Seite wirkt nicht sehr „modern“. Aber sie lädt verdammt schnell. In ca. 0,5 Sekunden.
Damit bin ich recht nahe am Ideal.

Wie nimmt ein User die Geschwindigkeit wahr
Quelle: radware
Legende:
0 - 100 ms Sofort
100 - 300 ms: Kurze, gerade eben wahrnehmbare Verzögerung
300 - 1000 ms: Die Maschine arbeitet
1000+ ms Die Gedanken (des Besuchers) wandern anderswohin.
10.000+ ms Die Aufgabe wird abgebrochen.

Es hat sich also nichts geändert. 8 bzw. 10 Sekunden Ladezeit werden vom User nicht akzeptiert. Anzustreben ist weniger als 1 (eine!) Sekunde.

Sehr wohl geändert haben sich aber die durchschnittlichen Seitengrößen:

Durchschnittliche Seitengrößen von 1995 bis 2014
Quelle: websiteoptimization.com
2003: 93 kB - 2014: 1,6 MB

Nein, ich rede nicht der Technik von 2003 das Wort. Moderne Seiten machen richtig Spaß. Aber nicht, wenn Sie 2 oder 3 MB schwer sind, und ich sie unterwegs im Mobilfunknetz aufrufe. Dabei sind viele Seiten Ihre MB gar nicht wert. Häufig ist es einfach Schlamperei (oder fehlendes Können?) der Seitenschreiberlinge. Man kann nämlich sehr gut grafisch ansprechende, ja sogar interaktive Seiten mit weniger als 1 MB erstellen. Und es gibt sie tatsächlich: Seiten, die in weniger als 1 Sekunde laden.

Selbstverständlich sollte heutzutage sein, dass Vorsorge getroffen wird für mobile Geräte und Menschen „on the road“.

So, genug des Grundsatzgeschwafels. Fakten her!

weiterlesen…


Archiv:

Kategorien:

Creative Commons Lizenzvertrag
Alle Texte (nicht Bilder!) Creative Commons CC BY-NC-SA 3.0 DE