Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zum Archiv und den Kategorien

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:


RWD und Lightbox & Co.

Montag, 22. Februar 2016

Präsentationstechniken für Fotos wie Lightbox & Co. sind im Web allgegenwärtig. Diese Lightbox-Skripte haben Responsive Web Design (RWD) quasi eingebaut; das vergrößerte Bild wird nie größer als das Browserfenster. Selbst auf Smartphones nicht.

Alles bestens, sollte man meinen.

02.08.2016: Dieser Artikel trifft für dieses Blog nicht mehr zu. Ich habe Fancybox durch PhotoSwipe ersetzt.

Beileibe nicht: Das Vorschaubild wird auf Smartphones in der Regel die ganze Monitorbreite einnehmen. Das macht Sinn, um den Bildinhalt auf dem kleinen Bildschirm überhaupt zu erkennen. Wenn nun beim Antippen des Vorschaubildes, analog zum Anklicken auf dem Desktop-Monitor, sich ein "Großbild" öffnet, das nicht größer oder gar etwas kleiner als das Vorschaubild ist? Dann ist das Prinzip Lightbox ad absurdum geführt, und der einzige Nutznießer der Mobilfunk-Provider, der — nutzloses — Datenvolumen abrechnen kann.
Das Großbild ist natürlich nicht wirklich kleiner als das Vorschaubild. Es wird lediglich vom Browser verkleinert dargestellt. Das herunter geladene Datenvolumen ist aber unabhängig der angezeigten Größe, und bewegt sich üblicherweise in der Größenordnung mehrere 100 kB bis zu mehreren MB.

Der Screencast vom iPhone zeigt, wie das Vorschaubild sich beim Antippen verkleinert, statt vergrößert.

Abhilfe?

Lightbox und viele Clones, so auch das von mir favorisierte Fancybox, benutzen als HTML-Syntax, um das Vorschaubild mit einem klickbaren Link zum Großbild zu versehen, einen Hyperlink.
Der HTML-Code sieht also prinzipiell so aus:
<a class="box" href="Pfad_zum_Großbild"><img src="Adresse_Vorschaubild" /></a>

An Smartphones sollte nun idealerweise der Link zum Großbild nicht ausgeliefert werden, sondern nur das "nackte" img-Tag:
<img src="Adresse_Vorschaubild" />

Meine Lösung:

Folgendes jQuery-Snippet (nur) an Smartphones ausliefern:
$('a[class="box"]').contents().unwrap();

Dieses Snippet entfernt alle Links der Klasse "box", der Linktext wird zu Text ohne Verlinkung.

Demo:

fritz-weisshart.de/meg_men/
Um den Unterschied zu sehen, die Demoseite auf dem Desktop und mit dem Smartphone aufrufen.

Ja, unwrap() erfordert jQuery. jQuery muss also auf der mobilen Version der Website verfügbar sein.
Und ja, um das Snippet ausschließlich an Smartphones auszuliefern, muss eine Technik zur Erkennung des User Agents installiert sein. Ich verwende http://detectmobilebrowsers.com/


Mobil Chatten - mit Event-Sounds

Montag, 8. Februar 2016

Auch mein Chat wird immer häufiger mit Smartphones oder Tablets benutzt. Ich hab' deshalb ein bisher dort fehlendes Feature nachgerüstet: Soundbenachrichtigung für verschiedene Events, z. B. «Neuer User betritt den Chatroom» oder «Eingang einer Nachricht».

Screenshot
Die geöffnete Liste mit den verfügbaren Optionen im mobilen Skin

Um die Sounds zu Aktivieren: Optionen [+] öffnen
Diese Option muss bei jedem Neuladen der Seite — z. B. beim Wechsel des Chatrooms, Wahl von Optionen — erneut aktiviert werden. Der Grund hierfür liegt in einer Einschränkung der mobilen Betriebssysteme iOS (iPhone, iPad) und Android.

Zur Technik:
Die Sounds liegen als .mp3 Dateien vor, die, anders als Flash, von iOS und Android akzeptiert werden. Und die einzelnen Dateien sind in ein audio sprite gepackt.


Eine responsive Website anstelle einer App

Mittwoch, 3. Februar 2016

Schön, wenn ich mal in meiner Meinung bestärkt werde, und sogar eine meiner Prognosen eintrifft.

Unter der Überschrift Eine App - um jeden Preis - für jeden Sch*** habe ich gefordert, die Möglichkeiten des Responsive Web Design RWD zu nutzen, und nicht um jeden Preis eine App anstelle einer gleichwertigen Website zu veröffentlichen.

Jetzt hat wetter.com sich offensichtlich meiner Meinung angeschlossen.

Screenshot der Website auf dem iPhone
mobile.wetter.com auf dem iPhone

Die mobile Ansicht von wetter.com bietet den gleichen Leistungsumfang wie die Desktopversion. Aber ich spare mir die Installation einer App. Und wie man ein Icon für eine Website erstellt, dürfte inzwischen auch bekannt sein.

Nachmachen! Vielleicht hab' ich dann irgendwann auf meinem iPhone wieder Safari-Lesezeichen anstelle von 250 Apps.

Nachtrag

Ein Test auf Barrierefreiheit mit VoceOver, dem integrierten Screen Reader von iOS, fiel leider katastrophal aus. So gut zugänglich die iOS-App ist, so schlecht ist die mobile Website.
Nein, dies ist kein Argument für Apps und gegen RWD. Es belegt nur, dass das iOS SDK Barrierefreiheit quasi eingebaut hat, die Entwicklungsumgebung für Webseiten dagegen nicht. Oder: Die Entwickler der App haben sich um Barrierefreiheit bemüht, die Entwickler der mobilen Website ganz offensichtlich nicht.

Für Interessierte Leser hier zwei Audios mit VoiceOver:

Zuerst die App:

Und nun die mobile Website, fortlaufend vorgelesen.

(Man beachte, wieviel sinnloser Schrott von VoiceOver vorgelesen wird.)

Was da von VoiceOver gelesen wird, hat nichts, aber auch gar nichts mit dem zu tun, was auf der (mobilen) Webseite zu sehen ist.
Wie kann es zu dieser Diskrepanz kommen?

  1. Die mobile Site wurde aus der existierenden Desktop-Site abgeleitet.
  2. Barrierefreiheit war ganz sicher nicht im Visier der Entwickler.

Schade!


Der Cookie Warnung Irrsinn - und kein Ende

Montag, 1. Februar 2016

Wie angekündigt wollte ich beobachten, wie viele Besucher das Opt-out wählen, und ihren Besuch nicht tracken lassen.
Nach einer Woche stellt sich das Ergebnis mehr oder weniger wie erwartet dar:

Screenshot Google Analytics
Das Liniendiagramm zeigt die Anzahl aufgerufener, oder besser: getrackter Seiten pro Tag im Vergleich zweier Wochen, vor und nach dem Einfügen des Opt-out-Buttons

Ca. 25% der Besucher dürften das Opt-out gewählt, also "Cookie ablehnen" gedrückt haben. Dieser Wert geht nicht unmittelbar aus obiger Grafik hervor. Die Besonderheit eines Opt-out bringt es mit sich, dass unabhängig von der Wahl des Besuchers jedenfalls die Einstiegsseite getrackt wurde. Nur ein Opt-in könnte dies verhindern.
Ich erspare mir die Erklärung, wie ich zum Wert 25% gekommen bin.

Zur Klarstellung: 25% Opt-out bedeutet keinesfalls 25% weniger Seitenbesuche. Sondern lediglich, dass etwa ein Viertel der Besucher den Button "Cookie ablehnen" gedrückt haben, und der Besuch weiterer Seiten nicht mehr von Google Analytics registriert wurde.

Nächster Schritt: Gegenprobe. Ich entferne den Hinweis, und damit die Möglichkeit des Opt-out, für eine Woche ab heute. (Die wiederkehrenden Besucher, die das Opt-out bereits gewählt hatten, d. h. das Opt-out-Cookie gesetzt haben, werden natürlich weiterhin nicht getrackt.)


Archiv:

Kategorien:

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