Designfrage - Logik en/disabled Steuerelemente

Hallo "Kollegen",

aktuell (eigentlich schon länger) treibt mich eine Frage um. Wie gehe ich mit der (funktionellen) Anzeige von Steuerelementen bei GUI-Anwendungen um.

In der Vergangenheit habe ich hier immer die Logik mit eingebaut, soll heißen, dass z.B. Buttons, Checkboxen ect. nur dann enabled (oder auch als ganzes angezeigt) werden, wenn das auch erlaubt ist. Zum Beispiel muss Benutzer in einer bestimmten Combox den 3. Eintrag auswählen, dann wird eine Checkbox angezeigt, die checked (vorbelegt) ist und es werden andere Steuerelemente disabled ... usw. Das Problem ist, wenn man so vorgeht und eine sehr komplexe Logik in den Steuerelementen hat, dass nach Anpassungen sich die ganze Logik nicht mehr so verhällt, wie eigentlich gewünscht, bzw. man Fehler immer sehr spät (wenn überhaupt) findet, weil sehr komplex und manche Fälle sehr selten auftreten. Dann ist z.B. ein Steuerelement aktiv, das disabled sein sollte usw.

Eigentlich kann das imo nur das totale Chaos werden. Jetzt tendiere ich in die Richtung, dass sofort alles mögliche angezeigt wird, und dem User halt dann die demensprechnenden Fehlermeldungen angezeigt werden, z.B. "Kann nicht gespeichert werden, weil ... bla" ....

Wie geht ihr mit dieser Problematik um? Vielleicht ist ja auch der Mittelweg (teilweise deakitivieren, bzw. Nichtanzeigen) von Controls der Königsweg.

Grüße und schon mal vielen Danke für euere Antworten im Voraus.

Hallo mosspower,

hier mal ohne Anspruch auf Vollständigkeit ein paar Gedanken dazu:

Vom Grundsatz ist es schon anzustreben, dass der Benutzer keine oder möglichst wenig Fehleingaben machen kann. Das ist aber nicht immer durchzuhalten und an manchen Stellen auch schlicht ungünstig oder unpraktikabel.

Zwei dieser Fälle habe ich in [FAQ] In einer TextBox nur bestimmte Zeichen/Eingaben zulassen beschrieben:

Es gibt übrigens ein Problem bei der ersten Variante [verhindern, dass der Benutzer überhaupt etwas falsches eingeben kann], dass meist übersehen wird. Der Benutzer hat - außer über die (oft nicht vorhandene) Online-Hilfe oder das (ebenfalls nicht selbstverständliche) Handbuch - keine Chance herauszufinden, warum er etwas bestimmtes nicht eingeben kann. Es piept halt bestenfalls nur blöd.

Bei alle dem sollte man auch noch berücksichtigen, dass während der Eingabe und besonders beim Editieren eines am Ende gültigen Werts oft ungültige Zwischenzustände entstehen können. Wenn man erzwingen will, dass zu jedem Zeitpunkt in der TextBox ein gültiger Wert ist, dann kann dadurch die Eingabe bzw. das Editieren sehr erschwert oder im Extremfall gar verhindert werden.

Ein weiterer Punkt wäre, dass man auf ein ausgerautes Feld keinen Fokus setzen, um dann mit F1 Hilfe zu bekommen, um z.B. zu erfahren, warum das Feld ausgegraut ist. Dafür gibt es jedoch manchen Anwendungen das Fragezeichen-Icon im Titel. Wenn man drauf klickt, wird der Cursor zum Fragezeichen und man kann auch auf ein ausgegrautes Feld klicken, um Hilfe zu bekommen.

Klingt als nicht danach als ob man einen Königsweg hätte, sondern es immer darauf ankommt. Es gibt also noch mehr als die von dir genannten Gründe, warum es ungünstig sein kann zu versuchen, Fehleingaben komplett zu verhindern. Auf der anderen Seite sind MessageBoxen mit Fehlermeldungen ganz übel. Man sollte andere Wege benutzen, um Meldungen anzuzeigen, z.B. die Statusleiste oder ErrorProvider.

Außerdem sollten Meldungen immer positiv formuliert sein. Also keine _Fehler_meldungen, die dem Benutzer unter die Nase reiben, was er (schon wieder) falsch gemacht hat, sondern Hinweismeldungen, die die ihm mitteilen, was er abändern muss oder wie er es machen muss, damit es funktioniert.

Es ist richtig, dass ein GUI möglichst wenig Logik enthalten soll. Aber natürlich trotzdem zu viel nötig. Gut ist es, wenn man z.B. Prüfungen in der Modell-Klasse durchführt, aber diese Prüfungen auch im GUI benutzen/aufrufen kann. Siehe dazu z.B. [Artikel] Attribute zur Prüfung von Properties verwenden.

GUIs lassen sich in der Tat schlechter testen als anderer (z.B. Business-)Code. Aber auch für den GUI-Test, gibt es entsprechende Tools zur Unterstützung.

herbivore

Hallo herbivore,

das Problem bei einem sog. Mittelweg ist, dass dann jeder für sich selber argumentieren kann und jeder nach seinem Geschmack "drauf los coded" ... und unter dem Stricht schaut es dann applikationsweit so aus, dass es auf den verschiedenen Seiten (oder Controls) von 20 bis 80 Prozent variiert zwischen sofortiger, enableter Anzeige aller Steuerelemente oder disableten, bzw. keiner Anzeige dieser Elemente. Das ist ein sehr bitterer Beigeschmack.

Du hast absolut Recht mit den Fehlermeldungsboxen. Diese habe ich schon immer gehasst und deshalb benutze ich jetzt immer ein Console Control. Ich benutze das als eine Art Kommunikationsschnittstelle mit dem Benutzer - je mehr Infos, desto besser (aber nicht damit "erschlagen"). Auserdem spart sich der Benutzer immer nach einer Meldung ein Buttonklick, denn er muss kein Fenster wegklicken, was total nervig sein kann.

Wie gesagt, ich tendiere gerade zum vollen Gegenteil von früher (hier immer die totale Logik eingebaut). Wer kennt denn das nicht, da sind auf einer Seite zig Steuercontrols abgebildet, die meißten deaktiviert und man kommt nicht weiter und alle "Herrgotssekunden", nach einer Aktion, poppt ein häßliches Fenster auf mit teilweise nichtssagenden Meldungen - das kennen wir doch alle, oder?

P.S. Deine zusätzlich hinzugefügten Punkte bestätigen mir persönlich, dass ich mit meinem "Umdenken" eher doch auf dem richtigen Wege bin 😉 - wie gesagt, einer "Zwitterlösung" stehe ich eher abgeneigt entgegen.

Hallo mosspower,

eine Lösung, bei der man weder das eine noch das andere Extrem verfolgt, muss ja nicht undefiniert sein. Mal ganz davon abgesehen, dass das eine Extrem - völlige Vermeidung von Fehleingaben - prinzipiell nicht geben kann. Aber deshalb nun in das andere Extrem zu verfallen, halte ich für ungünstig. Ich wäre als Benutzer wirklich genervt, wenn ich auf einen Button zum Auswählen einer Datei klicke, mich durch die ganzen Verzeichnisse hangle, eine Datei auswähle, OK drücke und mir dann gesagt wird, dass ich - z.B. weil CheckBox xyz nicht angehakt ist - gerade gar keine Datei wählen darf, statt dass der Button disabled ist. Ich kann dir also diesen Weg nicht empfehlen. Du solltest einen Mittelweg definieren(!) und diesen dann im Team über feste(!) Regeln (wann wird disabled und wann wird nachträglich geprüft) kommunizieren.

herbivore