Einzelnen Beitrag anzeigen

Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.272 Beiträge
 
Delphi 10.4 Sydney
 
#13

AW: Layout von Datenbankanwendungs-Fenstern auf 16:10 Monitoren

  Alt 19. Jan 2018, 13:59
Erstmal freue ich mich, dass mein Post auf so viel konstruktive Resonanz trifft. Um eines mal ganz deutlich zu sagen: Die im Eröffnungspost verlinkten Screenshots (kann ich ja so nennen da ich die nicht selbst gemacht hab ^^) waren eigentlich völlig willkürlich herausgepickt, weil ich das Bild grad aus einem anderen Thread vor Augen hatte. Diese "Tabberitis" kann man eigentlich in nahezu allen Wawis quer durchs Gemüsebeet beobachten (willkürlich per Google rausgepickt):

Büroware
HS Auftragsbearbeitung
Sage Office Line
Wintech Auftrag

Für mich hängen UI-Layout und Workflow immer sehr eng zusammen. Es macht IMHO einen gewaltigen Unterschied, ob z.B. die Belegerfassung Shop-zentriert erfolgt, wo viele Datenfelder vom Kunden bereits vorbelegt wurden. Oder aber ob man einen Vertrieb per Telefon hat, wo man den Kunden im laufenden Gespräch nur bedingt durch die Informationspfade des UI lenken kann. So ist das bei uns häufig.

So habe ich die Erfahrung gemacht, dass unsere Vertriebler nur ungern Shortcuts verwenden. Unser Wawi (ich nenne hier bewusst keine Namen) hat eine umfangreiche und ausgefeilte Shortcut-Steuerung. Viele Abläufe ließen sich über die F-Tasten wunderbar vereinfachen. Oder selbst das simple Anspringen von Eingabefeldern per TAB wird kaum genutzt. Die Leute greifen lieber ständig zwischen Maus und Tastatur hin und her, klicken sogar direkt aufeinander folgende Edits einzeln an.

Der naheliegendste Gedanke darauf hin ist meistens: Dann müssen die Anwender halt so lange geschult und trainiert werden, bis die das kapieren. Ich frage mich aber, ob es nicht sinnvoller ist, sich mit dem UI an sich verändernde Nutzungsgewohnheiten und Standards (meine insbesondere Standardauflösungen bei Monitoren) anzupassen anstatt immer oberlehrerhaft Bedienkonzepte durchsetzen zu wollen, die noch aus DOS-Zeiten stammen können. Langfristig ist doch das Programm das erfolgreichere, das den Anwender am meisten zufrieden stellt.

Den Verweis auf Mobilgeräte finde ich wichtig. Jedoch aus einem anderen Grund. Meiner Meinung nach sind Mobilgeräte nicht für alle Anwendungsfälle gleich gut geeignet. Irgendwie kann ich mir kein Szenario vorstellen, wo umfangreiche Eingaben in viele verschiedene Edits, wie sie üblicherweise bei Belegerfassung stattfinden, mit einem Tablet oder Smartphone per Toucheingabe erfolgen sollten - weil es einfach ineffizient ist. Wenn man das Tablet in ein Dock stellt und Tastaturen und Monitore anschließt, ist es IMHO kein Tablet mehr sondern eher ein verkrüppelter Desktop-Ersatz. Jetzt ein UI mit vielen Edits quasi responsiv zu machen, führt doch eher dazu, dass auf Desktop-Arbeitsplätzen viel verfügbarer UI-Raum sinnlos verschwendet wird.

Mir gefällt der Ansatz, einem Programm so eine Art Objektinspektor zur Layoutanpassung mitzugeben, viel besser als der Versuch mit responsiven Techniken ein UI für alle Arten von Bildschirmgröße zu bauen. Auf diese Weise könnte man auch ein Set von vordefinierten Layouts für typische Szenarien mitgeben. Doch grundsätzlich muss man sich vorher schon Gedanken machen, ob der exzessive Gebrauch von Tabsets Sinn macht oder nicht. Denn genau das wars ja, was bei uns am meisten bemängelt wurde: Dass das UI so unübersichtlich ist und der Großteil der verfügbaren Informationen stets hinter inaktiven Tabs versteckt ist.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden

Geändert von Codehunter (19. Jan 2018 um 14:01 Uhr)
  Mit Zitat antworten Zitat