Startseite   |  Site map   |  A-Z artikel   |  Artikel einreichen   |   Kontakt   |  
   
  •  
    Biologie
    Themen der Chemie
    Deutsch online artikel
    Englisch / Englische
    Franzosisch
    Geographie
    Geschichte
    Informatik
    Kunst
    Mathematik / Studium
    Musik
    Philosophie
    Physik
    Recht
    Sport
    Wirtschaft & Technik



    Biographie

    Impressum

informatik artikel (Interpretation und charakterisierung)

Graphische benutzeroberfläche


1. Java
2. Viren



5.1 Einleitung Ein Windows-Entwickler kann bis ins Detail das Verhalten und Aussehen seiner Anwendungen selber festlegen. Ihm steht die ganze Leistungsfähigkeit des Systems zur Verfügung, um blendende, elegante und vorallem nützliche Anwendungen zu schaffen.

5.2 Wie man es besser nicht macht
Bevor ich einige brauchbare Methoden für den Entwurf der Programmoberfläche vorstelle, möchte ich an einigen abschreckenden Beispielen zeigen, wie man es besser nicht tut.

Folie 1

Folie 1 zeigt die Maske, die zur Datenerfassung einer Versicherung dient. Die Augen finden keinen Ruhepunkt, die Anordnung ist einfach undurchschaubar; eine Ausrichtung ist praktisch nicht vorhanden.

. Welche Daten gehören zusammen ?
. Sind irgendwelche Bedienelemente von einem Anderen abhängig ?
. Welches Feld ist das Wichtigste ?
. Lassen sich die Zahlen in der unteren Reihe bearbeiten ?
. Was bedeuten sie überhaupt ?

Folie 2

Folie 2 sieht nicht gerade besonders gut aus, denn die Reihenfolge der Arbeitsgänge ist schlechter. Die Maske zeigt an, ob ein bestimmter Versicherungsschutz für den Versicherten vorliegt.

Das statische Textfeld am unteren Rand gibt völlig überflüssige Anweisungen, denn nirgends läßt sich die Auswahl "NEW APPLICATION" oder "UPDATE APPLICATION" treffen.

Folie 3

In Folie 3 legte der Entwickler großen Wert auf die Ausrichtung der Bedienelemente. Bei uns ist es üblich, von links nach rechts, und von oben nach unten zu lesen. In dieser Maske muß der Anwender die Felder rechts ausfüllen und dann zur linken Seite wechseln, um die gewünschte Aktion durchzuführen.
Außerdem sind die Eingabefelder alle gleich lang, obwohl schon der erste Blick genügt, um festzustellen, daß die typischen Eingaben in die jeweiligen Felder unterschiedlich lang sein werden.


Folie 4

Der Entwickler der Eingabemaske in Folie 4 hat eine Vorliebe für verschachtelte Menüs. Wenn es tatsächlich so viele Menüoptionen geben muß, so ist es besser, sie in einem Dialog anzubieten.

Es ist natürlich auch nicht besser so zu gestalten, wie es Folie 5 zeigt.


Folie 5

Diese Folie ertrinkt fast in Optionsschaltflächen. Sicher ist es hier besser, ein Pull-Down-Menü zu verwenden (Listbox oder Combobox).


Folie 6


Folie 6 ist ein weiteres Beispiel für rivalisierende Schaltflächen. Was ist der Unterschied zwischen APPLY und ACCEPT ? Da mit APPLY keine sichtbare Änderungen verbunden sind, ist diese Schaltfläche sowieso überflüssig.

Wichtig ist es, daß sich die Programmierer nicht nur mit dem Codieren befassen, sondern auch mit dem Layout. Sogar bei erfahrenen Entwicklern ist dieses Problem schon aufgetreten. Sie haben mit bestimmten Anforderungen an das Projekt angefangen, einer groben Spezifikation, aber sich kaum mit dem Auftraggeber über die Gestaltung der verschiedenen Masken (dem Layout) auseinandergesetzt. Sobald die ersten Probleme bezüglich Maske auftauchen, stellen die Entwickler fest, daß einige dieser Probleme ihre Ursache in der Programmstruktur haben. Ihre Behebung würde nicht nur Änderungen in der Programmstruktur nach sich ziehen, sondern auch in anderen Bereichen (Datenbankstruktur); sie müßten möglicherweise fast von vorne wieder beginnen. Der Ausdruck "QUICK AND DIRTY" ist oft nicht fehl am Platz. Der Entwickler soll sich wirklich Zeit für die Gestaltung der Masken nehmen.
5.3 Die Analyse
Spätestens hier ergibt sich die Frage "Wer ist mein Kunde" ? Wenn man eine Anwendung innerhalb einer Firma entwickeln soll (Bsp.: XESAS), so muß man den direkten Kontakt zum Anwender suchen. Nur so kann der Anwender wirklich das haben, was er will. Mit dem Anwender die grobe Spezifikation zu besprechen ist sicher sinnvoll. Wenn die Spezifikation dem Anwender zusagt, so beginnt der Prozeß des Prototypings. Der fertige Prototyp wird dann von einigen ausgewählten, nicht eingewiesenen Anwendern getestet. Auch hier können noch nicht umständliche Änderungen vorgenommen werden. Die Entwicklung wird dann weitergeführt bis zur ALPHA-Version (eine reine Testversion). Auch andere Entwickler oder Anwender können ihre graphischen Vorstellungen einbringen.

Weiters stellt sich die Frage "Kennt sich der Anwender mit PC-Programmen aus" ? Wenn man Anwendungen für Neulinge entwickelt, darf man nicht vergessen diverse Hilfe-Funktionen zu berücksichtigen. Am besten konzentriert man sich darauf, daß die Anwenderschnittstelle so gestaltet ist, daß Sie diese am liebsten gar nicht weitergeben möchten.

Es ist auch nicht unwesentlich, wie intensiv die Anwendung benutzt wird. Wenn man den ganzen Tag damit beschäftigt ist, treten die kleinsten Entwurfsschwächen schnell zu Ärgernissen auf. Wenn man sich nicht so intensiv damit beschäftigt, soll man dem nicht so kritisch beiwohnen.

Sobald die Hauptziele der Anwendung festgelegt sind, ist es essentiell die Arbeitsabläufe zu fixieren. Vielleicht kann man ähnliche Arbeitsabläufe verwenden. Möglicherweise kann man manuelle Vorgänge automatisieren und somit Zeit und Geld sparen.
Sich die genaue Reihenfolge der Funktionen zu überlegen ist ebenfalls wichtig. Man hat ja schließlich nicht vor, dem Anwender überflüssige Programmzustände aufzuzwingen.

5.4 Überlegungen zum Entwurf
Die Amerikaner kennen das Schlagwort KISS - Keep It Simple, Stupid. Eine bessere Interpretation wäre Keep It Simple and Straightforward, also "einfach und zielsicher". Sobald man weiß, welche Datenfelder und Verzweigungen man in der Anwendung braucht, sollte man überprüfen, was wirklich notwendig ist. Beschriftungen, statische Texte, Kontrollfelder, Gruppenrahmen und Optionsschaltflächen verstellen häufig den Blick auf die wirklich wichtigen Teile einer Eingabemaske und verbrauchen doppelt so viel Platz wie Nutzdaten.

Mit 2 einfachen Tricks erhöht man die Übersicht der Masken, nämlich:
. durch eine überlegte Ausrichtung der Bedienelemente in den Masken
. durch die Einheitlichkeit des Maskenaufbaus in der gesamten Anwendung.

Texte richten sich im allgemeinen nach dem linken Rand, bis auf die zentrierten Meldungen in den Meldungsfenstern, und Zahlen werden nach dem rechten Rand ausgerichtet.

Zu dem einheitlichen Erscheinungsbild der Masken gehört die gleiche Größe und Anordnung der Bedienelemente und der Beschriftung, gleiches Verhalten und gleicher Stil. Es ist nicht effizient eine Befehlsschaltfläche in der ersten Maske riesengroß und gleich in der nächsten Maske diese zu klein zu gestalten. Wenn man mittels PUSH-BUTTON eine weitere Maske öffnen kann, so soll diese Maske den selben Namen wie der PUSH-BUTTON haben. Wenn sich bestimmte Datenfelder in mehreren Masken wiederholen, wäre es sinnvoll, diese immer an der gleichen Stelle zu positionieren.

Um all diese Kriterien zu erfüllen gibt es einige grundlegende Dinge für einen einfachen Entwurf:
. Anordnung der Daten in funktionalen Gruppen. Alle Informationen, die der Anwender zur Abwicklung eines bestimmten Vorganges benötigt, gehören in dieselbe Maske.
. Anordnung der Felder, die am häufigsten benutzt werden, sodaß man sie gleich sieht.
. Zusammenfassung der zusammengehörigen Felder in Unterguppen.
. Gleichmäßige Abstände zu den verschiedenen Feldern.

5.5 Die Gestaltung der Anwendung
Sobald man die Funktion der Anwendung festgelegt hat, geht es um die Frage, wie viele Fenster man dem Anwender präsentiert. Alle Windows-Anwendungen öffnen zuerst ein Hauptfenster, von dem aus Teilaufgaben in MDI-Fenster oder Dialogfenster abgewickelt werden. Es ist essentiell MDI-Fenster zu benutzen, wenn man in der selben Ebene mehrere Vorgänge abwickeln möchte (Bsp.: Datentausch zwischen Dokumenten). MDI-Fenster sind auch in ihrer Größe beeinflußbar.

Dialogfenster haben normalerweise eine feste Größe und eignen sich somit auf Felder mit festgelegten Datenmengen.


Die Anwenderschnittstelle bildet den Ausgangspunkt für jede Aktion, die ein Anwender durchführen kann. Die Windows-Anwendung erhält die Befehle des Anwenders über:

. Menüs

. Befehlsschaltflächen
. Symbole
. OLE-Verbindungen (Object Linking and Embedding)

Die Funktionsschaltflächen sind von Programm zu Programm verschieden. In Word und Excel sind dies beispielsweise Befehlsschaltflächen mit denen Programmfunktionen angeboten werden; die aber auch über Menüs angesprochen werden können. Der Anwender kann seinen bevorzugten Zugriff individuell auswählen.

Die Anordnung der Menüs und Menüunterpunkte will sorgfältig überlegt sein. Die ersten Gedanken darüber hat man sicher schon in der Spezifikation gemacht; hier ist es aber höchste Zeit die genauen Menüoptionen festzulegen. Anschließend faßt man dann ähnliche Menüpunkte in Gruppen zusammen.

Die Anordnung der anderen Menüpunkte hängt von einer Reihe von verschiedenen Faktoren ab:


. von der Häufigkeit der Benutzung
. von der Wichtigkeit

. von den Arbeitsabläufen
. von der Reihenfolge

Folie 7

Folie7 zeigt ein etwas verwirrendes Menü; und die verbesserte Version. Das Sprichwort "Weniger ist oft mehr" oder "In der Kürze liegt die Würze" trifft hier voll zu.

Einige typische Bedienungsfehler lassen sich schon durch die Gestaltung der Masken vermeiden:

. Alle Menüpunkte, deren Auswahl zu Schäden führen könnte, zu sperren, ist sicher wichtig.
. Der Griff zu Auswahllisten ist sicher der richtige. Den Benutzer sooft als möglich auswählen zu lassen, verhindert unnötige Schreibfehler.
. Vor jeder kritischen Situation den Anwender noch einmal bestätigen lassen (Bsp.: Hiermit beenden Sie Ihre Windows-Sitzung).

Folie 8

Folie 8 ist ein Beispiel für feldspezifische Datenvalidierung. Die Anwendung zeigt sofort eine Fehlermeldung an, wenn der Anwender eine ungültige Staatenabkürzung eingibt und mit dem Cursor das nächste Feld anklickt.

Wenn der Anwender ein Feld anklickt, das er nicht bearbeiten darf, genügt ein simples Pieps als Hinweis.

5.6 Schrift und Farbe
Einheitlichkeit ist der Schlüssel für den effektiven Einsatz von Schriftarten und Farben. Falls die Systemschrift zu langweilig oder zu häßlich erscheint, kann man ohneweiters auf eine andere Schriftart ausweichen. Diese sollte aber leicht lesbar und nicht zu klein bzw. zu groß sein. Alles in Großbuchstaben zu schreiben ist nicht effizient, da man dies nicht so gut und auf den ersten Blick lesen kann. Eine Ausnahme wäre beispielsweise die OK-Taste.

Um die Aufmerksamkeit des Anwenders auf sich zu lenken, sollten ebenfalls verschiedene Farben für die Maskengestaltung herangezogen werden. Die Farben sind aber eher sanft und nicht grell zu wählen.

Farben können auch als Informationsträger verwendet werden. Beispielsweise macht man gesperrte Felder grün und die fehlerhinweisenden Felder rot.

5.7 Ergänzung
 Einheitlichkeit, Richtlinien (Kontrolle)
 Ergonomie (Arbeitsrichtung von links nach rechts und von oben nach unten)
 natürliche Reihenfolge
 an bestehende schriftliche Formulare halten
 Farben: auf großer Fläche keine grellen Farben und nicht zu viele Farben
 Felder: Muß-, Kann- und berechnete Felder in anderen Farben
 Schriften: nicht mehr als zwei verschiedene

 Gruppierung
 nicht zu viele Steuerelemente
 PB sollten am Aussehen von Formularen etwas ändern (Checkbox)
 Bilder für PB
 Unterscheidung: aktiv - inaktiv
 Probleme: Formulare mit zuwenig Platz
 Funktionen: Menü, PB oder Hotkeys
 Hilfe, Statuszeilen, Warnton

 Defaults
 einheitliche Benennung
 Qualifikation des Anwenders beachten

 
 




Datenschutz

Top Themen / Analyse
Ansätze der Kryptoanalyse
Internet in Students' Lives
Die Aufgabe des Prozessors (CPU) in einem Computersystem
MultiMedia und Mythos MultiMedia
Kompression und Archivierung
Selection Sort (Sortieren durch direktes Auswählen)
Der Mikroprozessor-
Sicherheitsaspekte
Versuchsaufbau
Sonstige Hardware - Geräte





Datenschutz

Zum selben thema
Netzwerk
Software
Entwicklung
Windows
Programm
Unix
Games
Sicherheit
Disk
Technologie
Bildung
Mp3
Cd
Suche
Grafik
Zahlung
Html
Internet
Hardware
Cpu
Firewall
Speicher
Mail
Banking
Video
Hacker
Design
Sprache
Dvd
Drucker
Elektronisches
Geschichte
Fehler
Website
Linux
Computer
A-Z informatik artikel:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z #

Copyright © 2008 - : ARTIKEL32 | Alle rechte vorbehalten.
Vervielfältigung im Ganzen oder teilweise das Material auf dieser Website gegen das Urheberrecht und wird bestraft, nach dem Gesetz.