Beat: ist target="_blank" wirklich userfreundlich?

Beitrag lesen

Hallo,

Das Thema wird hier bekanntlich oft diskutiert, wobei ich den
Eindruck habe, dass hier im Forum (und in ähnlichen Kreisen)
die Meinung vorherrscht, dass target="_blank" und
das Öffnen neuer Fenster "böse" sind.

Ich glaube, dass man das Thema, wie auch frames, sehr Kontext abhängig diskutieren sollte.
Nichts ist böse an und für sich. Auch frames können ihre Berechtigung haben.

Der Usability-Experte Jakob Nielsen beispielsweise vergleicht
das Öffnen von [normalen] Links [zu anderen HTML-Seiten] in einem
neuen Fenster mit einem Staubsaugervertreter, der als erstes
einen Aschenbecher auf dem Teppich seiner "Kunden" ausleert...
(Der Vergleich hat mir nie ganz eingeleuchtet, aber er zeigt,
wie "böse" es für Nielsen ist... ;-)

Was allerdings in diesem Gleichnis arg verzerrt ist, ist die tatsache, dass das éffnen eines neuen Fensters in der Regel nicht beim Betreten geschieht und oft auch aus der Art des Links man nicht so überrascht ist, wenn er denn in einem neuen Fenster oder Tab öffnet.

Vergessen wir nicht, dass es auch eine Methode ist, aus Schaufenstern auszubrechen.

Was dagegen spricht, Links (egal, welcher Art) in einem neuen
Fenster zu öffnen, ist die Behinderten-Zugänglichkeit (Accessibility).
Neue Fenster können z.B. für Sehbehinderte und Blinde ein Problem sein.

Hier geht man allerdings davon aus, dass Behinderte per se mit den falschen Krücken ausgestattet wurden.

Techniques for Web Content Accessibility Guidelines 1.0
...
Hinweis: Diese Empfehlungen stammen aus dem Jahr 2000.
Dieses Problem könnte heute dadurch entschärft sein, dass
Browser wie Firefox es dem Benutzer ermöglichen, das Öffnen
von neuen Fenstern zu unterdrücken, sodass alle Inhalte
zwingend im gleichen Fenster bzw. Tab angezeigt werden.

Im gleichen Sinne dürfte es auch für Behinderte heute weit fortgeschrittenere User-Agents geben.

Oft wird auch argumentiert, dass ja der mündige Benutzer (z.B. durch
Rechtsklick auf einen Link und "Link in neuem Fenster/Tab öffnen" u.s.w.)
selbst die Kontrolle habe.
Wobei ich mich frage, wie viele "normale" Benutzer diese Möglichkeit
überhaupt kennen. (Wir Webdesigner sind da nicht repräsentativ!)

Eigentlich ein falsches Argument, weil die Überraschung auf den Link folgt,und ihm nicht vorangeht.
In manchem Kontext mag es deshalb angebracht sein, in einem neuen Fenster/Tab zu öffnen.

Meine Sessions sind Seitenorientiert. Das hat viele Vorteile, aber auch einen Nachteil. Page Reload und Browser-Back brechen die Session (wie bei der Bank).
Wie also Links in einen Kontext ausserhalb der Session öffnen?
Ich muss voraus entscheiden.

Trotz dieser Zweifel an den Browser- und Fenster-Kompetenzen
der Benutzer mache ich selbst normalerweise alle Links ohne
target-Attribut und verzichte auf das Öffnen neuer Fenster.

In der Regel das Beste verfahren.

Ich gehe davon aus, dass Surfen ein linearer Prozess ist,
d.h. ich bewege mich als Surfer auf einer Schiene vorwärts,
von Seite zu Seite oder auch mal von einer HTML-Seite zu
einem PDF. Und wenn ich in einer "Sackgasse" bin (z.B. in
einem PDF-Dokument) oder sonst zurück will, kann ich immer
die "Zurück"-Funktion des Browsers nutzen. Und wenn ich
absichtlich "mehrgleisig" fahren will, dann öffne ich als
Benutzer die Links in zusätzlichen Tabs im Browser, weiss
dann aber auch, dass ich eben mehrere Tabs offen habe.
Das Öffnen von neuen Fenstern habe ich in Firefox abgeschaltet.

Hier unterscheiden sich unsere Erfahrungen. Ich erfahre das Web als eine Baumstruktur, nicht als linearen Prozess.
Bin ich mit einem wichtigen Direktory konfrontiert, so öffne ich Inhaltsseiten in einem neuen Tab.
Bestes Beispiel ist dieses Forum.

Spezialfall PDF & Co.

Ist für mich kein Spezialfall, weil PDFs gar nicht im browser geöffnet werden.

Vor kurzem erhielt ich ein Mail von einem Homepage-Besucher zum einem
"Problem", das dieser auf einer von mir gemachten Homepage hatte:
Der Benutzer klickte auf einen Link (ohne target oder dergleichen),
welcher ein PDF einfach im gleichen Browserfenster öffnete.
Am Schluss machte der Benutzer das Fenster (gewohnheitsmässig) zu.
Jetzt erwartete er, wieder die HTML-Seite zu sehen, auf der er vorher
war und wo er den Link zum PDF angeklickt hatte. Stattdessen war
da nichts mehr zu sehen.
Und dieser Benutzer ist offenbar nicht der einzige, der dieses
"Problem" hat.

Das ist ein gutes Beispiel.
Hier wären noch andere Situationen anzufügen, wie etwa Download-Links in Sourceforge. Oftmals möchte ich noch die Notizen vor der Download Seite (eine Abfrage zu Mirrors) behalten. Hier öffne ich standardmässig in einem neuen Tab.

Einerseits ist bei den "Top Ten Mistakes in Web Design"
(the very worst mistakes of Web design; updated 2007)
http://www.useit.com/alertbox/9605.html
der 9. Fehler: "Opening New Browser Windows".
Die Haupt-Begründung ist, dass das Öffnen von neuen Fenstern
die "Zurück"-Funktion des Browsers zunichte macht.

Das stimmt nicht. Es macht sie obsolet. Aber die History ist in der anderen Instanz immer noch vorhanden.

Aber für PDF und andere "Non-Web-Documents" (z.B. Excel-, Word-
oder PowerPoint-Dateien, die man auf dem Internet anbietet)
schreibt Nielsen folgendes:

  • Am besten sollte man - per HTTP-Head - dafür sorgen, dass
      die Dateien gar nicht erst in einem Browserfenster (z.B.
      per Plugin oder eingebauten Viewer) angezeigt werden,
      sondern dass der Benutzer sie herunterladen muss und sie
      dann mit einem externen Programm öffnet. (Punkt 4)

Sind also Plugins böse?

  • Ansonsten sollte man die Links so machen, dass
      1. die Dokumente in einem Zusatz-Browserfenster aufgehen

Also mit Javascript? Au du Sch....

2. der Benutzer im Vornherein gewarnt wird, dass der Link
     ein Zusatzfenster öffnen wird.

Das könnte doch der User-Agent automatisch machen, indem er ein target=_blank erkennt.

3. das Zusatzfenster die üblichen Browser-Schaltflächen
     und -Menüs *nicht* aufweist, da z.B. die Zurück-Funktion
     oder Datei -> Drucken oft nicht wie erwartet funktionieren,
     wenn es sich z.B. um PDF- oder PowerPoint-Dokumente handelt.
     (Das heisst technisch gesehen: Man müsste solche Links - neben
     dem href-Attribut und dem target-Attribut für Benutzer ohne
     JavaScript - mit einem Attribut im Stil
     onclick="window.open(this.href,'_blank','scrollbars=yes,resizable=yes'); return false;"
     ergänzen und somit das Zusatzfenster bei aktiviertem JS eben
     mit JS zu öffenen und die Browser-Schaltflächen ausblenden.)
http://www.useit.com/alertbox/open_new_windows.html

Wie gesagt, es ist nicht zu viel von User-Agents verlangt, dass den user bei einem existierenden Target vorwarnen können.
Der Tipp über Java-Script kann mich nicht begeistern.

Denken wir daran, dass es gerade im Zusammenhang mit JS Gründe gibt, dass jede Domain sein Fenster haben darf, damit keine Daten Gegenstand von XSS Attacken werden. leider ist XSS immer häufiger, und dies ist in der Diskussion nicht angesprochen worden.

Für mich persönlich gilt auch: Wenn ich Sicherheit gegen Usability verrechnen muss, dann ist mir ersteres einiges Lieber.

mfg Beat

--
Woran ich arbeite:
X-Torah
   <°)))o><                      ><o(((°>o
0 56

ist target="_blank" wirklich userfreundlich?

angie
  • meinung
  1. 0
    hotti
    1. 0
      angie
      1. 0
        Cheatah
        1. 1
          angie
    2. 1
      Klawischnigg
      1. 0
        Timo "God's Boss" Reitz
        1. 0
          Kai345
          1. 0
            Kai345
            1. 0
              Klawischnigg
          2. 1
            Klawischnigg
            1. 0
              Timo "God's Boss" Reitz
  2. 0
    Frank Schönmann
  3. 0
    Beat
    1. 0
      Matze
    2. 0
      Gunnar Bittersmann
      1. 0
        Der Martin
        1. 0
          Gunnar Bittersmann
      2. 0
        Beat
        1. 0
          Gunnar Bittersmann
          1. 0
            Siechfred
            1. 0
              Timo "God's Boss" Reitz
              1. 0
                Blaubart
              2. 0
                Siechfred
          2. 0

            target="_blank" kann Service sein

            cygnus
  4. 0
    Cheatah
    1. 0
      angie
      1. 1
        Thomas Luethi
        1. 0
          Længlich
          1. 0
            Der Martin
            1. 0
              Længlich
          2. 0
            Thomas Luethi
      2. 0
        Cheatah
        1. 0
          angie
      3. 0
        Ingo Turski
        1. 0
          molily
  5. 4
    Thomas Luethi
    1. 0
      Der Martin
    2. 0
      molily
      1. 0
        Thomas Luethi
        1. 0
          molily
    3. 0
      Beat
    4. 2
      Cheatah
      1. 0
        Thomas Luethi
        1. 0
          Alexander (HH)
    5. 0

      Das Plugin-Problem

      Tim Tepaße
    6. 0
      Ingo Turski
      1. 0
        Thomas Luethi
        1. 0
          Ingo Turski
    7. 0
      Vinzenz Mai
    8. 2
      Thomas Luethi
  6. 0
    schwarze Piste
  7. 0
    AndreD
  8. 0
    MudGuard
    1. 0
      Der Martin
  9. 0
    Cybaer