Adventskalender mit Codepen
ab dem 1. Dezember!

Optimieren – Ausgabe 2012

Als ich kurz vor der Jahrtausendwende beruflich im Internet anfing war „optimiert für …“ eine ganz normale Randnotiz. Die Zeiten änderten sich und wir begriffen, dass wir nichts optimieren sollten. Stattdessen bügelten wir die Fehler vor allem des IE aus. Das war keine Optimierung, eher Reparatur.

Dank der vielen mobilen Endgeräte und vor allem der ganzen i-Geräte befinden wir uns wieder in einer Optimierungsphase. Die Kunden und Kundenberater haben entweder nichts gelernt oder sind vergesslich. Jetzt müssen wir für das iPad optimieren, natürlich in zwei Varianten: einmal in Bezug auf Größe und Bedienbarkeit und einmal für das Retina-Display.

Dabei wird vergessen, dass die i-Geräte nur eine laute Minderheit sind. Deren Marketing ist laut und liegt in einer Hand. Bei Android, dem eigentlichen Marktführer, liegt es in vielen Händen und ist wesentlich dezenter.

Doch der Kunde sieht nur sein eigenes iPad (oder das seiner Tochter/Frau/seines Sohnes …) und in der Designagentur will man sich ohne Apple eh nicht erwischen lassen. Also fixieren wir uns wieder auf ein Produkt, statt uns eines generellen Problems anzunehmen. Das wird auch noch verschlimmert durch die ganzen media-querie-Sammlungen, die Dimensionen immer mit bestimmten Geräten gleichsetzen. Es ist die falsche Denkweise. Wir sollten nicht „optimiert für IE 5 mit einer Bildschirmauflösung von 1024×768 Pixeln“ durch @media screen and (max-width: 1024) { /* für das iPad */} ersetzen. Wenn wir einen Media-Querie einsetzen, sollte dies layouttechnische Gründe haben. Sie mit einem Gerät zu begründen führt zu mehr Problemen, als es löst.

Es sollte nicht so schlimm sein, wenn wir das iPad-Mini nicht erkennen können. Wir sollten nicht für Geräte arbeiten. Das Gerät sollte sich unser Design so anpassen, wie es dies benötigt. Serverseitige Detections scheinen mir sowieso nicht immer besonders hilfreich zu sein. Denn mit meinem Nexus 7 werde ich häufig auf mobile Webseiten geschickt, manchmal ohne die Chance auf eine Vollversion. Dabei ist die Auflösung meines Nexus höher als die meines iPad 2 oder die des iPad mini.

Die Fixierung auf Endgeräte und der Gedanke der „Optimierung“ für einzelne dieser Geräte ist zum Scheitern verurteilt. Luke Wroblewski hat die unterschiedlichen Endgeräte aufgelistet, die von Anfang September bis Ende Oktober diesen Jahres verkauft wurden. Eine imposante Zahl, die die Diversität des Marktes vor Augen führt. Eine Optimierung in eine Richtung würde immer eine Benachteiligung an anderer Stelle nach sich ziehen. Und wie wollen wir diese rechtfertigen?

Es gibt nur eine vernünftige Lösung: Lasst los! Akzeptiert endlich, dass das Internet ein flexibles Medium ist! Man kann die Darstellung seiner Inhalte nur marginal kontrollieren. Eigentlich kann man sie überhaupt nicht kontrollieren, denn der Geübte findet schnell Wege, um sein eigenes Layout zu erstellen. Und der Ungeübte verzweifelt, wenn er mit einem Endgerät daherkommt, für das dummerweise nicht „optimiert“ wurde, das deshalb aber Nachteile zu erleiden hat. Wer die vollständige Kontrolle über sein Design haben will, sollte sich vom Webdesign verabschieden und zum Printdesign überwechseln.

11 Responses to “Optimieren – Ausgabe 2012”

  1. […] bekomme sehr oft (meistens Blogs!) eine Webseite ohne Sidebar mir riesiger Schrift vorgesetzt. => Optimieren – Ausgabe 2012 « F-LOG-GE. Dieser Eintrag wurde veröffentlicht in Link und verschlagwortet mit Webdesign von Horst […]

  2. Matt sagt:

    Gut auf den Punkt gebracht. Breakpoints sollte man setzen, weil was bricht, nicht, weil ein Device zufällig diese Auflösung hat. Daher finde ich auch den Ansatz ganz smart, Breakpoints auf em- statt auf px-Basis zu setzen.

    Serverseitige Erkennung sollte man nur einsetzen, wenn man mit möglichst wenig Aufwand möglichst schnell möglichst viel Mist bauen will.

  3. Gut geschrieben, und ich kann dir da nur zustimmen. Nur leider ist es momentan noch sehr schwer, das auch Kunden begreiflich zu machen, wenn es halt auf dem Galaxy Tab ein wenig anders aussieht als auf dem iPad.
    Aber irgendwann wird sich auch diese Erkenntnis durchsetzen, genau so wie viele jetzt schon begriffen haben, dass man den IE6 nicht mehr unterstützen muss 🙂

  4. Chris sagt:

    Schöner Beitrag, ich finde es aber wesentlich trauriger, dass viele nicht so Ahnung haben. Die meisten Webentwickler haben entweder nicht die Möglichkeit oder die finanziellen Mittel um sich zig Geräte zu leisten. Und das ein iPad4 und ein iPad2 sowie ein iPadMini und Nexus7, oder ein iPhoneX und iPhoneY so große Unterschiede hat und zum testen benötigt wird, verstehen viele erst garnicht.

    „Aber wir haben doch schon ein iPad und einen iPod, reicht das nicht?“

    Es ist tatsächlich nahezu unmöglich für soviele Geräte anspruchsvolle Designs umzusetzen. Das mag vielleicht bei Blog und Newsseiten funktionieren, die vielleicht 5 verschiedene Seitenlayouttemplates haben, aber wie schaut es mit Produktseiten oder Shops aus? Da ist der Aufwand unerträglich hoch.

  5. Matt sagt:

    Das Shop-Thema hab ich noch vor mir. Und so viele unterschiedliche Templates gibt’s da auch nicht.

    Hatte ja auf Twitter schon mal angeregt, ein Open Device Lab in Mainz einzurichten (siehe http://mobile.smashingmagazine.com/2012/09/24/establishing-an-open-device-lab/). Ist aber keiner drauf angesprungen. Muss ich es halt selber machen, sobald wir in neue Räumlichkeiten gezogen sind.

  6. Peter sagt:

    Dem kann man nur zustimmem!

    Ich meine sogar, dass bei Smartphones die Bedienbarkeit und Lesbarkeit viel wichtiger ist, als ein angepasstes Design, welches sich an der „großen Version“ orientiert. Ausreichend große Schrift und Bedienelemente, die auch ein „Handwerker-Finger“ findet.

    Bei Tablets sieht es in der Tat etwas anders aus – aber da übe ich noch 😉

  7. Das hast Du sehr gut beschrieben.

    Die Optimierung ist irgendwie Segen und Fluch zugleich:

    Segen, weil einem die Arbeit nie ausgeht und Fluch, weil einem die Arbeit nie ausgeht…

  8. kjell sagt:

    die schlagrichtung des artikels finde ich gut, jedoch fehlt (wie von anderen schon hingewiesen) die conclusio/empfehlung. fluid design mit breakpoints sind mMn der richtige weg. dadurch kann es aber trotzdem passieten, dass auf einem nexus7 die mobilversion angezeigt wird…

    p.s. schade jalt dass dein blog noch nicht richtig für mobile optimiert ist. und: der meiste traffick kommt immer noch von iGeräten – auch von luke!

    • Jens Grochtdreis sagt:

      @kjell: Gut, meine Empfehlung ist mehr implizit zu erfassen. Wenn man sich mit responsive Webdesign den Tag versaut ;-), dann sollte man sich m.E. nicht an vermeintlich fixe und sichere Breakpoints halten, sondern den Inhalt die Arbeit übernehmen lassen. Wenn der Inhalt mir einen Layoutwechsel diktiert/empfiehlt, dann mache ich ihn.

      Das kann dazu führen, dass ich das gleiche Design auf meinem Nexus 7 bekomme, wie ein Smartphone. Aber sicher nur hochkant. In der Breite hat das Ding eine höhere Auflösung als das iPad 2.

      Du wühlst in einer Wunde herum mit dem Hinweis, dass mein Blog noch nicht meinen Ansprüchen genügen kann, vor allem in Hinsicht auf Mobilfreundlichkeit. Vor lauter Kundenprojekten komme ich nicht dazu, mein Blog endlich auf Vordermann zu bringen. Ich hoffe auf die Nachweihnachtszeit.

  9. Ich kann diese Breakpoint-Orientierung an bestimmten Geräten auch nicht verstehen. Bei meinen Responsive-Designs richten sich die Breakpoints immer nach dem Layout und nie nach aktuellen Geräten. Soll alles überall so gut wie möglich aussehen. Dann muss man auch nie nacharbeiten.

  10. Genau, wenn RWD richtig verstanden und umgesetzt wurde, muss Device-Testing nur noch aus funktionellen, nicht aus optischen Gründen erfolgen.