at: Zu Navigationsleisten und deren Umsetzung

Beitrag lesen

Hallo.

Was ich eben sagen wollte,

[...]

Ich stimme da vollkommen mit dir überein. Ich baue gerne ergänzend zu Navigation, die bei mir im Übrigen nur auf sehr kompakten Seiten vollständig ist, häufig noch eine kleine Liste der Rubrik "In diesem Zusammenhang ebenfalls interessant:" hinzu, gegebenenfalls sogar strukturiert oder kurz erläutert. Alternativ hätte ich thematisch naheliegende Referenzen auch innerhalb der Nauptnavigation mittels logischer Auszeichnung hervorheben können, aber meine Befürchtung war, mit unterschiedlichen hervorgehobenen Links innerhalb der gleichen Navigationselemente auf unterschiedlichen Seiten die Nutzer unnötig zu verwirren.

Nun, unter dem Aspekt, dem Besucher auf der Site zu behalten, habe ich es noch nicht gesehen. Das ist auch ein Argument, das völlig andere Kriterien zugrunde legt, als diejenigen, die gegen das verbreitete Konzept der »Navigationsleiste« genannt wurden. Es hat wenig mit der Frage nach der richtigen semantischen Auszeichnung gemein.

Stimmt, während die Semantik im Kopf des Betrachter entsteht, geht die Intention vom Autoren aus. Diese beiden Dinge haben also wirklich wenig miteinander gemein. Aber ohne Intention müsste ich auch keine Informationen zur Verfügung stellen. -- Sie sind ja kein Selbstzweck.

Wobei ich dies eher als eine Reaktion auf ein bestimmtes unerfreuliches Leserverhalten ansehe und nicht von einem grundlegenden Zusammenhang des Hypertexts sprechen würde.

Da hast du sicher Recht, aber das rechtfertigt meines Erachtens nicht, diesen Aspekt völlig zu ignorieren und auf eine Navigation zu verzichten, denn reinen Hypertext zu verwenden, ohne Begleiteffekte zu berücksichtigen, hielte ich für einen Tanz um das falsche goldene Kalb.

Vor allem möchte ich »Präsentation einer Dienstleistung« (was immer das sein mag) nicht so selbstverständlich mit einer vergleichsweise aufdringlichen Inhaltsaufbereitung verstanden wissen.

Nun, "aufdringlich" ist in diesem Zusammenhang sicher relativ, und "vergleichsweise" zu einem Hypertext der reinen Lehre ist eine Navigation immer sehr viel der guten Absicht. Unter einer Präsentation als Dienstleistung verstehe ich, nicht nur das naheliegende zu bieten (Hypertext), sondern eine darüber hinaus gehende Vernetzung zu schaffen, die einzelnen Wörtern oder Passagen des Textes nicht eindeutig zuzuordnen ist, so dass dies nicht mittels Hypertext geschehen kann. Zwar versuche ich auch das, aber ein gesonderter Punkt "Wegbegeschreibung" innerhlab der Navigation scheint vielen Nutzern wahrscheinlich aus Gewohnheit eingänglicher als mein Ansatz, einzelne Adresszeilen mit einem Link auf die Wegbeschreibung zu versehen.

Diejenigen Besucher, die wirklich Wissbegier und Neugier zeigen, werden einen Navigationsschritt mehr in Kauf nehmen, um zu den Inhalten zu kommen, die mit dem gegenwärtigen Dokument nur indirekt in Verbindung stehen.

Je nach Konzept wird ihnen ja auch wenig anderes übrig bleiben ;-)

Alles Vorhandene möglichst kompakt zu zeigen und Quersprünge zu ermöglichen, spricht meinem Verständnis nach eher diejenigen an, die nicht von sich selbst zum Stöbern bzw. zum sogenannten Flanieren bereit sind, was m.E. nicht dermaßen verhindert ist, wenn nicht in jedem einzelnen Dokument die komplette Sitemap wiederholt wird bzw. parallel zum Dokument angezeigt wird.

Hier sehe ich eine Parallele, denn die, "die nicht von sich selbst zum Stöbern bzw. zum sogenannten Flanieren bereit sind," haben es häufig schlicht eilig. Ich muss darauf keine Rücksicht nehmen oder kann versuchen, sie mittels meiner Inhalte ein wenig auszubremsen, aber ich kann ihnen auch einige Sprungbretter zur Verfügung stellen, die die Flaneure sicher auch gern übersehen.

Nein, auch eine Sitemap kann sich durch das Neuladen des des gesamten <frameset> dem Kontext anpassen.

Darum geht es doch gar nicht. Das ist ja im Prinzip noch schlimmer (und praktikabel schon gar nicht, weil es soviele Sitemap-Dokumente und soviele Framesets erzeugt, wie es Dokumente gibt - von JavaScript/Flash/Java-Lösungen einmal abgesehen).

Auch wenn es dir nicht darum ging, geht es mir sehr wohl darum. Und technisch ist so etwas auch durch mehrere Sitemaps mit unterschiedlichen Mittelpunkten (Standorten) innerhalb eines Dokumentes zu lösen -- aber das tatsächlich nur am Rande.

Ich wollte sagen, dass das Auslagern selbst das Problem ist. Jedes Dokument hat in der Sitestruktur einen bestimmten Platz. Dieser individuelle Kontext lässt teilweise etwa sich durch einen entsprechenden Ausschnitt der Sitehierarchie beschreiben, vereinfacht:

... <a rel="chapter" rev="child">B</a>  
 |- <a rel="section [prev]">1</a>  |- <strong title="aktuelles Dokument">2</strong>  - <a rel="section [next]">2</a>

Ja, soweit jedenfalls bei einer linearen Struktur. Innerhalb einer nicht-linearen Struktur hilf t dann wohl eher wieder reiner Hypertext -- gegebenenfalls auch mit Navigation.

Zum Kontext gehören neben dem Bewegen in Hierarchie und Sequenz auch Querverweise (verwandte, weiterführende Infos usw.) und die site-zentralen Einrichtungen, wie gesagt. Es ist in der Regel notwendig, diesen individuellen Kontext als solchen herauszuarbeiten, um grundlegende Navigation zu ermöglichen (was darüber hinaus möglich und aus anderen Gründen ratsam ist, lasse ich einmal außen vor, das ist dann m.E. eher Kür statt Pflicht). Das hatte ich mit »die direkten Zusammenhänge eines Dokuments mit anderen Knoten aus der Sicht des Einzeldokuments herauszuarbeiten« angesprochen. HTML bietet, wie ich in geschildert habe, die Möglichkeit, diesen Kontext explizit semantisch und formal angemessen auszuzeichnen - und zwar individuell aus der Fischaugenperspektive. Jedes Dokument enthält dadurch Verweise zum individuellen Kontext (und ist damit autonom, was später eine Rolle spielen wird).

Soweit gehen wir konform -- wenn man davon absieht, wie mangelhaft diese Methoden bisher eingesetzt werden können, wenn man keinen Einfluss auf den User Agent hat.

Demgegenüber steht nun die Vorgehensweise, auf diese Auszeichnung ganz oder weitesgehend zu verzichten und den individuelle Kontext nur noch implizit durch die Position des Titels des jeweiligen Dokuments bzw. Position des Links zum jeweiligen Dokument in der Listenhierarchie der Sitemap zu erkennen ist. Anstatt jedem Dokument diese Informationen mitzugeben, wird nur noch ein Meta-Dokument geboten, dass alle Zusammenhänge aus der Vogelperspektive beschreibt.

Wieso? Je nach gebotenem Ausschnitt können auch mehrere Perspektiven innerhalb eines Dokumentes liegen. Dies schließt zwar eine hohe Redundanz ein, aber die ist bei der anderen Methode ja auch nur auf mehrere Dokumente verteilt.

Von typisierten Verweisen, die die Einordnung eines Dokuments in den jeweiligen Kontext vornehmen, ist dabei keine Spur mehr, auch wird keine Unterscheidung von direktem und entfernterem Kontext gemacht.

Wieso? Ich muss doch nicht vom schlechtesten Beispiel auf die Allgemeinheit schließen, denn natürlich kann ich typisierte Verweise und den Kontext über Klassen oder logische Auszeichnung innerhalb der Sitemap herstellen und per CSS auszeichnen. -- Ich mag Sitemaps eigentlich nicht sonderlich und verteidige sie nur ungern, aber ich befürchte einfach, dass deine Darstellung die Sachverhalte ein wenig verkürzt.

Selbst wenn jedes an sich mit anderen nicht vernetzte Dokument ein eigenes Frameset mit einer eigenen angepassten Sitemap erhält, in der das jeweillige Dokument irgendwie markiert ist (wie oben etwa durch strong) und der spezielle Kontext hervorgehoben ist, kann darin nie diejenige Semantik untergebracht werden, die das lokale, individuelle Auszeichnen des Dokumentkontexts ermöglicht. Das hatte ich schon in anklingen lassen und Tim hat es in schön auf den Punkt gebracht.

Das es sich dabei um einen Behelf handelt, ist uns doch allen bewusst. Aber deswegen muss ich nicht ganz darauf verzichten oder darauf verzichten, die Methode zu verfeinern -- zumal die bessere Variante bisher leider kaum Unterstützung bei den User Agents findet.

Der praktische Nachteil davon, dass das Dokument nur durch Drittdokumente in seinen Kontext eingeordnet wird und nicht durch Metadaten in Form von link-Verknüpfungen (oder pragmatisch: breadcrumb trails, kleinere Sitemapausschnitte wie oben gezeigt), ist die fehlende Navigierbarkeit, wenn das Dokument außerhalb des Framezusammenhangs steht. Aber das ist ein generelles Problem von Frames, da verweise ich auf meine Postings im Archiv, welche die Notwendigkeit hervorheben, dass ein Dokument in dieser Weise autonom sein muss bzw. sollte, um unter verschiedenen Bedingungen benutzbar zu sein.

Keine Frage, aber die Idee mit den Frames war ja auch aus dem Vorwurf geboren, eine Sitemap oder sonstige Navigation nicht in die Seite einbinden zu dürfen. Die dadurch geschaffene Redundanz sehe ich sicher als kleineres Übel gegenüber Frames an. Wie ich zu Frames stehe, habe ich ja bereits innerhalb dieses Threads sowie im Vorfeld deutlich zu verstehen gegeben.

Es gibt sogar Suchmaschinen, die darauf basieren und diese Knoten visuell darstellen.

Wie hat man sich diese vorzustellen, als eine Art dynamisches Menü? Woher bekommt sie die Information über die Struktur und den jeweiligen Kontext, oder soll sie die Verbindungen gar nicht visualisieren? Sie müsste ja irgendwo die Daten hernehmen, etwa aus einem globalen RDF-Dokument.

Frage mich bitte nicht nach der zu Grunde liegenden Technik. Ich weiß nur, dass es sich wohl um ein Java-Applet handeln muss, dass unterschiedlich weit entfernte und unterschiedlich große miteinander vernetzte Knoten um den zentralen Suchbegriff darstellt und den Fokus beim Klick auf einen dieser Knoten auf diesen verlagert und weitere Knoten um diesen herum aufbaut.

Der Aufbau einer Navigation hat sich nach der Präsentation zu richten, so dass ein Kontext immer gegeben ist.

Ansonsten plädierst du dafür, die Präsentation bei der Auszeichnung zunächst zu ignorieren und die Auszeichnung an sich zu betrachten, wieso stellst du hier die Präsentation über alles und fragst nicht nach Semantik?

Nur kurz zur Begriffsklärung: Unter "Präsentation" verstehe ich "eine Präsentation", also eine bestimmte Anzahl zusammenhängender Dokumente. Was du als "die Präsentation" aufgefasst hast, bemühe ich mich, als "Darstellung" zu bezeichnen.

So findet man auf vielen Seiten eine entsprechend abgespeckte Version der Navigation mit einem zusätzlichen Verweis auf die Sitemap, die als Inhaltsverzeichnis ja per se einen Bezug zum Inhalt des Dokumentes hat.

Abgesehen davon, dass auch dies im Sinne des Ursprungsposting unsemantisch ist (krchch) und die link-Elemente die Navigation formalisieren könnten und damit das Problem der besagten »Interferenzen« lösen würden, halte ich es für einen alltagstauglichen/praktikablen Schritt, wenn die besonders relevanten Beziehungen herausgearbeitet werden. Davon, fast alle Navigationsbewegungen über reine Meta-Dokumente wie Sitemaps laufen zu lassen (Benutzer geht immer wieder zur Sitemap, zu einem Dokument, zur Sitemap, zur einem weiterem Dokument usw.), halte ich wiederum wenig.

Da sind wir uns einig.

Und eine übegreifende Navigation erweitert meines Erachtens lediglich diesen Kontext.

Sie verwischt den ursprünglichen Kontext m.E. vollkommen. Das Netzwerk konstituiert sich nicht in seinen Bestandteilen und deren Beziehungen mit Subjekten, Prädikaten (rel) und Objekten (href) bzw. umgekehrten Beziehungen, sondern nur in einem zentralen Metadokument.

Daher hatte ich von einem "zusätzlichen Verweis" gesprochen, der zum einen nicht die Meta-Angaben ersetzen soll und zum anderen ein ja auf ein in sich stimmiges Inhaltsverzeichnis als Gesamtdokument verweist, das in sich geschlossen funktioniert. MfG, at

0 65

Zu Navigationsleisten und deren Umsetzung

emu
  • html
  1. 0
    Jeena Paradies
    1. 0
      emu
      1. 0
        Orlando
      2. 0
        Jeena Paradies
        1. 0
          Jeena Paradies
  2. 0
    Andreas-Lindig
    1. 0
      emu
  3. 0
    Cheatah
    1. 0
      emu
      1. 0
        Cheatah
      2. 0
        wahsaga
    2. 0
      molily
      1. 0
        Cheatah
        1. 0
          molily
  4. 0
    Armin G.
    1. 0
      emu
      1. 0
        Armin G.
        1. 0
          at
      2. 0
        Chräcker Heller
        1. 0

          Innovation offener Standards und deren Entwicklung durch Firmen

          Tim Tepaße
          • sonstiges
  5. 0
    Chräcker Heller
    1. 0
      emu
      1. 0
        wahsaga
        1. 0
          molily
      2. 0
        Chräcker Heller
  6. 0
    Cyx23
    1. 0
      molily
      1. 0
        emu
        1. 0
          at
          1. 0
            molily
            1. 0
              at
              1. 0
                Cyx23
                1. 0
                  at
  7. 0

    Zu Navigationslisten in XHTML 2

    Tim Tepaße
    1. 0
      emu
      1. 0
        Tim Tepaße
  8. 0
    Tim Tepaße
    1. 0
      emu
      1. 0
        Tim Tepaße
        1. 0
          Cyx23
          1. 0
            Tim Tepaße
            1. 0
              Cyx23
              1. 0
                at
                1. 0
                  Cyx23
                  1. 0
                    at
                    1. 0
                      Cyx23
                      1. 0
                        at
                        1. 0
                          Cyx23
                          1. 0
                            Tim Tepaße
                            1. 0
                              Cyx23
                              1. 0
                                Tim Tepaße
                                1. 0
                                  Cyx23
                                  1. 0
                                    at
                                  2. 0
                                    molily
                                    1. 0
                                      Cyx23
                                      1. 0
                                        molily
                                        1. 0
                                          Cyx23
                                          1. 0
                                            molily
                    2. 0
                      molily
                      1. 0
                        at
                        1. 0
                          molily
                          1. 0
                            at
              2. 0
                Tim Tepaße
                1. 0
                  Cyx23