Menü Empfehlung?

[Martin]

Hallo!

Ich bräuchte für meine neue Homepage ein Navigationsmenü, dass folgendes können sollte:

es gibt Ober- und Unterkategoriene, bei Anklick einer Oberkategorie sollen die Unterkategoriepunkte direkt unter der Oberkategorie ausfahren? also so ähnlich wie beim Windows-Explorer, allerdings sollte das Menü vom Design her nicht unbedingt an den Windows-Explorer erinnern (also ohne Ordner und "+"-Symbol)

kennt jemand von euch so ein (fertiges) Menü?
wäre für jede Hilfe dankbar

lg

Martin

[Christian Seiler]

Hallo Martin,

kennt jemand von euch so ein (fertiges) Menü?

Ja: http://aktuell.de.selfhtml.org/artikel/dhtml/sitemap/index.htm

Christian

[Martin]

Hallo Martin,

kennt jemand von euch so ein (fertiges) Menü?

Ja: http://aktuell.de.selfhtml.org/artikel/dhtml/sitemap/index.htm

Christian

Hallo Christian,

herzlichen Dank für den Link, aber mir stellt sich dir Frage, ob ein Einsatz von JavaScript als Menü überhaupt sinnvoll ist, da ja immer mehr User JS aus Angst vor Angriffen aus dem INet (zB Dialer) deaktivieren....wenn also jemand JavaScript deaktviert hat, sieht er dann überhaupt kein Menü, oder?

[Christian Seiler]

Hallo Martin,

herzlichen Dank für den Link, aber mir stellt sich dir Frage, ob ein Einsatz von JavaScript als Menü überhaupt sinnvoll ist, da ja immer mehr User JS aus Angst vor Angriffen aus dem INet (zB Dialer) deaktivieren....wenn also jemand JavaScript deaktviert hat, sieht er dann überhaupt kein Menü, oder?

Du kannst in einem <noscript>-Bereich eine komplette Liste aller Menüpunkte mit unterbringen - dann kommen Suchmaschinen und Benutzer ohne JS auch weiter. Schön, dass Du Dir darüber Gedanken machst.

Das Problem ist Deine Aufgabenstellung »Ausfahren«, für die hast Du drei Alternativen:

* JavaScript
 * Für jede mögliche Kombination und Seite eine HTML-Datei (das multipliziert sich gewaltig, da kommst Du sicherlich auf 20000 oder so...)
 * Serverseitige Intelligenz

Die letzten beiden Alternativen haben den Nachteil, dass jedes Mal ein Request zum Server geht, wenn der Benutzer nur das Menü aufklappt. Daher halte ich JavaScript mit noscript-Alternative hier für am sinnvollsten. (Du kannst ja auch die noscript-Alternative möglichst ähnlich dem komplett aufgeklapptem JS-Menü machen, dann verlieren die Benutzer ohne JS nichts)

Christian

[MudGuard]

Hi,

Das Problem ist Deine Aufgabenstellung »Ausfahren«, für die hast Du drei Alternativen:

vier!

* JavaScript
* Für jede mögliche Kombination und Seite eine HTML-Datei (das multipliziert sich gewaltig, da kommst Du sicherlich auf 20000 oder so...)
* Serverseitige Intelligenz

* CSS (z.B. ul, li, und dazu :hover). Ok, das klappt nur in modernen Browsern (also nicht im IE)...

cu,
Andreas

[Martin]

danke für eure antworten, ihr habt mir sehr weitergeholfen!

aber vor allem das empfohlene "Treemenu" schaut mir sehr danach aus, dass es Frames verlangt? Kommt für mich nicht in Frage, da ich Tabellen verwenden werde

aber jetzt mal ganz abgesehen von meinen Menüdesignwunsch, zu welchem Menü würdet ihr mir persönlich raten? Eher einfach Sachen, wie in der rechten Tabelle nur Oberkategorien und dann in der Haupttabelle die Untermenüpunkte?

[Lude]

Hallo, Christian,

benoetige ebenfalls eine brauchbare Loesung zur Navigation und bin bisher nicht wirklich fuendig geworden.

Das Problem ist Deine Aufgabenstellung »Ausfahren«, für die hast Du drei Alternativen:

* JavaScript

Ja, nicht die Idealloesung.

* Für jede mögliche Kombination und Seite eine HTML-Datei (das multipliziert sich gewaltig, da kommst Du sicherlich auf 20000 oder so...)

Auch schon probiert, allerdings steckt die Navigation dann redundant "ueberall". Aber die Anzahl der Menues scheint mir mit der Anzahl der "anzunavigierenden" HTML-Dokumente identisch.

* Serverseitige Intelligenz

Natuerlich die beste Loesung?

Die letzten beiden Alternativen haben den Nachteil, dass jedes Mal ein Request zum Server geht, wenn der Benutzer nur das Menü aufklappt.

Das Menue wird serverseitig "gepflegt", so dass m.E. eben nicht bei jedem Menue-Zugriff ein Request an den Server entsteht. Richtig? (
'MS Frontpage' arbeitet i.p. Menuefuehrung doch so (und gar nicht so schlecht).)

Daher halte ich JavaScript mit noscript-Alternative hier für am sinnvollsten.

Ich nicht. Habe ich Recht?

Gruss,
Lude

[Christian Seiler]

Hallo Lude,

Das Menue wird serverseitig "gepflegt", so dass m.E. eben nicht bei jedem Menue-Zugriff ein Request an den Server entsteht. Richtig?

Wenn das Menü serverseitig erzeugt wird, dann gibt es _immer_ einen Request an den Server, wenn ein "Menüzugriff" auftritt, ansonsten müßtest Du mit clientseitigen Methoden arbeiten. (z.B. JavaScript)

(
'MS Frontpage' arbeitet i.p. Menuefuehrung doch so (und gar nicht so schlecht).)

Ich weiß jetzt natürlich nicht, was Du unter MS Frontpage verstehst - ich verstehe einen WYSIWYG-PseudoHTML-Editor darunter und sehe nicht, was das jetzt mit den serverseitigen Menüs zu tun hat...?

Christian

[molily]

Hallo,

mir stellt sich dir Frage, ob ein Einsatz von JavaScript als Menü überhaupt sinnvoll ist

Ob JavaScript oder nicht, ist sowieso irrelevant, da du in jedem Fall eine noscript-Version anbieten musst, auf welche du früher oder später deinen Blick wenden musst. Folglich stellt sich die Frage, ob dein Sitestruktur- beziehungsweise Navigationkonzept überhaupt sinnvoll ist. Dein Ansatz, der Sitestruktur über eine verständliche, der Dokumenthierarchie entsprechenden Navigation Herr zu werden, ist zunächst einmal unangemessen; du möchtest eine Pseudo-Sitemap als Navigation einbinden. Keine kontextorientierte assoziative Baumnavigation, welche direkte Unterkategorien und direkte Oberkategorien auflistet und den BenutzerInnen ermöglicht, Schritt für Schritt in der Sitehierarchie abzusteigen, es liegt kein Schwerpunkt auf Verzeichnisseiten der jeweiligen Kategorien und Unterkategorien, welche diesen schrittweisen Einstieg und sprungweisen Aufstieg über einen breadcrumb trail, sondern es wird davon ausgegangen, dass von *jedem* Dokument auf *jedes* darüber- und darunterliegende Dokument auf welcher Ebene auch immer zugegriffen werden kann, ohne Verknüpfung zu thematisch verwandten Seiten.
Ich bin kein Freund von Aufklapp-Navigationen, bei welchen beim Aufklappen nicht das jeweilige Verzeichnisdokument der aufgeklappten Kategorie aufgerufen wurd. Im Grunde genommen reicht eine sich an einem breadcrumb trail orientierende Navigation aus, welche zusätzlich durch *sinnvolle* Querverweise gestützt wird (verwandte Links). Angenommen, es existiert eine dreifach verschachtelte Sitestruktur (a->b->c), so würde es vollkommen ausreichen, wenn ein unterstes Dokument Links zum Großmutterdokument, zum Mutterdokument und den Geschwisterdokumente enthält, ferner wären die Geschwisterdokumente des Mutterdokuments und wenn es hoch kommt die Geschwisterdokumente des Großmutterdokuments interessant, aber nicht deren Kinder und Kindeskindes. Ein klassischer breadcrumb trail ohne Nebenpfade mit starker zusätzlicher assoziativer Verlinkung und einigen auf jeder Seite vorhandenen Meta-Links (Impressum, Kontakt, Suche, Hilfe usw.) wäre auch je nach Site angemessen, ausreichend und optimal benutzerfreundlich.

Ich rate dir deshalb dazu, dir ein (beziehungweise ein anderes) Navigationskonzept zu überlegen.

Grüße,
Mathias

[Lude]

Hi,

was hier immer unter Navigation laeuft, heisst fuer mich Benutzerfuehrung. Und da erwarte ich eigentlich keine "Vor"- und "Zurueck"-Schaltflaechen, sondern ein Menue, wie man es aus anderen "stinknormalen" Applikationen kennt. Das, was im Browser laeuft, kennt zwar keinen Status (bzw. muesste man serverseitig in einer Tabelle 'Stati' pflegen, auf die von der Tabelle 'Sessions' verwiesen wird.), aber ich sehe nicht ein, dass man keine normale Applikation schreiben kann.

Die "Sitemap" gibt es m.E. auch in 'MS Word'.

Daraus wuerde folgen, dass man eben keine typische Webnavigation benoetigt. - Stimmt das?

Gruss,
Lude

[molily]

...

was hier immer unter Navigation laeuft, heisst fuer mich Benutzerfuehrung.

Darin stimme ich dir zu. Wohin *führt* beziehungweise *leitet/begleitet* eine Sitemap? Sie stellt die Sitestruktur da, aber *führt* nicht zu mit dem aktuellen Node verwandten Dokumenten.

Und da erwarte ich eigentlich keine "Vor"- und "Zurueck"-Schaltflaechen,

Trotz einer strengen Hierarchie ist eine Site oft auch in Dokumentverbänden sequenziell aufgebaut, daraus ergibt sich, dass Links zu den jeweils vorherigen beziehungweise nächsten Knoten für die Navigation sehr hilfreich sind.

sondern ein Menue, wie man es aus anderen "stinknormalen" Applikationen kennt.

Das ein- oder mehrfach aufklappbare Hauptmenü einer stinknormalen Applikation erfüllt den Zweck, die lose geordneten Programmfunktionen schnell zugänglich zu machen. Für die jeweiligen Anforderungen mag dies ein cleveres Konzept sein, nur unterscheidet es sich grundlegend von der Navigation in Hypertextstrukturen. Du vergisst, dass es sich auf einer Website nicht darum dreht, alle Funktionen (übertragen: Dokumente beziehungsweise Knoten) in Klickweite verfügbar machen, sondern um das sinnvolle (assoziative) Verknüpfen von Knoten nonlinearen Hypertexts (Tautologie zur Verdeutlichung), eine solche Dimension existiert in deinem Vergleich überhaupt nicht, die Benutzung läuft völlig unterschiedlich ab, mangels eines inneren Zusammenhangs kann nicht von einer »Navigation« oder etwa von »Browsen« (blättern, durchstöbern) gesprochen werden.
Wenn untereinander aus den untersten Knoten hinaus keine Verknüpfungen hinausführen, dann ist die Webseite höchstens eine aus einzelnen, auf eine gewisse Weise angeordneteten klickbaren Texten bestehende Präsentation, aber *Hyper*text lässt sich dieser Verbund (?) nicht nennen. Im besten Fall herrscht aufgrund von extensiv verwendeten Hyper-Links zunächst ein Chaos zwischen den Knoten, wie Robert Bamlers Grafik zeigt:

<img src="http://www.bamler.de/robert/v4/struktur/netz.gif" border="0" alt="">
(http://www.bamler.de/robert/v4/struktur/)

Das, was im Browser laeuft, kennt zwar keinen Status (bzw. muesste man serverseitig in einer Tabelle 'Stati' pflegen, auf die von der Tabelle 'Sessions' verwiesen wird.), aber ich sehe nicht ein, dass man keine normale Applikation schreiben kann.

Wie kennzeichnest du eine Applikation? Lässt sie sich nur linear bedienen? Was ist daran queres Hyperdenken?
Im Grunde genommen ist es eine typische und hier legitime Mehrfensteranwendung (Aufklappen, ohne dass sich im Dokument selbst etwas ändert), auf der einen Seite befindet sich die im Grunde komplette Siteübersicht - mehr, als der aktuelle »trail« bedarf - und auf der anderen Seite der jeweilige Knoten. Die meisten Verknüpfungen werden zweifellos im Navigationsmenü angewählt, folglich sieht, falls man den Fenster-Fokuswechsel als Dokumentwechsel versteht, der Pfad des achso-geführten Benutzers folgendermaßen aus:

Sitemap -> Abstieg zum Knoten -> Aufstieg zur Sitemap -> Abstieg zum Knoten -> ...

Nur besteht hier dasselbe Problem wie bei allen Dokumenten, welche nur innerhalb eines Framesets-Kontexts zusammen mit einem Rubrik- und Metanavigationen navigierbar sind. Zwar ist jede Navigation ein Sitemap-Ausschnitt, aber entscheidend ist, dass das Sitemap-Menü hier in keinem Zusammenhang mit dem angezeigten Dokument steht, es gibt kein Sitestrukturausschnitt, welcher mit dem aktuellen Dokument untrennbar einzigartig verknüpft ist (in welchem das aktuelle Dokument beispielsweise hervorgehoben ist), beziehungsweise lässt sich dieser Ausschnitt ausblenden und je nach Komplexität der Sitestruktur ist dies sogar nötig beziehungsweise ratsam, um sich auf jeder Seite die Links zum Kontext selbst zuzuschalten.

Mit Applikationen hat eine Hypertext-Site insofern nichts zu tun, da es sich um miteinander unverknüpfte Funktionen handelt, die für Hypertext zentralen Begriffe »Dokument«, »Knoten«, »Hyperlink«/»Querverweise«, »Verzeichnis«/»Ordner« (als selbstständige Einheiten, welche Einheiten enthalten) und »Kontext« finden keine Entsprechung.

Die "Sitemap" gibt es m.E. auch in 'MS Word'.

Wobei dort? Eine Funktionsübersicht? Welche *Site* denn bitte? Nicht alles, was Überblick verschafft, kann Sitemap genannt werden.

Daraus wuerde folgen, dass man eben keine typische Webnavigation benoetigt. - Stimmt das?

Wie meinst du das? Was haben typischen Webnavigationen und Hypertextsysteme/-agenten mit Textverarbeitungsprogrammen zu tun?

M.

[Lude]

Hi,

Und da erwarte ich eigentlich keine "Vor"- und "Zurueck"-Schaltflaechen,

Trotz einer strengen Hierarchie ist eine Site oft auch in Dokumentverbänden sequenziell aufgebaut, daraus ergibt sich, dass Links zu den jeweils vorherigen beziehungweise nächsten Knoten für die Navigation sehr hilfreich sind.

ergaenzend sicherlich OK, aber natuerlich auch nicht notwendig.

Für die jeweiligen Anforderungen mag dies ein cleveres Konzept sein, nur unterscheidet es sich grundlegend von der Navigation in Hypertextstrukturen. Du vergisst, dass es sich auf einer Website nicht darum dreht, alle Funktionen (übertragen: Dokumente beziehungsweise Knoten) in Klickweite verfügbar machen, sondern um das sinnvolle (assoziative) Verknüpfen von Knoten nonlinearen Hypertexts (Tautologie zur Verdeutlichung), eine solche Dimension existiert in deinem Vergleich überhaupt nicht, die Benutzung läuft völlig unterschiedlich ab, mangels eines inneren Zusammenhangs kann nicht von einer »Navigation« oder etwa von »Browsen« (blättern, durchstöbern) gesprochen werden.

Ich habe einige Erfahrung mit "stinknormalen Applikationen" und deren Nutzern. Diese haben m.E. tendenziell nicht das Beduerfnis nach Hypertext und komplexeren Benutzerfuehrungen. Erfahrene Benutzer mit IT-KnowHow entwickeln moeglicherweise ein solches. (Die Konzepte, die hinter der von Dir geschilderten Navigation stehen, erahne ich natuerlich.)

Das, was im Browser laeuft, kennt zwar keinen Status (bzw. muesste man serverseitig in einer Tabelle 'Stati' pflegen, auf die von der Tabelle 'Sessions' verwiesen wird.), aber ich sehe nicht ein, dass man keine normale Applikation schreiben kann.

Wie kennzeichnest du eine Applikation? Lässt sie sich nur linear bedienen? Was ist daran queres Hyperdenken?

Ich fragte mich, ob eine "Webapplikation" ein "queres Hyperdenken" erforderlich macht. Und wenn dann nur wegen http? - Meine Antwort lautet nein.

Mit Applikationen hat eine Hypertext-Site insofern nichts zu tun, da es sich um miteinander unverknüpfte Funktionen handelt, die für Hypertext zentralen Zugriffe »Dokument«, »Knoten«, »Hyperlink«/»Querverweise«, »Verzeichnis«/»Ordner« (als selbstständige Einheiten, welche Einheiten enthalten) und »Kontext« finden keine Entsprechung.

Was sind denn unverknuepfte Funktionen? Idealerweise sind bereitgestellte Funktionalitaeten doch alleinstehend, denn sonst haette es ja keine saubere Trennung gegeben.

Daraus wuerde folgen, dass man eben keine typische Webnavigation benoetigt. - Stimmt das?

Wie meinst du das? Was haben typischen Webnavigationen und Hypertextsysteme/-agenten mit Textverarbeitungsprogrammen zu tun?

Meine Aussage war eben, dass man Navigation a la Hypertext nicht wirklich benoetigt. Diese mag zwar gut sein; ist aber sicherlich komplexer als noetig und darum wohl fuer viele Anwednungen weniger geeignet.

Ich behaupte natuerlich keineswegs, dass ich auch recht habe.

Gruss,
Lude

[donroca]

Hallo,

Morten Wang's Treemenu sieht zwar erstal aus wie Windows-Explorer, kann aber voellig konfiguriert werden:
http://www.treemenu.com/.
Schau mal bei Contributions nach Thomas Stutz, sein Tool finde ich sehr gut.

Dieter

[Martin]

hi nochmal!

danke für eure antworten, ihr habt mir sehr weitergeholfen!

aber vor allem das empfohlene "Treemenu" schaut mir sehr danach aus, dass es Frames verlangt? Kommt für mich nicht in Frage, da ich Tabellen verwenden werde

aber jetzt mal ganz abgesehen von meinen Menüdesignwunsch, zu welchem Menü würdet ihr mir persönlich raten? Eher einfach Sachen, wie in der rechten Tabelle nur Oberkategorien und dann in der Haupttabelle die Untermenüpunkte?