caroco.de

Modale Layer – Fluch oder Segen

Veröffentlicht am: 15 September 2010

In seinem aktuellen Artikel “Issues with modal overlays on the web” spricht Janko über die möglichen Probleme, die modale Overlay-Fenster für User von Webseiten mit sich bringen können. Es stimmt schon, die Verwendung dieser Overlays auf abgedunkeltem Hintergrund (als standard JavaScript Lightbox), hat in letzter Zeit stark zugenommen. Eine kritische Betrachtung der Vor- und Nachteile der Overlays ist vor jeder Konzeption auf jeden Fall sinnvoll.

Doch zuvor eine kurze Begriffserklärung – was versteht man unter modalen Layern oder Overlays?

Ein Overlay oder Layer ist ein Inhaltsbereich, der physisch vor der eigentlichen Website liegt, also als Schicht darüber. Modal bedeutet, dass der User dazu gezwungen ist, mit dem modalen Overlay zu interagieren, bevor er auf den dahinterliegenden Inhalt zugreifen kann.

Aktuelle Beispiele für die Verwendung von modalen Overlays gibt es auch bei spyrestudios.

Vorteile von modalen Overlays:

• Sie fokussieren den Benutzer auf die Aufgabe, die er erledigen soll, ohne dass der User den Kontext der Seite dahinter verliert.
• Sie bieten dem Content im Overlay eine optisch beruhigte Fläche, unabhängig vom Visual Design der dahinterliegenden Seite (beispielsweise geeignet für Bildergalerien).

Nachteile von modalen Overlays:

• Sie verdecken den Hintergrund der Seite, so dass eventuell für die Erledigung der Aufgabe wichtige Informationen nicht mehr zugänglich sind.
• Sie sind normalerweise nicht durch den User verschiebbar, um dahinter liegende Informationen sichtbar zu machen.
• Sie sollten nicht für mehrschrittige Aufgaben verwendet werden, da der “Zurück”-Button des Browsers auf die Seite dahinter reagiert.
• Ein Drucken ist nicht über Strg+P möglich, sondern muss stets über einen separaten “Drucken”-Button oder Link angeboten werden.
• Sie führen zu einem Bruch in der Erwartungskonformität, wenn sie direkt aus der Navigation aufgerufen werden und anstelle einer echten Seite erscheinen.
• Wenn sie für Login-Aktionen verwendet werden, ist meist nicht genug Raum vorhanden, falls das Login fehlschlägt und Fehlermeldungen (eventuelle sogar verlinkt zu Hilfeseiten) erscheinen müssen.
• Sie sind, falls sie für den User interessante Detailinformationen enthalten, nicht einfach als Lesezeichen im Browser speicherbar (dies ist auch aus SEO-Sicht ein Hindernis).
• Sie sollten, da sie eine fixe Höhe besitzen, nicht höher als 500 Pixel sein, da ansonsten User mit geringerer Bildschirmauflösung (z.B. auf Netbooks oder mobile Browsern) nur den oberen Teil des modalen Overlays sehen und verwenden können.
• Sie sind sehr eingeschränkt in der Menge an Content, den sie darstellen können und sollten möglichst nicht scrollen, da es oft zu Konflikten mit dem Scrollen der dahinterliegenden Seite kommen kann.
• Sie sollten stets einen gut sichtbaren “Schließen”-Button im oberen Bereich haben, damit der Weg “hinaus” einfach gefunden werden kann.
• Sie werden vom Benutzer schnell für lästige Werbung gehalten, die man einfach schließen muss, um seinen Weg fortzusetzen, vor allem, wenn sie unerwartet erscheinen.

Mögliche Alternativen:

1## Kleine Overlays (nicht modal) auf der Webseite

Für kurze negative oder positive Bestätigungsmeldungen bieten sich kleine Overlays an, die möglichst nah an der sie auslösenden Position erscheinen sollten oder an einer gleichbleibenden, gut sichtbaren Stelle auf dem Screen erscheinen und nach kurzer Zeit von selbst wieder verschwinden. Auf TV.com erscheint beispielsweise nach Aktionen wie “Zu Favoriten hinzufügen” stets eine Meldung im Header der Seite. Diese Form ist geeignet, wenn keine Interaktion des Users mit dem Overlay nötig ist (z.B. sollten keine Links o.Ä. enthalten sein, die ggf. schwer zu erreichen sind, bevor sich das Overlay wieder schließt).

2## Tray Area oberhalb des Contents

Kurze, wenig Information umfassende Overlays können oberhalb des Website-Headers in einer Tray Area untergebracht werden (wie bei Algorithm Ink). Diese Bereiche schieben bei ihrem Erscheinen oft (aber nicht immer) die gesamte Website nach unten, besitzen oft einen gut sichtbaren “Schließen”-Button und können (je nach Dringlichkeit gesehen zu werden) von selbst wieder verschwinden oder müssen durch den User aktiv geschlossen werden. Diese Form sollte ebenfalls nicht verwendet werden, wenn viel, kritisch zu beachtender oder mehrschrittiger Inhalt gezeigt werden soll. Für diese Inhalte sind “normale” Seiten mit eventueller Fortschrittsanzeige die einfachste Lösung.

3## Seitliche Overlays (sticky und non-sticky)

Overlays, die mehr Informationen darstellen müssen, können seitlich angebracht, mit einem “Schließen”-Button versehen und eventuell minimier- und maximierbar eine ebenfalls interessante Alternative bieten. Falls der User bei der Interaktion mit dem Overlay auf Informationen der eigentlichen Content-Seite zugreifen muss, macht eine “Klebefunktion” (sticky) ggf. Sinn, bei der das Overlay beim Scrollen der Seite mitwandert (z.B. sinnvoll bei Drag&Drop-Aktionen wie auf DerekAllard.com). Auch bei dieser Variante sollte darauf geachtet werden, dass die Höhe des Overlays 500 Pixel nicht überschreitet (s.o.) und kein doppelter Scrollbalken erscheint.

4## Inline Expansions

Innerhalb des Contents auf einer Website können Zusatzinformationen je nach Bedarf eingeblendet werden (dabei wird der darunterliegende Content typischerweise nach unten geschoben). Dieses Methode, auch oft Accordion genannt, kann anstelle eines Overlay sinnvoll sein, wenn es sich beispielsweise um Informationen handelt, die hierarchisch feingranulärer als die bereits dargestellte Information sind (z.B. bestimmte Parameter einer Abfrage), dabei jedoch aus Gründen der optischen Aufgeräumtheit nicht ständig sichtbar sein sollen. Auf der Website der Deutschen Bahn kann man beispielsweise dieses Verhalten in der Ergebnisliste der Verbindungen finden.

Es gibt sicherlich noch andere Alternativen für modale Overlays. Je nach Projektbedarf sollte man meiner Meinung nach einfach abwägen, wie man welche Informationen für den User in optimaler Weiser darstellen will. Idealerweise validiert man seine Annahmen dann nochmals mittels eines User-Testings.