alps hypertexte

Ich stecke seit einigen Monaten in der Frontendentwicklung der imedo-Site und in letzter Zeit konzentrieren wir uns verstärkt auf Accessibility- und Usability-Features. Ein großer Meilenstein, nämlich das bisher starr an 1024 px-Breite ausgerichtete, aber em-basierte Hauptlayout elastisch zu machen, ist heute online gegangen.

... und es werde elastisch

Kollegen wissen, dass es eine Monsteraufgabe sein kann, ein fixes Layout im Falle einer größeren Web2.0-Community-Site elastisch zu machen. Das Hauptproblem liegt hierbei nicht bei der Wahl der geeigneten Layoutmethode (davon gibt's es Tausende im weiten Web), sondern eher bei den bisherigen Unterelementen der Seiten. Historisch bedingt gehen die meisten Sites erstmal nur W/OAIM online. Das heisst sie sind fix designt, meist auf 1024px Breite ausgerichtet und daran, wie sich das Layout auf einem 800xirgendwas Pixel-Gadget verhalten soll, hat niemand gedacht. Folglich haben sich die Frontender bei der Umsetzung auf bequeme Masseinheiten wie px verlassen.

Von pixel-fest auf prozentual-elastisch wird's also ziemlich haarig. Man kann sich die Sache aber im Vorfeld vereinfachen, wenn man absieht, dass das Ziel aller Usability und Accessibility ein Layout ist, das sich der Browserfenstergröße einigermaßen anpassen kann. 'Einigermaßen', da es sinnlos sein kann, riesige Auflösungen (zu große Zeilenlänge) oder kleinere als 800px Breite zu unterstützen. Aber die 800px Breite sollte es ohne horizontalen Scrollbalken schaffen. Auch Besonders heute noch. [Wer mir jetzt mit billigen großen Monitoren heut zu Tage kommt, dem komme ich mit mobilen Gadgets, wie dem Asus eeePC ;-)].

Um die Übergangswehen von fest auf elastisch gering zu halten: gleich in Prozenten arbeiten und nur die Container fest setzen.

Das heisst: Dein Designer möchte eine 300 Pixel breite Box haben? Rechne aus, wieviel Prozent das im aktuellen Umfeld macht und benutze Prozentangaben auch bei festen Maßen. Man kann immernoch einen Container drumherum machen, der dann - meinetwegen - fest in Pixeln ist. Besser noch: em-basiert (für ältere Browser wie IE6 oder Firefox2). Diese Technik wird z.B. in Drei-Spalter, faux absolute positioniert näher erläutert.

Aber auch wenn man das so macht, bleibt noch genügend Anpassungsarbeit übrig. Nur zum Vergleich der ungefähre Aufwand bei dieser Umsetzung:

1. Umsetzung des elastischen Layouts als XHTML/CSS-Prototyp (samt Browsertest): 2 Stunden (FAP rulez!)
2. Umsetzung des elastischen Layouts in die Rails-Produktionsumgebung: 2 x 2 = 4 Stunden
3. Anpassung der übrigen Unterlemente, damit sie sich bei 800px Breite vernünftig verhalten (für Browser ab IE6): 16 bis 32 Stunden

Tools, um die Lesbarkeit zu verbessern

Mit dem neuen elastischen Layout sind auch ein paar Tools online gegangen, die das Ziel haben, die Lesbarkeit zu fördern. Einen gewöhnlichen Font-Size-Switcher gab es bereits in der vorherigen Version. Ein Invers-Stylesheet hat Michael Beck noch mit Hendrik Volkmer dazugebastelt. Und zwar so, dass sich der Font-Sizer auch innerhalb des Invers-Sytles verwenden lässt. Einmal im readability tools fever, haben Thomas Kadauke und Hendrik dann noch weitere Goodies wie das vereinfachte Layout (ohne Sidebars, Footer und Navigation), dem Fokus-Tool (was alle anderen Bereiche, außer des hoverten ausblendet) und die Bildschirmlupe in die Accessibility-Bar eingebaut, die mit Klick auf Hilfestellung ganz rechts im Navigationsmenü zu erreichen ist.

Faziterei

Frontender schlagen häufig die Hände über den Kopf zusammen, wenn ein festes Layout elastisch gemacht werden soll. Aber die Bedenken können unbegründet sein, wenn man von Anfang an auf Techniken wie FAP oder prozentuale Breitenagaben in festen Containern setzt.