Modale MessageDialoge in der Anwendung - wann?

Hallo Forum

Ich habe eine Frage eher konzeptioneller Art. Hier in der MSDN wird eigentlich schön die Art von "Messages" beschrieben, weiter gibt es dann auch gute Beispiel wann welcher Dialog und warum verwendet werden soll.

Das hilft mir aber bei der simplen Frage nicht weiter: Ist eine Eingabe eines falschen Passwortes beim Anmelden eines Benutzers an der Anwendung ein Fehler?

Ich komme deshalb auf diese simple Frage, weil wir bisher für ein falsches Passwort denselben FehlerDialog anzeigen, wie bei einem unerwarteten Fehler. (Rotes Stopp Symbol, Fehlernachricht, Schliessen-Button) Nun haben wir den Fehlerdialog um eine Funktion erweitert, die es erlaubt, automatisch das Logfile vom Kunden an unseren Server zu übermitteln - ein zusätzlicher Link-Button wird angezeigt mit der entsprechenden Beschriftung. Nun wird also ab sofort auch bei einem falschen Login ein "gefährlich" aussehender Dialog mit Log-Versende Funktionalität angezeigt. Das wirkt jetzt irgendwie überkandidelt! (Zumal uns der Kunde sicher nicht das Log zuschicken muss, wenn er sich wegen eines falschen Passwortes nicht anmelden kann)

Aus dieser Tatsache heraus bekomme ich also die Meinung, dass ganz grundsätzlich der FehlerDialgo für ein falsches Login nicht die richtige Benachrichtigung ist. Aber in welche "Kategorie" gehört die Benachrichtigung? Warnung, Info... ? Denn ein Fehler aus Anwenungstechnischer Sicht ist es ja nicht!

Gibt es UI Spezialisten hier, die dazu eine Meinung haben und eine Aussage machen können?
Vielen Dank für Hinwese und Meinungen

PS: Ich weiss, es gibt weltbewegendere und schlimmere "Probleme", aber wir haben betreffend unserer Anwendung eine maximale "User-Experience" auf unsere Fahne geschrieben... dazu gehört für mich auch die korrekte Darstellung und Benachrichtigung von Messages.

Hallo kaepten,

viel wichtiger als die Wahl der richtigen Kategorie ist überhaupt von MessageBoxen wegzukommen. Siehe dazu Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] und [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen.

Ansonsten würde ich bei Fehleingaben des Benutzers immer versuchen, positiv zu formulieren, also z.B. "Bitte geben die das Passwort korrekt ein. Achten Sie dabei darauf, dass die Feststelltaste nicht versehentlich gedrückt wurde." Entsprechend wäre es dann eine Information.

Siehe auch Wie sollte man einen Fehler benennen? (den konkreten Beitrag und auch den gesamten Thread).

herbivore

aber wir haben betreffend unserer Anwendung eine maximale "User-Experience" auf unsere Fahne geschrieben... dazu gehört für mich auch die korrekte Darstellung und Benachrichtigung von Messages.

Ich sehe das anders als herbivore. Ich stimme ihm zu, dass modale Fenster _oft _nicht sinnvoll eingesetzt werden - doch es gibt durchaus auch heute und auch noch in der Zukunft sinnvolle Zwecke.
Die pauschale Aussage "modale Dialog sind doof" will ich mit Gewissheit nicht teilen.

Die Kunst ist nun das korrekt einzusetzen. Meiner Meinung nach kann das nur ein verschwindend geringer Teil aller Entwickler.
Damit man einen Oberflächen-Workflow umsetzen kann, mit dem die Anwender auch effizienter sind/werden, brauchst Du jemand, der das lebt. Das ist normalerweise nicht der Entwickler; der sieht das einfach aus anderen Augen.

Zusätzlich brauchst Du jemanden, der die Prozesse versteht und in eine UI umsetzen kann. Auch das kann meiner Meinung nach ein reiner Entwickler nicht.
Nicht umsonst gibt es die sogenannten UI-Artists, die Workflows verstehen, zusammen mit dem späteren Anwender entwickeln und auf moderne Art und Weise umsetzen. Das ist auch die Grundlage dessen, dass es eine Trennung zwischen Oberfläche und Code gibt.
Ist wie das Handwerk: nen Metzger ist auch kein Maurer.

Solltet ihr also eine dementsprechend große Anwendung haben, die auch innovativ, modern, effizient ist bzw. den Anspruch, dass sie es sein soll, dann kommt ihr meiner Meinung nach ohne einen (externen) UI-Artist nicht aus.
Hier mal kurz jemanden zu fragen, der zu einem speziellen Element was sagen soll; das ist meiner Ansicht nach nicht zielführend, da ja die ganze Anwendung harmonisieren muss.

Microsoft will übriges sich dahin entwickeln, dass "mehr" Designer als Entwickler im eigenen Hause tätig sind.

Hallo Abt,

doch es gibt durchaus auch heute und auch noch in der Zukunft sinnvolle Zwecke.

welche? Ich kenne bzw. sehe keine Zweck, der eine MessageBox sinnvoll erscheinen lässt - außer der Bequemlichkeit des Programmierers zum Nachteil des Benutzers. Aus meiner Sicht gibt es immer bessere Lösungen als MessageBoxen.

herbivore

Wir reden nicht von Message-Boxen in Deinen Links, sondern von modalen Elementen -->

zB. sobald ein kritischer Zustand eintritt und ein Eingriff des Benutzers erzwungen werden muss.
Ob das Passwort nun dazu gehört und dort rein passt ist meiner Meinung nach nun die Aufgabe des UI Artists.

Es gibt durchaus Fälle, bei denen Anmeldemasken integriert sind, oder eben auch als modales Element.
Das kommt hier jetzt auf die Anwendung an; keine pauschale Antwort möglich.

Beispiel hier: Anmeldemaske, wenn man im Windows Explorer plötzlich auf eine Share zugreift, für den die Rechte fehlen.
Das ist ein kritischer Fehler und ohne diese weitere Information kann dieses Explorer Fenster nicht weiter arbeiten. Da hilft Dir also das Auslagern der Eingabe in ein eingebettes Elemtent auch nichts.

Anders sehe ich es zB beim Kopieren von Dateien. Das könnte meiner Ansicht nach auch gut in den Explorer integriert werden, ähnlich einem Download-Tab im Browser.

Um der Pauschale weiteren Boden zu entnehmen:
im Web wird es teilweise sogar wichtiger, mit modalen Elementen (DHTML) zu arbeiten* Tooltips

• Fancy Boxes
• Overlay Boxes
• Such-Boxen

Ich sehe es wie Abt.

Dialoge sind schon ziemlich beschränkend, aber wenn es in einer SW eine Situation gibt, in der es ohne die Bestätigung oder Eingabe keine andere Möglichkeit gibt dann setze ich Dialoge immer ein.

Auch ist es ja sicherlich schön das Du in den von Dir betreuten Unternehmen Leute hast die diese Art der Herangehensweise kennen, aber 90% der Anwender die ich kenne ( die SW nur gelegentlich benutzen ) verstehen nicht warum da kein Dialog kommt, wenn es wichtig wird.
Das dein Konzept nicht wirklich allen gefällt sieht man an der Ablehnung vieler ( die es meist nicht mal im täglichen Einsatz haben ) von Windows 8 und Metro Anwendungen.

Und das sich Dogmen in der SW Entwicklung schnell überholen müsstest du ja auch wissen.

Hallo ihr beiden,

im Titel und in meiner Aussage und meiner Nachfrage geht es nur um MessageBoxen. Da sehe ich es absolut. Ich bin zwar auch bei anderen modalen Dialogen der Meinung, dass man sie möglichst vermeiden sollte und dies auch fast immer kann - auf jeden Fall in weit mehr Fällen, als man auf Anhieb denkt - aber da würde ich vielleicht ein paar wenige Ausnahmen zugestehen. Darauf will ich hier aber nicht weiter eingehen, weil es im Thread (laut Titel und Startbeitrag) ja nur im MessageBoxen geht.

Und das sich Dogmen in der SW Entwicklung schnell überholen müsstest du ja auch wissen.

Genau das sage ich ja: Das Dogma, dass man MessageBoxen braucht, ist schon lange überholt. 😃

herbivore

EDIT: Ich habe nochmal darüber nachgedacht und ich sehe jetzt in keiner der genannten Situationen eine Notwendigkeit für modale Dialoge (im Sinne von Form.ShowDialog oder MessageBox.Show). Ich will wie gesagt hier nicht weiter darauf eingehen, weshalb ich Nenne deinen Fall, wo du denkst, ohne modalen Dialog geht es nicht und ich nenne eine Alternative erstellt habe.

Ein Vorteil von (modalen) Messageboxen kann auch genau der sein dass der User die Meldung bestätigen muss bevor er weitermachen kann. Mir selbst ging es schon so, es hat sich ein Fehler ergeben der sich heimlich und leise in einer Statusanzeige geäußert hat. Ich warte und warte - und dabei ist alles längst schon hinüber. Gleiches für OK-Meldungen. Manchmal passt sowas, manchmal nicht.

Gerade auch für Kollegen o.ä. die Empfehlungen als binäre Vorschrift sehen und nicht selbst über Hintergründe nachdenken möchten, finde ich es schon sinnvoll wenn Hintergründe zu Vorgehensweisen erklärt werden 😃

Zur Frage

Ist eine Eingabe eines falschen Passwortes beim Anmelden eines Benutzers an der Anwendung ein Fehler?

Es ist eine Fehlersituation. Wie man den anzeigt ist situationsbedingt. Man möchte im Fehlerfall die Anmeldung möglichst ohne viel Geklicke nochmal versuchen, je nach Anmeldedialog kann man ads auch ohne Messagebox erreichen. Hier besteht wenig Gefahr dass der Nutzer glaubt es wäre alles ok, sofern der Anmeldedialog dann immer noch spürbar und sichtbar ist.

Hallo chilic,

keiner hat behauptet, dass die Alternativen zu einer MessageBox unauffällig sein müssen oder auch nur sollen. Eine Fehlermeldung nur in der Statusleiste anzuzeigen, finde auch ich ungünstig. Das ist viel zu unauffällig. Aber es gibt ja wie gesagt bzw. wie verlinkt) bessere Alternativen.

Der große Nachteil, eine MessageBox zu bestätigen (bestätigen klingt erst mal gut), ist, dass sie dann weg ist. Insbesondere wenn in der MessageBox - wie es benutzerfreundlich ist - genaue Informationen enthalten sind, wie man den Fehler behebt, sind diese nach dem Wegklicken verschwunden. Und solange die MessageBox noch da ist, kann man wegen ihrer Modalität die Schritte zur Fehlerbehebung nicht durchführen.

herbivore

Besten Dank für die aufschlussreichen Antworten.

Am Ende geht es für mich auch wieder in die Richtung soll eine Exception geworfen werden oder nicht.

Das Anmelden des Benutzers am System mag ein Benutzerfehler sein/erzeugen = falsches Passwort. Ganz sicher darf es kein System-Fehler sein. Denn wenn ich eine Exception werfe bei nicht übereinstimmenden Login-Angaben, dann hab ich wohl den Sinn eines Login-Dialogs nicht verstanden. Denn der Login-Dialog hat zwei absolut nachvollziehbare Zustände: da kommst Du rein, da kommst Du nicht rein. Das hat nichts mit einem Anwendungsfehler zu tun. Meine Ansicht.

Hier aber fängt unser "Problem" ja an: es gibt Exceptions, die bubblen sich im System nach oben und sind wirkliche Fehler, die nirgends verarbeitet/abgefangen wurden - weil einfach niemand diesen Zustand erwartet und im Programmcode robust verarbeitet hat (robuster Code). Dann gibt es Exceptions, die aus jux und tollerei geworfen werden, ein falsches Login z.B. und dann kommt ein Fehlerdialog.

Am ende ist es mir ja wurscht, ob mein Kollege eine Exception wirft bei jedem kleinen Ding. Er darf nur nicht pauschal bei jeder Exception den Error-Dialog anzeigen und den Exception-Dump darstellen. Dann muss er Fallabhängig auch mal in einem Catch eine modale Warnungs-Box anzeigen: Passwort und Benutzername stimmen nicht überein.

Hallo,

ich würde das mit einer eigenen, für Falschanmeldung spezifischen Exception lösen (vllt von AuthenticationException ableiten). Der Logindialog filtert diese für seinen eigenen Hinweistext raus und läßt die anderen für die "globale Messagebox" -wie auch immer das gelöst ist- durch.

Hallo witte,

genau genommen sind falsche Anmeldedaten bei einem Anmeldedialog keine Ausnahme die als Exception zu werfen ist.

Schließlich gibt es bei der Anmeldung spezifische Zustände die ohne Exception ausgelöst werden können. Wir haben dafür einen Enum, der das Anmelderesultat repräsentiert.

Ich könnt mir Beispielsweise folgendes vorstellen:

public enum LoginResult
{
       Success,
       UnknownUserName,
       InvalidCredentials
}

...
private void Login(string sUserName, string sPassword)
{
       switch(this.AuthorizationProvider.Login(sUserName, sPassword))
       {
              case LoginResult.Success:
                     this.EnableControls();
                     break;
              case LoginResult.UnknownUserName:
                     MessageBox.Show("Unbekannter Benutzername.");
                     break;
              case LoginResult.InvalidCredentials:
                     MessageBox.Show("Die Kombination aus Benutzername und Passwort ist ungültig.");
                     break;
       }
}

Da gibt es keinen Grund eine Exception zu werfen.

Hallo

Der große Nachteil, eine MessageBox zu bestätigen (bestätigen klingt erst mal gut), ist, dass sie dann weg ist.

Das ist richtig und sicher in gewissen Fällen lästig.
Aber wir sollten feststellen und hinnehmen dass das oft eben keine Rolle spielt. Die Meldung "falsche Anmeldedaten" muss man eben nicht mehr lesen können wenn man sein Passwort neu eingibt. (warum es hier trotzdem nicht sein muss beschreibe ich unten)

Sorry ich weiß ich drehe den Kreis damit vielleicht wieder an. Eigentlich habe ich aber vor ihn zu beenden, indem man sich wirklich nur auf sinnvolle Fälle konzentriert und die anderen so stehen lassen darf wie sie sind.

Bei falscher Anmeldung hat eine Exception übrigens nichts zu suchen. Und wenn man schon einen kleinen und zentralen Anmeldedialog hat (hier leider auch wieder das Argument, währenddessen gibts nunmal nichts anderers zu tun) braucht man nicht noch eine MessageBox sondern kann die Meldung auffallend im Anmeldefenster anzeigen.
Dass der verschwindet erwartet der Nutzer. Wenn er es nicht tut wird er aufmerksam und sieht sich ihn genauer an.
Also eigentlich ein schönes Beispiel für keine Notwendigkeit einer MessageBox.

Vorab: Ich habe diesen Thread etwas spät entdeckt...

Hallo kaepten,

Kennst du irgendeine weltweit bekannte Anwendung die einen fehlgeschlagenen Logon(FxCop hat mir erklärt das es Logon heisst und nicht Login) mit einem modalen Fehlerdialog quitiert? All die grossen Softwarehersteller tun das schon seid Jahren nicht mehr und sie tun gut daran.

Der zweite Punkt den ich da rauslese hat mit UI aus meiner Sicht garnicht soviel zu tun.
Nämlich unterschiedlich geartete Fehler einfach durch die Standard Exception zu catchen und immer die gleiche Anzeige anzublenden. Das führt dann dazu das man zwischen erwarteten und unerwarteten Fehlern nicht mehr unterscheiden kann.

Ich löse das wie folgt:
Es gibt eine gemeinsame abstrakte Basisklasse MyApplicationException. Diese Exception meint einen erwarteten Fehler.(wie logon failed) Alle anderen Exceptions meiner Lösung erben von dieser Klasse. Meine try/catch Blöcke sehen dann immer wiefolgt aus:

try
{

}
catch(MyApplicationException exception)
{
    // erwartet
}
catch(Exception exception)
{
    // unerwartet
}

Für meine MyApplicationException Klasse und für die Standard Exception(unerwartet) gibt es dann immer 2 verschiedene Oberflächen.
Meine MyApplicationException geht dabei sogar soweit das sie Properties wie SupportsDetailed Log anbietet damit die zugehörige Oberfläche das bestmöglich darstellen kann.

Hallo zusammen,

da hier anscheinend so eine Art Abstimmung läuft, ob eine fehlgeschlagene Anmeldung eine Exception rechtfertigt, will ich auch meine Stimme abgeben. Aus meiner Sicht, sollte eine Methode, deren einziger Zweck es ist, die Anmeldung durchzuführen, bei einer fehlgeschlagenen Anmeldung keine Exception werfen. Diese Einschätzung basiert auf MSDN: Handling and Throwing Exceptions, insbesondere der Regel, dass man Exceptions nicht benutzen soll, um den normalen Programmfluss zu steuern. Wie einige meiner Vorredner schon gesagt haben, gibt es bei einer solchen Methode zwei von vornherein bekannte, gleichberechtigte Ausgänge: Der Benutzer kennt die Anmeldedaten und gibt sie korrekt ein oder eben nicht.

Anders sieht es aus, wenn eine Anmeldung nur ein kleiner Schritt in einer Methode ist, die eine ganze andere Aufgabe durchführen soll. Hier ist die Anmeldung (nur) erforderliches und möglicherweise gar nicht bei jeden Aufruf nötiges Mittel zum eigentlichen Zweck. Wenn der eigentliche Zweck nicht erreicht werden kann, weil eine Voraussetzung fehlt - welche auch immer - kann das durchaus ein Grund für eine Exception sein. So wie beim Versuch, eine Datei zu öffnen, für die die Zugriffsrechte fehlen, eine Exception geworfen wird.

herbivore

Hallo herbivore,

Vorab: Grundsätzlich natürlich richtig, Exceptions sind kein Mittel zur Programmsteuerung(obwohl ich einige Java Entwickler kenne die das anders sehen)
Ich will mich aber nur auf den Logon Fall beziehen.

Das problematische ist, das sich praktisch alle API's(auch die von Microsoft) eigentlich immer so verhalten das sie bei einem fehlerhaften Connect/Logon Versuch eine Exception auslösen. (Mehrheitlich benutzt man ja für Logon Scenarien eher eine API, da der Aufwand für einen sicheren Logon, inkl. verschlüsselte Übertragung der Logon Daten, etc. relativ hoch ist)

Wenn man dieses Verhalten nun einfangen möchte kommt so ein Konstrukt wie dieses dabei raus. (Soll mir keiner sagen das er sowas noch nie irgendwo gesehen oder vielleicht sogar selbst so gemacht hat, natürlich nicht unbedingt bezogen auf ein Logon Szenario)

internal bool Logon(string userName, byte[] userPass)
{
   try
   {
       _myPrivateLogonProvider.Logon(userName, userPass);
       return true;
   }
   catch
   {
       return false;
   }
}

Ich habe ja was gegen solche Konstrukte, letztlich ist es auch irgendwie nur eine Programmsteuerung durch Exceptions. Da fange ich die Exception im catch Block lieber ein und löse meine eigene LogonException aus(mit der origin Exception als InnerException)

Wie gesagt, das hier ist ein einfaches Logon Scenario, das heisst ein Logon muss funktionieren sonst gehts an der Stelle auf keinen Fall weiter. Es gibt genug andere Fälle wo die Situation sehr viel komplizierter ist. Ich selbst nutze dann am liebsten ein enum in der Rückgabe, bei API's die Exceptions auslösen muss ich dafür etwas mehr Aufwand treiben wenn ich den Vorgange einkapsen will. Einfaches Beispiel: Ich will in einem Connect Szenario für den MS SqlServer in der Methode zurückgeben ob der Server nicht erreichbar war oder der Connect wegen fehlender/falscher Credentials abgelehnt wurde. Dafür muss ich in meinem catch Block unterschiedliche Exception Typen adressieren um den jeweils richtigen Enum Wert zurückzugeben. Mir stinkt das selbst ganz gewaltig aber man muss der Realität halt irgendwie umgehen.

Hallo Sebastian.Lange,

wenn man eine fremde bestehende Login-Methode verwendet, würde ich mich auch danach richten, wie sie den Misserfolg meldet. Ich sehe da auch keinen Grund eine Exception auf einen passenden Rückgabewert umzubiegen. Was ich gesagt habe, bezog sich darauf, dass man die Login-Methode (von Grund auf) selber schreibt. Mag sein, dass das in der Praxis nur selten passiert.

herbivore