it-swarm-eu.dev

HTML-Schaltflächen vs Hyperlinks für die Navigation

Wie bestimmen Sie beim Erstellen eines allgemeinen Site Style Guides, wann eine Schaltfläche oder ein Hyperlink für etwas anderes als die Navigation verwendet werden soll?

Ich sehe oft, dass Hyperlinks aufgrund der starken Nutzung von jQuery und AJAX mehr als nur Navigation leisten. Ist es schlechtes Design, sie für etwas anderes als die Navigation zu verwenden?

16
rick schott

Im Allgemeinen erwarten Benutzer, dass Links verknüpft werden und Befehlsschaltflächen befehlen. Das heißt, Links navigieren und präsentieren neuen Inhalt, ohne die zugrunde liegenden Datenobjekte oder ihre Beziehungen oder Positionen zu ändern. Schaltflächen ändern diese Dinge, führen die Erstellung, Löschung, Zuordnung, Konvertierung, Vervielfältigung usw. durch. Eine einfache Faustregel lautet: Wenn die knappste Beschriftung für das Steuerelement ein Substantiv ist (z. B. Startseite, Produkte, Sitemap), verwenden Sie diese eine Verbindung. Wenn die Beschriftung ein Verb ist (z. B. Aktualisieren, Senden, Löschen, Kaufen), verwenden Sie eine Schaltfläche.

Sie haben jedoch Recht, dass in letzter Zeit auf verschiedenen Websites anstelle von Befehlsschaltflächen Links verwendet wurden, und sogar einige Styleguides unterstützen dies. Tatsächlich wurden Links anstelle nahezu aller anderen Steuerelemente (z. B. Optionsfelder, Registerkarten, Kontrollkästchen) verwendet. Darüber hinaus können in Thick-Client-Desktop-Apps Schaltflächen navigieren, insbesondere in älteren Apps, die vor der allgemeinen Verwendung des Webs (und von Links) erstellt wurden. Ich glaube, dies verwirrt die Benutzer und wir sollten wirklich unterschiedlich aussehende Steuerelemente für unterschiedliche Funktionen verwenden. Sowohl Web-Apps als auch Desktop-Apps sollten mithilfe von Links und Schaltflächen klar zwischen Navigation und Befehlen unterscheiden. Das Navigieren unterscheidet sich erheblich von Befehlen, weil:

  • Benutzer können die Navigation einfach zurücksetzen, indem sie auf Zurück klicken oder das Fenster schließen. Es ist immer eine "sichere" Aktion. Befehle können in einer Web-App häufig nicht zurückgesetzt werden. Wenn Befehle zurückgesetzt werden können, erfolgt dies über eine Rückgängig-Funktion, die eine andere Benutzerantwort als Zurück oder Schließen beinhaltet.

  • In Desktop-Apps müssen Benutzer nach dem Navigieren nicht speichern. Nach einem Befehl ist häufig ein Speichern erforderlich.

  • Befehle bieten unterschiedliche Rückmeldungen, die oft subtiler sind als die Navigation. Es ist im Allgemeinen offensichtlich, wenn dem Benutzer neue Inhalte präsentiert werden. Befehle können die Änderung des Inhalts anzeigen, aber häufig ist keine Änderung erkennbar (z. B. für Kopieren oder Speichern). Web-Apps greifen häufig auf Bestätigungsseiten zurück (was in meinem Buch nicht als Navigation gilt).

Aus diesen Gründen hilft es dem Benutzer, unterschiedliche Steuerelemente für Navigation und Befehle zu haben, und glücklicherweise machen die Erwartungen der Benutzer an Schaltflächen und Links dies einfach. Die fortgesetzte Verwendung von Links für Befehle (und Schaltflächen für die Navigation) untergräbt diese Erwartungen, und bald werden wir diese Gelegenheit verlieren.

Durch die grafische Unterscheidung von Navigation und Befehlen können wir leistungsstark mit unseren Benutzern kommunizieren. Wenn es sich bei "Kontakt" beispielsweise um einen Link handelt, wird eine Liste mit Adressen und Telefonnummern angezeigt (ich würde ihn eher als "Kontakt" als als "Kontakt" bezeichnen, da "Kontakt" eine so übliche Konvention ist, dass Benutzer scannen dafür speziell in Menüs). Wenn "Kontakt" eine Schaltfläche ist, werden Benutzer zu einem Formular weitergeleitet, in dem sie direkt Fragen oder Kommentare senden können (die Schaltflächenbeschriftung sollte eine Ellipse enthalten, um anzuzeigen, dass für den Befehl weitere Informationen erforderlich sind).

Ich bin damit einverstanden, dass Befehlsschaltflächen in der Regel größer und hässlicher als Links sind, insbesondere wenn sich viele davon im selben Fenster befinden müssen. Dies ist typisch für Web-Apps, denen eine Benutzeroberfläche für Objektauswahlaktionen oder Pulldown-Befehlsmenüs fehlen . Die Lösung besteht jedoch darin, eine leichtgewichtige Version der entsprechenden Steuerelemente zu entwickeln und kein anderes Steuerelement mit völlig anderen Benutzererwartungen zu rekrutieren. Solche leichtgewichtigen Steuerelemente können technisch gesehen Verknüpfungen sein, sollten jedoch wie das Steuerelement aussehen, das sie imitieren. Eine leichte „Schaltfläche“ kann beispielsweise ein verknüpftes Bild eines kleinen schattierten Rechtecks ​​mit einer mittig ausgerichteten Beschriftung sein.

Es gibt eine Grauzone in der Navigation/Befehlsunterscheidung, die wir aussortieren sollten. Ich empfehle Folgendes, bis die entsprechenden Untersuchungen durchgeführt werden können:

Verwenden Sie Links für:

  • Laden einer Inhaltsseite

  • Dynamisch generierten Inhalt laden.

  • Laden von Inhalten in einen Teil einer Seite, wenn keine andere Option haltbar ist (z. B. eine Registerkarte).

  • Navigieren zwischen den Seiten eines Assistenten (im Gegensatz zu herkömmlichen Desktop-Assistenten, die Schaltflächen verwenden).

Verwenden Sie Befehlsschaltflächen für:

  • Aktionen, die den zugrunde liegenden Inhalt oder die Datenobjekte ändern oder anwenden.

  • Aktionen, die sich auf die Ansicht des Inhalts auswirken, wenn keine andere Option haltbar ist.

  • Ausführung der Befehle eines Dialogfelds, einschließlich der Aktion "Fertig stellen" eines Assistenten.

  • Durch das Abbrechen eines Dialogfelds unter der Annahme, dass das Abbrechen die Dialogfeldparameter auf die Standardwerte oder vorherigen Werte zurücksetzt.

Verwenden Sie eine Befehlsschaltfläche mit einer Ellipse am Ende der Beschriftung, um auf einen Dialog zuzugreifen.

Noch mehr Details, wenn Sie es glauben können, unter http://www.zuschlogin.com/?p=18 .

17

Wenn es wie ein Link aussieht, erwarte ich im Allgemeinen, dass eine neue Inhaltsseite von einer anderen URL geladen wird. Manchmal ändert sich mein Fokus innerhalb des aktuellen Dokuments (d. H. Href = "# fragment"), was kein allzu großes Problem darstellt, solange es offensichtlich ist.

Wenn es wie eine Standardschaltfläche aussieht (d. H. Wie die Standardschaltfläche meines Betriebssystems), erwarte ich, dass es den gleichen Effekt hat, aber mit dem Nebeneffekt, dass einige von mir eingegebene Informationen die resultierende Seite beeinflussen.

Jedes andere, wesentlich andere Verhalten sollte meiner Meinung nach hauptsächlich durch Styling signalisiert werden. Das ist die puristische Sichtweise. Aus pragmatischer Sicht könnte argumentiert werden, dass sich ein Teil der Seite in irgendeiner Weise ändert, wenn ein Benutzer auf etwas klickt, das wie ein Link aussieht, und nicht zu einer anderen URL navigiert (der Link "Kommentar hinzufügen" auf Diese Seite ist ein gutes Beispiel), der Benutzer wird dadurch viel "verlieren".

Beachten Sie, dass diese Site sehr viele verschiedene Linkstile/-verhalten aufweist (ich zähle mindestens 8), aber das ist weniger ein Problem, da das Hauptpublikum wahrscheinlich sehr web-versiert ist.

3
Bobby Jack

Das Web ist mehr als eine Sammlung statischer HTML-Seiten, auf denen Hyperlinks ausschließlich zum Navigieren in den Dokumenten verwendet werden. Ich denke nicht, dass es schlecht ist, Hyperlinks zum Ausführen von Befehlen zu verwenden. Wenn wir Schaltflächen für alles verwenden würden, was angeklickt werden kann und was keine Navigation ist, würden Webanwendungen hässlich und sehr beschäftigt aussehen.

1
Tommy Carlier

Eine sehr wichtige Sache, die bei den Unterschieden zwischen Links und Schaltflächen zu beachten ist, ist, dass Crawler (sowohl für Suchwebsites wie Google als auch für viele Suchmaschinen auf Websiteebene) nicht zum Ziel einer Schaltfläche gelangen. Sie folgen nur Links.

1
Charles Boyung