[Meinung] Feststehender Header (position:fixed)

[Gunther]

Hallo werte Selfgemeinde!

Ich überlege mir gerade das Layout für mein neues Weblog. Dabei stehe ich aktuell vor der Frage, ob ich einen feststehenden Header verwenden soll? Dieser wäre eine relativ schmale Zeile mit dem Namen des Weblogs als H1 Überschrift links und einem Suchfeld rechts.

Nun findet man solche Konstrukte ja eigentlich relativ selten. Woran liegt das eurer Ansicht nach?
Eher daran, dass die IEs <= 6 position:fixed nicht unterstützen, oder doch eher daran, dass es für den User "ungewohnt" (und somit nicht "benutzerfreundlich") ist?

Es wäre sehr nett von euch, wenn ihr mir kurz eure Meinung/ Ansicht mitteilen würdet, damit ich möglichst alle Aspekte in meine Entscheidungsfindung mit einbeziehen kann - danke!

Gruß Gunther

[Cyx23]

Hallo,

Eher daran, dass die IEs <= 6 position:fixed nicht unterstützen, oder doch eher daran, dass es für den User "ungewohnt" (und somit nicht "benutzerfreundlich") ist?

m.E. weder noch.

Für die IEs kann position fixed per CSS nachgerüstet werden.
Und die Usability mag hier im Detail mit der von Frames verglichen werden,
ohne damit die meisten Nachteile von Frames hinnehmen zu müssen.

Es gibt aber vielleicht zwei verbreitete Layoutstrategien, so die Idee,
einmal alles in kleinem Rahmen festnageln. Da gibt es dann statt "fixed"
u.U. ein scrollbares Div. Oder gleich ganz wenig Inhalt auf jeder Seite und
womöglich noch Flash.
Anders die klassischen langen scrollbaren Seiten, da passt fixed, zumindest
an prominenter Stelle, auch nicht so schnell ins Konzept.
Ähnlich auch bei floatenden/liquiden Layouts.

Grüsse aus Düsseldorf

Cyx23

[Gunther]

Hallo,

vielen Dank für deine Antwort.

Eher daran, dass die IEs <= 6 position:fixed nicht unterstützen, oder doch eher daran, dass es für den User "ungewohnt" (und somit nicht "benutzerfreundlich") ist?

m.E. weder noch.

Für die IEs kann position fixed per CSS nachgerüstet werden.
Und die Usability mag hier im Detail mit der von Frames verglichen werden,
ohne damit die meisten Nachteile von Frames hinnehmen zu müssen.

Ja, OK. Wobei es mir jetzt weniger um den Nachbau für die IEs geht, sondern vielmehr halt um die Frage, ob ein feststehender Header aus Usability-Sicht irgendwelche Nachteile mit sich bringt?

Es gibt aber vielleicht zwei verbreitete Layoutstrategien, so die Idee,
einmal alles in kleinem Rahmen festnageln. Da gibt es dann statt "fixed"
u.U. ein scrollbares Div. Oder gleich ganz wenig Inhalt auf jeder Seite und
womöglich noch Flash.

Nein, weder noch. Ansonsten soll es ein "normales" (fluides) 2-spaltiges Layout werden, und Flash verwende ich gar nicht.

Anders die klassischen langen scrollbaren Seiten, da passt fixed, zumindest
an prominenter Stelle, auch nicht so schnell ins Konzept.
Ähnlich auch bei floatenden/liquiden Layouts.

Warum nicht?

Nochmal zur Veranschaulichung:
 |----------------------------------------------------------------|
 | Logo H1 Überschrift          (fixed?)              [Suchfeld]  |
 |----------------------------------------------------------------|
 |           |        Content            |  Sidecol  |            |
 |           |    (max. ca. 45em)        |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |           |                           |           |            |
 |----------------------------------------------------------------|
 |           |                    Footer             |            |
 ------------------------------------------------------------------

PROs:

• Rücksprung- / Link (Logo + Überschrift) zur Startseite immer erreichbar
• Suchfeld immer erreichbar

CONs:

• weniger Anzeigebereich in der Höhe

Gruß Gunther

[Orlando]

Wobei es mir jetzt weniger um den Nachbau für die IEs geht, sondern vielmehr halt um die Frage, ob ein feststehender Header aus Usability-Sicht irgendwelche Nachteile mit sich bringt?

Probleme mit Ankern und position:fixed

Mit den dort genannten Workarounds kann man festgenagelte Bereiche heutzutage durchaus ohne gravierende Probleme umsetzen. Intuitiver finde ich allerdings einen fixierte Bereich auf der Seite.

Roland

[Gunther]

Hi Roland.

Wobei es mir jetzt weniger um den Nachbau für die IEs geht, sondern vielmehr halt um die Frage, ob ein feststehender Header aus Usability-Sicht irgendwelche Nachteile mit sich bringt?

Probleme mit Ankern und position:fixed

Mit den dort genannten Workarounds kann man festgenagelte Bereiche heutzutage durchaus ohne gravierende Probleme umsetzen.

Ja, das ist in der Tat ein gravierender Punkt, den man unbedingt berücksichtigen sollte.

Allerdings finde ich, dass molily die einfachste & naheliegendste Lösung nicht erwähnt. Denn man kann zur Vermeidung der ganzen Problematik ja den Rest der Seite in ein absolut positioniertes, scrollendes DIV packen, welches erst unterhalb des fixen Kopfbereiches beginnt (siehe auch Cyxs Posting).

Intuitiver finde ich allerdings einen fixierte Bereich auf der Seite.

Meintest du:"Intuitiver finde ich allerdings einen nicht fixierten Bereich auf der Seite."?

Gruß Gunther

[Orlando]

Allerdings finde ich, dass molily die einfachste & naheliegendste Lösung nicht erwähnt. Denn man kann zur Vermeidung der ganzen Problematik ja den Rest der Seite in ein absolut positioniertes, scrollendes DIV packen, welches erst unterhalb des fixen Kopfbereiches beginnt (siehe auch Cyxs Posting).

Mit Einfachheit hat das dann aber nicht mehr viel zu tun. Das ist ein ziemlich großer Aufwand für diesen Effekt, nicht? Wie reagiert die Meute der genutzten Browser auf diese Spielerei?

Intuitiver finde ich allerdings einen fixierte Bereich auf der Seite.
Meintest du:"Intuitiver finde ich allerdings einen nicht fixierten Bereich auf der Seite."?

Ich meinte einen fixierten Bereich auf der linken und/oder rechten Seite der Seite anstatt oben.

Roland

[Gunther]

Allerdings finde ich, dass molily die einfachste & naheliegendste Lösung nicht erwähnt. Denn man kann zur Vermeidung der ganzen Problematik ja den Rest der Seite in ein absolut positioniertes, scrollendes DIV packen, welches erst unterhalb des fixen Kopfbereiches beginnt (siehe auch Cyxs Posting).

Mit Einfachheit hat das dann aber nicht mehr viel zu tun. Das ist ein ziemlich großer Aufwand für diesen Effekt, nicht? Wie reagiert die Meute der genutzten Browser auf diese Spielerei?

Also z.B.:

  
<div id="header" style="position: fixed; height: 4em;">  
  <h1>Überschrift</h1>  
</div>  
  
<div id="page" style="position: absolute; top: 4em; bottom: 0; overflow: auto;">  
  <h2>...</h2><p>...</p>  
</div>  

Ich finde das nicht gerade sehr aufwendig. Und unter Berücksichtigung des Umstands, dass das eh nur für Browser relevant ist, die position:fixed unterstützen, gehe ich davon aus [1], dass es da keine Probleme gibt. Man muss lediglich die IEs <=6 ausschließen, was aber ja per CC auch sehr einfach ist.

Intuitiver finde ich allerdings einen fixierte Bereich auf der Seite.
Meintest du:"Intuitiver finde ich allerdings einen nicht fixierten Bereich auf der Seite."?

Ich meinte einen fixierten Bereich auf der linken und/oder rechten Seite der Seite anstatt oben.

Dabei läuft man aber wieder Gefahr, Inhalte unzugänglich zu machen, da die verfügbare Höhe dann meist relevant wird. Von daher möchte ich diese Variante gerne vermeiden.

Gruß Gunther

[1] Habe aktuell meine ganzen älteren Browser-Versionen nicht zur Verfügung zum Testen.

[Orlando]

<div id="page" style="position: absolute; top: 4em; bottom: 0; overflow: auto;">

SELFHTML sagt über http://de.selfhtml.org/css/eigenschaften/positionierung.htm#position@title=position:

| Der Internet Explorer 7 berechnet bei Angaben [nur] zu top und bottom die Höhe nicht.

Das wäre auf jeden Fall eingehend zu prüfen. Und wie sieht es da mit dem Scrollen ohne vorherigen Klick in diesen Bereich aus?

Ich meinte einen fixierten Bereich auf der linken und/oder rechten Seite der Seite anstatt oben.

Dabei läuft man aber wieder Gefahr, Inhalte unzugänglich zu machen, da die verfügbare Höhe dann meist relevant wird. Von daher möchte ich diese Variante gerne vermeiden.

Welche Ausmaße stehen dir auf mobilen Devices für einen fixierten Bereich zur Verfügung? Du musst ohnehin per Media Queries bzw. JavaScript den verfügbaren Platz prüfen, also ist es unerheblich, ob du in diesem Fall eine Mindestbreite oder -höhe eben *nicht* voraussetzt.

Roland

[Gunther]

<div id="page" style="position: absolute; top: 4em; bottom: 0; overflow: auto;">

SELFHTML sagt über http://de.selfhtml.org/css/eigenschaften/positionierung.htm#position@title=position:

| Der Internet Explorer 7 berechnet bei Angaben [nur] zu top und bottom die Höhe nicht.

Ja! ;-)
Hab' ich auch gelesen. Er_berechnet_die Höhe nicht. Da ich die aber nicht zwingend brauche, ist das kein Problem, denn anzeigen tut er es wie gewollt.

Das wäre auf jeden Fall eingehend zu prüfen. Und wie sieht es da mit dem Scrollen ohne vorherigen Klick in diesen Bereich aus?

Ist zumindest in den aktullen Geckos (FF + SeaMonkey), sowie im IE7 kein Problem.

Ich meinte einen fixierten Bereich auf der linken und/oder rechten Seite der Seite anstatt oben.

Dabei läuft man aber wieder Gefahr, Inhalte unzugänglich zu machen, da die verfügbare Höhe dann meist relevant wird. Von daher möchte ich diese Variante gerne vermeiden.

Welche Ausmaße stehen dir auf mobilen Devices für einen fixierten Bereich zur Verfügung? Du musst ohnehin per Media Queries bzw. JavaScript den verfügbaren Platz prüfen, also ist es unerheblich, ob du in diesem Fall eine Mindestbreite oder -höhe eben *nicht* voraussetzt.

Nee! Der Einsatz von fix positionierten Bereichen auf bspw. mobile Devices ist wohl eher grundsätzlich zu vermeiden - zumindest wenn man dabei an Handys denkt. Mir geht es also hier ausschließlich um das Screen-Layout. Und da dürfte man wohl einen Platz in der Höhe von ca. 4em als sicher verfügbar voraussetzen.

Layouts, deren Zuverlässigkeit zwingend von JS abhängig ist, empfinde ich als nicht "brauchbar".

Ich meine so gesehen ist eine fixierte Kopfzeile auf einer Webseite ja nichts anderes, als quasi eine zusätzliche Symbolleiste im Browser. Von denen dürften ja etliche User auch welche installiert haben (Google-Bar, Webdeveloper, Lesezeichen, Navigation, etc.). Von daher erachte das grundsätzlich mal als "vertretbar" (wenn auch "ungewohnt" aufgrund fehlender Verbreitung) unter Usability-Gesichtspunkten.

Gruß Gunther

[ChrisB]

Hi,

Also z.B.:

<div id="header" style="position: fixed; height: 4em;">
  <h1>Überschrift</h1>
</div>

<div id="page" style="position: absolute; top: 4em; bottom: 0; overflow: auto;">
  <h2>...</h2><p>...</p>
</div>

  
Das ist aber kein "position:fixed-Layout" im eigentlichen Sinne mehr - zumindest nicht mehr so, wie ich es interpretiere. Das hat schon mehr was von dem IE < 7-Workaround [1], nur dass der jetzt allen Browsern vor den Latz geknallt werden soll.  
  
Mit dieser Loesung hast du jetzt wieder einen Scrollbalken, der \*nicht\* ueber die komplette Seitenhoehe geht, sondern bei 4em von oben erst beginnt. Und der obere Bereich wird wieder ueber die komplette Fensterbreite gehen.  
Wieder exakt so haesslich, wie mit echten Frames :-/  
  
  
[1] Wenn sich sonst nichts anderes mehr in dem Dokument befindet, dann kannst du die fixe Positionierung fuer den header-Div naemlich auch gleich komplett weglassen, der Effekt waere nach wie vor der gleiche.  
  
MfG ChrisB

[Gunther]

Hi,

Also z.B.:

<div id="header" style="position: fixed; height: 4em;">
  <h1>Überschrift</h1>
</div>

<div id="page" style="position: absolute; top: 4em; bottom: 0; overflow: auto;">
  <h2>...</h2><p>...</p>
</div>

>   
> Das ist aber kein "position:fixed-Layout" im eigentlichen Sinne mehr - zumindest nicht mehr so, wie ich es interpretiere. Das hat schon mehr was von dem IE < 7-Workaround [1], nur dass der jetzt allen Browsern vor den Latz geknallt werden soll.  
>   
> Mit dieser Loesung hast du jetzt wieder einen Scrollbalken, der \*nicht\* ueber die komplette Seitenhoehe geht, sondern bei 4em von oben erst beginnt. Und der obere Bereich wird wieder ueber die komplette Fensterbreite gehen.  

Das ist beabsichtigt.  
  

> Wieder exakt so haesslich, wie mit echten Frames :-/  

Aha, du bist also der Meinung, dass der Scrollbalken wenn immer über die gesamte Fensterhöhe gehen sollte.  
  
  

> [1] Wenn sich sonst nichts anderes mehr in dem Dokument befindet, dann kannst du die fixe Positionierung fuer den header-Div naemlich auch gleich komplett weglassen, der Effekt waere nach wie vor der gleiche.  

Schon klar! Obiger Code-Schnippsel ist rein exemplarisch. Wie ja bereits erwähnt, geht es um das Layout für ein Weblog. Da gibt es dann schon etwas mehr Inhalt.  
  
Gruß Gunther

[ChrisB]

Hi,

Wieder exakt so haesslich, wie mit echten Frames :-/
Aha, du bist also der Meinung, dass der Scrollbalken wenn immer über die gesamte Fensterhöhe gehen sollte.

Sofern nichts dagegen spricht, bin ich da durchaus dafuer, ja.

Der durchgaengige Scrollbalken am Seitenrand ist das komfortabelste und zudem unaufdringlichste Navigationselement, wo gibt.

Ihn irgendwie "aufzuteilen" oder zu kuerzen, so dass er nicht mehr ueber die komplette Hoehe geht, halte ich fuer a) haesslich und b) schlechter benutzbar.

[1] Wenn sich sonst nichts anderes mehr in dem Dokument befindet, dann kannst du die fixe Positionierung fuer den header-Div naemlich auch gleich komplett weglassen, der Effekt waere nach wie vor der gleiche.
Schon klar! Obiger Code-Schnippsel ist rein exemplarisch. Wie ja bereits erwähnt, geht es um das Layout für ein Weblog. Da gibt es dann schon etwas mehr Inhalt.

Ja, mehr Inhalt schon - aber ich meinte, wenn es nur die zwei Gruppen "(oben) feststehendes Element" und "restlicher Inhalt in einem scrollbaren Container" gibt - wozu dann den Scrollbalken auf einen Teil der Fensterhoehe "kastrieren"?

MfG ChrisB

[Gunther]

Hi,

Wieder exakt so haesslich, wie mit echten Frames :-/
Aha, du bist also der Meinung, dass der Scrollbalken wenn immer über die gesamte Fensterhöhe gehen sollte.

Sofern nichts dagegen spricht, bin ich da durchaus dafuer, ja.

Der durchgaengige Scrollbalken am Seitenrand ist das komfortabelste und zudem unaufdringlichste Navigationselement, wo gibt.

OK. Allerdings frage ich mich, ob das wirklich so ein_entscheidendes_Kriterium ist? Denn
1. reden wir hier ja von einem relativ schmalen Streifen (ca. 4em) als Header, der bei den meisten Usern wohl im einstelligen Prozentbereich der Viewport-Höhe liegen dürfte, und
2. gibt es ja durchaus noch etliche andere (komfortablere) Methoden, eine Seite vertikal zu scrollen (Scroll-Rad, Leertaste, Bild auf/ ab Tasten, Mouse-Gestures).
Ich persönlich benutze bspw. nie die Scroll-Leiste.

Ihn irgendwie "aufzuteilen" oder zu kuerzen, so dass er nicht mehr ueber die komplette Hoehe geht, halte ich fuer a) haesslich und b) schlechter benutzbar.

[1] Wenn sich sonst nichts anderes mehr in dem Dokument befindet, dann kannst du die fixe Positionierung fuer den header-Div naemlich auch gleich komplett weglassen, der Effekt waere nach wie vor der gleiche.

Ja, stimmt. ;-)

Ja, mehr Inhalt schon - aber ich meinte, wenn es nur die zwei Gruppen "(oben) feststehendes Element" und "restlicher Inhalt in einem scrollbaren Container" gibt - wozu dann den Scrollbalken auf einen Teil der Fensterhoehe "kastrieren"?

Um das Problem mit den Sprungmarken/ Ankern zu vermeiden.
Soweit ich das bis jetzt überblicke gibt es nur die 2 Varianten:
1. Scrollbalken durchgehend = "Würg-around" für die Anker nötig
2. Seite unterhalb des Headers in scrollbarem DIV = Scroll-Leiste nicht durchgehend

Jetzt wird mir auch langsam klar, warum man das eben nicht so häufig auf "ordentlichen" Seiten findet (Seiten mit Frame-Layouts mal außen vor gelassen).

Das ist wieder so ein typischer Fall, wo man bei der praktischen Umsetzung in den Browsern einen bestimmten Anwendungsfall schlicht nicht berücksichtigt hat. Denn idealerweise würde der Browser den fix positionierten Bereich oben auf der Seite "erkennen" und die Sprungmarken entsprechend anpassen beim Anspringen. Aber das wird es wohl vermutlich nicht geben - schade eigentlich.

Tja, jedenfalls danke ich euch Dreien für eure Meinungen und Tipps - bleibt mir immer noch die Qual der Wahl ...!

Gruß Gunther

[Cyx23]

Hallo Roland,

Probleme mit Ankern und position:fixed

Mit den dort genannten Workarounds kann man festgenagelte Bereiche heutzutage durchaus ohne gravierende Probleme umsetzen.

Hier bei position fixed für Internet Explorer 6 ist die Lösung mit padding-top
zu sehen.

Safari 3 scheint -wie der aktuelle Opera- damit auch klarzukommen, dafür ist
aber womöglich die Sprachumschaltung (JavaScript) auf der betr. Seite etwas
"reformbedürftig".

Grüsse aus Düsseldorf

Cyx23

[ChrisB]

Hi,

Ich überlege mir gerade das Layout für mein neues Weblog. Dabei stehe ich aktuell vor der Frage, ob ich einen feststehenden Header verwenden soll?

Warum nicht?
Es muesste ja auch nicht unbedingt ein rechteckiger "Balken" sein - z.B. ein Logo/Schriftzug mit transparenten Bereichen, unter dem der restliche Inhalt dann einfach drunter wegscrollt, kann ziemlich gut aussehen ...

Dieser wäre eine relativ schmale Zeile mit dem Namen des Weblogs als H1 Überschrift links und einem Suchfeld rechts.

Da sehe ich, abgesehen von der angesprochenen Anker-Problematik, kein Problem.

Bei groesseren Bereichen, die fix positioniert werden sollen, muss man natuerlich aufpassen - die lassen bei zu kleinem Viewport moeglicherweise keinen Platz mehr fuer den eigentlichen Inhalt, der dann komplett unerreichbar werden kann.
(*Gute* Mobile-Browser koennen natuerlich auch mit sowas umgehen, Opera im Small Screen Rendering-Modus bspw. entfernt dann selber die Fixierung.)

Wenn ich groessere Bereiche fixiert darstellen moechte, wuerde ich per Javascript die Viewportmasze abfragen, und davon abhaengig fixed an- oder abschalten (auf window.onresize sollte man dann auch reagieren).

Nun findet man solche Konstrukte ja eigentlich relativ selten. Woran liegt das eurer Ansicht nach?
Eher daran, dass die IEs <= 6 position:fixed nicht unterstützen,

Kann man, wie schon erwaehnt, mit etwas Aufwand nachbasteln - oder man verzichtet fuer IE < 7 halt einfach darauf. (Wenn das Element am oberen Viewportrand fixiert ist, muss man dazu idR. nichts weiter tun, als diesen IE position:absolute statt fixed zu servieren.) Dann scrollt das Element halt einfach so mit, wie der restliche Inhalt auch.

oder doch eher daran, dass es für den User "ungewohnt" (und somit nicht "benutzerfreundlich") ist?

So unueblich ist es doch gar nicht - gibt doch genug Seiten, die sowas einsetzen.

Zudem ist der Nutzer sowas doch sowieso schon gewoehnt - von Frames-Layouts eben. Die Aufteilung Header-Frame/scrollbarer Content-Frame ist (/war) doch auch weit verbreitet.
Mit modernen Mitteln hab ich jetzt nur die Moeglichkeit, ihm das ganze etwas huebscher (Scrollbalken ueber gesamte Fensterhoehe, und nicht irgendwo "mittendrin" anfangend) und mit weniger Bedienschwierigkeiten zu praesentieren.

MfG ChrisB