Entwickeln von Responsive Web Design - Vorschlag für eine Vorgehensweise
04.04.2015
Dieser Artikel wendet sich an Personen, die immerhin HTML- von CSS-Code unterscheiden können. Also fast an alle.
Hier sollen möglichst allgemeingültige Methoden gezeigt werden, aber nicht ein bestimmtes Layout oder ein bestimmter Gestaltungsvorschlag. Da andererseits theoretische Überlegungen nur an praktischen Besipielen aussagekräftig dargestellt werden können, muss doch ein konkretes Layout verwendet werden. Damit es sich nicht in den Vordergrund drängt, ist es bewusst schlicht gehalten.
Anders gesagt: Es geht hier nicht um das Aussehen der einzelnen Elemente der Testseite, sondern um die Art, wie sie sich zueinander verhalten.
Vorgegeben waren für eine Prüfung der IHK:
• ein Logo mit einem bestimmten Seitenverhältnis
• ein Menü mit fünf Hauptpunkten für die Navigation
• die Anweisung, dass eine Sprachauswahl für die Sprachen
Deutsch, Englisch, Französisch und Spanisch
von Anfang an sichtbar integriert werden sollte
• ferner Texte und Fotos
Drei Layouts für vorgegebene Bildschirmgrößen sollten entwickelt werden.
(Ein wenig realistischer Ansatz, aber davon später.)
Ein aktueller Leitsatz beim Entwickeln von Responsive Web Design lautet
'mobile first'!
Wir richten also zunächst das Aussehen der Webseite ein für das Display eines hochkant gehaltenen Smartphones (orientation: portrait).
Aber was bedeutet das? Selbst eine oberflächliche Recherche zeigt uns: Es gibt eine Vielzahl von Displaygrößen, egal ob in Millimeter, Zoll oder Pixel angegeben. Dieselbe Recherche verrät uns auch: Die jeweils verwendeten Bildpunkte liegen bei verschiedenen Geräten unterschiedlich dicht gepackt, und das heißt, sind unterschiedlich groß.
Deswegen verwenden führende Hersteller von Betriebssystemen für Smartphones unterschiedliche Umrechnungsfaktoren von (aus dem Ursprungsmaterial) vorgegebenen Bildpunkten zu den tatsächlichen Punkten des verwendeten Schirms.
Aus all dem ergibt sich die Folgerung:
Hier sind Angaben in px fehl am Platz!
Welche Maßeinheit nehmen wir dann?
Uns bleiben Prozentangaben (fürs Grobe) und für die Feinheiten die M-Einheit (em). Sie bezieht sich auf den Platzbedarf des Großbuchstabens M der im jeweiligen Browser verwendeten Schrift und Schriftgröße. Das befreit uns vom Zwang, tatsächliche Größen Dutzender von Displays und Browsern, die wir nicht kennen können, 'erraten' zu müssen.
Außerdem verwenden wir
<meta name="viewport" content="width=device-width, initial-scale=1.0">
Damit gewöhnen wir Smartphone-Browsern ab, 'vorsorglich' unsere Webseite auf ihr Lieblingsformat zu skalieren.
Was wollen wir erreichen?
Es muss zu schaffen sein, vier Links für die Sprachauswahl nebeneinander anzubieten.
Von der Sprachauswahl sind die restlichen Inhalte abhängig. Folglich gehört die Sprachauswahl auch ganz nach oben. Lediglich das Logo hätte da 'ein Wörtchen mitzureden'. Aber ein gutes Logo macht auf sich selbst aufmerksam, kann also den Platz an der Spitze großzügig abgeben.
Da es als hochkant stehendes Rechteck vorgegeben war, bietet sich an, die Einträge des Hauptmenüs senkrecht untereinander daneben zu stellen. Der Rest (einspaltig natürlich) mag darunter folgen.
So sieht das aus (screenshot eines Smartphonedisplay-Simulators):
Und so ist es gecodet
- in HTML5:
<div id="rahmen">
<nav>
<ul id="sprach">
<li><a href="#">deutsch</a></li>
<li><a href="#">english</a></li>
<li><a href="#">français</a></li>
<li><a href="#">español</a></li>
</ul>
<ul>
<li id="logo"><a href="index.html"><img src="logo_f_kl.gif"
alt="Logo der Firma"></a></li>
<li><a href="#">Touren</a></li>
<li><a href="#">Buchen</a></li>
<li id="lang"><a href="#">Wissenswertes</a></li>
<li><a href="#">Kontakt</a></li>
<li><a href="#">Impressum</a></li>
</ul>
</nav>
(Das Logo ist als Link zur Startseite ins Menü integriert.)
und in CSS3:
* { margin: 0; padding: 0; }
#rahmen { width: 97.5%; margin: .0625em auto; padding: .125em;
background: #565656; border-radius: .25em; }
nav { width: 100%; max-width: 34em; margin: 0 auto; }
nav ul { list-style: none; }
nav #sprach { height: 1.125em; width: 100%; max-width: 28em;
margin: 0 0 0 auto; padding-top: .25em;
background: #999; }
nav li { float: left; width: 7em; margin: .25em 0 0;
margin-right: 1em; }
nav #sprach li { width: 25%; margin: 0; margin-top: -.25em;
text-align: center; }
#logo { width: 6em; margin: 0; margin-right: 1em; }
#lang { width: 9em; }
nav a { text-decoration: none; font-weight: bold;
font-size: 1.125em; color: rgb(97%, 97%, 97%); }
nav #sprach a { font-size: .875em; }
#logo a { font-size: .001em; line-height: 1%; }
Diese Raumaufteilung funktioniert (im echten Gerät getestet, nicht im Simulator) ab einer Displaybreite von 320 dargestellten Punkten.
Haben wir mehr Platz, rücken die vier Sprachlinks einfach immer weiter auseinader. Am Haupt menü ändert sich zunächst nichts – und irgendwann sieht es 'verloren' aus, wenn es weiterhin an seinem Logo klebt.
In einer ersten 'Ausbaustufe' könnten wir die Einträge des Hauptmenüs anordnen, wie folgt:
(In der Titel-Leiste und -Lasche des Browsers erkennen wir die Außen- und Innenabmessungen des Browserfensters.)
Wenn wir die Eigenheit der deutschen Sprache, sehr unterschiedlich lange Wörter (Element #lang) zu enthalten, schon nicht ändern können, sollten wie sie uns zunutzemachen. In den anderen Sprachversionen empfiehlt sich daher vielleicht eine andere Anordnung.
In den CSS-Code ist nach der Zeile mit #lang { width: 9em; } einzufügen:
@media screen and (min-width: 24em) {
nav li { width: 8em; }
#lang { width: 14em; }
}
Irgendwann wirkt auch das seltsam und wir können übergehen zu der Form, wie sie unser erstes Display auch hätte zeigen können, hätten wir es waagrecht gehalten (orientation: landscape):
Nach der Zeile für nav a … sind nun folgende Zeilen einzufügen:
@media screen and (min-width: 32em) {
nav li { width: 11%; margin-right: 1.5%; }
#lang { width: 21%; }
#logo { margin-right: .5em; }
nav a { font-size: .9375em; }
}
Was manchen Lesern vielleicht beim ersten Einschub schon aufgefallen ist: Auch für die Abfrage an das darstellende Gerät (media query), wie breit (z.B.) sein Bildschirm sei, an den sogenannten break points, verwenden wir die em-Einheit und nicht etwa Pixel. Wer sagt uns denn, dass Displaygrößen, die sich nun einmal in Pixeln bemessen, der einzige begrenzende Faktor der Darstellungsbreite sei?
Was, wenn ein nicht mehr so gut Sehender mit den Möglichkeiten seines Browsers die Schrift generell vergrößert – und alles Andere wahrscheinlich auch?
Haben wir unsere Abfrage in em gestellt, wird unser Layout auch darauf reagieren.
Weniger oder anzeigbare M-Einheiten: 'schmaleres' Layout!
Hat unser Menüsystem seine optimale Breite erreicht, lassen wir es nicht weiter anwachsen. Wir sorgen nur dafür, dass es immer schön in der Mitte bleibt. Das stört niemand. Den weiten Raum darunter, der sich mit wachsender Monitorgröße immer mehr auftut, nützen wir, um von einspaltiger zu zweispaltiger zu dreispaltiger Darstellung überzugehen und gegebenenfalls auch die Spalten zu verbreitern, aber nur soweit die Zeilen darin lesbar bleiben.
Alles schön und gut. Aber was für Layouts entwerfen wir also? Wonach richten wir uns?
Wir entwerfen Raumaufteilungen – nicht nach einer festen Bildschirmbreite, sondern nach unseren Vorstellungen für ein zugehöriges Platzangebot: Einspaltig sehr schmal, einspaltig breiter (eventuell), einspaltig optimal, zweispaltig optimal, dreispaltig optimal.
Und wie finden wir die break points?
Nicht nach bestimmten uns bekannten Monitorgrößen jedenfalls.
Sondern wir nehmen die Umsetzung in Code einer optimalen Raumaufteilung und quetschen sie zusammen, indem wir das Browserfenster schmaler ziehen. Irgendwann 'bricht' unser geplantes Layout 'unter diesem Druck zusammen'.
Die Breite, die der Schirm dann hatte, halten wir fest. Den break point, der aus dem schmaleren Layout das breitere macht (Nicht vergessen: der endgültige Code beginnt mit dem Normalen, Schmalen!), setzen wir dann mit ausreichendem Sicherheitsabstand in den Raum hinein, von dem wir wissen, dass er für unsere großzügigere Raumaufteilung ausreicht. Und eben nach Möglichkeit gar nicht 'in die Nähe' bekannter Bildschirmgrößen (800, 1024, 1280 usw.). Selbst dann nicht, wenn wir Pixel verwenden wollten! Aber wir nehmen ja ohnehin em.
Und damit das am Ende des Artikels nicht etwa in Vergessenheit gerate:
Hier sollten Methoden gezeigt werden und nicht eine bestimmte Gestaltung. Es ging hier nicht um das Aussehen der Testseite, sondern um die Art, wie sich deren Elemente zueinander verhalten können und wie das im Code veranlasst wird.