Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zum Archiv und den Kategorien

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ß.


Mobile Nutzung des Web

Sonntag, 9. Oktober 2016

Man kann es gar nicht oft genug wiederholen:
Das Web wird mit mobilen Geräten benutzt. Zunehmend. Und ein Ende dieser Tendenz ist nicht absehbar.
Zum Beleg hier die aktuelle Verteilung der Besucher einer Kundenseite:

Tortengrafik
Desktop (blau): 48,4%
Smartphones (grün): 33,3%
Tablets (rot): 18,4%

Und nein. Es handelt sich nicht um meine eigene Site, mit möglicherweise überdurchschnittlich vielen technikaffinen Besuchern. Sondern um die Site eines Beherbergungsbetriebs.
Und ja: Die Site ist natürlich für mobile Nutzung optimiert.


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.


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.


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.

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/


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!


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.


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}
 
}


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.


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.


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.


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!

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…


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.

Archiv:

Kategorien:

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