Layout von Datenbankanwendungs-Fenstern auf 16:10 Monitoren

[p80286]

Meiner Meinung nach, hat Codehunter das Problem richtig beschrieben, aber die falschen Schlüsse gezogen. Der Benutzer, der Daten zu bearbeiten hat, möchte dafür nur ein Bild (Formular) nutzen. Hin und her blättern unterbricht da nur den Arbeitsablauf. Und je nach Aufgabenstellung (des Arbeitsplatzes) sind die Anforderungen an die Oberfläche ganz andere. Bei der Erfassung von Adressen z.B. ist es manchmal angenehm verschiedene Adressarten gleichzeitig in der Anzeige zu haben (Versand-,Rechnungs-Adresse). Wer eine Rechnung erstellt, den interessiert die Versandadresse nicht unbedingt.
Diese Abbildung von Arbeitsabläufen ist meiner Meinung nach wichtiger als die optimale Ausnutzung von Bildschirmoberfläche.

Gruß
K-H

[jobo]

Zitat von p80286:

Diese Abbildung von Arbeitsabläufen ist meiner Meinung nach wichtiger als die optimale Ausnutzung von Bildschirmoberfläche.

Das scheint mir ein Kernpunkt zu sein. (Wobei hier der Punkt, neue Software = neue Möglichkeiten = neue-verbesserte- Abläufe dem Ganzen noch einen interessanten Dreh gibt).
Die optimale Ausnutzung der Bildschirnmoberfläche steht dabei vielleicht hinten an, aber nicht wirklich weit hinten. Dass dieses Thema mit aktuellen (und zukünftigen) Arbeitsmitteln eher komplexer als einfacher wird, dürfte auch klar sein. Auflösung, relative Auflösung, Seitenverhältnis sind da sehr wichtige Basics, Medienarten jenseits des Monitors als Standarddarstellungswerkzeug sind sicher eine große Herausforderung, vom Smartphonescreen bis zu AR Visualisierung oder auch Einbeziehung von TextToSpeech, usw..
ResponsiveDesign wurde bspw. genannt und ist ja an sich nicht neu. Schaut man auf alte Erfolgsmerkmale von Delphi, dann sähe ich hier eigentlich einen großen Spielraum im Komponentenbereich, mit leistungsfähigen, komplexen und smarten Komponenten neue Maßstäbe zu setzen, gerade im Hinblick auf das Threadthema.

[blondervolker]

Morgen,

was für "Faule"... ResizeKit... Dann klappt es auch...Siehe Abbildung...

[Daniel]

Zitat von blondervolker:

was für "Faule"... ResizeKit... Dann klappt es auch...Siehe Abbildung...

Kannst Du das weiter ausführen? Was genau macht diese Komponente? Welche Voraussetzungen müssen erfüllt sein, welche Möglichkeiten und Grenzen hat diese Komponente? So knapp formuliert hilft Dein Beitrag nur wenig weiter.

[Fukiszo]

Wenn ein Formular dynamisch sein soll, geh ich ähnlich vor.
Der Anfang bei mir ist ein minimal formular wo alle controls reinpassen.
Dann les ich Monitor dimensionen aus um auf diese Werte reagieren zu können.
Je nach benutzer/rechte kann man entweder sich ein von mir vorgefertigtes design aussuchen,
auch pivot designs sind enthalten,
oder wie IBexpert bereits schrieb sich alle controls selbst zurechtschieben.
Wobei ich immer die zuvor ausgelesenen Dimensionen berücksichtige.
Ich arbeite allerdings nicht direkt mit dem basis formular,
das dient mir nur als vorlage um alle controls in das "anzeige formular" zu übertragen.
In den grundeinstellungen biete ich, je nach produkt, auch multi-monitor support an,
so das der anwender das original formular auch splitten kann.
Dynamisch halt.

[Jasocul]

Zitat von Daniel:

Zitat von blondervolker:

was für "Faule"... ResizeKit... Dann klappt es auch...Siehe Abbildung...

Kannst Du das weiter ausführen? Was genau macht diese Komponente? Welche Voraussetzungen müssen erfüllt sein, welche Möglichkeiten und Grenzen hat diese Komponente? So knapp formuliert hilft Dein Beitrag nur wenig weiter.

Die Komponente skaliert "alle" Controls auf der Form mit (inkl. Font), wenn die Größe der Form verändert wird.
Ich hatte die Komponente auch mal im Einsatz. Sie unterstützt aber nicht alles (Grids und Frames waren z.B. ein Problem), wodurch es teilweise ziemlich beknackt aussieht. Es gibt zwar ein Event, wo man dann selbst noch eingreifen kann, aber ... .
Ich habe das dann einmal selbst programmiert (mit erweiterter Funktionalität). Ist dann eine Komponente mit 500 Zeilen Code geworden. Also nix Großes. Da es Firmen-Code ist, kann ich es hier aber leider nicht zur Verfügung stellen. Für Fragen (PN) bin ich aber offen, falls Bedarf ist.

[Codehunter]

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.

[stahli]

Hallo Codehunter,

eine ganz klare Meinung kann ich hier nicht abgeben, aber vielleicht mal ein paar passende Links:

Hier hatte ich eine DOS-ähnliche Oberfläche im Möbelhaus gesehen, mit der die Verkäufer offenbar (und für mich überraschend) bestens zurecht kamen.
http://www.delphipraxis.net/191273-dos-like.html

Wenn Du bisherigen Tab-Inhalte künftig nebeneinander anordnen willst, kämen vielleicht Groupboxen in Betracht, die ggf. umgebrochen werden.
http://www.delphipraxis.net/165177-scrollboxflow.html

Hier hatte ich mal einen Versuch gemacht, dass Controls nach bestimmten Regeln gestaucht, gestreckt und verschoben werden (so eine Art Physik).
http://www.delphipraxis.net/1230983-post4.html

Die beste Lösung ist sicher, den Bearbeitern Möglichkeiten zu geben, die Formulare nach eigenen Bedürfnissen anzupassen.

[p80286]

Zitat von Codehunter:

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.

Das kommt darauf an.
Ich habe mich dabei erwischt, daß ich das gleiche Programm auf drei unterschiedlichen Rechnern (Laptop ohne ext. Mouse, Laptop mit externer Mouse, Desktop mit Trackball) unterschiedlich bediene. Es scheint also daran zu liegen, welche Bedienmöglichkeiten ich habe. Es nur auf den dummen Benutzer zu schieben geht wohl an der Realität vorbei.
Diese DOS-Oberflächen gefallen mir auch recht gut, weil die übersichtlich sind. Sie verlangen natürlich auch angepasste Texte. Mit einem spanischen Programm kommt man da in Deutschland nicht weit. Dafür sollten Spanier und Deutsche aber kein Problem mit dem Drucker Symbol haben.

Gruß
K-H