Frames und Co.

Dieser Teil der Seite widmet sich alljenen, die auf die Anwendung von Frames schwören. Folgende Texte bemühen sich, besonders über die Vorurteile in Bezug auf die Technik aufzuklären, gehen speziell auf allgemeine Argumente ein und zeigen Einschränkungen im täglichen Gebrauch auf. Dieser Text beansprucht einige Zeit (ca 15 Minuten), bildet jedoch eine fundierte Grundlage zu Thematik und Verständnis.

„Mit Frames lässt sich leicht arbeiten“

Die Aufteilung der Seite in Frames hat sich lange Zeit bewährt – schliesslich lassen sich so auch komplexe Seiten erstellen, ohne in jeder einzelnen Seite das Menu immer und immer wieder schreiben zu müssen. So erspart man sich natürlich auch jede Menge Arbeit, wenn das Menu mal abgeändert werden muss – so zB. wenn sich ein Link ändert, oder neue Teile hinzukommen. Viele werten es auch positiv, dass Teile einer Seite nicht jedes Mal neu geladen werden müssen, sobald man einen anderen Teil der Seite aufruft und er „feststeht“, dort bleibt, wo er ist – auch beim Scrollen. Somit wird zudem angenommen, die zu übertragenen Daten würden sich minimieren.

„Also warum dann wechseln?“

Trotz vieler angeblicher Vorteile von Frames, sollte man möglichst auf ihren Einsatz verzichten, da sie grosse Nachteile für die Benutzbarkeit (Usability) der Seite aufwerfen. Viele der vorher genannten Vorteile kratzen nur an der Oberfläche – sieht man sich die Technik dahinter genauer an, werden Sie feststellen, dass das Gegenteil der Fall ist.

Keine Bookmarks für einzelne Seiten, erschwerter Druck

Da Frames nur einen Verbund aus mehreren getrennten Seiten darstellen, zerstückeln Sie die Zusammenhänge des Ganzen. Die Sruktur der Seite mag für den normalen Benutzer klar erkennbar sein – jedoch wird eine Maschine diese nicht als eine komplette, zusammanhängende Seite erkennen und somit gesondert behandeln können, was dazu führt, dass Bookmarks, die nur für eine einzelne Seite im Verbund ausgelegt sind, sich grundsätzlich auf die Hauptseite, das Frameset stützen. Damit ist es nicht möglich, gezielt auf Inhalte zurückzugreifen – bei jedem Besuch muss der User wieder durch das Menu. Die Eindeutigkeit einer Seite ist nicht mehr gegeben. Auf dieses Verhalten wird ein weiteres Mal im Abschnitt „Kein intuitiver Reload“ eingegangen.

Zudem wird es dem User massiv erschwert, bestimmte Inhalte auf Papier zu bannen – das Drucken einer Seite ist mit Hindernissen verbunden, die daraus resultieren, dass nur der aktive Frame für das Drucken vorbereitet wird – was bei einem simplen Klick im Menu mit darauffolgendem Ausdruck dazu führt, dass nicht der Inhalt gedruckt wird, sondern das Menu – dies kann zu Irritation führen, da nicht ersichtlich ist, welcher Frame gerade als aktiv markiert und somit für den Druck vorbereitet wird.

Kein intuitiver Reload

Auch das Neuladen einer Seite gehört zum festen Bestandteil eines jeden Browsers. Doch hier machen die Frames dem User einen Strich durch die Rechnung – es wird nicht nur der einzelne Frame, dessen Inhalte man gerade betrachtet, neugeladen, sondern gleich das gesamte Frameset, alles Sichbare. So weit wäre es noch kein Problem – jedoch hat das Neuladen des Framesets den Nachteil, dass man die Startseite zu Gesicht bekommt – durchaus unerwünscht wenn man nur bestimmte Inhalte auf, zB. eine aktueller Version, prüfen wollte. Diese sind dann nicht mehr vorhanden, man muss sich wieder durch das Menu klicken.

Suchmaschinen

Suchmaschinen – ein wichtiger Faktor um an bestimmte Informationen zu kommen. Eine Suchmaschine ähnelt im Grunde einem Browser, der nur Text lesen kann. Google zB. ist nicht in der Lage, ein Frameset darzustellen - er indiziert nur einzelne Seiten. Was passiert nun, wenn er auf eine Seite stösst, die sich auf Frames aufbaut?

Er sieht sich diese Seite an, untersucht sie auf Links und folgt ihnen, indiziert wieder und folgt weiter Links. Sobald nun jemand über Google eine solche Seite findet und aufruft, steht er ohne Menu da – dieses befindet sich in einem anderen Frame, der nicht sichtbar ist – schliesslich wurde ja nicht das Frameset aufgerufen, sondern nur die einzelne Seite.

„Aber da kann man doch mit JavaScript Abhilfe schaffen“ wird sicherlich so mancher argumentieren. So weit kann man ihm damit auch Recht geben, bloss was passiert, wenn der User JS deaktiviert hat? Er steht wieder ohne Menu dar.

„Ich möchte keine Dateinamen in der Adressleiste“ (URL-Hiding)

Aber warum denn nicht?

Manche meinen, es würde „Nicht schön aussehen“, „Nicht seriös sein“ oder man „möchte nicht zeigen, wie die Dateinamen sind“. Um Mal den Gedanken hinter der Adresszeile zu nennen: Sie dient allein der Anzeige der Adresse der aktuellen Quelle. Nichts Anderem. Diese muss erstmal nicht schön aussehen, sondern funktional sein, einen eindeutigen Bezeichner haben – was Frames umgehen. Der Bereich, in dem sich der Autor austoben kann, beinhaltet weder die Adressleiste, noch die Statusleiste – Manipulationen an ihnen sind somit unnötig. Und was finden Sie seriöser oder vertrauenserweckender? Jemanden, der die Quellen, zu denen er linkt, offen angibt, oder hinter einer Maske versteckt? Man könnte sich die Frage stellen, warum es jemand nötig hat, seine Dateinamen zu verstecken. Man könnte gar Entführung zu unbekannten Seiten vermuten, von der man aber nichts mitbbekommen soll. Was hat derjenige zu verbergen?

Ein statisches Menu

Ein statisches, feststehendes Menu ist keine Frage von „Frames oder nicht“, sondern eine Frage der Kenntnisse über die Technologien des Designs einer Seite. Grundlegenden Bestandteil bilden hier CSS, worauf in diesem Abschnitt nicht weiter eingegangen wird, was es uns ermöglicht, ein Menu auf der Seite „festzupinnen“.

Das Argument der Dateigrösse ist nur bedingt anwendbar – wenn man genauer den Aufbau des ganzen betrachtet, fällt auf, dass beim ersten Aufruf ja nicht nur eine Seite, sondern noch weitere geladen werden müssen – hier das Frameset an sich, der Menu-Frame und der Inhalts-Frame, oder als Formel n+1-Seiten, wobei „n“ die Anzahl der Frames stellt, plus ein Frameset. Dies ist durch weitere Frames oder sogar Schachtelung von Framesets noch steigerbar. Was wiegt jetzt wohl schwerer? Drei komplette Seiten, die damit verbundenen drei kompletten Markups mit Doctype, <html>, <body> und eventuellen <meta>-tags, oder die einzelne Seite mit einer kleinen, zusätzlichen Liste? Noch hinzu kommen die schon weiter oben genannenten Nachteile.

„Und was kann ich jetzt dagegen machen?“

Wie man all diese Nachteile beheben kann, sich jedoch nicht mit weniger Komfort und Wartungsaufwand zufriedengeben muss, wird ihnen im nächsten Teil des Tutorials nahegelegt. Hierbei gibt es verschiedene Methoden – am einfachsten realisieren lassen sich diese mit besserer Software und dem sogenannten „Dateiübergreifenden Suchen & Ersetzen“. Andere jedoch erfordern ein wenig mehr Lernaufwand (arbeiten mit include()s per PHP oder SSI) – jedoch ist dies alles im Endeffekt nicht schwieriger als das Erstellen eines Framesets, beinhaltet jedoch ein deutlich höheres Mass an Benutzbarkeit und Flexibilität – Dies kommt sowohl Ihnen, als auch Ihren Benutzern zugute.

Tuen Sie etwas für ihre Besucher, schaffen sie leicht benutzbare Seiten ohne Frames – Man wird es Ihnen danken.