GUI-Design richtig umsetzen... Wie?

[John68]

Hallo,

mit GUI-Design meine ich nicht das grafische Design, sondern die praktische Umsetzung im Project (Designer, Code...). Wie lautet der korrekte Begriff für das was ich meine? Vielleicht GUI-Architekture?

Ich weiß nicht wie ich das sonst beschreiben soll. Und in Sufu's kommen bei GUI-Design und Screen-Design nur Links die die grafischen/künstlerischen Aspekte beleuchten.

Beispiele für das was ich meine...

Bsp.1: Optionsmenü mit mehreren Seiten, wenn das TabControl nicht passt.

• Button1.click --> Panel1.BringToFront

• Button2.click --> Panel2.BringToFront

Bsp.2: Taugt diese Variante etwas?

Ich erstelle ein kleines Anzeigeelement in einer eigenen Form.. Ich wähle als Hintergrund eine TransparencyBackcolor aus.
Nun kann ich das Anzeigeelement über einer anderen Form aufrufen und pixelgenau positionieren, so das es so aussieht, als gehöre es zu dieser Form. (Natürlich sind da noch andere Dinge zu berücksichtigen, die lasse ich hier mal ausser acht...)

Bsp.3: GUI-Entwurf als Grafik

GUI-Grafik entwerfen. Dann als Background in die Form und farblich angepasste Steuerelemente dazu.

Das sind natürlich nur simple Beispiele. Aber es dürfte klar sein was ich meine. Also gibt es hier andere/bessere Techniken für grafisch gestaltete GUI's (Windows Forms) ?

Arbeiten Profis durchaus auch so (WPF mal ausser acht gelassen...), oder ist das kompletter Käse?
Kann man es zumindest semiprofessionell nennen?
Gibt es Todsünden?
Oder ist das immer eine Einzelfallentscheidung?

Wäre nett, wenn jemand Links oder Tipps zu diesem Thema hätte.

mfg John

[Christian Marquardt]

mit GUI-Design meine ich nicht das grafische Design, sondern die praktische Umsetzung im Project (Designer, Code...). Wie lautet der korrekte Begriff für das was ich meine?

GUI -> Graphical User Interface

Beinhaltet die von dir aufgeworfenen Fragen

[fanderlf]

Bsp.1: Optionsmenü mit mehreren Seiten, wenn das TabControl nicht passt.

• Button1.click --> Panel1.BringToFront

• Button2.click --> Panel2.BringToFront

Standardverhalten von Controls sollte aus Usability Gründen nicht verändert werden.

Bsp.2: Taugt diese Variante etwas?

Ich erstelle ein kleines Anzeigeelement in einer eigenen Form.. Ich wähle als Hintergrund eine TransparencyBackcolor aus.
Nun kann ich das Anzeigeelement über einer anderen Form aufrufen und pixelgenau positionieren, so das es so aussieht, als gehöre es zu dieser Form. (Natürlich sind da noch andere Dinge zu berücksichtigen, die lasse ich hier mal ausser acht...)

Hier würde ich sagen kommt es auf die Anwendung an wie man hier vorgeht. Aber ich mag unsichtbare Controls eigentlich nicht so gerne

Bsp.3: GUI-Entwurf als Grafik[INDENT]GUI-Grafik entwerfen. Dann als Background in die Form und farblich angepasste Steuerelemente dazu.

GUI sollte eigentlich nie eine Grafik sein, weil die Grafik nicht mit der Auflösung skaliert. Nicht umsonst ist WPF auf Vektorgrafik aufgebaut. Ich würde soweit es geht auf Grafik in einer Benutzeroberfläche verzichten bzw. Vektorgrafik verwenden. Damit fährt man einfach flexibler.

Ich versteh trotzdem noch nicht genau wo jetzt eigentlich Dein Problem ist. Weisst Du nicht wie man eine Oberfläche designt? Oder wie man eigene Controls baut? Wie man eigene Grafik einbaut?

[Christian Marquardt]

Ich habe auch nicht verstanden, was hier zum Problem erhoben wird.

Jedoch

GUI sollte eigentlich nie eine Grafik sein, weil die Grafik nicht mit der Auflösung skaliert.

Dem würde ich so nicht zustimmen wollen. Winamp, VCL, PowerDVD haben grafische GUIs.

Das ist immer eine Einzelfallentscheidung.

Und wenn man schon mal einige Programme genutzt hat, weiss man doch wie das umzusetzen ist, bzw. sollte dann mit " Sufu's " ensprechende Hinweise gefunden haben

Ggf EN ISO 9241-10

[John68]

Grundsätzlich ist mein Problem, das mir als Hobbyprogrammierer einfach ein wenig Sicherheit in der Praxis fehlt.

Ich versteh trotzdem noch nicht genau wo jetzt eigentlich Dein Problem ist. Weisst Du nicht wie man eine Oberfläche designt?...

Ich denke schon, siehe meine Beispiele in Post #1.
Speziell in diesem Thread wollte ich einfach nur wissen, ob das so ok ist oder ob es noch andere Vorgehensweisen/ Fallen/ Tipps gibt. Bzw. wie das erfahrenere Entwickler speziell mit Windows Forms umsetzen.

Ich kenne kein einziges Buch oder Tutorial, wo sowas mal genauer beschrieben wird.

Ich möchte auch keinen Preis für's GUI-Design gewinnen, sondern mir einfach einen sauberen Stil angewöhnen.
Oder seh ich da Probleme wo keine sind?

...weil die Grafik nicht mit der Auflösung skaliert. ...

In dem ein oder anderen Fall mag das so sein. Ich habe es aber dennoch schon mal so umgesetzt für eine Startform/Hauptmenü, das halt nicht skaliert werden muß/kann. Kommt natürlich auf den Einsatz an. Ich geh hier von einem kleineren Tool aus, daß ich Mitarbeitern angeboten hatte und einfach ein bißchen aufpeppen wollte (auch hinsichtlich der Benutzerführung). Hier kenn ich als Net/PC-Betreuer ja auch die vorhandenen Umgebungen und Bedürfnisse (Monitorauflösung usw.).

Danke John

[Christian Marquardt]

(Monitorauflösung usw.).

Schlechtes Vorgehen, Die Zeiten sind vorbei, als man sich daran orientierte. Sowohl in Desktopanwendungen und um so mehr in Webanwendungen.

Ich kenne kein einziges Buch oder Tutorial, wo sowas mal genauer beschrieben wird.

google benutzen

Beitrag 4 lesen -> ISO Norm

Ausgangspunkt http://de.wikipedia.org/wiki/Grafisc...berfl%C3%A4che


EDIT

geh hier von einem kleineren Tool aus, daß ich Mitarbeitern angeboten hatte und einfach ein bißchen aufpeppen wollte (auch hinsichtlich der Benutzerführung). Hier kenn ich als Net/PC-Betreuer

In so einem Falle wäre sogar zu überlegen, Programme plattformunabhängig zu entwerfen. Änder sich die Plattform muss dein "Tool" migriert werden. Mit mehr oder weniger Aufwand

[John68]

In so einem Falle wäre sogar zu überlegen, Programme plattformunabhängig zu entwerfen. Änder sich die Plattform muss dein "Tool" migriert werden. Mit mehr oder weniger Aufwand

Die Anwendungen die ich hier und da erstelle sind wirklich nur bescheidene Dinge, die aber den ca. 400 fachlichen Mitarbeitern hier und da das Leben erleichtern und für mich als Übungsprojecte (interessanter als "Hello World") dienen. Zu 90 % ist das einfach Hobby. Von unserer Struktur her muß ich deshalb bestimmte Dinge ausblenden bzw. abschätzen oder auch ablehnen. Aus professioneller Hinsicht kann ich das natürlich voll und ganz nachvollziehen und nehme das in meinem Hinterstübchen auf.

Schlechtes Vorgehen, Die Zeiten sind vorbei, als man sich daran orientierte. Sowohl in Desktopanwendungen und um so mehr in Webanwendungen.

Das natürlich auch

Ausgangspunkt http://de.wikipedia.org/wiki/Grafisc...berfl%C3%A4che

Ich kenne diese Links die mir beschreiben was eine GUI ist oder erfüllen soll.
Mich interessiert aber die Umsetzung / Erfahrungen...
Ich werde mir das aber nochmal ansehen, evt. habe ich ja was übersehen.
Trotzdem Dank für Deine Mühe...


Wenn's nicht zu nervig ist, noch eine Frage anhand eines Beispiels.

Nehmen wir ein Optionsmenü das aufgrund des Designs nicht mit einem Tab-Control realisiert werden soll.
Ausgangslage: 5 Buttons und 5 Panels und dann die Variante Button1.click -> Panel1.BringToFront usw.

Ich bin aufgrund der Pflegbarkeit und Handhabung da immer so vorgegangen.
Ich habe die eigentliche Form im Designer wesentlich größer aufgezogen als sie später sein soll. Dann habe ich die Panels nebeneinander ggfs. untereinander angeordnet und dort alles reingepackt und im Designer auch so belassen.
Später dann per Code die Form auf die eigentliche Größe gebracht und die Panels hintereinander positioniert. Funktionalität dann wie in oben beschriebener Ausgangslage.

Ist dies eine empfehlenswerte Vorgehensweise? Oder gibts da eleganteres?

mfg John

[fanderlf]

Warum sollte man nicht verschiedene Panels mit eigenen Buttons durchschalten. Dort sehe ich kein Problem. Viel wichtiger an dieser Stelle ist, den UI Code möglichst frei von Geschäftslogik zu halten und hier die Grenze sauber zu ziehen.

Ansonsten bin ich wie oben beschrieben kein großer Freund von so handgestrickten Sachen, weil der User sich bei jedem neuen Programm an das eigens programmierte Verhalten gewöhnen muss.
So etwas wie einen Wizard würde ich aber so wohl auch implementieren.

[John68]

Viel wichtiger an dieser Stelle ist, den UI Code möglichst frei von Geschäftslogik zu halten und hier die Grenze sauber zu ziehen.

Um mal beim Beispiel zu bleiben, in der besagten Form stehen dann in den Click-Ereignissen nur Aufrufe. Die Funktionalität selbst lagere ich in Klassen aus. Meinst Du das so?

So etwas wie einen Wizard würde ich aber so wohl auch implementieren.

Auch ein gutes Beispiel. Das gibt mir schon mal etwas Sicherheit, zu hören, daß andere das auch so machen würden.

Ansonsten bin ich wie oben beschrieben kein großer Freund von so handgestrickten Sachen, weil der User sich bei jedem neuen Programm an das eigens programmierte Verhalten gewöhnen muss.

Das sehe ich grundsätzlich genauso. Ich orientiere mich da an vorhandener Fachsoftware, um die User nicht zu verwirren und behalte wenn möglich den gleichen Stil bei. Bei verschiedenen Themen und Abteilungen habe ich nur verschiedene Farben etabliert/übernommen, die teilweise auf PrintFormularen auch schon vorhanden sind.

Und ich nutze das überwiegend nur in einer Startform (Ähnlich dem Willkommensscreen von OpenOffice), um die Hauptauswahl aus den eigentlichen funktionellen Forms rauszuhalten. Die Enduser haben teilweise sehr schlechte PC-Kenntnisse, arbeiten rein fachbezogen und sind schon bei mäßig gefüllten Menüleisten schnell überfordert.

[Ralf Jansen]

Es gibt ein paar Guidelines für Windows die man zumindest mal gelesen haben sollte.

http://msdn.microsoft.com/en-us/library/ff657751.aspx

Das wichtigste was man aber beherzigen sollte ist das man UI's für User schreibt und nicht für sich selbst. Man sollte also den Useranforderungen und deren Fähigkeiten folgen. Daraus kann man dann ableiten wann man die oben aufgeführten Guidelines ignorieren sollte Das hat dann aber üblicherweise immer erhöhten Pflegeaufwand der Software zur folge. Man sollte also immer abwägen was wichtiger ist.


Zu deinen Beispielen

Bsp1. Buttons + Panels sind für mich ein Tabcontrol. Wenn letzteres nicht passt sehe ich nicht wie ersteres passen könnte Da sind vermutlich graphisch vorher schon das eine oder andere schief gegangen.

Bsp2. Durch Formen übereinander legen um irgend etwas zu simulieren wirst du dir das ein oder andere Folgeproblem rein holen. Das wären z.B. Tabreihenfolge, Focusverhalten, schließen durch z.B. Alt+F4 etc. Die Probleme werden je nach OS(bzw. OS Version) auch leicht unterschiedlich sein. Das allgemein lauffähig zu machen(und lauffähig zu halten!) ist Aufwand den man vermeiden sollte.

Bsp3. GUI-Entwurf als Grafik. Hängt voll und ganz von der verwendeten Technik ab. In Winforms sicher nicht empfehlenswert oder überhaupt sinnvoll machbar in WPF/Silverlight natürlich deutlich einfacher. Wenn denn die graphischen Fähigkeiten dazu ausreichen

[John68]

Hallo Ralf,

den Link schau ich mir natürlich an.


Bsp.1:

Da sind vermutlich graphisch vorher schon das eine oder andere schief gegangen.

Vielleicht hab ich mich da mißverständlich ausgedrückt. Ich will nicht das eine fertige TabControl-Steuerelement benutzen, sondern das mit Buttons und Panels wie beschrieben selbst konstruieren.


Bsp.2: War nur mal so ne Überlegung. Kann man wohl in die Tonne klopfen.

Danke
mfg John