About

This page contains a single entry from the blog posted on May 7, 2009 2:20 PM.

The previous post in this blog was Petition gegen Stoppschilder im Internet.

The next post in this blog is Neue USV.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31

« Petition gegen Stoppschilder im Internet | Main | Neue USV »

Buttons oder Links?

vs. Delete

Wenn wir alle vorgeben, das Prinzip von REST verstanden zu haben, warum taucht dann immer wieder die Frage auf, warum (besonders zu Zeiten von Javascript, Ajax und Web 2.0) Links als Verweise auf Aktionen ("lösche Blogeintrag", "sende Formular ab"...) so schlimm seien.

Dabei ist es doch nur eine Hilfe für den Benutzer UND den Entwickler:

  • Links kann man (noch!) ohne Gefahr zu laufen, unerwünschte Nebeneffekte zu erzeugen, folgen. In REST-Sprech: Links verweisen auf Repräsentationen von Ressourcen.
  • Buttons verweisen auf Aktionen, die per definitionem (?) Nebeneffekte aufweisen. In REST-Sprech: Ihre Betätigung leitet Veränderungen an Ressourcen ein.

Will ich einem Benutzer also zeigen, was er sich alles ansehen kann, so biete ich ihm eine Liste von Links an. Will ich ihm hingegen die Möglichkeiten zur Veränderung der dargestellten Ressource(n) anbieten, so biete ich ihm eine Sammlung an Buttons.

Dieses Prinzip konsequent angewendet nimmt dem Entwickler m.E. sowohl im UI-Design als auch bei der Umsetzung einer RESTful Webanwendung (Denk-)Arbeit ab. Dem Benutzer der Anwendung macht es die Interpretation der UI ebenfalls erheblich leichter.

Was die Implementierung selber angeht, also ob Buttons nun Formulare abschicken oder ob die Aktionen via JavaScript eingeleitet werden, ist bei dieser Betrachtung erst einmal unerheblich. Ersteres ist der Accessibility von Webanweniungen natürlich bedeutend zuträglicher, zweiteres ist für "flashy" Web 2.0-Anwendungen wohl das Mittel der Wahl. Den Königsweg zu beschreiten und die Formulare per "unobtrusive Javascript" nach dem Laden der HTML-Seite zu verändern, um sie durch Ajax-getriebenes Verhalten zu ersetzen, ist aber auch kein bedeutender Mehraufwand (der sich aber auszahlt).

Leider wird o.g. Verhalten durch gewisse Standardmethoden in Ruby on Rails nicht unbedingt gefördert: link_to_remote setzt per default einen POST-Request ab, link_to_function existiert und button_to_remote existiert erst seit Rails 2.0 oder 2.1.

Sieht das jemand anders? Was sind dafür die Gründe? Diskussionsbeiträge sind willkommen!

Anmerkungen zu Michaels Kommentar (Danke dafür!): Ich gebe dier zu 100% recht, dass einen die richtige technische Lösung nicht davon entbindet, das Interface-Design derart zu gestalten, dass der Benutzer klar sieht wo er ohne Nachzudenken hinklicken darf und wo Vorsicht angebracht ist. Jedoch führt meines Erachtens die o.g. Regel, konsequent umgesetzt, automatisch zu besserem Interfacedesign: einfach nur deswegen, weil man eine einfache Regel umsetzt, an die sich der Benutzer gewöhnen kann. Siehe dazu auch die immer wieder geführte Diskussion, ob in einem Dialog der mit einem [OK] und einem [Abbrechen]-Button [OK] links oder rechts von [Abbrechen] angebracht werden sollte: es spielt keine Rolle, Hauptsache man wendet ein einziges Schema konsequent an.

Ich behaupte jedenfalls, dass es keinem Entwickler weh tut, konsequent Buttons für Aktionen und Links für "Ansichten" zu verwenden. Spätestens seit CSS 2.0 lassen sich beide ohnehin beliebig stylen. Und dann gibt's ja noch die Textbrowser... (nein, die sind beileibe nicht tot ;-))

TrackBack

TrackBack URL for this entry:
http://www.innoq.com/movabletype/mt-tb.cgi/3089

Comments (1)

Also ich sehe das sicher nicht anders :-)

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)