Nicht Menüleisten, sondern Contentboxen werden so gemacht. Per Mausklick werden über eine kleine Reiternavigation weitere Informationen aufgerufen. Die sind entweder bereits in der Seite versteckt oder werden dynamisch nachgeladen. Javascript, DHTML und AJAX, verschiedene Techniken kommen zum Einsatz. Sie sind mehr oder weniger browsersicher. Mitunter klappt es mit dem Backbutton nicht mehr. Das Angebot dürfte aber genügen, um etwas nach eigenem Geschmack zu finden. Schliesslich wird diese Art der Contentpräsentation immer beliebter. Alle Begleittexte sind in Englisch.
Control.Tabs
Basiert auf dem Prototype Javascript Framework.
Javascript Tabs vom Stilbüro
Basierend auf jQuery | Demo
Yahoo TabView
Ein Teil der UI Library | Demos
Ein TabPanel gehört auch zum Google Web Toolkit. Eine Online Demo gibt es dafür nicht. Von Adobe Spry existieren die Tabbed Panels.
AJAX Tabs Content Script
Klassiker von Dynamic Drive
Tab Panes
in zwei Versionen von DHTMLGoodies mit Close-Buttons. Demo I | Demo II
JavaScript Tabifier
Die Gebrauchsanweisung zieht selbst einen Nutzen aus der Technik
AJAX Tabs
Ajax Project – Tabbed Page Interface
DOMTab – Navigation tabs with CSS and DOMscripting
Präsentiert sich in zwei Varianten
Tabtastic
Ist bereits älter…
Tabmenu
Funktioniert als MouseOver ohne Klick
dhtmlxTabbar
Dieses aufwändige Konstrukt – soweit muss man es nicht treiben – stammt aus einem kostenpflichtigen Paket.
ActiveWidgets 2.0
Auch das hier ist Bestandteil eines Pakets, das nur gegen Bezahlung erworben wewrden kann.
Zapatec Tabs
Gleiches gilt hier. Es gibt mehrere Versionen und Bezahlmodelle.
Etwas vergessen? Wahrscheinlich. Doch 14 zum Download bereite Muster sollten genügen.
Wie hilfreich war dieser Beitrag?
Klicke auf die Sterne um zu bewerten!
Durchschnittliche Bewertung 0 / 5. Anzahl Bewertungen: 0
10 Antworten zu „14 Tab Interface Scripts“
— was ist Deine Meinung?
Eine sehr schöne Tab-Variante hat auch Stu Nichols ausschließlich mit CSS zusammen gebaut.
@Niels,
keiner behauptet, dass ein CMS zugänglich sein muss, schnelle Reaktionen ohne Reloads überwiegen hier auf jeden Fall alles. Nicht zu vergessen: wie soll man ein CMS überhaupt zugänglich machen? Wenn die Core-Funktion, der Editor nicht zugänglich sein kann, da Formatierungen nur mit visueller Hilfe machbar sind, kann man auch den Rest vergessen, wo es mit ein wenig Mühe noch möglich wäre.
Ich lasse mich da natürlich eines besseren belehren, da ich gerade jetzt noch in der Phase bin, wo ich mein neues CMS noch rumreissen kann, da Accessibility in einem CMS sicher eine Marktlücke und ein starkes Marketing-Argument wäre (der Output ist es so oder so schon).
Vieleicht könnte man da irgend was mit Word-Dokumenten machen, die man in den Editor reinkopieren kann, wobei ein sehr starker HTML-Filter wirken müsste, um das CMS damit nicht zu verseuchen.
mfG
Peter
@Christoph:
Schon, siehe z.B.
– Javascript Tabs vom Stilbüro
– JavaScript Tabifier
– Yahoo TabView
@Carsten:
Nix für ungut, aber die Schärfe Deines Beitrages find ich eigenartig.
Sich bei diesem Thema über´s mokieren mokieren ist ja selbst schon eine Standartreaktion und vielleicht nicht so professionell wie Du meinst – wenn Du Deine Webadresse angegeben hättest, hätten wir uns von Deiner Professionalität überzeugen können.
Ich find die Diskussion fruchtbar und nicht als Kritik: Thema Backend, Trennung von Wichtigem (Navigation) und „Spielerei“ usw. – alles hilft bei der Einwertung und nicht Abwertung der vorgestellten Lösungen.
Ich hab es schon mal an andere Stelle erwähnt:
Ich denke, dies ist eine Seite VON Profis FÜR Profis!
Das ständige Gejammere von wegen deaktiviertem JavaScript kann man sich mithin langsam sparen. Die Tatsache ist jedem bekannt, der auch nur halbwegs mit der Materie vertraut ist. Konstruktive Kritik gern, aber sowas ist nun wirklich langweilig. Wichtig machen kann man sich damit nicht!
Weiterhin hat niemand verlangt, das nun jeder überall alles benutzen soll, was hier vorgestellt wird. Aber kommt mal etwas weg von der Idee der immer und überall und für jeden zugänglichen Website hin zur Webapplikation, gern in einem abgeschlossenen Bereich / Intranet. Oder das schon erwähnte Backend, etwa in einem CMS. Dort ist es für viele Redakteure /Bearbeiter w.e. auf jeden Fall ein Segen, wenn er nicht bei jedem Klick alles reloaden muss und zügiger arbeiten kann. Zeit ist auch hier Geld. Und man sollte abwägen, ob die große Mehrheit der potentiellen Benutzer da wirklich auf Barrierefreiheit angewiesen ist. Ganz davon abgesehen schliesst sich das nicht unbedingt gegenseitig aus…
Tabs werden leider nur zu häufig als Ersatz für ein Navigationsmenu genommen. Aber als Spielerei würde ich Tabs jetzt nicht bezeichnen wollen. Im Gegenteil: immer wieder findet man heraus, daß gerade Tabs häufig Neugierde beim Betrachter hervorrufen – und die braucht man, will man ihn in die Tiefe der Seite locken. Ob dazu Tabs notwendig sind, ist eine andere Frage.
Ihr habt euch aber schonmal die Scripts angeschaut, oder?! Die meisten sind so gebaut, dass sie auch ohne JS ganz sauber funktionieren…
Ist doch auf einer mit serverseitigen Scripten erzeugten Seite je nach Task einfach, solche Funktionalitäten auch JS-unabhängig nachzubauen, per DOM wird einfach der dynamische Link gleicheseite.asp?view=2 entfernt, da braucht es nicht mal noscript.
Allerdings gibt es nur selten die Notwendigkeit, Tabs auf einer handelsüblichen Seite einzusetzen, sowas ist mehr fürs Backend geignet.
Auf Webseiten unterscheide ich da strikt zwischen Spielerei und Notwendigkeit. Ist es eine Spielerei wie eine Umfrage, bei der man auf 1-3% Fanatiker verzichten kann, wird sie ganz einfach für diese gar nicht erst auf visible gesetzt. Alle anderen Funktionalitäten müssen natürlich auf jeden Fall zugänglich sein.
mfg
Peter
Es ist nicht nur nicht barrierefrei, es ist nicht sehr „useable“.
Aber das interessiert scheinbar nur wenige. Das Netz ist voller wunderschöner Seiten guter Designer, die aber keine Webdesigner sind.
Da zerböseln die Seiten beim Schriftvergrößern oder funktionieren nicht, weil das JS deaktiviert ist, was einem einen Haufen Ärger beim Surfer erspart.
Hauptsache was für’s Auge.
Navigation mit Javascript – da kommt doch sofort der Einwand: Was ist mit den Besuchern mit deaktiviertem JS?
– Ist der Einwand relevant, gibt es Zahlen, wie viel User das eigentlich machen?
– Lösung wäre, die Navi im Noscript-Tag nochmal nachzubilden, ist aber aufwändig …
– Barrierefrei ist es auf jeden Fall nicht
Ein weiteres Beispiel hat auch das OpenSource Framework qooxdoo: TabView 1. Incl. Tastertursupport.