Laden...

Nenne deinen Fall, wo du denkst, ohne modalen Dialog geht es nicht, und ich nenne eine Alternative

Letzter Beitrag vor 9 Jahren 74 Posts 18.225 Views
Nenne deinen Fall, wo du denkst, ohne modalen Dialog geht es nicht, und ich nenne eine Alternative

Hallo zusammen,

aufgrund meines Nachdenkens in Modale MessageDialoge in der Anwendung - wann?, bin ich nun mehr der Meinung, dass es keinen Fall gibt, in dem modale Dialoge sinnvoll und notwendig sind. Ich bin im Gegenteil der Meinung, dass es immer eine bessere, benutzerfreundliche und gleichzeitig verständlichere Alternative gibt. Deshalb habe ich diesen Thread erstellt. Ich stelle mich der Herausforderung, dass vielleicht doch jemand einen Fall hat, für den ich keine gute Alternative finde. Andersherum möchte ich jedem, der wirklich an Alternativen interessiert ist, die Möglichkeit geben, sich von mir (und gerne auch von anderen Helfern) diese Alternativen aufzeigen zu lassen.

Da ich mich mit Web- und WPF-Anwendungen nicht so gut auskenne, beschränke ich die Anfragen auf Windows Forms, obwohl ich davon ausgehe, dass es auch für andere Anwendungsarten immer eine Alternative gibt. Fälle, die nicht Bezug auf die speziellen Möglichkeiten einer bestimmen Oberflächentechnologien nehmen, sind ebenfalls ok. [EDIT]Es geht hier also um normale Desktop-Anwendungen.[/EDIT]

In Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] habe ich bereits einige Gründe gegen modale Dialoge beschrieben und gleichzeitig für die gängige Fälle - insbesondere für MessageBoxen - Alternativen aufgezeigt. Und in [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen habe ich exemplarisch eine Alternative für einen "Vorm Schließen noch speichern?"-Dialog umgesetzt.

Doch nun zu den konkreten Fällen. Lucy von den Peanuts würde sagen "The Doctor is [span=white]in[/span]". 😃 Um zu demonstrieren, wie ich mir das vorstelle, wähle ich ein Beispiel von Abt, was aber auch jeder andere hätte einwerfen können:****

Den modalen "Verbinden mit ..."-Dialog, der im Windows Explorer erscheint, wenn man im Dateibaum auf eine Freigabe kickt, an der man noch nicht angemeldet ist. Wie könnte man das ohne modalen realisieren Dialog (besser) realisieren (z.B. wenn man einen eigenen Explorer programmiert)?
Zunächst sind wir uns einig, dass ein Zugriff auf die Freigabe nicht möglich sein soll, solange die Anmeldung noch nicht erfolgt ist. Das bedeutet aber nicht, dass ein modaler Dialog benötigt wird. Und es bedeutet nicht, dass es keine anderen Aktionen gibt, die man trotz der laufenden Anmeldung sinnvoll ausführen kann.

Es wäre praktischer und mindestens genauso verständlich, wenn die Eingabefelder und die Buttons für die Anmeldung an der Freigabe einfach dort eingeblendet werden, wo sonst die Dateiliste erscheint. Das stellt genauso gut sicher, dass man erst auf die Freigabe kommt, nachdem man sich dort angemeldet hat. Wenn man sich aber nur im Dateibaum verklickt hat, kann man ohne im Dialog "Abbrechen" klicken zu müssen, einfach auf das tatsächlich gewünschte Verzeichnis klicken. Ein modaler Dialog würde das direkte Weiterarbeiten verhindern.

****Habt ihr einen eigenen Fall eines (bisher) modalen Dialogs, zu dem ihr eine Alternative haben wollt? Dann immer her damit. Bitte möglichst immer nur einen Fall pro Beitrag. Und bitte möglichst einen neuen Fall erst, wenn der laufende abgeschlossen ist.

herbivore

PS: Nachdem nun schon einige Fälle behandelt wurden, prüfe bitte, ob für deinen Fall schon eine passende Alternative genannt wurde und es vielleicht gar nicht nötig ist, ihn (neu) zu posten. Vielen Dank!

Hi herbivore,

für die (Windows-)Dialoge zum Öffnen und Speichern von Dateien hab ich für die meisten Anwendungsfälle noch keine brauchbare Alternative gefunden. Dazu verwende ich nach wie vor modale Dialoge. Da es sich allerdings um Dialoge vom Betriebssystem handelt, bin ich mir nicht sicher, ob das mit deiner Frage auch gemeint ist.

Christian

Weeks of programming can save you hours of planning

Hallo MrSparkle,

ja, die Ausgangslage ist ungünstig. Die eigentliche Lösung, die ich aber leider nicht erzwingen kann, wäre, dass Microsoft eine Möglichkeit anbietet, dass man die Dialoge auch nicht-modal anzeigen kann. Für normale Fenster/Dialoge kann man sich ja auch entscheiden, ob man diese mit Form.ShowDialog modal oder - meiner Meinung nach besser - per Form.Show nicht-modal anzeigt.

Solange es diese Möglichkeit nicht gibt, kann man sich damit behelfen, dass man den Dialog aus einem separaten Thread öffnet. Man muss ein bisschen aufpassen, um keinen Bock zu schießen, aber das ist eine der wenigen Ausnahmen, bei der mehr als ein GUI-Thread angebracht wäre. Es ist zugegeben ein Workaround. Doch einer der gut funktionieren kann, wenn man alles richtig macht. Ich überlege mal, ob ich daraus ein Snippet oder eine Komponente mache.

herbivore

Hi herbivore,

den Dialog nicht-modal anzuzeigen, ist sicherlich kein besonders großes Problem. Aber ist das auch sinnvoll? Das würde ja bedeuten, daß der Benutzer nachdem er auf "Datei speichern..." geklickt hat, den Dialog in den Hintergrund bringen, und sein Dokument weiterbearbeiten kann. Wenn er den Dialog wieder in den Vordergrund bringt, ist beispielsweise nicht klar, welcher Stand des Dokuments dann gespeichert wird. Es könnte also dazu führen, daß der Benutzer verwirrt ist, und das sollte man meiner Meinung nach unbedingt verhindern.

Eine bessere Lösung wäre für mich, auf das Öffnen eines zusätzlichen Fensters nach Möglichkeit ganz zu verzichten.

Christian

Weeks of programming can save you hours of planning

Fangts doch einfacher an 😃 Einen Speicherndialog halte ich für einen der überzeugendsten um beruhigt modal zu bleiben. Oder eine Sicherheitsabfrage.
-> Bitte jetzt eine Entscheidung treffen. Wer doch was anderes tun will bricht das ab und öffnet es später wieder ohne dass Information verloren gehen.
Hier würd ich nicht nur um des Prinzips willen modal vermeiden und dann alles von Hand doch wieder auf modal trimmen.

Es gibt genügend Beispiele die einen schnell ersichtlichen Vorteil bringen. Beispiel Kontoführungsprogramm. Es hat eine Übersichtsliste der Kontobewegungen mit Löschfunktion usw.
Die Eingabe einer neuen Position erfolgte bisher über einen modales Fenster, da im Hauptdialog unübersichtlich.
Währenddessen soll in der Liste nichts geändert werden. Man will sie aber weiterhin readonly bedienen und durchsuchen können um Buchungsnummer / Text / Datum einer ähnlichen Kontobewegung zu suchen. Schließen der Eingabemaske würde evtl. einige Daten wieder verwerfen.

Die Lösung bestand aus dem disablen bestimmter Buttons und Eingriffen in weitere GUI Elemente. Dann kann die Erfassung einer neuen Position nichtmodal erfolgen. Automatisch ging hier nicht viel, es war den Aufwand aber wert. Es muss nur darauf geachtet werden dass das Fenster nicht minimiert wird oder in den Hintergrund gelangt.

Hallo chilic,

nein, gerade das sehr ich anders. Ich behaupte, es gibt nie einen Grund für einen modalen Dialog. Ich halte es für eine reine Illusion, dass man denkt, dass gerade nur das eine möglich ist und nichts andres. Mein Beispiel mit dem Windows Explorer oben zeigt genau das. Und was die Speicher-Dialoge angeht, habe ich in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] ebenfalls aufgezeigt, warum man zu diesem Zeitpunkt noch andere Aktionen durchführen will. Bei einem Abbrechen geht - zumindest bei den Standard-Dialogen - die Information verloren, bis zu welchem Verzeichnis sich der User durchgeklickt hatte. Es geht nicht ums Prinzip, sondern um die konkreten Nachteile, die ich genannt habe. Neben den genannten auch noch, dass man das hinter dem Dialog liegende Fenster nicht verschieben kann, solange der Dialog offen ist.

Natürlich stimme ich dir zu, dass es andere Beispiel gibt, in denen die Nachteile durch die Modalität stärker ins Auge springen.

Hallo MrSparkle,

bei normalen Dialogen kann man einfach den Owner setzen (myDialog.Owner = myForm) und der Dialog bleibt automatisch vor dem Form, kann also gar nicht in den Hintergrund kommen. Das wäre in diesem Fall sicher nicht schlecht. Allerdings würde das wohl bei den (Windows-)Dialogen mit dem Workaround kollidieren, diese in einem separaten Thread zu öffnen. Bei eigenen Dialogen ist es kein Problem.

Ich finde klar, dass das Dokument in dem Stand gespeichert wird, den es hat, wenn man auf "Speichern" drückt. Ich bin nie auf einen anderen Gedanken gekommen. Meine ganze Argumentation in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte], wo ich explizit auf den Fall eingehen, bei dem man mitten im Auswählen des Speicherpfades merkt, dass man noch eine kleine Änderung im Dokument vornehmen will, basiert genau darauf, dass der aktuelle Stand des Dokuments gespeichert wird.

Wenn wirklich der Stand des Dokuments zum Zeitpunkt des Öffnens des Speichern-Dialogs gespeichert werden soll, kann und sollte dieser Stand angezeigt werden, wenn man dem Dialog wieder aktiviert, er also den Fokus bekommt. Das kann man sicher noch visuell hervorheben, z.B. durch eine sich ändernde Hintergrundfarbe des Dokuments. Jedenfalls sehe ich kein Problem, optisch klar zu machen, was genau passiert.

Es kann in vielen Fällen durchaus sinnvoll sein, wenn man das Öffnen eines separaten Dialogs vermeidet und stattdessen dessen Controls im Hauptfenster anzeigt/einblendet. Bei den Öffnen- und Speichern-Dialogen wird dieses allerdings darauf hinauslaufen, dass man deren Funktionalität nachprogrammieren muss. Das kann man machen.

herbivore

Modale Dialog, sind dann ok, wenn nichts gemacht werden darf, außer die Bedingungen des Dialoges sind erfüllt.

Ich kenne es z.B. von Software die auf Maschinen läuft. So bald eine Wartungsklappe geöffnet, reagiert die Software auf den Sensor und Blockiert mit einem Modalen Dialog alle Eingabemöglichkeiten. Die Maschine wird natürlich auch angehalten.

Nach dem Schließen der Wartungsklappe oder Eingabe eines Entsprechenden Benutzers. (Wartungstechniker der Entsprechend geschult ist und die UI wider Blockieren kann). Danach ist man dann an genau der Stelle wo man war. Beim Wartungstechniker sind es dann meist die Dialog zu Justierung der Mechanik.

MFG
Björn

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Hallo Palin,

mein Beispiel mit dem Windows Explorer oben zeigt, dass modale Dialoge auch dann nicht nötig, sind wenn zum Erreichen einer erforderlichen Bedingung die Komplettierung des Dialogs nötig ist. Und es zeigt, dass es es so gut wie immer andere sinnvolle Aktionen gibt, die man nur nicht gleich im Blick hatte, die statt der Komplettierung des Dialogs durchgeführt werden können. Das ist gerade mein Credo: Modale Dialoge sind nie nötig und immer störend. Es gibt immer bessere Alternativen. Und ich bin bereit das an konkreten Fällen zu zeigen.

Meine Aussagen beziehen sich dabei auf Software. Bei echter Hardware mag das anders sein, das überblicke ich gerade nicht. Wenn echte Hardware durch Software [auf einem Desktop-PC] gesteuert wird, sind jedoch wieder keine modalen Dialoge nötig. Es gibt immer einen anderen, besseren Weg. Auch dann, wenn man in einem ungewöhnlichen Sonderfall tatsächlich alle anderen Aktionen verhindern muss (wobei es selbst dann üblicherweise die Möglichkeit gibt, die laufende Aktion abzubrechen, also doch mindesten eine andere sinnvolle Aktion gibt). Das geht nämlich auf viele Arten. foreach (Control control in form.Controls) {control.Enabled = false; } ist bei weitem nicht die einzige Alternative.

herbivore

Vorschlag.
Der Nutzer will einen Vorgang auslösen, der aber wegen fehlenden Angaben so nicht ausgeführt werden kann. Er muss merken dass das gewünschte nicht passiert.

Info. Ich habe mit Software zu tun die hauptsächlich von not digital natives verwendet wird. Menschen die den Computer als notwendiges Übel sehen und mühsam statt versiert damit arbeiten.
zB der ErrorProvider ist eine echt coole Sache. Allerdings birgt er die Gefahr von Aussagen "ich klicke und nichts passiert. Da steht nur so ein komisches Zeichen". Oder noch schlimmer, man klickt und geht wieder weg, in der Annahme es wird schon alles gut sein. Da ist es fast noch zu wenig dass sich eine Meldung mitten in den Bildschirm knallt, eigentlich müsste sich der Rest noch abdunkeln. Bissig gesagt wollen die gar nicht wissen was sie alles parallel tun können sondern möchten/müssen so geführt werden dass sie wenigstens eine Sache zu Ende schaffen 😃

Die Frage war, wo ein modaler Dialog sinnvoll ist. Palin's Beispiel ist nahezu perfekt.
Ob da eine Hardware dran steckt oder nicht; da solltest Du jetzt nicht ausweichen 😉

Hallo Abt,

deine Behauptung/Vermutung entbehrt jeder Grundlage. Ich habe konkrete Alternativen genannt. Alle Eingaben kann man z.B. durch das genannte foreach (Control control in form.Controls) {control.Enabled = false; } verhindern. Weitere Alternativen kann ich nennen, wenn er kein abstraktes Beispiel macht, sondern ein konkretes. Wie viele Fester gibt es? Wie sehen die aus? Erst dann kann man sagen, ob es vielleicht sinnvoll wäre, den Wartungsdialog so in das Fenster einzublenden, wie es in [FAQ] Assistenten/Wizards: Mit Windows Forms eine Art Frameset einer Website nachbauen gemacht gezeigt wird (natürlich ohne die Navigationsplane). Ein modaler Dialog ist jedenfalls auch für Wartungsklappen nicht nötig.

Hallo chilic,

natürlich muss der Benutzer merken, dass seine Aktion nicht durchgeführt wurde. Das tut er in deinem Fall - so wie ich ihn verstanden haben - daran, dass sich das Dialog-Fenster nicht schließt. Wenn das nicht reicht, dann kann man die Tatsache auch explizit in das Fenster einblenden, z.B. so wie es in [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen eingeblendet sind.

herbivore

zu Sperrung einer Software:

Hab ein Programm, wenn bestimmte Daten ankommen müssen einige sichtbare TabPages erstmal gesperrt werden, bis der User eine Aktion tätigt.

In diesem Fall packe ich jeweils ein Panel über die TabPages die zu diesem zeitpunkt sichtbar waren.

In diesen Panels ist jeweils ein Image mit dem vorher eine Art screenshots der Child Controls der TabPage gemacht wurde.
(Nicht ganz so kräftig gezeichnet wie die original Controls damit man erkennt das dieser bereich inaktiv ist)

Der User muss ein Button auf dem Panel betätigen damit dann diese TabPage wieder aktiv wird.

Das Panel packe ich einfach drüber um weitere eingabe controls auf billige art und weiße zu blockieren und ich muss mich auch nicht um eventuelle ContextMenüs kümmern.

So blockiere ich auch nicht sofort das komplette FOrmular.

Hallo Spyke,

ich finde diese Lösung etwas um die Ecke, aber es ist auf jeden Fall ein Ansatz. Und darum ging es mir ja in diesem Thread. Zu zeigen, dass man mit etwas Überlegen und gutem Willen ohne modale Dialoge und ihre Nachteile auskommt. Jeder wird sicher eine etwas andere Vorstellung haben, wie eine Alternative am besten zu realisieren ist. In diesem Sinne begrüße ich den Vorschlag.

herbivore

Das es nicht anders geht habe ich nicht behauptet. Aber es ist recht einfach Implementiert und recht "Robust". Was meines Erachtens bei Sicherheitskritischen Anwendungen ein wichtiger Aspekt.

Du hast natürlich recht deiner Ursprünglichen Fragestellung genügt es nicht. Aber ich denke es ist trotzdem ein Aspekt der in einer Diskussion betrachtet werden sollte.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Hallo Palin,

sicher ist Robustheit ein Kriterium. Aber foreach (Control control in form.Controls) {control.Enabled = false; } ist nun z.B. auch nicht weniger robust als ein modaler Dialog.

Klar, manche Alternativen sind aufwändiger zu implementieren. Aus meiner Sicht lohnt sich das, wenn dem entsprechende Vorteile in der Benutzerfreundlichkeit gegenüberstehen.

herbivore

deine Behauptung/Vermutung entbehrt jeder Grundlage. Ich habe konkrete Alternativen genannt. Alle Eingaben kann man z.B. durch das genannte foreach (Control control in form.Controls) {control.Enabled = false; } verhindern.

Und ich sage, dass dieses Vorhaben völlig unpraktikabel ist und speziell Enabled eine .NET Sache ist.

Wozu soll ich noch Elemente als Disabled anzeigen, wenn das wichtigste aktuell die Warnmeldung ist?
Wenn zum Beispiel das Schneidgas niedrig wird, also eine Warnung, dann kann das ruhig embedded angezeigt werden, da es die Arbeit nicht einschränkt.

Befinde ich mich aber in einer Touch Umgebung und hab dann eine modales Fenster hab ich doch viel mehr Platz um eine große rote Warnung anzuzeigen, weil es ein kritischer Fall ist.
Es ist groß, ich kann es von weitem sehen, was angezeigt wird. Perfekt für das Vorhaben.
Ein Maschinenbediener hat keine Lust da erst irgendeine Font=12px Statusleiste mit unnötigen Disabled Elementen zu sehen. Aus UI-Kontext-sicht völliger Käse.

Hallo Abt,

hier soll es um normale Desktop-Anwendungen gehen. So war mein einleitender Text jedenfalls gemeint. Darauf bezog sich meine Behauptung, dass modale Dialoge unnötig sind. Und darauf bezogen sind meine Aussagen stimmig. Du scheinst über etwas ganz anders zu reden, was am Thema vorbei geht. Sollte ich mich irren und du doch normale Desktop-Anwendungen meinen, bescheib es bitte genauer. Am besten mit GUI-Skizze oder Screenshot.

herbivore

@herbivore
Mir ist an den Punkt nicht klar, welchen mehr wert, der Benutzer an der Stelle, durch den zusätzlichen Code erhält.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Hallo Palin,

zusätzlicher Code ist in vielen Fällen gar nicht nötig. Im einfachsten Fall reicht es Form.ShowDialog durch Form.Show zu ersetzen. Ohne irgendwelche weiteren Änderungen. Oder nur mit minimalen Änderungen z.B. dem vorübergehenden Disablen von Controls. Und selbst das kann man in eine extra Bibliotheks-Methode auslagern(*).

Ansonsten habe ich die wichtigsten allgemeinen Nachteile von modalen Dialogen und einige weitere Nachteile in speziellen Fällen, bereits in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] beschrieben (bitte lesen). Welche Nachteil es darüberhinaus in einer konkreten Situation gibt, hängt natürlich von der konkreten Situation ab. Dafür ist dann dieser Thread hier.

herbivore

() Hier eine erste Skizze, wie so ein Auslagern aussehen könnte. Das kann man sicher noch verfeinern, z.B. dass man am Ende nur die Controls enabled, die zu Beginn enabled waren und

  • nur die Controls disabled, die wirklich disabled werden müssen (was ich am wichtigsten fände) und
  • ein DialogResult zurückgibt und
  • vermutlich noch einiges mehr.

So oder so ist der ganze zusätzliche Code in einer universell einsetzbaren Klasse gekapselt. An der Aufrufstelle entsteht kein zusätzlicher Aufwand, denn mit der folgenden Klasse ist es möglich, einen Dialog genauso einfach anzuzeigen, wie mit ShowDialog, nur dass das dahinterliegende Fenster zumindest verschiebbar bleibt.

dialog.ShowDialogNonModal (owner);
public static class FormHelper
{
    public static void ShowDialogNonModal (this Form dialog, Form owner)
    {
       owner.EnableControls (false);
       dialog.Owner = owner;
       dialog.FormClosing += DialogFormClosing;
       dialog.Show ();
    }

    public static void EnableControls (this Form form, bool enable)
    {
       foreach (Control control in form.Controls) {
          control.Enabled = enable;
       }
    }

    public static void DialogFormClosing (Object sender, FormClosingEventArgs e)
    {
       ((Form)sender).Owner.EnableControls (true);
    }
}

Hallo Herbivore,

das beispiel mit den deaktivieren deiner Controls finde ich ok, durch einen Modalen Dialog wird dir diese Arbeit aber abgenommen.

Ich sehe es so: Modale Dialoge benutzen Programme seit Äonen. Dieses Verhalten zu ändnern obliegt uns SW Entwicklern und Architekten. Ob es die Kunden dann annehmen ist eine andere Sache.

Ich sehe nicht die Frage wann Modale Dialoge Sinnvoll sind und ob, sondern wie man die Akzeptanz für andere "Mittel" fördert.

Ich zB kriege immer klare Vorgaben unserers Fachbereiches, darf zwar mitmischen bei Veränderungen der Oberfläche, solche Radikalen änderungen allerdings werden abgewatscht mit dem Spruch : "Wie selbst Windows/Linux machen das doch so"

Herbivore, hast du Software ohne Modale Dialoge im Einsatz und wie kommt das an ?

Grüße

Hallo Ahrimaan,

in der Skizze geht es doch darum, die Nachteile von modalen Dialogen, minderstens, dass das dahinterliegende Fenster nicht verschoben werden kann, zu verhindern. Außerdem ist das Disablen alle Controls im dahinterliegenden Fenster nicht meine erste Wahl. Die Skizze sollte hauptsächlich zeigen, dass man Alternativen zu modalen Dialogen einfach und ohne viel Aufwand als universelle Komponenten kapseln kann. Meine These ist, dass trotz des geöffneten Dialogs oft sinnvolle Interaktionen mit dem Fenster möglich sind, weshalb ich andere Alternativen bevorzuge. Ich gehe halt immer auf die gerade gestellte Frage ein.

Weil es modale Dialoge schon solange gibt, ist es vielleicht - rein mental, nicht wegen tatsächlicher Hindernisse - auch so schwer, davon wegzukommen. 😃 Es ist halt schwer, aus eingefahrenen Bahnen herauszukommen.

Ein Versuch, die Akzeptanz für Alternativen zu fördern, ist dieser Thread. Doch dazu muss man natürlich auch an einigen Stellen über Sinn und Unsinn und über Vor- und Nachteile zu sprechen.

Ich verwende modale Dialoge seit langem nicht mehr und hatte nie irgendwelche Problem damit oder dadurch. Auch nicht Kunden oder Benutzern, eher im Gegenteil.

Hallo zusammen,

um selber noch einen Fall zu nennen: Ganz schlimm finde ich, wenn Hilfetexte - vollkommen ohne Not - modal angezeigt werden. Hab ich alles schon erlebt. Gerade wenn in der Hilfe eine Schritt-für-Schritt-Anleitung enthalten ist, der man folgen möchte, ist es natürlich extrem nervig, wenn die Hilfe in einem modalen Dialog angezeigt wird. Hier kann man immer einfach ein normale Fenster statt eines modalen Dialogs verwenden.

herbivore

Gerade wenn man Spezial-Anwendungen für Unternehmen schreibt ist es oftmals besser Modale Dialoge zu verwenden.

Ein Beispiel aus unserem Haus:
In einer Anwendung können Messwerte für einen Artikel eingegeben werden (Dickenmessungen). Die Messwerte werden gegen die dem Artikeltyp zugeordneten Grenzwerte überprüft.
Derzeit ist es so implementiert, dass bei Über- oder Unterschreitung nur ein Panel eingeblendet wird mit dem Hinweis. Der Benutzer kann also weiter arbeiten und die Werte speichern (Vorgabe vom Kunden, da wirklich mal Artikel außerhalb der Grenzwerte liegen können ist das Speichern dennoch möglich).

Der Kunde fordert nun aber einen Dialog der Bestätigt werden muss, da die Benutzer sonst darauf nicht achten und Fehlmessungen ohne drüber nachzudenken in die Datenbank übertragen werden, was im Nachhinein negative Auswirkungen auf die Auswertung hat. Denn obwohl der Artikel OK war hat der Benutzer sich vertippt und einen völlig unglaubwürdigen Wert in die Datenbank geschrieben.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Hallo inflames2k,

es ist ok, wenn der Kunde möchte, dass unplausible Werte explizit bestätigt werden. Doch ein modaler Dialog ist (auch) dafür nicht erforderlich. Hier würde es z.B. reichen, einen Bestätigungs-Button neben den unplausiblen Werten einzublenden. Erst wenn der bzw. alle Bestätigungs-Buttons gedrückt wurden (und dadurch wieder verschwinden), kann der Datensatz als ganzes gespeichert werden.

Das kann man natürlich noch variieren. Wenn z.B. nicht jeder Wert einzeln bestätigt werden soll, sondern nur die Tatsache, dass in dem Datensatz unplausible Werte enthalten sind, kann man auch eine entsprechende Sicherheitsabfrage per [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen einblenden.

Zusätzlich können unplausible Werte rot dargestellt oder rot hinterlegt oder in anderer Weise hervorgehoben werden, damit sie sofort ins Auge springen. Ich persönlich finde solche optischen Signale sehr hilfreich.

Hallo zusammen,

es ist - ich glaube das zeigt sich langsam - meistens nur eine Frage des Willens, sich auf die Suche nach einer benutzerfreundlichen Lösung zu machen. Ich erhebe nicht den Anspruch, dass ich hier in diesem Thread immer auf Anhieb eine Alternative finde, die dem Geschmack des Entwicklers oder der Benutzer sofort 100%ig trifft. Doch statt sich darauf zu konzentieren, was an meinen Vorschlägen möglicherweise nicht auf Anhieb passt, ist es produktiver, den Ansatz weiterzuspinnen und zu überlegen, wie er weiter verbessert werden, bis er gefällt. Oder eine ganz eigene Alternative zu entwickeln.

herbivore

Ich verstehe ehrlich gesagt die ganze Diskussion nicht wirklich. Was genau soll eigentlich verwerflich sein an modalen Dialogen?

Für mich sind modale Dialoge eine einfache und intuitive Möglichkeit vom Bediener eine Bestätigung, Eingabe, o.Ä. abzufragen, ohne die das Programm nicht weiter arbeiten kann. Klar kann man das auch immer anders lösen, aber warum den Aufwand betreiben, selbst die falsche Ausführung mit eigenem Code zu verriegeln, wenn es dafür ein seit langem bewährtes Standardwerkzeug gibt?

Hallo Mallett,

verwerflich ist vielleicht das falsche Wort. Positiv ausgedrückt, bin ich der Meinung, dass es immer (deutlich) bessere Alternativen gibt.

Und ich behaupte, dass "... ohne die das Programm nicht weiter arbeiten kann" eine Annahme ist, die bei weitem nicht so oft zutrifft, wie man das denkt.

Ich habe bereits konkrete Gründe genannt, welche Nachteile ich sehe, hier in diesem Thread und zusammengefasst in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte]. Ich hatte gehofft, dass die verlinkten Threads gelesen werden. 😃

herbivore

Ich finde, dass gerade Modale Dialoge die Bedienung für nicht so PC-affine Benutzer in vielen Fällen vereinfachen. Viele Benutzer kommen nicht mit mehreren, gleichzeitig geöffneten und gleichzeitig zugänglichen Fenstern klar.

Beispiel:

In der Hauptmaske von Programm A wird eine Untermaske nicht modal aufgerufen. Nachdem der Benutzer die Maske aufgerufen hat, macht er Outlook auf und möchte, nachdem er eine Mail beantwortet hat wieder zurück in sein Programm A wechseln.
Durch die nicht modale Anzeige der Untermaske werden in der Windows Taskleiste Hauptmaske und Untermaske separat angezeigt. D. h. der Benutzer klickt in der Taskleiste auf Programm A und wundert sich, wo seine Untermaske hin ist.

Diese Situation habe ich tatsächlich schon erlebt, woraufhin auf Kundenwunsch der Aufruf der Untermasken auf modal umgestellt wurde.

Hallo hypersurf,

wenn man im Unterform den Owner auf das Hauptform setzt, dann bleibt das Unterform immer vor dem Hauptform. Ich habs jetzt nicht beim Minimieren ausprobiert, aber selbst wenn es da nicht auf Anhieb (automatisch) klappt, kann man das leicht programmieren.

Eine andere Möglichkeit wäre, den Inhalt des Unterforms in das Hauptform einzublenden. Dann kommt es/er auf jeden Fall wieder mit nach vorne. Je nach Situation kann man den Inhalt des Dialogs zusätzlich zu eigenlichen Inhalt einblenden oder statt des eigentlichen Inhalt (letztes z.B. mit Techniken, wie in [FAQ] Assistenten/Wizards: Mit Windows Forms eine Art Frameset einer Website nachbauen beschrieben).

Ob ein Fenster in der Task-Leiste angezeigt werden soll, kann man zudem einfach über Form.ShowInTaskbar einstellen.

Hallo zusammen,

nochmal: Ich erhebe nicht den Anspruch, auf Anhieb eine Lösung zu nennen, die keinen Raum für Widerspruch zulässt. Manches muss man sicher weiter ausarbeiten und vielleicht noch die eine oder andere Kante abschleifen. Doch wo der Wille ist, genau das zu tun, findet mal meiner Ansicht nach immer Lösungen, die für die jeweilige Benutzergruppe besser geeignet sind, als modale Dialoge.

herbivore

wenn man im Unterform den Owner auf das Hauptform setzt, dann bleibt das Unterform immer vor dem Hauptform. Ich habs jetzt nicht beim Minimieren ausprobiert, aber selbst wenn es da nicht auf Anhieb (automatisch) klappt, kann man das leicht programmieren.

Wenn die Untermaske immer vor der Hauptform bleibt ist die Untermaske modal.

Eine andere Möglichkeit wäre, den Inhalt des Unterforms in das Hauptform einzublenden. Dann kommt es/er auf jeden Fall wieder mit nach vorne. Je nach Situation kann man den Inhalt des Dialogs zusätzlich zu eigenlichen Inhalt einblenden oder statt des eigentlichen Inhalt (letztes z.B. mit Techniken, wie in
>
beschrieben).

Das ist definitiv eine gute Möglichkeit. Ich persönlich würde am liebsten auf alle Untermasken verzichten und nur mit Tabs arbeiten. Es gibt mittlerweile ja auch TabControls bei denen man einzelne Tabs auf verschiedene Monitore legen kann. So könnte man gänzlich auf Untermasken verzichten.

Ob ein Fenster in der Task-Leiste angezeigt werden soll, kann man zudem einfach über Form.ShowInTaskbar einstellen.

Jep, das hatten wir in dem von mir beschriebenen Fall aber extra nicht deaktiviert, weil es ja auch versierte Benutzer gibt die mit vielen gleichzeitig geöffneten Fenstern gut klar kommen und diese effektiv nutzen (z. B. auf mehreren Monitoren). Dann kam der Chef des Kunden, welcher nicht mit so vielen Fenstern klar kam und alles wurde modal X(

Hallo zusammen,

ich gebe mal meine bescheiden Meinung dazu:
Je länger ich das Thema mitlese und darüber nachdenke, desto mehr kristallisiert sich für mich heraus, dass sobald die Software ein abgeschlossenes System ist herbivores These richtig ist.
Ich finde es ist wesentlich schöner und benutzerfreundlicher Fehlerstellen zu markieren und abhängige Funktionen zu deaktivieren, solange der Fehler nicht behoben ist. Oder anders: Was soll das ein Fenster aufpoppen zu lassen, in dem man eine Aktion fordert und erst danach an einer anderen Stelle weitergearbeitet werden kann? Was ist, wenn man den Wert erst irgendwo erfragen muss? Dann ist das Programm solange nicht nutzbar, bis man dem 1000.en nachtelefoniert hat! 8o

Ich behaupte, wenn man herbivores These widerlegen will, muss man in die Richtung voneinander abhängiger Programme oder Maschinensteuerungen denken, wo man "von außen" Fehlerzustände bekommt.
Also so die Richtung von Palin: Was ist, wenn ein physisch sicherheitskritischer Zustand auftritt? Darf dann etwas an der Software eingestellt werden, solange der Zustand, der zwangsläufig einen Prozess-Stopp bedeutet, nicht behoben ist? Oder würde dies zu Inkonsistenzen führen? Dann könnte man wahrscheinlich aber die Gegenfrage aufstellen: Ist in diesem Fall die Software gut designed?

Soweit von mir.

Ezio

Hallo Ezio,

danke für die Einschätzung. Diese hat was für sich.

Hallo hypersurf,

Wenn die Untermaske immer vor der Hauptform bleibt ist die Untermaske modal.

nein, das Davorbleiben wird durch die Owner-Beziehung verursacht. Man kann es also durch Setzen der Owner-Beziehung erreichen, unabhängig davon, ob der Dialog modal ist oder eben nicht. Andersherum stimmt es. Wenn der Dialog modal ist (im hier diskutieren Sinne), dann bleibt er auch immer vor dem Hauptform.

Dann kam der Chef des Kunden, welcher nicht mit so vielen Fenstern klar kam und alles wurde modal

Das ist natürlich tragisch. Wenn man gute Alternativen anbieten kann, kann man sowas mit etwas Glück verhindern.

herbivore

Um meinen Senf auch noch dazu zugeben 😉
Selbst nutze ich ModaleDialoge meist für Einrichtungen o.ä.. Während man Einstellungen vornimmt, soll man nicht weiter in der Haupt-Applikation rumfummeln. Natürlich könnte ich das Hauptfenster Disablen, aber wenn es ohnehin nicht editierbar/enabled ist, bringt das imho auch keinen Mehrwert.

Anders sehe ich das bei Fehlermeldungen oder Warnungen. Wenn man diese einblendet, soll man das Fenster nicht mehr schließen können, bis dieses Problem behoben ist. Ein Disablen halte ich für unnötig, da gerade hier der Mehrwert liegt:
Ich gebe ein falsches Datumsformat ein, ein Fehler erscheint am oberen Rand. Ich fahre (weil ich es auch so gewohnt bin) erstmal mit meinen Eingaben fort, bis ich die letzte Eingabe getätigt habe. Dann lese ich mir die Meldung durch, oder ich weiß schon woran es liegt. Die Meldung erscheint nach der Datumseingabe => Klar, habe ich mich wohl vertippt.

Falls es nicht so eine triviale Eingabe wie eine Datum ist, schreibe ich ne Mail mit dem Problem, warte auf eine Antwort und arbeite einfach in einem anderen Fenster weiter.

Meines Erachtens das Perfekte Beispiel. Aber:
Dieses Fenster muss nun (zumindest) die Haupt-Applikation und ggf. den Aufrufer der entsprechenden Form sperren, da ich diesen Fehler nicht stehen lassen und das Programm beenden darf. Womit ich wieder bei einer gewissen Modalität gelandet bin...

Hallo trib,

gerade bei Einstellungsdialogen finde ich es wichtig, dass diese non-modal sind und am besten noch einen Übernehmen-Button haben, mit denen man die geänderten Einstellungen aktivieren kann, ohne den Einstellungsdialog zu schließen. Gerade bei Einstellungen will ich oft schnell verschiedene Varianten ausprobieren und die Auswirkungen schnell prüfen können. Dafür ist aber oft auch eine Bedienung des Hauptfensters nötig, z.B. um dort die Ansicht so zu ändert, dass die geänderten Einstellungen sichtbar werden. Oder um Einstellungen auszuprobieren, die eine Verhaltensänderung bewirken. Zum Glück ist das bei mehr und mehr Anwendungen der Fall.

Dass gezielt bestimme Aktionen gesperrt werden, die tatsächlich aktuell keine Sinn machen oder sogar keinen Konflikt verursachen würde, ist ok. Man sollte immer genau überlegen, auf welche Aktionen das wirklich zutrifft, damit man nicht unnötig viel sperrt.

herbivore

Hallo herbivore,

Wenn die Untermaske immer vor der Hauptform bleibt ist die Untermaske modal.
nein, das Davorbleiben wird durch die Owner-Beziehung verursacht. Man kann es also durch Setzen der Owner-Beziehung erreichen, unabhängig davon, ob der Dialog modal ist oder eben nicht. Andersherum stimmt es. Wenn der Dialog modal ist (im hier diskutieren Sinne), dann bleibt er auch immer vor dem Hauptform.

Folge ich jedoch der Definition von modalen Dialogen, hat hypersurf in gewisser Weise jedoch recht, was die Modalität des Formulars angeht das per Owner-Beziehung dem Hauptformular zugewiesen wird.

Denn per Definition gilt für Modale Dialoge:

  • Sie sperren den Rest der Anwendung, solange der Dialog angezeigt wird.

Folge ich nun deiner Aussage, dass man ja alles disablen kann und erst wieder aktiviert wenn der Dialog bestätigt wurde kommt hier per Definition raus, dass der Dialog Modal angezeigt wird.

Erst, wenn ich Eingaben auf dem Hauptformular erlaube während der Dialog offen ist, habe ich einen nicht-modalen Dialog.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Hallo inflames2k,

deshalb schrieb ich auch "modal (im hier diskutieren Sinne)", also ShowDialog. Mir ist klar, dass wenn man die Code-Skizze von oben, so wie sie ist, verwendet, in gewissem Sinne einen modalen Dialog nachbildet. Immerhin ohne den Nachteil, dass das Hauptformular festgetackert ist und sich nicht verschieben lässt.

Wenn es nach mir geht, sollte im Hauptformular möglichst wenig deaktiviert werden. Und dann hat man faktisch wirklich keinen modalen Dialog mehr (weder in dem einen noch in dem anderen Sinne). Und kann durch die Owner-Beziehung trotzdem dafür sorgen, dass der Dialog sich immer vor dem Hauptfenster befindet.

Oder man wählt gleich eine der vielen anderen Alternativen, die ich beschrieben habe. 😃

herbivore

es ist - ich glaube das zeigt sich langsam - meistens nur eine Frage des Willens, sich auf die Suche nach einer benutzerfreundlichen Lösung zu machen.

Zunächst ist es bestimmt die Frage was an einem speziellen Fall überhaupt so nutzerunfreudlich ist. Das ist sicher nicht allen auf Anhieb klar.
Mit Sicherheit ist es auch eine Frage des Willens, denn man vermutet zum Teil erheblichen Aufwand hinter so einer Umstellung.
Und eine Frage des Sinns dürfte es auch sein, in Fällen wo man das Verhalten eben so braucht, die Nachteile nicht ins Gewicht fallen und man dadurch gerne einfach modal mit dazu schreibt und praktisch das selbe hat wie nach selbstgemachten Versuchen. Letztere gibt es auch, da wird nicht jeder alles umstellen wollen und können. Aber es bleiben ja genügend Fälle übrig wo eine Umstellung wirklich einen sofort erkennbaren Vorteil bringt.

Ich finde das Thema interessant, aber mit so Dingen wie IMMER oder NIE usw. wird die Diskussion wahrscheinlich nicht weit kommen. Beschränken wir uns doch auf die Fälle wo eine Umstellung wirklich viel bringt, die man vielleicht nur nicht wagt weil man nicht recht weiß wie.

Ein Beispiel zu Fehlermeldungen in Eingabeformularen.
Den Nutzer aus einem Feld nicht mehr rauslassen bis alles stimmt ist Terror, sowas mag ich gar nicht. Messagebox pro Feld genauso. Ich habs lieber wenn am Ende alles überprüft wird und man dann in Ruhe korrigieren kann.
Das kann schon durch Fehlersymbole geschehen, die kann man bereits während der Eingabe anzeigen. Nur muss man das auf Anhieb finden und es sollten detailliertere Infos anzeigbar sein. Soweit der klare Vorteil.

Wenn dann jemand trotzdem auf OK klickt hat er das wohl nicht bemerkt. Das wäre für mich nun ein Fall für ein STOP, bitte JETZT SOFORT zur Kenntnis nehmen dass hier was anders läuft als geplant. Da sehe ich den Komfort darin dass der Nutzer nicht lange überlegen und suchen muss warum nichts passiert.
Eine MessageBox würde in diesem Fall keine Information enthalten die man nochmal genauer nachlesen muss. Da steht nur drin pass auf es gibt Fehler die im Formular markiert sind. Da kann mir auch wirklich niemand erzählen er müsse während dieser kurzlebigen Meldung noch was anderes nachsehen 😉

Formulare sind in meinen Augen ein klassischer Fall dafür, dass modale Infos stören.
Das ist (und mit MVVM / AngularJS) unabhängig von der Technologie sehr einfach embedded zu lösen.
zB ist der Absenden-Button erst dann enabled, wenn das FORMAT der Daten stimmt (Abhängigkeiten nicht zwangsläufig beachtet). Solange ist zB ein rotes Icon hinter dem entsprechenden Eingabefeld und ein Tooltip mit dem Fehlerhinweis über dem Absende-Button.

Hallo chilic,

sicher ist die IMMER/NIE-Diskussion plakativ. Aber ich halte sie für angebracht, um einen Anstoß zu bewirken. In der täglichen Praxis gibt es dann genug (vermeidliche oder reale) Sachzwänge, die einen wieder zurück in die ausgefahrenen Pfade führen. Um dem zu entrinnen, finde ich es schon wichtig aufzuzeigen, dass es immer anders und vermutlich auch immer besser geht. Und das man vor dem geplanten Einsatz von modalen Dialogen IMMER überlegen sollte, ob und wie es besser geht.

Gerade bei verbreiteten Standard-Anwendungen wäre der Aufwand, modale Dialoge zu ersetzen, sehr oft gut investiert. Und oft sind gerade dort modale Dialoge eine im Grunde unnötige Altlast. Wenn ich auch nur ein bisschen dazu beitragen kann, solche Altlasten zu entsorgen und für die Zukunft gar nicht erst entstehen zu lassen, dann bin ich schon glücklich.

Was die Fehlermeldungen in Eingabeformularen angeht, stimme ich dir zu, außer dass ich die MessageBox am Ende durch [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen ersetzen würde. Und schon kommt man auch dort ohne Mühe ohne eine MessageBox aus.

herbivore

Ein sehr schlechtes Beispiel für den Einsatz nicht modaler Dialoge habe ich neulich bei einer Präsentation gesehen. Es ging gerade darum, wie man das Format von URLs anpassen kann. Das Resultat einer Codeänderung war ähnlich dem Screenshot von unten - Es sollte eine bestimmte Adresse aufgerufen werden, aber - obwohl eigentlich alles korrekt umgesetzt worden war - hat man nur ein "Not Found" gesehen. Auch nach mehrmaligem Aufrufen sah man kein Ergebnis.
Das Problem dabei war, dass schon alles einwandfrei funktioniert hat. Allerdings zeigt der Internet Explorer bestimmte Inhaltstypen nicht an, sondern blendet den "Speichern oder Öffnen"-Dialog ein - in dem Fall nicht modal ganz am unteren Rand. Die "Not Found"-Seite ist das Resultat irgendeiner Aktion davor. Alle haben nur auf die Adresszeile geguckt und (vermeintlich) einen 404 als Ergebnis gesehen. Dabei hätte man auf den Hinweis ganz unten gucken müssen.

Hallo dN!3L,

schlechtes Design kann es natürlich immer geben, in welchem Zusammengang auch immer. Das sehe ich allerdings nicht als Gegenargument an. Ich plädiere ja gerade für einen bewussten und durchdachten Einsatz von nicht-modalen Dialogen.

herbivore

Hallo,

ich finde diese Lösung gar nicht so schlecht. Zumindest dürfte eine modaler Dialog nicht die Adresszeile sperren.

Es sollte auch nicht als Gegenargument herhalten. Ist viel mehr ein "nett gedacht aber total blöd umgesetzt".

Hier mal ein konkretes Beispiel für das Weglassen von MessageBoxen: Es gibt einen "Speichern (unter)"-Dialog für Datenquellen-Abfragen. Sobald man auf "Speichern" klickt und es eine Abfrage mit gleichem Namen schon gibt, kam die modale Nachfrage, ob man denn die existierende Abfrage überschreiben möchte (Ja, Nein, Abbrechen). Das ist allerdings ziemlich nervig, wenn man immer wieder speichert - denn die Antwort ist stets "Ja".
Ich habe den Dialog dann so umgebaut, dass einfach ein farblich auffälliger hinterlegter Hinweistext eingeblendet wird. Beim Klick auf "Speichern" wird die bestehende Abfrage einfach überschrieben. Da die alten Versionen eh erhalten bleiben (es gibt Versionierung) ist das im Endeffekt auch nicht so schlimm. Wieder unnötige Klicks gespart 😉

so sieht es mMn eleganter aus, als wenn man jedesmal ein neues Fenster aufpoppen lässt

Hallo zusammen,

es gefällt mir natürlich sehr, wenn eigene Positivbeispiele gepostet werden, also welche die traditionell betrachtet ein Fall für modale Dialoge wären, aber ohne modale Dialoge auskommen bzw. wo modale Dialoge durch bessere Alternative ersetzt wurden. Wenn ihr da noch mehr habt, immer her damit.

herbivore

Das finde ich auch eine ziemlich coole Idee. Auf sowas wär ich so schnell nicht gekommen.
Wer das immer noch nicht wahrnimmt, würde auch eine Box einfach wegklicken.

Zugegeben. Das Beispiel von dN!3L sieht schickt aus. Deutlich ansprechender wie eine 0815 MessageBox.

Aber mal ernsthaft. Der Aufwand für die Umsetzung ist doch deutlich höher verglichen mit einer schlichten MessageBox.

Im konkreten Fall muss man mit der Hintergrundfarbe des Panel herum spielen, es muss ein Text und ein Icon angezeigt werden und natürlich muss alles wieder rückgängig gemacht werden wenn es korrigiert wurde.
Bleibt noch die Frage wann dN!3L die optische Information einblendet. Erst wenn der Nutzer auf speichern klickt oder doch schon während der Eingabe? Muss der Nutzer dann noch einmal auf speichern klicken wenn er die vorhandene Abfrage überschreiben will? Ist das nicht etwas verwirrend? Im Hintergrund muss man das ja alles aus programmieren mit dem "ja Nutzer will überschreiben" usw.

Da ist mir eine MessageBox mit MessageBoxButtons.OKCancel deutlich lieber. Das ganze erschlage ich mit deutlich weniger Codezeilen und der Nutzer ist sich ohne weitere Beschreibung im klaren "Abbruch" bricht das speichern ab und er kann einen anderen Namen eintragen.

Ich muss sagen, dass die Idee von dN!3L für den Dialog echt nett ist. Habe ich in der Form auch noch nicht gesehen.

Aber mal ernsthaft. Der Aufwand für die Umsetzung ist doch deutlich höher verglichen mit einer schlichten MessageBox.

Bei Verwendung von WPF, ist das vielleicht ein Aufwand von 5min. Wenn überhaupt...

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

Hallo Talon,

nach meiner Erfahrung ist der zusätzlicher Aufwand nicht vorhanden, vernachlässigbar oder vertretbar. Und in vielen Fällen lässt sich erforderlicher Code sogar in einer separaten wiederverwendbaren Klasse kapseln. Davon abgesehen hat man den evtl. etwas höheren Aufwand nur einmal, wogegen der Nutzer der Vorteil jeden Tag hat. Insofern lohnt sich das also (fast) immer.

Im konkreten Fall geht es wohl um nicht mehr als das Ein- und Ausblenden eines vorgefertigten Labels bzw. Containercontrols, das Text und Icon enthält. Die Farbe ist vermutlich fest eingestellt, zumindest könnte man es so machen. Rumspielen braucht man da gar nicht. Ich gehe davon aus, dass im TextChanged der Name-Textbox ganz profan geprüft wird, ob das Ziel vorhanden ist (den Code für diese Prüfung braucht man so oder so) und dann die Meldung ein- bzw. ausgeblendet wird. Beim Drücken von Speichern wird dann einfach gespeichert, egal, ob das Ziel vorhanden ist oder nicht. Dadurch fällt dann sogar eine Abfrage weg. Das ist wirklich simpel zu verstehen und zu realisieren. Ich denke, dass man nicht mehr (handgeschriebenen) Code braucht als wenn man eine MessageBox verwendet, eher etwas weniger.

Das ist ja überhaupt, wofür ich hier plädiere. Sich einfach mal auf die Alternativen einlassen, um zu sehen, wie gut das funktioniert.

Natürlich kann man immer Aufwand, Nutzen und Akzeptanz infrage stellen und klar gibt es bei Neuerungen und Veränderungen immer Bedenken, aber bevor man sich nicht mal darauf eingelassen hast oder wenn man es nur abstrakt behandelt, bleibt das alles reine Theorie.

Ich freue mich über jeden, der sich einfach mal auf diese spannende Erfahrung einlässt, statt nur Gegenargumente liefert, die sogar in seinen eigenen Augen verpuffen, wenn man es mal probiert hat.

herbivore

Der zusätzliche Aufwand für sowas sei mal dahin gestellt, auf jeden Fall höher als ein MessageBox.Show() ... davon aber mal abgesehen, ich fände so einen Dialog sehr verwirrend. Man hat sich mittlerweile an die Standard-Abfrage "Wollen Sie wirklich überschreiben..." gewöhnt. Ich kenne viele Entwickler die hier schon beim Speichern standardmäßig zwei Mal Enter drücken.

Auf jeden Fall ist mir eine standardisierte Lösung lieber, als bei 20 verschiedenen Softwareprodukten jedes Mal eine andere, individuelle Bedienerlogik zu haben, so dass ich mich ständig umgewöhnen muss. Ganz zu schweigen von Bedienern, die nicht viel mit dem PC zu tun haben. Sollen die ständig neue Bedienkonzepte in teuren Schulungen lernen müssen?

Bei großen Auftraggebern ist daher eine "windows-konforme Bedienlogik" häufig sogar vertraglich gefordert.

Gibt es denn Statistiken das die User eine MessageBox nicht wollen?
Oder reden wir hier eher von subjektiven Erfahrungen einiger weniger leute?

Ich finde das sollte man ev. bei der Diskussion mit beachten.

Ich hatte jetzt mal schnell egoogled, ob ich da eine Statistik finde. Hab ich jetzt auf die schnelle leider nicht.

Was aber schnell auftaucht ist Barrierefreiheit, hier mal eine Artikel wie so es sinvoll ist eine Lightbox so abzuändern das sie sich wie ein modaler Dialog verhält.
Aktion Mensch:Eine kleine Untersuchung zur Barrierefreiheit von Lightboxes

MFG
Björn

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern