molily: Zu Navigationsleisten und deren Umsetzung

Beitrag lesen

Diese Verknüpfungen sind aber aus objektivierter Sicht willkürlich und nicht assoziativ.

Natürlich sind sie das. -- Ich möchte sogar sagen: Sie sind suggestiv, denn sie sind nur ein Hilfsmittel, die ohnehin nicht vollständig zu lenkende Ausmerksamkeit etwas breiter zu kanalisieren.

Was ich eben sagen wollte, ist, dass das Anlegen von zahllosen Kanälen durch »eine möglichst vollständige Navigation« nichts mit dem Lenken der Aufmerksamkeit auf die im Besonderen relevanten Verknüpfungen liegt, die nicht nur existieren, weil sie angelegt wurden und vom Besucher begangen werden, sondern weil die Inhalte korrespondieren. Ich streite nicht ab, dass viele Leser beim Bewegen durch die Site die Lust zu Quersprüngen zu anderen Teilen der Site haben, die mit dem Ursprungsdokument nichts direkt zu tun haben. Auch ist ihnen durch eine vollständige Navigation immer bewusst, was es »sonst noch« auf der Site gibt. Es ist natürlich legitim, diese Bedürfnisse zu bedienen. Allerdings sehe ich auch das Bedürfnis, sich in der Sitestruktur innerhalb der Pfade zu bewegen, die inhaltlichen Zusammenhang markieren. Anstatt dem Benutzer also einen Haufen von Links vorzusetzen, von denen der Leser nicht direkt weiß, ob und wie sie mit dem gegenwärtigen Dokument zu tun haben, sehe ich es als wichtig an, kontextuelle Verweise als solche deutlich zu machen. Das kann natürlich auch dadurch geschehen, eine Sitestruktur so auszuarbeiten, dass eine »Navigation« Schwerpunkt auf diesen engeren Kontext eines Dokuments setzt, aber auch darüber hinaus geht, um Quersprünge zu erlauben (was ich persönlich nicht für wichtig halte und den Umweg über einen rel="up"- bzw. rel="start"-Link für zumutbar halte, aber ich kann den Sinn nachvollziehen).

Was das Denken des Benutzers angeht, bei dem eigenständig Bezüge hergestellt werden, deren Sinn sich nicht intersubjektiv vermitteln lässt und die sich wie du sagst nicht voraussehen lassen, so ließe sich genauso rechtfertigen, auf jeder Seite zufällige Links unter anderem hinaus ins Web unterzubringen, weil die Gedanken des Benutzers ja springen und er plötzlich in einem irrationalen Anflug vom Hölzchen aufs Stöckchen will.

Das ist richtig, aber warum sollte mir als Autor daran gelegen sein?

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.

Nur ist es wirklich angebracht, solche Kanäle anzulegen, ist das die Aufgabe des Autors?

Das ist eine Frage der Absicht, die der Autor verfolgt. Wenn ich meine Präsentation als Dienstleistung auffasse, ist es töricht, darauf zu verzichten. Wenn ich jedoch einen Fachartikel, mag das anders sein.

Das mag stimmen. Wobei ich dies eher als eine Reaktion auf ein bestimmtes unerfreuliches Leserverhalten ansehe und nicht von einem grundlegenden Zusammenhang des Hypertexts sprechen würde. Prinzipiell sehe ich diesbezüglich auch keinen notwendigen Unterschied zwischen verschiedenen Absichten von Sites. 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. 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. 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.

Wenn ein Frameset genutzt wird, um die sogenannte Navigation auszulagern, gar eine Sitemap ständig im Blickfeld haben, fehlt wie gesagt jede Herausarbeitung der Beziehungen eines Einzelknoten.

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). 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>
...

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 [pref:t=67816&m=388766] 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).

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. 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.
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 [pref:t=67816&m=388762] anklingen lassen und Tim hat es in [pref:t=67816&m=393891] schön auf den Punkt gebracht.

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.

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.

Eine solche Suchmaschine in einen <frame> einzubinden, während ein zweiter den Inhalt des Dokuments anzeigt, wird meinen Ansprüchen an die Methode gerecht.

Wie gesagt, das Dokument verliert ohne diese Navigationshilfe jegliche Verbindungen zum Kontext bzw. hatte sie an sich nie.

Es wird ganz und gar dem Benutzer überlassen, zwischen beabsichtigten und unbeabsichtigten Kontext zu unterscheiden. Der Leser wird nicht durch wenige vorangelegte Kanäle geleitet, deren beschreiten sich lohnt, er steht nur vor einer Flut von Verweisen, deren kein Zusammenhang mitgegeben ist. Die Links sind einfach deshalb da, weil es das Zieldokument gibt.

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? Und wieso ist der Kontext immer gegeben? Wenn die Präsentation als Fundament defizitär ist, dann ist eine darauf aufbauende und dem entsprechende Navigationstrategie nicht per se angemessen und der entstehende Kontext muss nicht kohärent sein. Sowieso zieht die Präsentation an sich Fragen der Hypertextualisierung nicht in Betracht...?

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.

Der Sinn des Hypertext ist m.E. eben nicht, von jedem Knoten einen Sprung zu jedem anderen Knoten zu ermöglichen, sondern kontextuelle Verweise zu bieten und damit kohärente Netzwerke an Informationen zu weben, die nicht nur im Kopf des Betrachters entstehen und eine andere Person kein bisschen nachvollziehen kann, wieso das eine mit dem anderen in Verbindung/Wechselwirkung steht.

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.

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