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

Oder reden wir hier eher von subjektiven Erfahrungen einiger weniger leute?

Wahrscheinlich je nach Anwendungsfall mehr oder weniger. Ich möchte das ganze auch gerne aus der Perspektive sehen, eine Lösung für Fälle mit wirklichem Mehrwert zu haben, aber mich bei unrelevanten Fällen nach wie vor ohne schlechtes Gewissen das gewohnte tun zu trauen.

Den farbigen Hinweis finde ich ne coole Idee, man muss aber aufpassen wir man es verpackt. Das Argument mit der Gewohnheit sehe ich nämlich auch. Gerade im geschäftlichen Bereich mit Software die man nutzen muss statt nutzen will sind Erkennungswerte wichtig. Im einen Programm kommt der Hinweis so, im anderen anders...
Es sollte auf jeden Fall ein geradliniges Konzept innerhalb eines Systems geben.
Außerdem ist die geniale Idee des Programmierers nicht immer das was dem Nutzer auch gefällt. Sonst sähen die Einstellungen von Windows nicht in jeder Version so anders aus dass man nichts mehr findet 😃

Die Lightboxen in Palins Link halte ich für noch nicht perfekt. Der Hintergrund wird dunkel, aber er scrollt. Wenn man eine Meldung in diesem Stil liest erwartet man nicht dass man sich gerade unbemerkt den Kontext im Hintergrund aus dem Bild scrollt.
Man muss außerdem wissen wie man sie schließt. x unten ist innovativ, aber ich will nicht wissen wer das rechts oben sucht und hier nicht weiter weiß. Auch an sowas muss man denken wenn mans bis ins Detail richtig machen will.

Das sind zwar alles altbackene Argumente, die aber schnell entscheidend werden können sobald auf irgendeiner Seite (Hersteller und Anwender) Finanzen ins Spiel kommen.

Zum einen habe ich echt kein Problem mit modalen Dialogen und habe auch noch nie irgendwas gehört, dass sich jemand beschwert hätte. Wir haben z.B. teilweise viel größere Usability Probleme 😉 Und eigentlich mag auch ja auch niemand diese Eigenentwicklungen, die sich nicht an den Standard halten. Bei Star Office hat ja auch jeder über die komischen Dateidialoge geschimpft. Da finden sich Beispiele ohne Ende.

Zum anderen sehe ich den Mehraufwand schon. Man muss sich an zig Stellen überlegen, was alles passieren könnte, wenn irgendwelche Dialoge nicht modal sind. Das muss man sich jedes mal im Detail anschauen und dann kommt später doch jemand, erweitert oder ändert irgendwas und schon hat man ein verstecktes Problem.
Und dann gibts auch noch technische Probleme. Wir haben auch eine Komponente, die man in NX integrieren kann. NX hat praktisch keine modalen Fenster. Deren GUI Api können wir aber auch nicht ohne weiteres benutzen. Wir haben natürlich schon hunderte eigene Fenster, die weitere Fenster aufmachen können usw. Das alles irgendwie so zu verpacken, dass beim Erzeugen von einem Fenster alles in ein "NX Fenster" verpackt wird, würde technisch vielleicht irgendwie gehen, wär aber sehr viel Aufwand und wahrscheinlich auch mit zig Problemen verbunden, die jetzt noch nicht abzusehen wären. Jedenfalls hatten wir Riesenprobleme mit den nicht modalen Dialogen. Wir machen z.B. ein Standard Datei Öffnen Dialog auf, man verklickt sich, das Fenster verschwindet im Hintergrund, die anderen Fenster sind deaktiviert und den Dialog kriegt man auch nicht mehr in den Vordergrund. Oder man macht irgendein Fenster auf, kann aber NX beenden, ohne das Fenster explizit zuzumachen. Dann entlädt NX zuerst die Plugins (auch uns) und zerstört dann die Fenster oder irgendwie so. Komische Abstürze ohne Ende.

Hallo allerseits,

Wir machen z.B. ein Standard Datei Öffnen Dialog auf, man verklickt sich, das Fenster verschwindet im Hintergrund, die anderen Fenster sind deaktiviert und den Dialog kriegt man auch nicht mehr in den Vordergrund.

Genau dazu hatte ich ja auch schon Bedenken geäußert.

Und wenn es keine modalen Dialoge mehr gibt, hindert den User auch niemand mehr daran, ein Programm mit einem ungespeichterten Dokument zu schließen. Da kommt ja sonst immer die (aus gutem Grund) modale Dialogbox "Dokument speichern?"

Christian

Hallo Mallett,

nein, der Aufwand ist nicht auf jeden Fall höher. Man sollte für einen aussagekräftigen Vergleich natürlich die Logik (Codemenge, Aufwand, ...) für die Gesamtoperation betrachtet. Für den konkreten Fall habe ich ja schon dokumentiert, dass er Aufwand für bisherige und neue Variante so ziemlich genau auf das Gleiche hinausläuft. Wenn man die Logik für das eingeblendete Panel ein für alle Mal als quasi NewStyleMessageBox kapselt, fängt man sogar an zu sparen.

Wenn man eine neue Software benutzt, wird man beim Speichern nicht automatisch zweimal Enter drücken, sondern sich erstmal anschauen, was passiert. Und wenn man merkt, dass man bei gleicher bzw. besserer Benutzerfreundlichkeit nur einmal Enter drücken muss, sich beginnen zu fragen, warum man es bei der alten Anwendung zweimal musste. Zumal der (Windows-)Standard nun wirklich nicht so weit geht, dass man jede neue Anwendung von Anfang an blind benutzen kann.

Davon abgesehen würden ohne Abweichungen von bestehenden Standards bzw. ohne das Herausbilden neuer Standard die Anwendungen immer noch so gruselig bedienbar sein, wie in den Anfangstagen von Windows (3.x). Neuerungen werden immer an bestimmten Punkten von Standards und Gewohnheiten abweichen müssen, haben aber auch das Potenzial neue Standards zu werden. Wenn man das aber geschickt und intelligent macht, werden die Benutzer es begrüßen und danken.

Gerade wenn man sich die Versionshistorie von gängigen Browser-Programmen anschaut, aber nicht nur da, sondern auch bei anderer Standard-Software, kann man das gut beobachten.

Hallo Spyke,

Statistiken kenne ich nicht, aber man kann den Rückgang von MessageBoxen und modalen Dialogen überall beobachten. Dieser deutlich spürbare Rückgang war ja erst die Motivation, mich dem Thema anzunehmen.

Hallo Palin, hallo chilic,

wie gesagt liegt der Fokus dieses Threads auf Windows Forms bzw. Desktop-Anwendungen. Prinzipiell bin ich aber auch bei Web-Anwendungen der Meinung, dass es im Wesentlichen die gleichen Vorteile durch die Vermeidung von Modalität gibt. Dort kenne ich mich selbst nur leider weniger mit dem technischen Aspekten bei der Umsetzung aus, um hier konkrete Alternativen aufzeigen zu können.

Hallo chilic,

ich stimme dir zu, dass man die Benutzer mit Neuerungen nicht überrollen darf. Doch wie auch die Reaktion auf dN!3L Beispiel zeigt, gibt es auch intuitive Lösungen, bei denen die Benutzer sofort die Vorteile erkennen und begrüßen.

Hallo Coder007,

bei allem Neuen gibt es auch Bedenken, was alles schlimmes passieren könnte. Einige deiner Bedenken habe ich schon weiter oben ausgeräumt. Zum Beispiel kann man auch ohne Modalität sicher stellen, dass ein Dialog vor dem Hauptfenster bleibt, indem man die Owner-Beziehung entsprechend setzt.

Wenn man nun die Aktion, die erfolgen soll, nachdem ein (nicht-modaler) Dialog komplettiert und bestätigt wurde, im FormClosed-EventHandler durchführt, der sich im natürlich Hauptfenster befindet, dann ist das ein EventHandler wie für jeden anderen Button, Menüeintrag oder sonstiges Control auch. Er wird einfach auf den aktuellen Zustand des Fensters ausgeführt, egal zu welchem Zeitpunkt der Dialog geöffnet wurde. Es gibt da überhaupt keinen prinzipiellen Konflikt mit anderen Aktionen, keinen prinzipiellen Unterschied und nicht mehr Abhängigkeiten als wenn der Dialog modal wäre.

Hallo MrSparkle,

und genau bei diesem Bedenken hatte ich schon aufgezeigt, wie man das Eintreten der Situation verhindern kann (Stichwort Owner).

Und wie man auch ohne einen modalen Dialog sicherstellen kann, dass der Benutzer das Fenster nicht schließen kann, ohne dass er die Frage, ob er das Dokument speichern will, beantwortet hat, ist genau der Fall, der in [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen exemplarisch realisiert ist.

Hallo zusammen,

es ist eben oftmals viel mehr möglich als man denkt und es ist oft viel leichter möglich als man denkt. Wissen tut man es erst, wenn man es wirklich mal gemacht hat.

Davon abgesehen kommen wir ein bisschen vom Thema ab, wenn wir allgemein darüber diskutieren, ob modale Dialoge gut oder schlecht sind und ob deren Vermeiden aufwändig ist oder nicht. Nennt doch bitte weiter konkrete Fälle, die ihr euch ohne modalen Dialog nicht vorstellen könnt und ich werde weiter passende Alternativen nennen (das war für alle Desktop-Fälle bisher möglich und wird es wohl auch weiterhin sein). Dann kann man an dem konkreten Fall auch gerne vergleichen, ob z.B. die Alternative aufwändiger ist oder nicht. Sonst verliert sich der Thread im Allgemeinen oder driftet auf die Ebene von Vor-Urteilen. Im konkreten Fall oben hat das ja schon gezeigt, dass der Aufwand in etwa gleich ist.

herbivore

d!n3L Beispiels ist nicht schlecht und würde ich auch sofort so übernehmen.

Wenn man sich jedoch sein Screen anschaut, wird hier, denke ich mal, selbst auch ein modales Dialog für die Eingabe aufgerufen.
In so einem verkleinertem Fenster fällt auch sone Gelbe Warnmeldung sofort auf.

In einem maximierten Fenster mit mehreren Controls , Listen etc. kann solch eine Meldung aber schonmal unter gehen.
In solchem Fall bringe ich dann doch lieber eine MessageBox mit dem Hinweis inkorrekter Daten und zeige diese dann allerdings über ErrorProvider etc. bei den jeweiligen Controls an.

Hallo Spyke,

ich sehe keinen Grund, warum der Dialog modal sein sollte. Die Größe eines Fensters ist jedenfalls kein Grund, der drauf Einfluss hat, ob ein Dialog modal oder nicht-modal sein sollte. Das nur am Rande.

Wenn das Fenster wirklich so groß ist, dass eine Einblendung vielleicht übersehen werden kann, kann man die Meldung auch an der Stelle einblenden, auf die sie sich bezieht. Im konkreten Fall wäre das das Eingabefeld Name, unter dem sie eingeblendet werden könnte. Das ist genau die Stelle, auf die sich die Aufmerksamkeit des Benutzers bei der Eingabe richtet.

Wenn man für das (logische) Layout z.B. ein TableLayoutPanel verwendet, dann sind solche dynamischen Einblendungen besonders einfach zu realisieren.

herbivore

Ich Klink mich hier nocheinmal ein, da ich für nen aktuellen Fall eine elegante Lösung brauche, die für mich schwieriger ausfällt.

Folgender Fall (zu dem schon einmal hier im Thread genannten Programm):
Der Benutzer scannt einen Barcode für einen Artikel. Liegen zu diesem keine Informationen in der Datenbank vor, werden alle Artikeltypen als Overlay angezeigt und eine Auswahl des Nutzers angefordert (als Beispiel für nicht Modal 8; kein Artikeltyp ist an der Stelle im Produktionsablauf eigentlich ein Fehlerzustand daher die Auswahl)).

Nun werden nach Auswahl der Artikeltypen die zugehörigen Grenzwerte für die Vermessung geladen. Dabei können durchaus Datenbankzugriffsfehler auftreten. Wie könnte man hier am elegantesten auf den Fehler hinweisen?

Was ich mir bisher überlegt habe ist, dass das Overlay geöffnet bleibt schließlich soll der Nutzer die Möglichkeit haben den Vorgang zu wiederholen. Ein Overlay im Overlay anzeigen das auf den Fehler hinweist halte ich für nun ja unschön. Tendenziell würde ich hier nun eine MessageBox anzeigen die auf den Fehler hinweist und den Nutzer dazu auffordert, die Auswahl zu wiederholen.

Eine Einblendung in der Statusleiste halte ich für nicht zielführend, da die Auswahlliste bereits farblich markant hervorgehoben ist.

Was wäre denn aus euerer Sicht, speziell herbivore, der Optimale Weg dafür?

Hallo inflames2k,

ganz genau habe ich die Ausgangssituation nicht verstanden, aber ich versuche es trotzdem mal.

So wie ich es verstehe musst du entweder die geladenen Artikeltypen anzeigen oder wenn das Laden nicht geklappt hat, eine Fehlermeldung. Dazu würde ein einziges Overlay reichen, in das das entsprechende eingeblendet wird, also die Artikeltypen oder die Fehlermeldung.

Wenn ich es richtig verstanden habe, könnte man, um das zu optisch stärker zu unterscheiden, die Hintergrundfarbe ändern und/oder ein Status-Icon wechseln.

Ein Overlay im Overlay scheint mir nicht nötig.

Falls ich dich falsch verstanden habe, könntest du vielleicht einen Screenshot posten.

herbivore

@herbivore

Mir ging es bei dem Link nicht um die Implementierung, sondern um die Erläuterung wie so modale Dialoge zur Barrierefreiheit Beitragen.

Wenn man sich aus dem Gesichtpunkt dN!3L Beispiel anschaut (Was mir im überigen auch sehr gut gefällt). Ergeben sich für einen Blinden durchaus Nachteile. Wenn er am Anfang mit Tab, das Form erforscht. Sich die Shortcuts für Abbrechen und Speichern merkt. Und dann nach dem Ausfüllen die Shortcuts verwendet, wird er wohl möglich nie die Warnung mitbekommen.

MFG
Björn

Hallo herbivore,

es wird die Auflistung der Artikeltypen als Overlay angezeigt. - Soweit hast du das schon richtig verstanden. Nach der Auswahl eines Typs sollen die diesem zugeordneten Vermessungsgrenzwerte abgerufen werden. - Hier ist der Punkt wo der Fehler auftreten kann. - Die anders farbige Gestaltung könnte allerdings eine Lösung sein. Das Overlay in dem Fall in einem rot Ton einfärben und die Meldung am unteren Ende auszugeben.

Hallo Palin,

ich bin im Unternehmensumfeld unterwegs, Anwendungen für deren Mitarbeiter. Da war bisher Barrierefreiheit noch kein Thema. Deshalb kann ich dazu konkret nichts sagen. Es würde mich aber sehr wundern, wenn Barrierefreiheit nur mit modalen Dialogen möglich sein sollte. Nur kann ich auf diesem Gebiet keine konkreten Alternativen vorschlagen. Vielleicht kennt sich jemand anders damit aus.

Hallo inflames2k,

ok, dann scheinst du einen Ansatz zu haben.

Was ich mir grundsätzlich auch vorstellen kann, ist in einem Fenster oder einem Overlay, statt nur eine einzelnen Meldung, einen Meldungsstapel einzublenden. Also so, dass weitere Meldungen an der gleichen Stelle eingeblendet werden und dabei die bestehenden Meldungen nach oben (oder unten) schieben. Das kenne ich jetzt zwar eher aus Spielen (oder vielleicht erinnert es auch ein bisschen an ein Chatfenster) und man sollte auch sicher Maßnahmen ergreifen, damit die Anzahl der gleichzeitigen Meldungen nicht überhand nimmt, aber bei dir wäre es ja wohl sowieso auf maximal zwei Meldungen gleichzeitig begrenzt. Das könnte also auch noch eine Idee sein.

herbivore

Hallo Palin,

in dem von dir verlinkten Artikel spricht sich der Autor aber gegen (die im Web üblicherweise verwendeten) Lightboxes (d.h. modale Overlays/Dialogs) aus. Erst durch sein Accessibility-Plugin versucht er der Barrierefreiheit gerecht zu werden.

...Erst durch sein Accessibility-Plugin versucht er der Barrierefreiheit gerecht zu werden. Und ein solches Plugin wäre für WPF ebenfalls einfach möglich wenn dieses durch (genormte) AttachedProperties dem Reader Hinweise über die Lesereihenfolge gibt.

Grundsätzlich sind modale Dialoge keine technische Notwendigkeit. Aber sie sind für den Entwickler halt unglaublich bequem. Das Program wird unterbrochen bis der Anwender eine Antwort gegeben hat, ganz im Sinne der prozeduralen Programmierung. Das lässt sich meisten mit 5-6 Zeilen zu erledigen.

Die Variante ohne Modale Dialoge ist mit sehr sehr viel mehr Eigenarbeit verbunden da die ganze Anwendung darauf vorbereitet sein will(und die der Kunde auch bezahlen muss und der sieht das nach meiner Erfahrung eher pragmatischer)

Ich löse das in kleinen Programmen immer so das ich irgendwelche UserControls hin und her schubse und bei den grösseren Lösungen ist mein Framework von Anfang davon vorbereitet. Da gibts dann immer so eine IAppHost.ShowQuestion/IAppHost.ShowError oder was auch immer Methode.

Idealerweise könnte man eine Formular Klasse(System.Windows.Forms.Form) erstellen die mit einer definierten Methode in der Lage ist UserControls als modales Child ähnlich einem Dialog anzuzeigen und das innerhalb der Anwendung(Parent Windows), und als Bonus sogar in der Lage ist die externen Framwork/oder sonstige Dialoge(OpenFileDialog, etc) einzufangen die auf so eine Verwendung nicht vorbereitet sind.

Ich hatte die Idee vor einigen Jahren schon mal, leider ist das daran gescheitert das die externen Dialoge(OpenFileDialog,etc..) des .Net Frameworks nicht von Control erben, also kein WIN32 API Handle(Control.Handle) haben. Ich hab hab nochmal kurz darüber nachgedacht ob ich irgendwie erraten kann was mein Zielfenster ist aber das erschien mir alles zu unsicher.

So oder so: Ich stimme herbivore voll zu, in der Theorie hat er recht, die Praxis ist aber, schon aus Kostengründen, leider oft eine andere.

"Sie entwickeln Software nicht aus interlektuellem Vergnügen sondern für den "Kunden" - Scott Hanselmann

"Praxis schlägt Theorie" - Joachim Löw

EDIT: In der bisherigen Diskussion habe ich das Gefühl das hier auch 2 Welten aufeinander prallen. Die der Web-Entwickler und die der Desktop Entwickler. Die Web Entwickler haben glaube ich kaum eine andere Wahl als modale Dialoge(mittels dem werkzeug des teufels: also javascript) Die Wahl haben dann eh halt nur die Desktop Entwickler(Microsofts verstossende Kinder)

Hallo Sebastian.Lange,

danke für deine Einschätzung. Dass es in der Praxis leider gewisse Hinderungsgründe geben kann, das umzusetzen, was man als gut und richtig erkannt hat, ist mir bekannt und davon hatte ich schon oben geschrieben.

"Bequem" sind modale Dialoge aber vor allem für den Entwickler und vor allem, weil es ihm eingefahrenes Muster ist und nicht weil der Aufwand für die Alternativen höher oder die Alternativen schlechter wären, ganz im Gegenteil. Ich habe nun schon mehrere Alternativen genannt, deren Aufwand gerade nicht höher ist und bei denen man auch keine größeren Aus- oder Wechselwirkungen hat, als bei modalen Dialogen.

Wenn man das merkt, fällt in den meisten Fällen schon mal das Argument des wirtschaftlichen Zwangs weg.

Ob Web-Entwicker stärker zu modalen Dialogen gezwungen sind als Desktop-Entwickler weiß ich nicht, glaube es aber eigentlich nicht.

Hallo zusammen,

mir ist noch eingefallen, dass modale Dialoge aus Zeiten stammen, wo die Standard-Auflösung von Monitoren 640x480 betrug. Da waren viele Dialog-Fenster (fast oder vollständig) schirmfüllend. Das waren ganz anderer Voraussetzungen als heute. Insofern greift, das Argument auch nicht, dass man es schon immer so gemacht und es sich bewährt hätte. Früher - als z.B. auf Großrechnern - hatte man auch starre fremdbestimmte Dialogabläufe bzw. Maskenfolgen. Diese sind heute nicht nur out, sondern soweit ich weiß nach Arbeitsschutzbestimmungen sogar verboten.

Noch mal zurück zu der damaligen Standard-Auflösung von 640x480. Auf heutige Bildschirme passt oft 10 mal soviel Inhalt oder sogar noch mehr. Das Einblenden von Controls oder Nachrichten direkt ins (Haupt-)Fenster scheiterte früher schlicht und einfach am nicht vorhandenen Platz. Dieses Argument fällt heute meistens weg.

Die Zeiten haben sich geändert. Das ist bedeutet, dass man darüber nachdenken sollte, wie man die neu gewonnenen Möglichkeiten einsetzen kann und wie man - aus meiner Sicht - überkommene Techniken sinnvoll ersetzen kann.

herbivore

Hallo herbivore,

meiner Meinung nach sind alle von Dir bisher genannten Alternativen, zumindest auf WinForms-Seite mit mehr Aufwand verbunden, als die Einblendung einer Messagebox. Letzteres dauert ca. 10 Sekunden (eine Zeile + anschließende Auswertung des Dialogresult).

Sämtliche sonstigen Vorschläge erfordern immer eine Art von Prüfung, ob eine bestimmte Aktion X ausgeführt werden darf, bzw. ob die Voraussetzungen dafür gegeben sind, was sicherlich mehr Entwicklungsaufwand und vor Allem Testaufwand bedeutet.

Etwas Besser sieht es mMn bei WPF aus, hier kann man über Execute / CanExecute sicher schon Einiges abdecken.

Darüber hinaus konntest Du für mich nicht hinreichend darlegen, warum dieser Mehraufwand gerechtfertigt wäre, bzw. welcher Vorteil sich dabei gegenüber normalen modalen Dialogen / Messageboxes ergäbe. Generell frage ich mich nach wie vor, was an einem modalen Dialog schlecht sein soll. Ich lese das immer wieder, aber eine wirklich schlüssige Begründung hat dafür bisher noch niemand geliefert. Ist dieser Gedanke also mehr ein "Problem intellektueller Programmierer" ohne Bezug zur Praxis? Bitte nicht falsch verstehen, wenn ich das etwas provokant in den Raum stelle, ist nicht persönlich gemeint.

Hallo Mallett,

üblicherweise benötigt man auch eine Prüfung, ob die MessageBox angezeigt werden soll oder eine Prüfung, was passieren soll, wenn die MessageBox mit einem bestimmten DialogResult verlassen wurde. Diesen Aufwand spart man durch die Verwendung einer MessageBox schon mal nicht ein. Und ein Label einzublenden statt eine MessageBox anzuzeigen, ist auch kein größerer Aufwand. Und ob der Code, der nach einem Dialog ausgeführt werden soll, hinter dem ShowDialog steht oder im FormClosing des Dialogs, kommt auch so ziemlich auf das gleiche hinaus. Ich sehe da also keinen prinzipiell größeren Aufwand. Du muss schon immer den Gesamtaufwand für die zu realisierende Aktion betrachten. Und da habe exemplarisch ich am Fall oben schon gezeigt, dass der Aufwand so ziemlich auf das gleiche hinausläuft.

Da es oft keinen Mehraufwand gibt, muss ich ihn auch nicht rechtfertigen.

Einige der Gründe, die gegen modale Dialoge sprechen, habe ich in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] genannt; weitere - zugegeben verstreut - in diesem Thread hier. Mag sein, dass sie dich vielleicht nicht überzeugen, aber genannt habe ich die Gründe alle schon.

Abstrakt gesprochen verbessert sich die Bedienbarkeit und Benutzerfreundlichkeit deutlich. Das würde dann sogar einen erhöhten Aufwand rechtfertigen, wenn es ihn tatsächlich gäbe. Aber je länger ich darüber nachdenke und je mehr Alternativen ich beschreibe, desto mehr komme ich zu dem Ergebnis, dass der Aufwand (sowohl in Codemenge als auch in Komplexität) nicht höher ist.

herbivore

@Mallett:

Es gibt Szenarien und Produkte, wo Usability ein wichtiges oder sehr wichtiges Verkaufskriterium ist. Beispielsweise Task-Management-Tools, evtl. Entwickler-Werkzeuge usw. Das kommt natürlich darauf an, wie man sich von anderen Produkten differenzieren kann und wie die Prioritäten liegen.

Und dann spielt es einfach keine Rolle, ob man 10 Minuten Arbeit einsparen kann. Hier zahlt sich jeder Mehraufwand direkt durch eine höhere Kundenzufriedenheit aus. Auf der anderen Seite gibt es natürlich viele B2B-Lösungen, die einfach runterentwickelt werden, die keine Konkurrenz haben oder wo die Feature-Menge entscheidend ist. Das dann wenig Zeit für UI und Usability eingeräumt wird, ist nur logisch.

Die Praxis ist also sehr unterschiedlich.

Btw: Ich glaube in WPF ist der Aufwand eine MessageBox anzuzeigen höher als eine alternative Lösung, weil ich hier mehr Aufwand treiben muss, um die MessageBox für Tests zu mocken.

Und da habe ich, am Fall oben schon gezeigt, dass der Aufwand schon so ziemlich auf das gleiche hinausläuft.

Selbst bei .NET pauschal ist das nicht der Fall.

Eine MessageBox verschwindet immer, ein Overlay nicht. Der Aufwand KANN gar nicht gleich sein.
Was ein deutlich höher Aufwand ist - und das lässt sich nicht leugnen - ist das Testen. Anders sieht das bei WPF aus.

Hier muss abgewogen werden, ob das Overlay nun wirklich einen Mehrwert bietet. Ich seh das - wie einige hier - so, dass dre Mehrwert oft nicht erkennbar ist.
Kommt eben drauf an, was das für eine Software ist. Pauschale Aussagen jeglicher Art sind jedenfalls wenig konstruktiv.

dN!3Ls Beispiel finde ich sehr gut; das findet sich auch in vielen Produkten, wie der kompletten Buhl-Data-Suite wieder.
Dieses Beispiel rechtfertigt in meinen Augen aber in keinster Weise das _generelle _Vermeiden von modalen Dialogen, wenn die Gewichtung an anderer Stelle liegt.

Zusagen, dass das der Entwickler aus Faulheit macht, zeugt von massiver Arroganz.
Es identifizieren sich immer noch die meisten Entwickler mit seinem Werk und das soll natürlich hübsch sein. Viele verzetteln sich dabei auch. Aber trotzdem zu sagen aus Faulheit wird etwas nicht "schön" gemacht ist schon ziemlich respektlos, wenn man die Umstände (Zeitdruck, Vorgaben..) nicht kennt.

Ob Web-Entwicker stärker zu modalen Dialogen gezwungen sind als Desktop-Entwickler weiß ich nicht, glaube es aber eigentlich nicht.

Sobald eine Funktion den Zugriff auf eine durch den Benutzer definierte, externe Ressource benötigt gibts da kein Weg dran vorbei, zB File Upload - außer Du verwendest nicht-barrierefreie Technologie wie Flash.

Hallo Abt,

der Aufwand kann durchaus gleich sein. Wenn das Overlay, wie im Fall oben, von einer Bedingung im TextChanged abhängt, dann wird Enabled von dem Overlay einfach auf das Ergebnis der Bedingung gesetzt. Das Ausblenden erfolgt dann genauso automatisch wie das Einblenden und erfordert keinen zusätzlichen Aufwand, nicht mal eine zusätzliche Codezeile.

Analog sieht es beim Testen aus. Hier muss gar nichts widerlegt werden, sondern ich sehe es wie malignate, dass der Testaufwand durch eine MessageBox sogar höher wäre.

Das Wort "Faulheit" hast du in die Diskussion gebracht. Vor dir hat es keiner erwähnt. Falls du andere Aussagen oder Formulierungen so aufgefasst hast, dass sie einen versteckten Vorwurf enthalten, ist das wohl ein Missverständnis. Wir sollten keine unnötige Schärfe in die Diskussion bringen. Ich jedenfalls habe durchaus Verständnis für die Einflüsse in der Praxis gezeigt.

Wie gesagt, kann ich zu den technischen Möglichkeiten von Web-Anwendungen nicht so viel sagen, aber wenn bei Desktop-Anwendungen keine modalen Dialoge nötig sind, wenn ein Zugriff auf eine externe Ressource benötigt wird, sehe ich nicht, warum das bei Webanwendungen der Fall sein sollte.

herbivore

Hallo,

ich finde die Diskussion entgleitet ein bisschen:

Aufwand: Die Frage ist nicht entscheidend, sondern vielmehr wo meine Prioritäten liegen und was mir den größten Nutzen bringt. In einem Szenario ist es die perfekte UI/UX mit wenigen Features in einem anderen Szenario vielleicht viele Features, mit einer eher funktionalen Oberfläche. Hierbei macht ein kleines Feature wie der Overlay aber nicht den großen Unterschied, sondern eher der Gesamteindruck für den Benutzer.

Externe Resourcen: Möchte man z.B. im Web eine Datei hochladen ist man eben teilweise auf die Dialoge angewiesen, wie sie der Browser implementiert. Die sind nun mal modal, da führt kein Weg daran vorbei. Man kann und sollte vielleicht auch alert und confirm-Boxen verwenden. Hier gibt es mittlerweile ja viele schöne, alternative Lösungen.

Die Diskussion ist aber zu abstrakt und lässt sich nur für bestimmte Szenarien wirklich durchdiskutieren. Da ist die Diskussion auch ein bisschen vom Titel abgewichen. Im Prinzip geht das Thema auch noch viel weiter, ein Beispiel wäre vielleicht auch die Speichern-Ansicht in Office, die zwar kein modaler Dialog ist, aber ähnliche Nachteile hat.

Hallo,
ich habe zur Vermeidung modaler Dialoge in einer Anwendung eine Art erweitertes Benachrichtigungszentrum implementiert.
Erfolge, Infos, Warnungen und Fehler werden dort in einem Stapel angezeigt. Je nach Art hat es eine andere Farbe (z.B. sind Erfolge grün). Zusätzlich werden Erfolge und Infos nach einer bestimmten Zeit automatisch ausgeblendet, da diese Informationen nicht langfristig benötigt werden. Warnungen und Fehler werden automatisch ausgeblendet, wenn sie nicht mehr bestehen, sodass immer nur aktuelle Meldungen in der Liste sind. Soll eine Meldung trotzdem ausgeblendet werden, kann dies der Nutzer manuell durch Anklicken erledigen.

pinki

Hallo herbivore,

Da es oft keinen Mehraufwand gibt, muss ich ihn auch nicht rechtfertigen.

Ich habe auch keine Rechtfertigung verlangt, sondern nur darauf hingewiesen, dass es einen Mehraufwand - wohlgemerkt unter WinForms - praktisch immer gibt. Das willst du nicht einsehen, also lassen wir es dabei.

Einige der Gründe, die gegen modale Dialoge sprechen, habe ich in
> genannt; weitere - zugegeben verstreut - in diesem Thread hier. Mag sein, dass sie dich vielleicht nicht überzeugen, aber genannt habe ich die Gründe alle schon.

Der einzige "Grund" den du dort aufführst, ist die Tatsache, dass Du das Hauptfenster nicht verschieben kannst, während eine Messagebox angezeigt wird. Der Rest sind deine persönlichen Meinungsäußerungen, die man teilen kann aber nicht muss. Zum Thema "Verschieben des Hauptfensters" ist das auch reine Geschmackssache, ob man das nun schlimm findet oder nicht. Das per Definition als Nachteil zu deklarieren ist jedenfalls in der Diskussion unzulässig. Wird z.B. eine Messagebox angezeigt um eine Bestätigung für eine Aktion einzufordern, bevor diese endgültig ausgeführt wird, dann macht es sogar Sinn, dass das Hauptfenster währenddessen nicht verschoben, minimiert oder sonstwas werden kann, damit man als Bediener auch sieht, worauf sich die Bestätigungsabfrage bezieht.

Abstrakt gesprochen verbessert sich die Bedienbarkeit und Benutzerfreundlichkeit deutlich.

Ich akzeptiere Deine Meinung, halte aber meine Meinung dagegen, dass ich es extrem benutzerunfreundlich finde, wenn sich jede Anwendung anders bedienen lässt. Daher ist meine Meinung dazu gegenteilig. Da es in dem Thread aber nicht darum geht, um Meinungsverschiedenheiten zu streiten, nur noch mal der Hinweis, dass sich aus einer persönlichen Vorliebe keine Tatsachenbehauptungen ableiten lassen.

Das würde dann sogar einen erhöhten Aufwand rechtfertigen, wenn es ihn tatsächlich gäbe. Aber je länger ich darüber nachdenke und je mehr Alternativen ich beschreibe, desto mehr komme ich zu dem Ergebnis, dass der Aufwand (sowohl in Codemenge als auch in Komplexität) nicht höher ist.

Wie gesagt, alleine der Testaufwand für eine vom üblichen Standard abweichende Lösung ist automatisch höher. Als Analogon könnte man auch behaupten, es wäre weniger Aufwand, einen eigenen, von Control abgeleiteten Button zu entwickeln und zu verwenden, statt die bereits bestehende Button-Klasse zu benutzen. Die Aussage wäre genau so falsch.

Hallo Mallett,

ich fühle mich an die bereits vor deinem Beitrag erfolgte Aufforderung von gfoidl gebunden, dem Titel des Threads zu folgen und nicht mehr auf der allgemeinen Ebene über modale Dialoge zu diskutieren, zumal deine Ansichten ebenfalls nicht mehr sind als deine persönliche Meinung, die ich an verschiedenen Punkten für sachlich falsch halte, der deshalb bereits oben widersprochen und sie - wiederum nach meiner Ansicht - bereits oben vollständig widerlegt habe. Jeder Leser kann sich seine eigene Meinung bilden (und wird z.B. sehen, dass dass kein Mehraufwand existiert und ich viel mehr und viel relevantere Gründe genannt habe, als du herausgepickt hast).

Das Thema des Threads ist von Anfang an, konkrete Situationen zu nennen, in denen man meint, dass ein modaler Dialog zwingend erforderlich ist, und ich oder ein anderer Helfer doch eine passenden Alternative aufzeigen kann. Ob der Fragesteller die Alternative für besser hält, als einen modalen Dialoge, ist im Grunde schon nicht mehr das Thema, auch wenn ich überzeugt bin, dass alle hier genannten Alternativen besser sind. Jeder der eine konkrete Alternative ernsthaft ausprobiert, wird selbst sehen, was von dem hier von beiden Seiten Behaupteten zutrifft, dazu brauchen wir keine theoretische Diskussion. Probiert es also einfach mal aus.

Klar freue ich mich über jeden, denn ich alleine durch das Aufzeigen - aus meiner Sicht praktikabler - Alternativen von modalen Dialogen abringen kann. Dass mir das (leider) nicht bei jedem gelingen wird, war und ist mir schon klar. Es gab ja schon früher Threads, in denen der Sinn und Unsinn von modalen Dialogen das Thema war. Jeder der die Diskussion über Sinn und Unsinn auf der allgemeinen Ebene diskutieren möchte, kann einen neuen Thread öffnen und dies dort (weiter) diskutieren. Es geht also nicht darum, die Diskussion abzuwürgen, sondern lediglich diesen Thread hier beim eigentlichen Thema zu halten.

herbivore