nicht angemeldet
Hallo,
danke erst einmal. Ja ich wollte ein Fenster öffnen und nur kurze Infos eines Glossars über Namen, Gebiete usw, dem Anwender mitteilen.
Aufgrund deiner Mail werde ich das nochmal überdenken.
Íst eine 3 Frame Seite Benutzerunfreundlich? Was für sinnvoll Alternativen gibt es?
Wenn ein Frame nur zur Anzeige eines Logos o.ä. benutzt wird, beschränkt sich das Navigationkonzept auf die Hauptnavigation im entsprechenden Navigationsframe und auf den Inhaltsframe, welcher i.d.R. als Zielframe für die Links des Navigationsframedokuments ist. Dass eine Hauptnavigation keinesfalls eine Art Sitemap, also eine Komplettübersicht über alle Unterrubriken, darstellen kann, habe ich in diesem Posting http://forum.de.selfhtml.org/archiv/2002/10/27370/#m149759 erläutert. Darin legte ich dar, wieso eine volle Navigation oder ein breadcrumb trail auf jeder Unterseite nötig ist, und zwar in jedem Fall und nicht nur in einem noframes-Element. Eine Hauptnavigation kann nun einmal nicht die Struktur der Seite offenbaren, bei einer framelosen Version hat man die Möglichkeit einer Hauptnavigation sowie mehreren Nebennavigationen, welche eine Verbindung mit allen "Eltern" in der Hierarchie und ggf. dem Wechseln zu "Geschwistern" der jeweiligen Ebene ermöglichen (oder Sprünge zum Impressum, Kontakt usw.).
Wenn folglich eine Site *mehr* Dokumente beinhaltet, als über die Hauptnavigation erreichbar sind (das ist meist der Fall), schlägt das Frame-Navigationskonzept fehl, da der Benutzer die Orientierung verliert; aus diesem Grund existieren auch die Probleme mit dem Bookmarking von sich in Frameset befindenden Dokumenten, was man zwar durch eigene Framesets für jede Unterseite kompensieren könnte, dies wäre aber der absolute Overkill. Da gibt es natürlich diese schrecklichen JavaScript-Lösungen, mit denen man zwei Frames ändern kann und somit eine Primär- und Sekundärnavigation auch mit Frames realisieren kann, aber diese funktionieren nur mit JavaScript und erzeugen ein heilloses Framechaos, welches man 1:1 auf eine framelose Version übertragen könnte, die Übersicht wäre um ein vielfaches besser, siehe z.B. Amazon.de. Des weiteren könnte man alternativ für jede Unterrubrik eine eigene Seite für das Navigationsframe mit Links zu den Unterseiten entwerfen, sodass man sich erst im Navigationsframe voranklickt bzw. absteigt in der Seitenhierarchie und erst dann die Unterseiten im Inhaltsframe auftauchen. So etwas gefällt mir aber nur mäßig, da je nach dem Grad der Verschachtelung eine Art breadcrumb trail *sogar* *im* *Navigationsframe* nötig wird, siehe auch http://forum.de.selfhtml.org/archiv/2002/9/23902/#m132365 beginnend mit "1. Die Navigation desorientiert den Besucher...", es ging da um http://www.gil-marl.de/. (Übrigens sehr toll, dass man dort meine Vorschläge nicht beherzigt hat... :-/) Eine solche von mir dort dargestellte Navigation ist im Grunde genommen perfekt (weil hierarchisch!), aber das Schlechteste was man machen kann, ist dies mit einem *Framelayout* zu realisieren.
Achja, bevor du fragst, ein breadcrumb trail ist eine Aneinanderreihung von Links, welche die Spur bzw. den Pfad bzw. die Abzweigungen in der Seitenhierarchie bzw. dem Dokumentbaum von der Startseite einer Site (sic) aus zum aktuellen Dokument kennzeichnen, das sieht meist so aus:
Sie befinden sich hier: <a>[Sitename]</a> -> <a>[Rubrik X]</a> -> <a>[Unterrubrik Y]</a> -> <strong>[Dokument Z]</strong>
Alle Selfhtml-Inhaltsseiten haben ausschließlich eine solche Hauptnavigation.
Zurück zu unseren geliebten Frames: Die Problematik, dass auch immer eine zugängliche gleichwertige Alternativversion ohne Frames zur Verfügung, dürfte dir bekannt sein, denn Barrierefreiheit und die völlige Interoperabilität sind von Nöten. Eine Frames benutzende Seite sollte immer auch im noframes-Element die relevanten Links zu den Unterseiten haben, für gewöhnlich kann jedoch nur zu den Unterseiten gelinkt werden, welche natürlich keine eigene Navigation beinhalten, denn die wurde von den Inhaltsseiten getrennt und befindet sich in völlig anderen Dokumenten. Ohne das/die zugehörige(n) Navigationframe(s) ist ein solches Dokument unvollständig, was auch das Problem auslöst, dass das Frameset nachgeladen werden muss, wenn der Benutzer die Seite über Suchmaschinen oder direkte Links aufruft - dieses Nachladen geht wiederum nur mit JavaScript, wodurch manche Besucher die Navigation nie zu Gesicht bekämen. Eine naheliegende Möglichkeit ist, ein Frameset dadurch barrierefrei zu machen, dass auf jeder Unterseite eine zusätzliche für den Framesbenutzer unsichtbare Navigation in einem noframes-Element angeboten wird, aber oben habe ich bereits belegt, wieso eine Navigation (welche die Hierarchie wiederspiegelt) für *jeden* Besucher sichtbar sein muss.
Das waren alles nur die Nachteile von Frames bezüglich der Navigation - bei näherer Betrachtung lassen sich die vermeintlichen Navigationsvorteile von Frames m.M.n. um Längen besser mit einer framelosen Seite realisieren.
Hm, ich finde leider gerade keinen passenden Thread zu Frames im Archiv, es wäre unsinnig dass ich die hundertmal genannten Nachteile von Frames wieder aufrolle, ich habe die ersten 2200 Suchresultate durchgeschaut... ;) Eine gute Einführung in die weiteren Probleme stellt aber Michael Nahraths Artikel http://www.subotnik.net/html/frames.html dar.
Desweiteren bringe ich mir das alles selbst bei und habe mich bis zu Entdeckung des Forums auf ein Buch verlassen und da gibt es das.
<script language="JavaScript"> "HTML 4.0 Handbuch"
Hm, ja, glaube mir, es ist sinnfrei, das languge-Attribut anzugeben. Wenn du einigermaßen standardkonformes HTML schreibst ist hingegen das type-Attribut Pflicht, denn AFAIK wird ein script-Element ohne jegliche Angabe des Mime-Types von einigen Browsern nicht als ECMAScript/JavaScript angenommen (ist mir AFAIR schon einmal untergekommen), denn es könnte theoretisch in jeder möglichen clientseitigen Scriptsprache verfasst sein, bspw. VBScript, wobei ich gar nicht weiß, wie man VBScript richtig einbinden, es muss schließlich auch ein Mime-Typ haben...
Mathias