Layout von Datenbankanwendungs-Fenstern auf 16:10 Monitoren

[Codehunter]

Hallo,

ich möchte mal ein paar Gedanken zum Thema Oberflächendesign loswerden, die mich seit längerem umtreiben. Alles fing eigentlich gar nicht mit meinen eigenen Programmen an, sondern mit zugekauften Wawis etc.

Wir haben in unserer Firma vor mehreren Jahren ein anderes Wawi eingeführt. Seitdem beschweren sich die Nutzer über das umständliche Handling. Irgendwann hab ich mich einen Tag daneben gesetzt und zugeschaut, wie die das im Alltag handhaben. Dabei stellte sich heraus, dass die Mauspfade und Klickfolgen sehr lang sind, um auch nur einen Beleg zu erstellen.

Dann habe ich mir die Oberflächen angeschaut. Mir fiel recht schnell auf, dass die Eingabemasken mit sehr vielen Pagecontrols arbeiten und darüber die einzelnen "Themenbereiche" wie z.B. Belegkopfdaten, Artikelpositionen usw. voneinander trennen.

Wenn man nun so eine Eingabemaske auf einem FullHD-Monitor maximiert, dann hat man regelmäßig den Effekt, dass sich im linken Drittel des Bildschirms sehr viele Controls befinden, während die rechten zwei Drittel leer bleiben oder "großzügigerweise" von einem Freitext-Memo ausgefüllt werden.

Irgendwann hatte ich mal einen Arbeitsplatz mit einem älteren 4:3-Monitor und 1280x1024 Auflösung. Dort ergab diese Anordnung plötzlich Sinn, der Platz wurde optimal ausgenutzt.

Hier eine typische Eingabemaske von einem aktuellen Wawi (nicht das was wir einsetzen, aber ein typischer Fall vom beschriebenen Problem):

Bild 1
Bild 2

Nur sind doch heutzutage Full-HD-Monitore mit 1920x1080 eigentlich der unterste Standard. Also nicht nur dass die Auflösung höher ist, auch das Seitenverhältnis ist ein anderes. Darum frage ich mich, ob man eigene Anwendungen nicht für Full HD optimieren und das ganze Eingabelayout umkrempeln sollte.

Am Beispiel einer Belegeingabemaske könnte man die Kopfdaten im linken Drittel erfassen, die Artikelpositionen im mittleren Drittel und die Fußoptionen wie Versandart, Lieferkonditionen etc. im rechten Drittel.

Noch eleganter wäre es, wenn man sich einen 16:10-Monitor um 90 Grad gedreht vorstellt (Pivot-Funktion). Dann könnte man die Eingabemaske strukturell schon so abbilden (abstrahiert), wie sie später auch auf einem Beleg ausgegeben werden.

Ich habe mal probeweise so eine "Portrait-Eingabemaske" als Dummy erstellt und einen unserer Vertriebler damit konfrontiert. Zuerst fand der das ziemlich bekloppt, den Monitor hochkant zu stellen. Doch nachdem ich ihn (gespielt) drei Belege im Akkord eingeben lassen habe, wollte der plötzlich gar nicht mehr aufhören. Am Ende beschwerte er sich sogar, dass das nur ein Dummy war und nicht auf unser zugekauftes Wawi übertragbar.

Was meint ihr: Wäre die Zeit reif, um Programme anzubieten, die sich komplett auf aktuelle Bildschirmauflösungen orientieren, statt (als Entwickler) immer noch gedanklich auf einen vermeintlichen, jedoch lange veralteten Mindeststandard von 1280x1024 zu orientieren? Könnte man gar Monitore mit Pivot-Funktion als Mindestanforderung für professionelle, an gewerbliche Anwender richtende Programme vorgeben?

Beim Praxistest ergab sich übrigens noch die Erfahrung, dass man die Pivot-Funktion nur mit IPS-Panels sinnvoll einsetzen kann. Bei TN-Panels jeglicher Couleur sind die Betrachtungswinkel im Hochformat nicht ausreichend. Man hat dann grässliche Farb- und Helligkeitsverläufe von oben nach unten.

Grüße
Cody

[mensch72]

Wir erstellen zufällig auch Software für den sagen wir "gehobenen/speziellen" Finanzsektor.
Da haben wir ganz oft mit verschiedensten (Multi)Bildschirmlayouts zu tun.

Ich unterscheide aktuell 4 Screen-Designs:
- 4:3/Quadratisch/3:4 (=> läuft bei mir alles unter "Quadrat-Design")
- 16:9/16:10"waagerecht" (=> läuft bei mir unter "Breitbild")
- 9:16/10:16"senkrecht" (wird aber eigentlich nur im "FreeUserMode" genutzt)
- für Extrembreitbild 20..21:9 unterstützen wir ein simuliertes/virtuelles DualScreen mit "fast quadratischem" zwei mal 10:9

=> bei klassischem 4:3 platzieren wir im "Quadrat-Design" Menü und Auswahl stets "oben"
=> bei "Breitbild" 16:9/16:10 platzieren wir Menü und Auswahl optional link oder rechts(wahlweise als reiner TreeView oder "segmentierter 2003er ExchangebarStyle" mit SubTree's)


"ResponsiveDesign's als Entwurfspattern" hin oder her, auch bei mobile definiere ich funktional lieber stets 3 oder 4 separate Oberflächen(quer, quadratisch, hoch, optional "mini" für Smartwatch).
Viele IDEs behaupten zwar man könne das z.B. per "MultiView" rein per variablem Design funktional auch mit einem Quellcode lösen...
nö: ich behaupte wenn man Daten&Funktion&Design eh sauber getrennt hat, kann man selbst fix frei wahlweise entscheiden ob man mit einem weiterem Design(View) auskommt, oder ob man eine zusätzliche Kombi mit/aus Funktion&Design realisiert... ich kann&mache je nach Bedarf beides.

[IBExpert]

Mal so als ergänzende Anregung (und wie wir das in unserer BRP Software machen):

Ein generelles Layout für alle Anwender ist immer ein Kompromiss, den der Programmierer vorgibt.
Alle Wünsche aller Anwender zu erfassen ist unmöglich, erst recht dann, wenn auch noch völlig unterschiedliche
Abteilungen oder ganz andere Firmen mit der Software arbeiten.

Wir haben in unserer Applikation einen simplen Designmodus eingebaut, bei dem der Anwender (jedenfalls
dann wenn er in der Software einen Account mit entsprechende Rechten benutzt) die Position aller
Controls selber bestimmen. Wenn er per Rechtsklick Popup Menü den Designmodus aktiviert, dann kann
er jedes Control anklicken und über das OnClick Event werden alle Selektieren Komponenten in eine
TList eingetragen und farblich verändert, so das man erkennt, was markiert ist. Durch erneutes anklicken
wird die Komponente wieder auf normale Farbe gestellt und aus der TList entfernt.

Über simple Tastenkombinationen Ctrl+Cursortasten bzw Alt+Cursortasten kann er nun alle selektierten Komponenten
frei auf dem Form damit pixelweise hin schieben wo er das haben möchte, weil die entsprechenden Events auf dem Form
in entsprechenden popup menu items per short cut hinterlegt sind, aber nur dann aktiv sind, wenn
Designmode aktiv ist.

Beim Beenden des Designmodes (wieder über popup) gehen wir einfach durch die Components im aktuellen form
und schreiben die relevaten Eigenschaften (top/left/height/width) zusammen mit dem Komopnenten Name
in eine TStringlist in so einem Format

edtNachname.left=123
edtNachname.top=10


usw.

Bei uns landet das dann in der Datenbank und kann global für alle User gelten. Optional kann aber auch
ein User sich die vorgegebenen Eigenschaften noch mal überschreiben, so das der mit zB seinem 4K Screen ein
ganz anderes layout hat als seine Kollegen mit zB FHD Screen.

Beim nächsten Laden des Formulars wird dann aus einer Tabellen zu jedem Form je nach o.a. Implementation
die Stringlist aus einem Blob geladen, wieder in eine Stringlist gepackt und im OnShow Event abgearbeitet.
Dabei gehen wir dann einfach wieder durch die automatisch erzeugten Components, holen deren Namen und suchen
in der TStringlist über Values nach der zugehörigen Eigenschaft. Wenn die gesetzt wurde, wird die automatische
Größe/Position verändert und erscheint mit der Anzeige da wo der Endanwender das bestimmt hat.

Das System kann man bis hin zu Schriften, Font Eigenschaften, Farben, Sichtbarkeit usw ergänzen, wenn man will.

Die Tabreihenfolge legen wie fest über die generelle Vertikale Position und wenn top identisch ist geht es innerhalb
der aufsteigenden Left werte weiter. Das ist einfach zu automatisieren.

Die fest einkompilierten Werte aus der Dfm Datei, die ja nur der Delphi Entwickler bestimmt, kann der mehr oder weniger
talentierte Enduser dann auf Wunsch auf diesem Weg selber anpassen. Alternativ kannst du für deine Software auch unterschiedliche
Layouts auf dem Wege gleich mitliefern.

Bei unserem wichtigsten Kunden für BRP macht ein Mitarbeiter des Kunden immer das komplette Formdesign, ohne jemals
einen Delphi oder Lazarus Compiler benutzt zu haben. Und ganz wichtig: Er überlegt sich auch oft später anhand neuer
Erkenntnisse andere Reihenfolgen innerhalb der Formulare. Da muss er uns nicht mal danach fragen ....

Auf deinen Beispielbildern sieht man ganz gut das bei vielen WAWIs viele Einstellungen möglich sind, die der
Durchschnittsanwender nicht kennt und auch nicht für irgendwas benutzen sollte, wofür es gar nicht gedacht ist.
Das dynamische Ausblenden von solchen Felder erleichtert den Anwendern das leben ganz erheblich und der Programmierer
muss sich nicht 100 Meinungen anhören, in welcher Reihenfolge das denn viel besser wäre. Du gibst nur den Default
vor und überlässt dem Endanwender/Kunden das Customizing. Automatisch angepasste Designs können da auch nur Kompromisse sein.

[Ghostwalker]

Eine UI auf eine bestimmte Auflösung zu optimieren macht imho keinen Sinn.

1. Man kann nie Sicherstellen, das (im laufe der Jahre), diese Auflösung gängig bleibt.

2. Wenn die Anwendung auch ggf. auf Mobil-Geräten laufen soll, hast du hier wieder ganz
andere Auflösungen. Auch in der Industrie werden z.B. Tablets gerne eingesetzt (z.B. Lagerhaltung).

3. Daran denken, nicht jeder Anwender arbeitet im Vollbild-Modus.:)


Deshalb würd ich auf folgende Punkte achten:

1. Basis-Design so "klein" wie möglich. Darauf achten, das die Anwendung dabei noch gut bedienbar ist.
2. Von Haus auf die Möglichkeit berücksichtigen, das man evtl. mehrere angepasste Designs verwendet.

Da ich die letzen Jahre vorwiegen Webanwendungen (nein..nicht Webseiten sondern richtige Anwednungen :) ) programmiert habe, hat mich dieser Ansatz recht weit gebracht.

[bepe]

Wenn du als Beispiel schon ein Programm zeigst, an dem ich vor vielen Jahren, viele Jahre lang mitentwickelt habe, dann muss ich auch eine mögliche Lösung anhand von Software aufzeigen, an der ich aktuell mitarbeite :-D

Habe keine schönen Screenshots zur Hand aber auf Youtube haben wir angefangen Videos zu veröffentlichen.

Dort werden die einzelnen Reiter neben- bzw. untereinander angezeigt (per Einstellungen auch als klassische Reiter). Das ganze geschieht dynamisch, abhängig vom Seitenverhältnis des Fensters. Also wird der Platz immer ideal ausgenutzt. Auch hochkant passt (wenn du Tablets, Convertibles etc. drehst, passt sich die Oberfläche an).

Technisch eher eine riesen Maske durch die man scrollen kann. Und die Tabs sind Sprungmarken zum schnellen navigieren.

[TigerLilly]

Spannender Thread. :-)

In Ergänzung zu den schon gesagten Dingen:
Früher, als die kleinen Auflösungen Standard waren, waren Anwendungen leichter zu bedienen, wenn sie im Fullscreen-Modus betrieben wurden. Gleichzeitig mit den höheren Auflösungen sind aber iPads, Tablets etc aufgekommen, die zwar hohe Auflösungen haben, aber geringe physische Maße. So mag ein Tablet die gleiche Auflösung wie ein 30 Zöller haben, aber die physischen Maße sind ganz andere.

So hat es wenig Sinn, eine Software auf den 30 Zöller im Vollbildmodus zu betrieben, während es auf dem Tablet die einzige Möglichkeit ist, damit sinnvoll zu arbeiten.

Wie so oft hängt eine Antwort von der Zielgruppe ab. Habe ich Finanzer, die jede Menge Diagramme und Tabellen in Echtzeit und gleichzeitig sehen wollen, muss ich anders designen, als wenn ich von Personen ausgehe, die Laptops benutzen und dann solche, die ev. schon in die Jahre gekommen sind.

Auf einem riesen Monitor kommen sehr große links/rechts Wege zusammen, da hat FullScreen keinen Sinn. Das wäre viel zu viel Info und der Überblick ginge völlig verloren.

In der Regel (= Achtung: Hinweis auf mögliche Ausnahmen!) genügt es, eine 1024x768 Auflösung bei 96 DPI beim Designen vor Augen zu haben. Das entspricht ca. einer DinA4 Seite + enthält die Menge an Daten, die man visuell noch sinnvoll erfassen kann. Monitor Hochformat/Querformat, individuelle Layouts etc sind cool + super Ideen, die grundsätzlich dargestellte Datenmenge sollte DinA4 nicht überschreiten. Stichwort Ergonomie von Software-UI.

Wir erleben durch Tablets und Mobiles einen ziemlichen Rückschritt, was UI anbelangt, weil die benutzbare Fläche wieder klein geworden ist. Wir haben zwar viel höhere Auflösungen, aber die Bildschirmdiagonale eines Tablets entspricht der eines Monitors aus 1990. Insoferne haben die Ergonomieüberlegungen von damals immer noch Gültigkeit.

[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:

Zitat von p80286 (Beitrag 1391352)

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...:-D

[Daniel]

Zitat:

Zitat von blondervolker (Beitrag 1391360)

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

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:

Zitat von Daniel (Beitrag 1391367)

Zitat:

Zitat von blondervolker (Beitrag 1391360)

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

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.

[HolgerX]

Hmm..

Und mal über den Tellerrand!
Der Windows-Standard bei den Menus immer Oben positioniert zu sein, mag bei Mausschubser noch gut sein, aber spätestens bei Verwendung eines 19/20/24 Zoll TouchScreen an einem Haltearm nerven... (Immer dieses nach oben strecken, um an das Menu zu kommen).

Hier sollten die 'wichtigsten' Bedienungsknöpfe oder Menus eher unten angeordnet werden. (Kleine Mitarbeiter danken! ;) )
Deshalb sollte nicht nur auf die 'Größe'/'Auflösung' des Bildschirmes geschaut werden, sondern auch auf die Art mit deren anderer Benutzung.

Nur, wenn ich selbst bei Software für Touchtablets immer noch die Bedienelemente oben angeordnet finde, dann ist mir klar, das die Software auf einem 'Maussystem' entwickelt wurde und die Useability nie von kritischen Anwendern getestet wurde.
;)

(Nur so eine Idee, ohne Anspruch auf richtigkeit ;) )

[Codehunter]

Diese DOS- bzw. eher Clipper-ähnlichen Windows-Oberflächen habe ich auch schon einige Male gesehen. Glaube die Wawi bei Raiffeisen basiert noch darauf. Beim Arbeitsamt war sowas vor 10 Jahren auch noch im Einsatz, keine Ahnung wie das heute aussieht.

Interessant ist das schon, weil man sich hier voll und ganz auf Text beschränkt. Das sind ja eigentlich sehr starre Oberflächen. Ich kann mich nicht erinnern, dass damals das Konzept der Tabsets schon üblich war. Vielmehr hatten wir damals doch eher so browserartige Fenster, die man komplett durchgescrollt hat.

Es kam ja schon der Hinweis auf die A4-Orientierung. Das ist ja im Prinzip das selbe was ich auch eingangs schon erwähnt habe: Dass man den späteren Beleg in einer abstrakten Form schon mal abildet. Dafür eignen sich z.B. aufklappbare Bands sehr gut. Quasi so Groupboxen mit einem Treenode-artigen Aufklapp-Button. Auf diese Weise kann der Anwender zusätzliche Abschnitte einblenden, z.B. zusätzliche Lieferkonditionen oder abweichende Lieferanschrift. Wysiwyg im ursprünglichen Sinne würde ich sagen :-)

So ein Konzept macht natürlich nur dort Sinn, wo die Eingabe unmittelbar an eine Belegausgabe gekoppelt ist. Es gibt auch abstraktere Themengebiete wie z.B. Artikel- und Kundenstamm. Wobei ich mir vorstellen könnte beim Artikelstamm auf ein typisches Shoplayout zurück zu greifen. Bei allen größeren Plattformen wie ebay, Amazon, Zalando, usw. werden auch vertikale Layouts verwendet. Tabsets gibts da keine.

Bei alldem komme ich immer wieder auf das gleiche Ergebnis: 16:10-Bildschirme im Landscape-Modus sind denkbar ungünstig für die Erfassung komplexer strukturierter Daten. Weder das Auge noch die "Maushand" mögen weite horizontale Wege. Eigentlich müssten 4:3-Monitore die bessere Wahl sein, doch dort hörte die Entwicklung bei 21 Zoll und 1280x1024 auf, was heute auch sehr wenig ist.

[blondervolker]

Ja ich sollte dies mal beschreiben hier der Link:

http://www.imagekit.com/resizekit2.html

Funktioniert bei mir perfekt... Auch mit vielen "Schnulli" auf der Form...:-D

Kostet etwas Geld...:-D

[Neumann]

Diese "DOS-artigen" Systeme sind Software-Terminals von IBM System I oder dem Vorgänger AS400. Diese Terminals laufen in der Regel auf normalen Windows-PC. Dieses wird in der Regel bei großen Firmen mit vielen Standorten eingesetzt und ist für seine Stabilität bekannt. Habe vor langer Zeit(>15 Jahre) auch mal ab und zu in der Firma gearbeitet in der ich damals beschäftigt war; ich habe das z.B. für Bestellungen, Freigabe von Zahlungen nach Lieferungen und ähnliche Sachen genutzt. Gab aber noch wesentlich mehr Funktionen, die mich nicht betrafen. Das System hatte keine Probleme wenn 500 User über Deutschland verteilt gleichzeitig darauf aktiv waren.

Zu dem Problem mit der Skalierung:

Wir haben für unser Kassenprogramm (Touch-Bedienung) einen Designer, mit dem man die Oberfläche individuell anpassen kann, damit auch an die jeweilige Bildschirmgröße.

Habe mal zwei Bilder angehängt, beide zeigen Screens vom gleichen Programm einmal für Baumarktkasse (Artikel werden in der Regel gescannt (1024*768) und eine Ticketkasse(1280*800) mit Auswahl über Artikelbuttons. Es gibt noch etliche weitere Möglichkeiten z.B. für Supermarkt, Imbissund eine Variante mit Tischplänen für Gastronomie.

Manche Kunden passen das Design selber an, viele nehmen vorgefertigte und lassen uns die Anpassungen machen. Der Quellcode ist immer der gleiche.

[Codehunter]

Gibt es eigentlich fertige Frameworks für solche frei anpassbaren Oberflächen? Ich hätte zwar eine Vorstellung wie ich sowas coden müsste, aber wie immer muss man ja vorher schauen ob man die Mannstunden investieren will/muss oder ob man das nicht fertig einkaufen kann.

Mit Framework meine ich, dass es vergleichbar zu Tools wie dem Report Builder eine Art Designer gibt, mit dem man Formulare umgestalten kann.

[Jumpy]

@Neumann: Wieso gibt es bei eurem Kassensystem immer eine Möglichkeit den Chef mit zwei Klicks außer Haus zu schicken? Find ich grundsätzlich sympatisch, aber ich wunder mich, dass ein Chef das kauft? :-D

[Neumann]

Naja - die Leute wollen in Ruhe arbeiten - da stört der Chef nur.

Aber im Ernst: Wo "Chef" steht ist nur eine Anzeige wer angemeldet ist. "Ausser Haus" ist bei den beiden Kassen eigentlich sinnlos, da das eigentlich nur für Restaurants relevant ist, wegen den MwSt-Sätzen und ev. unterschiedlichen Preisen.

Sind nicht ganz die realen Kassen.

[p80286]

Zitat:

Zitat von Codehunter (Beitrag 1391392)

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

[Codehunter]

Zitat:

Zitat von p80286 (Beitrag 1391630)

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.

Grundsätzlich ging es mir ja darum, ob man nicht inzwischen für bestimmte Arten von Software (in dem Fall Wawi) inzwischen guten Gewissens 16:10-Bildschirme mit mindestens 1920x1080 als Mindestanforderung angeben kann. Es geht mir ja hauptsächlich um den kausalen Zusammenhang zwischen Auflösung, Bildformat und Bedienkonzepten. Klar kann man sagen: Ich will mit einer Oberfläche auch Leute am Laptop glücklich machen. Da sind ja FullHD-Auflösungen noch nicht überall Stand der Dinge oder machen einfach keinen Sinn (Ultrabooks). Aber genau dann hast du wieder diese "Tabberitis" wegen derer ich den Thread ja aufgemacht habe.

Kurz gesagt: Muss man immer Kompromisse eingehen oder kann man auch mal so "rücksichtslos" sein und sagen: Unterhalb von FullHD wirds ganz einfach nix.

Zitat:

Zitat von p80286 (Beitrag 1391630)

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.

Ich habe da vor nicht allzu langer Zeit erbitterte Diskussionen um das Thema Stringlängen in verschiedenen Lokalisierungen geführt (bin da in verschiedenen Übersetzungsprojekten eines amerikanischen Herstellers involviert, der muttersprachlich eben nur Englisch kennt). Da wollte man allen Ernstes maximale Zeichenanzahl vorgeben weils sonst nicht auf den (mobilen) Bildschirm passte. Mal ganz davon abgesehen dass unterschiedliche Schriftarten, Zeichenbreiten und Schriftgrößen da mit rein spielen. Die DOS-Oberflächen arbeiten ja naturgemäß mit Fixed-Fonts. Da könnten sprachliche Eigenheiten noch schwerer wiegen. Manche Sprachen sind mehr beschreibend, andere neigen dazu für jedes Ding ein eigenes Wort zu erfinden. Oder gar ein separates Zeichen je Wort, wie im Chinesischen. Multi-Language in DOS-ähnlichen Oberflächen stelle ich mir jedenfalls sehr knifflig vor.