.NET GUI

prog1:

Nebenbei macht es keinen Unterschied ob ich mit der linken Maus etwas auswähle und dann einen Koopf drücke, oder rechte Maus auf ein Objekt und dann im Kontextmenü auswähle. Beides sind zwei Klicks.

 

Es macht einen gewaltigen Unterschied ob ich das Menü mit den entsprechend Funktionen dann ausgelöst durch den Rechtsklick direkt an der Position vorfinde, an der ich mich befinde, und an der ich selbst eine Aktion erzeugt habe, oder ob ich mich danach erst wieder in der gesamten Oberfläche neu orientieren muss, um den Anschluss, d.h. die Buttons, zu finden.

Das ist 1000x benutzerunfreundlicher als die Verwendung eines Kontextmenüs.

Norbert Eder:

Unterschiedliche Funktionen für linke und rechte Maustaste haben sich in der Software-Industrie, als auch bei Benutzern etabliert. Würde man dem Benutzer von Windows-Systemen also nur mehr Mäuse mit einem einzigen Button zur Verfügung stellen, dann hätten wir wieder die Mac-Situation, wo eben dieses Verhalten sehr oft bemägelt wurde. So gesehen ein Katze-Schwanz-Problem.

Klar am 2 Tastensystem möchte ich auch garnicht rütteln. Ist halt wirklich nur eine These. Dass sich ein solches Menü in Businessanwendungen nötig ist oder sogar Anforderung, habe ich auch gar kein Problem damit.

Was aber auf alle Fälle vermieden werden sollte, ist die Überladung eines solchen. Man muss natürlich auch den Kosten-Nutzen-Faktor sehen. Wann benötige ich etwas wirklich oder in wie weit reicht das vorhandene.

Das ist genau das, was ich auch gemeint habe: Das Kontextmenü muss  das beinhalten, was zum aktuellen Zeitpunkt im aktuellen Kontext tatsächlich benötigt wird. Nicht mehr und nicht weniger.

Da mus sich der Softwarehersteller Gedanken darüber machen und eventuell den Usability Guide von Microsoft lesen. Die haben das schon recht gut raus.

 Und selbst Apple hat ja inzwischen kapiert, dass eine Rechte Maustaste durchaus nützlich sein kann ;-)

Sehr interessante Diskussion. Da misch ich mich doch glatt mal ein. :-)

Also ich bin auch kein großer Freund von Kontextmenüs. Wenn ich es so recht überlege, fällt mir kein Kontextmenüpunkt ein, den ich regelmäßig benutze.

Das kann aber daran liegen, dass ich als Programmierer eben ein versierter "Computerbediener" bin, der die benötigten Funktionen über Tastaturkürzel erreicht. Deshalb sollte wir uns zuerst darüber einig sein, dass wir einen Computer bzw. die Programme wahrscheinlich anders bedienen als unsere Kunden. Die Einschätzung und Bewertung von Usability-Angelegenheiten wie diese hier sollte also in letzter Instanz von den entsprechenden UI-Experten durchgeführt werden. Und: Die meisten Programmierer sind keine UI-Experten!

Nachdem das geklärt ist, möchte ich trotzdem meine eigene Programmierersicht zum Besten geben. :)
Das Kontextmenü in seiner gewohnten Form ist für meine Begriffe auf dem Rückzug. Norbert erwähnt zum Beispiel die Neuerungen in Office 2007 in diesem Bereich. Das könnte man ja auch als Eingeständnis werten, dass das Kontextmenü, wie wir es kannten, ausgedient hat. ;)
Interessant, dass ein TreeView ein beliebtes Beispiel für die Verwendung von Kontextmenüs darstellt. Dafür, dass diese beiden eine prominente Kombo sind, habe ich eine eigene Vermutung. Während vermutlich viele anderer Meinung sind, halte ich das TreeView-Control mittlerweile für ein veraltetes und ausgedientes Control. Die Verwendung des Kontextmenüs soll diesen Umstand kaschieren! Das ist meine These, die auch gleich noch das TV-Control mit ins Gemetzel zieht. :) (Zum TreeView können wir ja gerne ein gesonderten Thread eröffnen *g*)

Ich halte das Kontextmenü für Funktionen angebracht, die zwar kontextsensitiv aber zugleich auch anwendungsneutral sind. Beispiele dafür sind die Funktionen "Kopieren", "Einfügen" usw. Ich bin mir nicht sicher, ob programmspezifische Funktionen gut in Kontextmenüs aufgehoben sind. Aber wie gesagt, ich bin Programmierer - kein UI-Experte. Hier bin ich leicht zu bekehren. ;)

Jetzt ist mir doch noch eingefallen, welche Rechte-Maustasten-Funktionen ich öfter verwende:

• im Webbrowser "Copy Link Location" im Kontextmenü eines Weblinks
• im Visual Studio "Close all but this" im Kontextmenü eines Editor-Tabs

Ciao,
Jens

FantaMango77:

Und: Die meisten Programmierer sind keine UI-Experten!

Und wir sind hoffentlich alles Entwickler und keine Programmierer ;-)

FantaMango77:

Das Kontextmenü in seiner gewohnten Form ist für meine Begriffe auf dem Rückzug. Norbert erwähnt zum Beispiel die Neuerungen in Office 2007 in diesem Bereich. Das könnte man ja auch als Eingeständnis werten, dass das Kontextmenü, wie wir es kannten, ausgedient hat. ;)

DAS hab ich SO nicht gesagt. Wenn man sich das was ich angesprochen habe genauer anssieht, dann sind das alles keine Dinge, die etwas in einem Kontextmenü zu suchen haben. Daher ist es lediglich eine Erweiterung der Usability und kein Ersatz zum Kontextmenü. Dieses hat natürlich weiterhin seine Bereichtigung.

FantaMango77:

Interessant, dass ein TreeView ein beliebtes Beispiel für die Verwendung von Kontextmenüs darstellt. Dafür, dass diese beiden eine prominente Kombo sind, habe ich eine eigene Vermutung. Während vermutlich viele anderer Meinung sind, halte ich das TreeView-Control mittlerweile für ein veraltetes und ausgedientes Control. Die Verwendung des Kontextmenüs soll diesen Umstand kaschieren! Das ist meine These, die auch gleich noch das TV-Control mit ins Gemetzel zieht. :) (Zum TreeView können wir ja gerne ein gesonderten Thread eröffnen *g*)

Wie würdest du hierarchisch Daten darstellen?

FantaMango77:

Ich halte das Kontextmenü für Funktionen angebracht, die zwar kontextsensitiv aber zugleich auch anwendungsneutral sind. Beispiele dafür sind die Funktionen "Kopieren", "Einfügen" usw. Ich bin mir nicht sicher, ob programmspezifische Funktionen gut in Kontextmenüs aufgehoben sind. Aber wie gesagt, ich bin Programmierer - kein UI-Experte. Hier bin ich leicht zu bekehren. ;)

Alle diese Funktionen sind programmspezifisch, wenn gleich sie zum Standard geworden sind (Kopieren, Einfügen etc.). Wie gesagt, ein überladenes Kontextmenü ist sinnfrei. Übersichtlich und beschränkt auf die häufigsten Tasks im jeweiligen Kontext.

Norbert Eder:

FantaMango77:

Und: Die meisten Programmierer sind keine UI-Experten!

Und wir sind hoffentlich alles Entwickler und keine Programmierer ;-)

Lustigerweise hatte ich mich bei meiner Aussage gewusst gegen den Begriff "Entwickler" entschlossen. :-D

Norbert Eder:

FantaMango77:

Das Kontextmenü in seiner gewohnten Form ist für meine Begriffe auf dem Rückzug. Norbert erwähnt zum Beispiel die Neuerungen in Office 2007 in diesem Bereich. Das könnte man ja auch als Eingeständnis werten, dass das Kontextmenü, wie wir es kannten, ausgedient hat. ;)

DAS hab ich SO nicht gesagt.

Ja, du hattest nur Office 2007 erwähnt. Mehr hatte ich nicht gemeint. Ich wollte dir keine Worte in den Mund legen. Tut mir leid, wenn das falsch rübergekommen ist.

Norbert Eder:

Wie würdest du hierarchisch Daten darstellen?

Vermutlich mit einem TreeView. ;) Aus der Diskussion ist aber nicht genau herauslesen, dass es um die Darstellung hierarchischer Daten geht.
Oft wird ein TV z.B. als Navigationshilfe benutzt. Ganz klassisches Beispiel für solch einen "Missbrauch" ist die Verwendung in einem Optionendialog (bspw. im Visual Studio). Fragt nicht wie ich es anders machen würde. Ich weiß es nicht. ;)
Interessanterweise hat sich diese Form des Optionendialog nach und nach durchgesetzt. Aber ich glaube, nur deshalb weil das Einbauen so einfach ist, und nicht weil es für die Aufgabe so geeignet ist.

Ich wollte darauf hinweisen wollte, dass sich jeder die Frage nach dem geeigneten Control stellen sollte, bevor er reflexartig zum TV greift. Das gleiche gilt bei der Verwendung von Kontextmenüpunkten. ;)


Ciao,
Jens

FantaMango77:

Oft wird ein TV z.B. als Navigationshilfe benutzt. Ganz klassisches Beispiel für solch einen "Missbrauch" ist die Verwendung in einem Optionendialog (bspw. im Visual Studio). Fragt nicht wie ich es anders machen würde. Ich weiß es nicht. ;)
Interessanterweise hat sich diese Form des Optionendialog nach und nach durchgesetzt. Aber ich glaube, nur deshalb weil das Einbauen so einfach ist, und nicht weil es für die Aufgabe so geeignet ist.

Was ja durchaus auch Sinn macht: Die einzelnen Optionen sind dem Kontext entsprechend angeordnet. Und daraus ergibt sich nun mal eine Baumstruktur. Das hilft sich zu orientieren. Ergo - aus meiner Sicht - äußerst passend das so zu lösen.

Thomas Bandt:

Und selbst Apple hat ja inzwischen kapiert, dass eine Rechte Maustaste durchaus nützlich sein kann ;-)

Interessant ist hierbei, dass die Entscheidung der 1 Tastenmaus von Steve Jobs (mehr Entwickler?) kam, der sich gegen die Lösung des damaligen Usability-Experten Jef Raskin durchgesetzt hat. Raskin wollte eine 2 Tastenmaus mit BESCHRIFTUNG auf jeder Taste.

Soviel zu Aussage:

FantaMango77:

Die meisten Programmierer sind keine UI-Experten!

FantaMango77:

Während vermutlich viele anderer Meinung sind, halte ich das TreeView-Control mittlerweile für ein veraltetes und ausgedientes Control.

Also ich habe da schon einmal die gleiche Meinung. Wie ich schon am Beispiel zu docs.google.com gemient habe:

prog1:

würde vielleicht eine komplette Liste aller Docs reichen.

Ich kann ja dann in der Suche entsprechen Filtern. Am besten natürlich nach vergebenen Labels, Stichworten und Dateiformaten.

Naja, da hast du aber immer noch keine Möglichkeit, des Schnellzugriffs. Also noch nichts gewonnen. Vielmehr musst du dich beim Hover damit auseinandersetzen was du machst, wenn 1000 Unterelemente vorhanden sind. Denn wenn du immer nur die ersten n Elemente anzeigst, wirst du den Benutzer damit nicht befriedigen können. Der will das dann flexibler, oder er will es gar nicht :)

Dein Rechtsklick verhält sich dann auch anders als es der Benutzer erwartet. Der erwartet sich ebenein Kontextmenü und nicht, dass dann gleich etwas passiert ...

Norbert Eder:

Vielmehr musst du dich beim Hover damit auseinandersetzen was du machst, wenn 1000 Unterelemente vorhanden sind.

Das Problem gibt es doch im TreeView auch, oder? Wenn ich dort viele Unterelement habe muss ich zumindest scrollen oder ähnliches.

Norbert Eder:

Dein Rechtsklick verhält sich dann auch anders als es der Benutzer erwartet.

Ja, das ist klar. Aber wenn das ein- zwei- mal passiert sollte sich der Benuzter daran gewöhnt haben. Es wäre ja nicht so, dass das Verhalten nicht nachvollzogen werden kann. Das Kontextmenü würde eben einer anderen Funktionalität weichen.

prog1:

Aber wenn das ein- zwei- mal passiert sollte sich der Benuzter daran gewöhnt haben. Es wäre ja nicht so, dass das Verhalten nicht nachvollzogen werden kann. Das Kontextmenü würde eben einer anderen Funktionalität weichen.

Ja, für die eine Anwendung schon. Aber eine andere Anwendung macht das wieder anders, eine dritte macht es wieder anders, usw. Wie soll sich das ein User jemals merken? Und genau daher gibt es Standards ...

Norbert Eder:

Wie soll sich das ein User jemals merken? Und genau daher gibt es Standards ...

Wenn dr Benutzer aber Haupsächlich mit dieser Anwendung arbeitet und ich ihm die Arbeit erleichtern kann, sollte ich das tun. Klar gibt es Standards, aber diese müssen nicht die optimale Lösung sein. Hätte Apple damals den IPod so gestaltet wie es der Standard bei MP3 Player ist, dann gäbe es Apple wohl nicht mehr...

Klar musste man sich an die Bedienung gewöhnen, aber es wurde auch klar, dass man den einen MP3 Player besser über ein Rädchen bedient als nur über Tasten. Solche Dinge sollte man auch auf die Usability anwenden, auch wenn es hier Standards gibt.

Hallo zusammen,

diese Diskussion ist zwar schon ein wenig älter (und ich hoffe, ich mache mich nicht unbeliebt, wenn ich sie wieder "aufwecke" ), aber dennoch sehr interessant, wie ich finde.

Ein Aspekt fehlt mir allerdings noch:
Das Kontextmenü sollte weniger der einzige Ort sein, um wirkliche Aufgaben erfüllen (z.B. "Datei löschen", etc.), sondern vielmehr die Interaktion mit dem jeweiligen Controltyp fördern.
Das mag jetzt vielleicht eigenwillig klingen, aber was ich damit meine: Wenn ich als Benutzer eine Textbox anklicke, möchte ich immer Befehle wie "Alles markieren", "Kopieren", etc. zu sehen bekommen. Also Aktionen, die für alle Textboxen gelten.

Ähnlich verhält es sich mit Links: Mit entsprechenden Addons bietet der Firefox eine Option "In neuem Tab im Hintergrund öffnen", die ich sehr häufig verwenden. Wenn ich in Silverlight- / Flashanwendungen auf einen Link rechtsklicke passiert gar nichts. Das ist für mich als User dann nicht innutiv; ich bin ja gewöhnt, dass ich alle Links durch Rechtsklick (und Auswahl eines bestimmten Items) in einem neuen Tab im Hintergrund öffnen kann.

Was ich also sagen will: Das Kontextmenü wegzulassen, wäre IMHO grob fahrlässig.
Es sollte nur keine Interaktion mit der Anwendung verbergen, sondern Interaktion mit den Controls ermöglichen. Und das immer auf dieselbe Art und Weise.

Wir als Entwickler sollten meiner Meinung nach "die Finger vom Kontextmenü" lassen und es dem OS bzw. dem Browser überlassen. Außer, wie designen ein vollständig neues Control.

Kein Problem. Ist doch gut, wenn es hier wieder weiter geht :)