Diplomarbeit
 HTML-Version
 HTML (eine Datei 300 Kb)
 PDF-Version
 

Links
 Startseite
 Empfohlene Seiten

Suchportale Campingplätze in Deutschland bei Campingplatz-suchen.de

Reiterhöfe in Deutschland bei Reiterhof-suchen.de

4 Style Guide

Style Guides sind Dokumente, die den Entwicklungsprozess für ergonomische Software mittels Vorgaben, Empfehlungen und Hinweisen unterstützen. Sie beschreiben die Prinzipien und Regeln, die der Benutzungsschnittstelle zugrunde liegen. Synonym dazu wird auch der Begriff Design Guideline genutzt. Style Guides ersetzen jedoch keine Design-Spezifikation (vgl. [GöMa00] S. 43), da sie keine Erklärungen über den logisch konsistenten Bedienungsablauf des Dialoges geben. Im benutzerorientierten Entwicklungsprozess unterstützen sie den dritten Arbeitsschritt (vgl. Anhang A.8). Dieser besteht im Entwurf der Gestaltungslösungen. Die Style Guides kommen dabei vor allem bei späteren Iterationsschritten, die sich mit der Feingestaltung des Prototyp beschäftigen, zum Einsatz.

Style Guides verstehen sich als Leitfäden, die lediglich empfehlenden Charakter besitzen. Im Gegensatz dazu sind Standards Dokumente, die direkte Anweisungen für die Gestaltung von Benutzungsschnittstellen geben. Diese müssen unbedingt befolgt werden. Standard sind sehr allgemein formuliert, was die Überprüfung ihrer Einhaltung erschwert (vgl. [HiHa93] S. 18). Style Guides sind im allgemeinen in zwei Bereiche gegliedert. Der erste befasst sich mit der Beschreibung der Bildschirmelemente. Dazu gehört sowohl das Aussehen (engl. look), als auch das Verhalten des Objektes (engl. feel). Der zweite Bereich gibt Empfehlungen, in welchen Anwendungsfällen und in welcher Art und Weise die entsprechenden Bildschirmelemente zu nutzen sind. Fasst man die beiden Teile des ersten Bereiches zusammen, so entsteht der Begriff Look and Feel, mit dem die Charakteristik einer Benutzungsschnittstelle beschrieben wird.

Style Guides unterscheiden sich in der Konkretheit ihrer Gestaltungskriterien. So ist die Richtlinie ISO 9241 durchaus als Style Guide anzusehen. Aufgrund ihrer absoluten Allgemeingültigkeit ist sie als alleinige Grundlage für die Gestaltung der Oberfläche einer Anwendung nicht geeignet. Sie gibt vor allem Auskunft darüber, was kein ergonomisches Design ist, kann demzufolge auch zur Evaluierung einer Oberfläche eingesetzt werden. Konkreter als die ISO 9241 sind die Style Guides der verschiedenen Betriebssysteme. Diese fußen auf der offiziellen Norm, sind aber bereits detaillierter, da betriebssystemabhängige Techniken und Paradigmen bekannt sind. So ist beispielsweise im MS Windows Style Guide festgelegt, dass rechts oben im Fenster ein kleines x das Schließen dieses Fensters ermöglicht. In der ISO 9241 wird lediglich gefordert, dass ein Fenster jederzeit geschlossen werden kann.

Der Java Look and Feel Design Guideline hat sich zum Ziel gesetzt, plattformunabhängigen Anwendungen wie sie mit Java entwickelt werden können, ein konsistentes Aussehen und Verhalten zu verleihen (vgl. [Java01]). Er wird mittels der Java Foundation Classes (JFC) umgesetzt. Die JFC sind eine Sammlung von standardisierten Dialogelementen. Dieses Toolkit wurde auch im Prototyp verwendet. Trotz des einheitlichen Look and Feel werden plattformabhängige Grundkonzepte nicht durchkreuzt. So bleibt das Aussehen der Fenster oder standardisierte Tastenbelegungen nach wie vor betriebssystemabhängig.

Hix und Hartson fassen die bis jetzt erwähnten Style Guides unter dem Begriff Commercial Style Guides zusammen. Diese werden von einzelnen Organisationen entwickelt und publiziert. Sie sind im allgemeinen mit einem kommerziellem Toolkit verbunden (vgl. [HiHa93] S. 22). Obwohl diese Style Guides schon deutlich konkreter sind, reichen sie in der Regel nicht aus, um den Entwicklungsprozess optimal zu unterstützen. Sie bilden lediglich die Grundlage, auf der ein anwendungsabhängiger Style Guide entwickelt werden muss. In diesem werden für ein bestimmtes Projekt spezifische Gestaltungshinweise definiert, da erst in diesem Fall ist der genaue Nutzungskontext bekannt. So kann auf anwendungsspezifische Merkmale wie beispielsweise die Zielgruppe entsprechend Rücksicht genommen werden. Damit soll die Anwendung einen größtmöglichen Grad an Ergonomie erhalten.

Durch die Nutzung der verschiedenen Style Guide entsteht eine mehrstufige Filterung der Gestaltungsmöglichkeiten für den Entwickler. Diese ist in der folgenden Grafik abgebildet.

Style Guides sind ein wichtiges Hilfsmittel für die Entwicklung von Oberflächen. Sie können jedoch nie alle Fragen des Designs beantworten. Ein Nachteil von Style Guides besteht darin, dass sie zwar sehr gut beschreiben, was für Interaktionselemente genutzt werden können. Sie geben jedoch wenig Aufschluss, in welchem Fall diese angewendet werden müssen. Außerdem besteht die Gefahr, dass sie bei zu konkreter Ausprägung die Kreativität des Entwicklers einschränken. Die Nutzung von Style Guides befreit den Oberflächendesigner nicht von der Pflicht, eine ausführliche Evaluation der Benutzungsschnittstelle durchzuführen.

4.1 Entwicklung des Style Guide

Die Entwicklung eines Application Style Guide findet in einer frühen Phase des Projektes statt. Er sollte auf Grundlage von bereits vorhandenen Style Guides und nach Analyse des Nutzungskontextes unter Anleitung eines Experten entstehen. Während der Projektentwicklung muss der anfangs unvollständige Application Style Guide stetig erweitert und aktualisiert werden. Hix und Hartson schlagen eine Gliederung in fünf Bereiche vor (vgl. [HiHa93] S. 25). In der Einleitung werden grundsätzliche Paradigmen erklärt. Hier wird beispielsweise festgelegt, ob eine grafische oder textuell orientierte Oberfläche entwickelt werden soll. Der zweite Bereich beschäftigt sich mit den Ein- und Ausgabegeräten. Der nächste Teil des Style Guide zeigt repräsentative Bildschirmdarstellungen. Diese dienen als Vorlage bzw. Muster. Sie sind vor allem für die Sicherstellung des konsistenten Aussehens von Bedeutung. Der vierte Bereich beschreibt alle Interaktionselemente. Es wird zu jedem einzelnen sowohl Aussehen als auch Verhalten erklärt. Falls nötig, muss beschrieben werden, in welchem Fall das Element benutzt wird. Der letzte Teil des Application Style Guide beinhaltet alle auftretenden Meldungen. Dazu gehören sowohl Fehler- und Warnmeldungen als auch andere Rückinformationen.

Der hier entwickelte Application Style Guide umfasst hauptsächlich den vierten Teil der eben beschriebenen Gliederung. Die im Anhang A.4 bis A.7 gezeigten Abbildungen gehören zu dem dritten Bereich. Die drei fehlenden Bereiche sollten noch ergänzt werden. Der im folgenden näher beschriebene Style Guide baut auf dem Java Look and Feel Design Guideline (vgl. [Java01]) auf. Er umfasst lediglich die Erweiterungen und anwendungsabhängigen Spezifikationen, die getroffen wurden, um eine konsistente Anwendung entwickeln zu können. Hauptsächlich werden Empfehlungen für Layout, Bezeichnung, Farben u.ä. für alle visuellen Klassen gegeben. Weicht das Verhalten vom Java Look and Feel Design Guideline ab, wird es ebenfalls beschrieben. Das Ziel ist eine Reduzierung der Möglichkeiten für den Designer, ohne ihn jedoch beim kreativen Entwurf einzuschränken. Damit soll die Entwicklung einer konsistenten Anwendung sichergestellt werden. Zusätzlich zu den hier ausgearbeiteten Richtlinien sollten die im Abschnitt 3.4 beschriebenen Entwurfstechniken beachtet werden. Diese unterstützen vor allem bei der Entwicklung der inneren Struktur und Organisation der Anwendung. Es existieren noch eine Vielzahl von Zusammenstellungen einzelner Regeln, die zu einer ergonomischen Oberfläche beitragen können. Eine bekannte Sammlung sind beispielsweise die acht goldenen Regeln von Shneiderman (vgl. [Shne98] S. 74f).

4.2 Beschreibung der visuellen Klassen

Im folgenden Abschnitt werden die visuellen Klassen näher spezifiziert. Im ersten Teil wird jeweils kurz erläutert, in welchem Anwendungsfall das Bildschirmelement benutzt werden kann. Die Einschränkungen und Empfehlungen für Aussehen und Verhalten werden im zweiten Teil diskutiert.

4.2.1 GMEJFrame

Diese Klasse bildet die Grundlage aller Fenster, die im Prototyp dargestellt werden. Sie ist von JFrame abgeleitet und besitzt mehrere zusätzliche Methoden. Diese sollen sowohl die Arbeit für den Entwickler vereinfachen, als auch in ergonomischer Sicht Vorteile bringen. Es wurde die Methode setSizeAndPosition() entwickelt (vgl. Anhang 0). Diese dient dazu, sowohl Position und Größe der letzten Darstellung wieder herzustellen. Sie definiert ebenfalls, welche Buttons für die Standardfunktionen OK, Hilfe und Abbruch zu benutzen sind. Das ist für die Klasse von Bedeutung, da sie die Funktionstasten ENTER, F1 und ESC mit Ausführung dieser Funktionen belegt. Damit wird eine einheitliche Steuerung der Fenster gewährleistet (vgl. Abschnitt 3.4.1).

Es ist mindestens ein Panel in das Fenster einzubringen. Das erste Panel ist dabei gleichbedeutend mit dem Attribut contentPane. Die Evaluierung eines Fensters kann mit Hilfe der Checkliste in Anhang B.1 erfolgen.

4.2.2 JPanel

Die Klasse JPanel dient zur Gliederung bzw. Organisation eines Fensters. Sie stellt einen Arbeitsbereich innerhalb eines Fensters dar. Dieser Fensterbereich wird im englischen mit panel bezeichnet. Aufgrund einer fehlenden adäquaten Übersetzung wird im folgenden der englische Begriff genutzt. Panele können verwendet werden, um semantisch zusammengehörige Bildschirmelemente auch als Gruppe erscheinen zu lassen. Damit verringert sich die Suchzeit für den Benutzer (vgl. [Krus99] S. 40). Zusätzlich kann durch die Verwendung von Panelen ein konsistentes Aussehen innerhalb der verschiedenen Fenster einer Anwendung sichergestellt werden. Panele besitzen drei funktionale Merkmale:

 

• Sie können Bildschirmelemente aufnehmen, man spricht deshalb auch von einer Containerklasse. Dabei kann ein Panel wieder andere Panele aufnehmen, was zu einer Anordnungshierarchie führt.

   

   

• Sie besitzen ein Layout, d.h. eine Vorschrift, wie die inneren Elemente angeordnet werden (vgl. Abschnitt 4.2.9).

   

 

• Sie können einen Rand annehmen. In Ausnahmefällen kann auf die Nutzung eines Randes verzichtet werden. Um die einheitliche Benutzung von Rändern zu ermöglichen, wurde die Klasse GMEBorder entwickelt (vgl. 4.2.8).

   

Für die Verwendung von Rändern wurden eindeutige Regeln festgelegt. Die Auswahl des zu benutzenden Randes hängt dabei sowohl von der Anordnung des Panels als auch von der inhaltlichen Beziehung zu anderen Panelen ab. So besitzt beispielsweise das erste Panel jedes Fensters den Randtyp null. Die derzeit definierten Randtypen wurden im Anhang abgebildet.

Folgende Regelungen werden für die Verwendung der Ränder vorgegeben:

 

• Das jeweils erste Panel in einem GMEJFrame, JTabbedPane oder einem JSplitPane hat den Randtyp null.

   

 

• Berühren sich zwei Panele, ist zwischen diesen Beiden ein Abstand von insgesamt 6 Pixel zu einzuhalten, indem in beiden Panelen ein Abstand von 3 eingetragen wird. Bei den vier Außenseiten eines Panels ergeben sich damit maximal 15 Kombinationen die den Randtypen null bis 15 entsprechen.

   

 

• Ist der Inhalt des Panels deutlich vom Rest des Formulars zu unterscheiden, kann eine Umrandung mit einer Überschrift erfolgen. Diese entspricht dem Randtyp zwei.

   

4.2.3 JScrollPane

Die Klasse JScrollPane generiert bei Bedarf automatisch Bildschirmlaufleisten (engl. scroll bar), die bei in der Größe anpaßbaren Bildschirmelementen benötigt werden, um diese komplett darzustellen. Üblicherweise wird diese Klasse mit einem Fenster verknüpft. Wird das Fenster verkleinert, ermöglichen die Laufleisten das Verschieben des sichtbaren Bereiches. Die Klassen JTree, JTable und JEditorPane sollten ebenfalls grundsätzlich mit einem JScrollPane verknüpft sein. Diese Klassen verändern während der Benutzung die Größe des Bereiches, in dem sie ihre Informationen darstellen. Die Größe des Bildschirmelementes bleibt davon jedoch unberührt. Damit kann beim Entwurf keine Aussage getroffen werden, ob die vorgegebene Größe während der späteren Benutzung ausreichend ist. Für den Rand gelten die gleichen Regelungen wie für ein JPanel.

4.2.4 JTabbedPane

Die Klasse JTabbedPane ist immer dann zu verwenden, wenn die Informationsmenge eines Fensters zu hoch ist, um auf einmal dargestellt zu werden. Eine Trennung wird durch die Darstellung von Karteikarten, die durch die Klasse gekapselt werden, erreicht. Durch das Anklicken auf einen Reiter kann zwischen ihnen gewechselt werden. Die Reiter sollten immer oberhalb der Karteikarten angezeigt werden. Es wird grundsätzlich nur eine Karteikarte angezeigt. Aus diesem Grund sollten inhaltlich zusammengehörige Elemente auf dem selben Panel angeordnet sein. Es empfiehlt sich diese Klasse in ein mit einem JScrollPane zu verknüpfen, da der Inhalt der unterschiedlichen Karteikarten auch verschiedene Dimensionen besitzen kann. Das erste Element einer Karteikarte ist, abgesehen von Ausnahmen, ein JPanel. Für dieses gelten die Anweisungen aus Abschnitt 4.2.2.

4.2.5 JSplitPane

Die Klasse JSplitPane ist einzusetzen, wenn eine nicht unbedeutende Menge an Informationen abhängig von einer vom Benutzer veränderbaren Variable anzuzeigen ist. Die Klasse teilt den Bildschirmausschnitt in zwei unterschiedlich große Teile. Üblicherweise wird die vom Benutzer zu verändernde Variable in Form einer Liste angezeigt. Dafür eignen sich im besonderen die Klassen JList und JTree. Sie sind im linken Teil des JSplitPane anzuordnen. Die rechte Seite enthält die davon abhängigen Informationen. Die Klasse JSplitPane wurde im Prototyp in mehreren Fenstern verwendet, um die Konsistenz bei der Gliederung zu erhöhen. Die Abbildung 5 illustriert die Anwendung der Klasse.

Beide Bereiche des JSplitPane sind grundsätzlich mit einem JPanel bzw. JScrollPane zu versehen. Die Eigenschaft dividersize ist mit 10 zu belegen. Sie gibt die Breite des Balken zwischen den beiden Bereichen an. Für das Attribut dividerposition, das der Breite des linken Teiles entspricht, ist eine geeignete Größe zu finden. Im Prototyp wurde üblicherweise ein Bereich zwischen 150 und 250 ausgewählt.

4.2.6 JToolBar

Ein JToolBar ist immer dann zu verwenden, wenn über Icons eine schnelle Auswahl von Funktionen ermöglicht werden soll. Dazu wird ein Container ähnlich einem Panel bereitgestellt, der die Buttons aufnimmt und anordnet. Man bezeichnet dieses Bildschirmelement auch als Symbolleiste. Zusätzlich wird die Funktionalität angeboten, die Leiste aus dem Fensters durch ziehen mit der Maus herauszulösen. Gesteuert wird diese Funktion über das Attribut floatable.

Der JToolBar sollte grundsätzlich oben in horizontaler Ausrichtung im Fenster platziert werden. Ist ein Menü implementiert, dann wird es direkt unter dem Menü angeordnet. Das Attribut floatable sollte auf false gestellt werden. Es ist im Einzelfall zu prüfen, ob ein Herauslösen des Symbolleiste aus dem Fenster sinnvoll ist. Werden mehrere JToolBar nebeneinander platziert, so ist der Randtyp 16 (vgl. Abschnitt 4.2.8) zu verwenden.

4.2.7 Border

Die Klasse Border wird verwendet, um Bildschirmelemente mit einem Rand bzw. Rahmen zu versehen. Dabei können Abstände zwischen einzelnen Elementen hergestellt werden, wodurch engere Zusammenhänge zwischen Informationen visualisiert werden. Durch Abstände zwischen einzelnen Teilen wird eine Gliederung des Fensters erreicht.

Grundsätzlich gibt es zwei verschiedene Ausprägungen dieser Klasse. In der ersten Form wird lediglich Platz um das zu umrahmende Bildschirmelement reserviert. Als Alternative gibt es die Möglichkeit zusätzlich eine Linie inklusive Überschrift um die Bildschirmelementgruppe zu platzieren. Die Farbe der Überschrift ist dabei auf schwarz zu setzen. Durch die Umrahmung wird eine noch größere Unabhängigkeit dieser Elemente von den restlichen im Fenster befindlichen Elementen vermittelt. Die Klasse Border sollte nur in der Klasse GMEBorder verwendet werden.

4.2.8 GMEBorder

Diese Klasse stellt alle Ausprägungen der Klasse Border für den Prototypen zur Verfügung. Damit wird eine einheitliche Verwendung von Rändern in allen Fenstern gewährleistet. Soll ein Rand mittels der Methode setBorder einem Bildschirmelement zugewiesen werden, dann ist als Parameter anzugeben:

GMEBorder.getBorder(GMEBorder.<< BORDERTYP >>).

Die zur Zeit definierten Randtypen sind in Anhang C.3.5 definiert. Diese können jederzeit erweitert werden.

4.2.9 Nutzung von Layoutmanagern

Der LayoutManager ist ein Interface, welches abgeleiteten Klassen ermöglichen soll, Position und Größe von Komponenten innerhalb eines Containers festzulegen. Ändert ein Container, beispielsweise ein Fenster, seine Größe, so positioniert der LayoutManager entsprechend den Vorgaben die Bildschirmelemente neu.

Der LayoutManager wurde in verschieden Klassen implementiert. So teilt BorderLayout beispielsweise den Bildschirm in die fünf Bereiche Oben, Unten, Links, Recht und Mitte. Die Klasse wurde in den meisten Fällen des Prototyp benutzt. Existieren in einem Fenster Bildschirmelementgruppen die sich auch bei Änderung der Fenstergröße gleich verhalten sollen, wird GridLayout benutzt. Um eine tabellarische Anordnung von Elementen zu erreichen kann die Klasse GridBagLayout genutzt werden. Bei dieser sind vorhandene Spalten mit einem Abstand von insgesamt 10 Pixeln zu versehen.

Wann welcher Layoutmanager zu verwenden ist, kann nicht konkret vorgegeben werden. Wichtig ist, dass der gesamte Bildschirminhalt auch bei Änderung der Fenstergröße sinnvoll positioniert bleibt. Zusätzlich sollten die allgemeinen Gestaltprinzipien unterstützt werden. Ob die richtigen LayoutManager eingesetzt wurden, muss bei jedem Fenster separat geprüft werden.

4.2.10 JMenu, JPopupMenu

Ein Menü stellt die Menge an verfügbaren Optionen des aktuellen Fensters dar. Ist in einem Fenster ein Menü implementiert, muss es alle Funktionen bereitstellen. Menüs wurden im Abschnitt 3.4.2.2 ausführlich behandelt. Sind nur wenige Funktionen verfügbar, muss kein Menü implementiert werden. Es reicht dann aus, ein Symbolleiste mit diesen Funktionen anzubieten.

Menüpunkte können mit einem Piktogramm versehen werden. Dieses muss das gleiche sein, dass an anderer Stelle bei gleicher Funktion verwendet wird. Soll kein Piktogramm angezeigt werden, dann muss ein Leeres angegeben werden, um eine einheitliche vertikale Ausrichtung der einzelnen Menüpunkte zu erreichen. Jeder Menüpunkt sollte mit einer Beschleunigungstaste versehen werden. Die einzelnen Menüpunkte sind nach logischen Kategorien zu organisieren. D.h., es sind logische Funktionsgruppen zu bilden. Die Reihenfolge innerhalb dieser sollte konsistent und nach Wichtigkeit geordnet sein. Ist eine Wichtung nicht möglich, kann auf eine konventionelle und danach auf die alphabetische Reihenfolge zurückgegriffen werden. Für häufig verwendete Menü-Optionen sollte eine Funktionstaste bereit gestellt werden. Konventionelle Belegungen, wie z.B. F1 für Hilfe, sollten übernommen werden. Optionen, die momentan nicht verfügbar sind, sollten den Status disabled erhalten. Damit ist es dem Benutzer möglich, alle Optionen zu explorieren, und bei Nichtverfügbarkeit über das Hilfesystem zu erfahren, wie diese Option aktiviert und benutzt werden kann. Menü-Optionen sollten einen kurzen erklärenden Text am unteren Rand des Fensters einblenden, da eine Option mit einem oder zwei Worten meist nur unzureichend erklärt ist. Bei Ihrer Bezeichnung selbst ist darauf zu achten, dass der Benutzer möglichst genau weiß, was mit dieser Option erreicht werden kann.

Kontextmenüs, die bei allen Klassen für Mengen, wie z.B. JList und JTree empfohlen sind, enthalten stets eine Untermenge des aktiven, globalen Menüs. Sie zeigen für das aktuell ausgewählte Bildschirmelement eine Auswahl an Optionen und werden durch Klicken der rechten Maustaste aufgerufen. Funktionen, die nur im Kontextmenü erreichbar sind, sollten vermieden werden. Ansonsten gelten auch für Kontextmenüs die gleichen Regelungen wie für globale Menüs.

4.2.11 JLabel

Die Klasse JLabel dient zum Darstellen eines einfaches Textes. Sie wird im allgemeinen genutzt, um Textfelder, Listen u.ä. zu spezifizieren. Die Position des Label sollte oberhalb des dazugehörigen Bildschirmelements sein. Damit wird vermieden, dass bei Längenänderungen des Textes, die z.B. durch Übersetzen in andere Sprachen auftreten können, Teile des Label überdeckt werden. Da Java in einem solchen Fall am Ende des Textes drei Punkte anfügt, die nochmals Platz benötigen, kann u.U. der Sinn des Elementes für den Benutzer nicht mehr erkannt werden. Wird dennoch eine Anordnung links des Bildschirmelementes gewählt, ist durch den Einsatz eines entsprechenden LayoutManagers (vgl. Abschnitt 4.2.9) sicherzustellen, dass solche Nebeneffekte nicht auftreten. Der Schrift des Labels ist weder kursiv noch fett. Ihre Farbe ist schwarz.

4.2.12 JButton

Die Klasse JButton dient dazu, einen Button auf dem Bildschirm darzustellen. Mit seiner Hilfe kann eine Funktion direkt ausgelöst werden. Buttons werden im Prototyp in drei verschiedenen Ausprägungen genutzt, die jeweils abhängig von der Position und der Semantik sind. Wird ein Button in einem JToolBar platziert, so wird er als Icon benutzt. Er hat dann die feste Größe von 27x27 Pixel. Der Button besteht lediglich aus einem Piktogramm, ein Text wird nicht angegeben.

Wird der Button unterhalb des Arbeitsbereiches des Fensters platziert, dient er als Zugriff auf die Sekundärfunktionen des aktuellen Fensters. Im allgemeinen sind das die Funktionen Bestätigen, Abbrechen, Hilfe und Zurücksetzen. Die Buttons haben in diesem Fall eine variable Breite und die feste Höhe von 27 Pixel. Ein Piktogramm ist im Gegensatz zum Text keine Pflicht. Das Standardlayout sieht vor, die Buttons je nach Vorhandensein rechtsbündig in der Reihenfolge Hilfe, Abbrechen und Bestätigen anzuordnen (vgl. Abbildung 7). Zusätzliche Button wie Zurücksetzen oder ähnliches werden linksbündig angeordnet. Der Standardbutton, welcher mit der Taste ENTER ausgelöst wird, bekommt zur Visualisierung automatisch den Randtyp 15 (vgl. Abschnitt 4.2.8) von der Klasse GMEJFrame zugewiesen.

Der Text der einzelnen Button muss je nach Anwendungsfall angepasst werden. Es empfiehlt sich die jeweilig ausgelöste Funktion zu beschreiben. Allgemeine Beschreibungen wie "OK" sollten möglichst vermieden werden.

Werden Buttons im Arbeitsbereich des Fenster angeordnet, so ist ihre Höhe auf 21 Pixel festzulegen. Ist ein Text angegeben, so ist die Breite variabel. Wird nur ein Piktogramm angezeigt, ist die Breite ebenfalls auf 21 Pixel zu setzen.

Eine Abwandlung der Klasse JButton ist die Klasse JToggleButton. Dieser Button hat die Möglichkeit, Ein/Aus Zustände zu visualisieren. Der Schriftschnitt des beschreibenden Textes des Button ist grundsätzlich Fett, die Farbe ist schwarz.

4.2.13 JTextField

Die Klasse JTextField ermöglicht die Eingabe von Daten. Grundsätzlich ist immer abzuwägen, ob für den jeweiligen Anwendungsfall das Textfeld ideal ist. Ist die Eingabe von begrenzter Länge, der Inhalt jedoch frei wählbar, dann sollte dieses Element genutzt werden. In anderen Fällen können auch Kombinationsfelder (JCombobox), Listen (JList) oder mehrzeilige Texteingabe (JTextArea) die bessere Wahl sein. Diese Klasse JTextField kann auch genutzt werden, Informationen anzuzeigen. Dabei ist lediglich die Eigenschaft editable auf false zu setzen. Der Vorteil gegenüber der Anzeige mit einem JLabel besteht darin, dass der Benutzer die Information markieren, kopieren und anderweitig verwenden kann.

4.2.14 JDateField

Die Klasse JDateField (vgl. Anhang C.1.3) wird verwendet, wenn ein Datum ein- oder ausgegeben werden muss. Sie wurde von JTextField abgeleitet, um eine bessere Unterstützung des speziellen Formates zu erreichen. Aus diesem Grund gelten für die Klasse die gleichen Bedingungen wie für die Klasse JTextField.

Werden weitere Eingaben eines bestimmten Datentyps öfters benötigt, sollte auch für diese eine Klasse abgeleitet werden. Das erleichtert sowohl die Implementation, als auch die spätere Benutzung durch eine bessere Fehlerbehandlung. Zusätzlich wird sichergestellt, dass spezielle Datenformate immer in der gleichen Form verwendet werden.

4.2.15 JTextArea, JEditorPane

Sowohl die Klasse JTextArea als auch die Klassen JEditorPane werden nicht verwendet. An Ihrer Stelle wird grundsätzlich JTextPane genutzt.

4.2.16 JTextPane

Die Klasse JTextPane ermöglicht die Anzeige und Eingabe von mehrzelligem Text. Dabei wird ein plug-in Editor Kit benutzt, das an den anzuzeigenden Text angepasst werden kann. Bereits vorhanden sind RTF, HTM Styled Text und Default Editor Kit. Für die Anzeige von HTML-Seiten ist das JTextPane ausreichend. Für die Eingabe von normalen Text, wie er beispielsweise für die Dokumentation gebraucht wird, muss mindestens das RTF Editor Kit implementiert werden. Die Funktionen für Schriftartwechsel u.a. müssen mittels einer Symbolleiste oder einem Menü dem Benutzer zugänglich gemacht werden. Wird dem Bildschirmelement JTextPane kein JScrollPane zugewiesen, so muss ihm grundsätzlich der Randtyp 18 (vgl. Abschnitt 4.2.8) zugewiesen werden.

4.2.17 JCombobox

Ein Kombinationsfeld ermöglicht die Auswahl aus einer Liste von Objekten. Es ist keine Mehrfachauswahl möglich. Falls erforderlich kann die Eingabe einer neuen Option ermöglicht werden. Kombinationsfelder bieten sich ideal an, um beispielsweise Statusanzeigen zu visualisieren. Die Hintergrundfarbe ist auf weiß zu setzen. Die Höhe ist wie bei den übrigen einzeiligen Elementen auf 21 Pixel festzulegen.

4.2.18 JList

Eine Liste visualisiert ein Menge an Objekten, welche normalerweise in Textform dargestellt sind. Die Objekte können jedoch auch grafisch angezeigt werden. Listen ermöglichen eine Mehrfachauswahl. Es ist immer zu prüfen, ob für die dargestellten Objekte ein Kontextmenü angeboten werden soll. Die Klasse JList muss grundsätzlich mit einem JScrollPane verknüpft sein, um ein Scrollen zu ermöglichen. Die Bezeichnung von Listen wird oberhalb angeordnet. Werden Elemente eingefügt, muss der neue Eintrag anschließend selektiert sein. Wird ein Eintrag gelöscht, sollte der nächste gültige Eintrag selektiert sein. Bei Listen, die einen größeren Umfang erreichen können, sollte eine Sortier- sowie eine Suchfunktion angeboten werden. Wird dem Bildschirmelement JList kein JScrollPane zugewiesen, so muss ihm grundsätzlich der Randtyp 18 (vgl. Abschnitt 4.2.8) zugewiesen werden.

4.2.19 JTree

Auch die Klasse JTree dient zum Anzeigen einer Menge von Objekten. Im Unterschied zu einer einfachen Liste, stehen hier die Objekte in einer hierarchischen Ordnung. Zusätzlich ist meist der Typ von Objekten einer Ebene gleichartig, während er sich in untergeordneten Hierarchien ändern kann. Ist dies der Fall, sollte vor der textuellen Beschreibung ein Piktogramm zur Identifikation dargestellt werden. Das folgende Beispiel zeigt drei Ebenen, wobei die Objekte jeder Ebene einen anderen Typ besitzen.

Besitzt das angezeigte Objekt untergeordnete Elemente, so sollte das durch ein zusätzliches Piktogramm angezeigt werden. Auch bei diesem Bildschirmelement wird die Bezeichnung oberhalb angeordnet. Beim Einfügen oder Löschen von Einträgen verhält sich die Klasse JTree wie JList. Wird ein Element untergeordneter Ebene eingefügt, muss der Pfad zu diesem Element ebenfalls mit geöffnet werden. Auch der Klasse JTree sollte ein JScrollPane zugewiesen werden. Ansonsten ist dem Bildschirmelement der Randtyp 18 (vgl. Abschnitt 4.2.8) zuzuweisen.

4.2.20 JTable

Tabellen stellen zweidimensional organisierte Informationsmengen dar. Eine explizite Bezeichnung durch einen Label ist nicht unbedingt nötig, da die Spaltenüberschriften meist ausreichend Aufschluss über den Inhalt der Tabelle liefern. Üblicherweise wird in Zellen Text mittels der Klasse JLabel dargestellt. Hier sollte der Schriftschnitt von fett auf normal zurückgesetzt werden. Werden andere Klassen innerhalb der Tabelle abgebildet, so sind die in diesem Style Guide aufgestellten Regeln zu beachten. Der Benutzer sollte die Möglichkeit haben, Tabellen nach ausgewählten Spalten zu sortieren. Diese sollten auf Verlangen auszublenden und untereinander auszutauschen sein. Die vom Benutzer vorgenommen Änderungen in der Darstellung der Tabelle sollten gespeichert werden, um beim nächsten Programmstart die gleiche Anzeige wieder herstellen zu können.

4.2.21 JCheckBox

Die Klasse JCheckBox wird genutzt, um zwischen zwei möglichen Zuständen auszuwählen. Sie ist die vereinfachte Form von zwei voneinander abhängigen JRadioButton und besitzt die gleiche Funktionalität wie ein JToggleButton. Der Vorteil diesem gegenüber ist die Möglichkeit, eine längere Beschreibung mit darzustellen. Diese sollte einen normalen Schriftschnitt und die Farbe schwarz besitzen.

4.2.22 JRadioButton

Die Klasse JRadioButton wird benutzt, um eine endliche Anzahl von sich ausschließenden Optionen anzuzeigen und gleichzeitig einen schnellen Zugriff zu gewähren. Müssen mehr als fünf Optionen visualisiert werden, sollte eine nicht editierbare Klasse JList bzw. JCombobox vorgezogen werden. Die Klasse JRadioButton muss grundsätzlich einer Instanz von ButtonGroup zugeordnet werden. Die Schriftart der Bezeichnungen ist weder kursiv noch fett. Ihre Farbe ist schwarz.

4.2.23 Tooltips

Tooltips stellen Hinweise dar, die angezeigt werden, wenn der Benutzer eine kurze Zeit mit dem Mauszeiger auf einem Bildschirmelement verweilt. Es sollte für jedes sichtbare Element ein entsprechender Text vorgesehen sein. Dabei sollte das Bildschirmelement inhaltlich beschrieben werden. Wie bei den beschreibende Texten der Klasse JLabel ist auf allgemeine Floskeln zu verzichten. Die Beschreibung: "Bitte Text eingeben" gibt wenig Aufschluss, welche Art von Text eingegeben werden soll.

4.3 Icons

Icons ermöglichen die grafische Darstellung von Optionen oder Objekten. Für Icons gibt es zwei Standardgrößen. Die Größe 16 x 16 Pixel wird für Bäume, Fenster, Listen u.ä. genutzt. Für Button wird die Größe 24 x 24 Pixel empfohlen. Die Entwicklung einer Icon-Familie wird ausführlich im Abschnitt 3.4.4 diskutiert.

 © yves köth