Sprung zum Inhalt [/]

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zur Liste der Kategorien | zum Archiv

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…


Wie gut ist der Akku meines iPhones noch?

Samstag, 28. Februar 2015

Die Akkuladung eines iPhones geht immer viel zu schnell zur Neige. Dagegen helfen auch die zahlreichen Tipps über sparsamen Umgang mit der Akkuladung relativ wenig. Wer sein iPhone nicht nur als Statussymbol nutzt, sondern die Möglichkeiten — Internet, Navi, Apps — wirklich nutzt, wird früher oder später die nächste Steckdose aufsuchen müssen.
Das Dumme dabei: Als das Gerät neu war, hat der Akku viel länger durchgehalten. Tatsache oder Einbildung? Hat die Leistung des Akkus wirklich so schnell nachgelassen? Oder nutze ich das Gerät nur intensiver?

Um zu messen, wie gut der Akku tatsächlich noch ist, mussten bisher ziemliche Klimmzüge unternommen werden. Das ist ab sofort viel einfacher. Ein Tool, das schon lange auf meinem Macbook installiert ist, und dort den Status der Batterie misst und protokolliert, gibt jetzt auch ganz einfach Auskunft über die Qualität des iPhone-/iPad-Akkus: coconutBattery

Screenshot
coconutBattery zeigt den Status des Akkus von angeschlossenen iOS-Geräten

Einfach das Gerät (iPhone, iPad, iPod) per USB an den Mac / das MacBook anschließen, und sofort werden die gewünschten Infos über den Status des Geräteakkus angezeigt.


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.


Facebook ohne Flash

Mittwoch, 4. Februar 2015

Ich habe mich ja vor einiger Zeit von Flash verabschiedet. Aus Gründen.
“Ordentliche” Websites werden auch ohne Flash ordentlich dargestellt. Auch, wenn sie praktisch nur aus Videos bestehen. ;-)
YouTube — kein Problem.
Twitter — kein Problem.
Nur Facebook ist anscheinend mit Adobe “verbandelt". In Facebook gepostete Videos werden auf meinem Macbook nicht angezeigt.

Fehlermeldung bei Facebook
Beim Aufruf eines Videos zeigt Facebook diese Fehlermeldung:
“Du musst die neueste Version von Adobe Flashplayer herunterladen und installieren.

Du musst … Nein! Muss ich nicht. Und werde ich auch nicht.
Facebook will mich nur vera***en. Auf den Servern von Facebook liegt nämlich das Video nicht nur in einem Flash-kompatiblen Format, sondern sehr wohl auch in einem Format (mp4 H.264), das vom nativen HTML5-Player verstanden wird. Klar: nur so schafft es Facebook, Videos auch auf iOS (iPhone, iPad) und Androiden (Smartphones, Tablets) darzustellen.

Was also tun, um Facebook-Videos auch ohne Flash auf dem Desktop / Notebook zu spielen?
Nichts einfacher als das.
Im Adressfeld des Browsers die angezeigte Adresse ändern von https://www.facebook.com/… in https://m.facebook.com/…

Das Adressfeld des Browsers.
Das Adressfeld des Browsers nach dem Aufruf eines Videos auf dem Desktop / Notebook
Das Adressfeld des Browsers
Das Adressfeld des Browsers nach dem Ändern auf http://m.facebook.com/…

(Achtung! Nach dem Ändern der Adresse die Seite nicht reloaden (mit F5 o. ä.), sondern die geänderte Adresse mit Enter aufrufen!)

Et voilà - Das Video rennt. Das “m” gaukelt Facebook vor, dass ich die Seite mit einem mobilen Gerät besuche.
(Dass Facebook zu doof ist, direkt die Verfügbarkeit von Flash abzufragen, möchte ich lieber nicht unterstellen.)

Das Video
An der Adresse https://fbcdn-video-b-a.akamaihd.net/… erkennt man, dass das (H.264) Video auf dem Facebook-Server liegt.

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.

Das HTML5 audio Element - wo Apple falsch denkt

Samstag, 3. Januar 2015

Die HTML5 Elemente audio und video kennen unter anderem die Attribute autoplay und preload. Beide Attribute werden von iOS (und auch Android ab Version 4.2.2) nicht erkannt. Unter iOS muss ein Audio bzw. Video durch eine Nutzereingabe gestartet werden. Das — scheinbar logische — Argument: Benutzer, die im Mobilfunknetz surfen, sollen vor unerwartetem Datenverbrauch geschützt werden.

Ich halte dies für eine unsinnige Bevormundung des Users, und einen Usabilty-Fail.

Beispiele:

  1. Gerade Tablets werden häufig im WLAN genutzt, und nicht automatisch im Mobilfunknetz.
  2. audio autoplay ist nützlich, um bei bestimmten Events Sounds auszugeben. Nicht nur Games nutzen Sounds, auch z. B. mein Chat.
  3. Eine Liste, aus der verschiedene Videos ausgewählt werden können. Nachdem der User ein Video gewählt hat (also bereits einmal eine Nutzereingabe getätigt hat) muss mit einem weiteren Tipp das Video selbst gestartet werden. Eine Zumutung.

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.

Ältere Beitäge:

Kategorien:

Creative Commons Lizenzvertrag
Alle Artikel des Blogs Creative Commons CC BY-NC-SA 3.0 DE