Bearbeiten in Grids vs. Detailformularen - wie schlau sind Endbenutzer?

Meiner Erfahrung nach können Grids mit Bearbeitung sowohl für den Programmierer als auch für den Tester und den Benutzer schwierig sein, da der Auslöser für die Validierung normalerweise das Killfokusereignis ist. Das bedeutet, dass der Benutzer eine Zelle ausblendet und mit einem Fehler in dieser Zelle gestoppt wird, bis er sie korrigiert.

Ist das in Ordnung? Hängt davon ab.

Wenn die Daten in jeder Zelle im Grid validiert werden können, ohne auf andere Zellen und besonders auf andere Zeilen zu verweisen, dann ist das vielleicht in Ordnung. Wenn die Gültigkeit einer Zelle jedoch von dem Wert in einer anderen Zelle abhängt, kann eine Überprüfung durch den Kill-Fokus schwierig sein. Ihr Benutzer kann in eine Situation geraten, in der er SOMETHING in eine Zelle setzen muss, nur um diese Zelle verlassen zu können und zu der realen Zelle zu navigieren, die das Problem verursacht.

Ein weiterer Vorteil eines Dialogfelds besteht darin, dass neben den fehlerhaften Feldern eine Menge Platz auf dem Bildschirm für hilfreiche Texte, längere Beschriftungen und mehrere Fehlermeldungen gleichzeitig vorhanden ist. In einem Raster können Sie manchmal nur die Zellenfarbe ändern und einen modalen Dialog für genau diese Zelle öffnen.

Ich arbeite an einer App, die eine App ersetzt hat, die in Gittern bearbeitet wurde. Jeder Programmierer, der an der älteren App beteiligt war, stimmte zu, dass in der neuen App keine Bearbeitung in den Grids stattfinden würde und dass wir nicht faul sind. Wir wollten nur etwas liefern, von dem wir wussten, dass wir es stabil machen könnten, was für unsere Tester einfacher wäre.

Ich stimme zu, dass Benutzer mit Excel-Erfahrung komfortabel in Gittern arbeiten, aber dann sollten Sie besser sicherstellen, dass Ihre Grids genauso gut funktionieren wie die Grids von Excel.

Wenn möglich, bearbeiten Sie direkt im Raster und haben keinen Bearbeitungsdialog. Ich kann mir keinen Vorteil vorstellen, einen "Bearbeitungsmodus" zu haben, und es verschwendet Zeit und bringt der App Komplexität (aus der Sicht des Benutzers). Ein Bearbeitungsdialog macht es schwieriger, die App zu erlernen, als sie vor Ort zu bearbeiten, weil der Benutzer zwei Fenster und lernen muss, um zu navigieren zwischen ihnen.

Wie die Erfahrung mit Excel, Access und anderen Desktop-Apps zeigt, haben Benutzer kein Problem damit, ein Grid zu bearbeiten, anstatt etwas anderes zu bearbeiten. Sie sollten kein Problem haben, insbesondere wenn Sie Ihr Grid wie ein Excel-Arbeitsblatt oder eine Access-Tabelle oder ein Access-Formular aussehen lassen und nicht wie Ihre typische Web-App "Click here to update".

Ich denke, dass die Tendenz einiger Entwickler, schreibgeschützte Raster zu erstellen, ein Überbleibsel aus den frühen Web-App-Tagen ist, als es keine bearbeitbaren Raster oder gar keine Raster gab - es gab HTML-Tabellen und jede Bearbeitung erforderte ein Formular. Ich sehe keine Entschuldigung für den Bearbeitungsmodus mit der heutigen Technologie.

Wie zur Validierung, informieren Sie den Benutzer über alle Validierungsfehler, wenn der Fokus die Zelle verlässt, aber keine modalen Fehlermeldungen verwenden (das Markieren des Feldes mit Farbe ist eine Möglichkeit, aber nicht ein der einzige Weg). Lassen Sie den Benutzer korrigieren, wann immer Sie möchten, vielleicht indem Sie andere Felder fixieren. Dies löst das abhängige Validierungsproblem.

Wenn es asynchron oder in weniger als einer halben Sekunde durchgeführt werden kann, sollten Sie automatisch Datensatzänderungen mit dem Fokusverlust auf die Zelle oder (alternativ) auf die Zeile schreiben. Dies betrifft die Probleme des gleichzeitigen Zugriffs auf mehrere Benutzer-Apps und bietet Ihren Benutzern eine implizite Speicherung, eine weitere Verbesserung der Benutzerfreundlichkeit, die Web-Apps nutzen könnten.

Die direkte Manipulation ist ein bewährtes Usability-Prinzip, seit GUIs erfunden wurden. Modi sind seit langem bekannt, um Usability-Probleme zu präsentieren. Es ist höchste Zeit, dass Web-Apps mit einer Benutzerfreundlichkeit von 1980 aufwarten.

Übrigens, viele erläuternde In-Window-Texte (z. B. lange Labels und mehrere Nachrichten) sind ein Hinweis auf ein Usability-Problem, keine Lösung.

Benutzer können vollständig mit Gittern umgehen. Es ist intuitiver als eine Bearbeitungsschaltfläche und ein Detailformular.

Ist diese Anwendung jedoch eine Anwendung für mehrere Benutzer? Können die zugrunde liegenden Daten von mehreren Benutzern gleichzeitig geändert werden? Wenn dies der Fall ist, müssen Sie einige Entwurfsentscheidungen für den gemeinsamen Zugriff treffen. Dies kann manchmal einfacher zu lösen sein, wenn Benutzer nur eine Zeile gleichzeitig bearbeiten können.

Es riecht allerdings ein wenig fischig, und ich vermute, dass Ihr Programmierer praktische Ausreden macht, weil es einfacher für ihn ist, schreibgeschützte Gitter in einem Master / Detail-Muster zu entwerfen.

Bleib bei deinem Bauchgefühl. :)

Wenn Sie Ihrem Hauptentwickler nicht vollständig vertrauen , sollten sie nicht Ihr Hauptentwickler sein.

Nebenbei: Wenn Ihr Hauptentwickler einen Abschluss in Informatik (oder einem ähnlichen Abschluss) hat, nennen Sie ihn nicht "Programmierer". Es ist negativ für einen professionellen Ingenieur.

Wenn Sie ihre Entscheidung außer Kraft setzen, werden sie die Liebe nicht am wenigsten spüren. Seien Sie sehr vorsichtig, wenn Sie Ihren Softwareingenieuren auf die Zehen treten. Tun Sie das nur, wenn Sie sich zu 100% sicher sind, dass sie einen Fehler machen. Selbst dann können Sie das Problem so angehen, dass es erkennt, dass es ein Fehler ist, ohne dass Sie tatsächlich eine ihrer Entscheidungen außer Kraft setzen. Hilf ihnen, die bessere Entscheidung zu treffen, indem du sie fragst, wie sie den speziellen Fall lösen könnten, um den du dir Sorgen machst. Wenn sie sich nicht um den gleichen Fall sorgen, lass es gehen. Deshalb sind sie der Hauptentwickler. Solange sie schlau sind und Ihre Bedenken verstehen, ist das das Beste, was Sie tun können, solange Sie die richtigen Leute einstellen. Der Schaden, den Sie Ihrer Beziehung und ihrer Produktivität zufügen könnten, indem Sie die Entscheidung Ihres Hauptentwicklers außer Kraft setzen, könnte weit schlimmer sein als die bearbeitbare gegenüber der nicht editierbaren Rasteransicht.