UI DESIGN COOKBOOK BOOKLET - bbv.ch · · [email protected] MAKING VISIONS WORK. Unsere Booklets und vieles mehr finden Sie unter Beratung Ausbildung Engineering ERFOLG Lösungen

Copyright © 2015

bbv Software Services AG

BO

OK

LET UI DESIGN COOKBOOK

UI DESIGN COOKBOOK

2 COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

Kontakt Schweiz

bbv Software Services AG

Blumenrain 10

6002 Luzern

Telefon: +41 41 429 01 11

E-Mail: [email protected]

Kontakt Deutschland

bbv Software Services GmbH

Agnes-Pockels-Bogen 1

80992 München

Telefon: +49 89 452 438 30

E-Mail: [email protected]

PROFITIEREN SIE VON UNSERER ERFAHRUNG!

Der Inhalt dieses Booklets wurde mit Sorgfalt und nach bestem Gewissen erstellt. Eine Gewähr für die Aktualität, Vollständigkeit und Richtigkeit des Inhalts kann jedoch nicht übernommen werden. Eine Haftung (einschliesslich Fahrlässigkeit) für Schäden oder Folgeschäden, die sich aus der Anwendung des Inhalts dieses Booklets ergeben, wird nicht übernommen.

UI DESIGN COOKBOOK

3COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

1 Einleitung 5

2 Generelle Tipps 7

3 Architektur 12

4 Komponenten 15

4.1 Menüs (Menü, Toolbar, Taskpane, Ribbon, Outlook-Bar) 16

4.2 Panels mit Docks und Anchors, UI bauen leicht gemacht 20

5 Internationalisierung und Lokalisierung 24

5.1 Pseudolokalisierung 25

5.2 Tastatur 29

5.3 Unicode und Fonts 33

5.4 Schriftgrösse 34

5.5 Sortierung 36

5.6 Bidirektionale Oberflächen 40

5.7 Lokalisierung in WPF 41

5.8 Lokalisierung in ASP.NET 50

6 Datenverwaltung 54

6.1 Datensuche 55

6.2 Dateneditierung 57

6.3 Datenerfassung 58

6.4 Datensuche 60

6.5 Dateneditierung und Dateneingabe 62

6.6 Schnellsuche 63

6.7 Formatierte Werte 65

6.8 Darstellung von Einheiten 67

6.9 Optimale Lösung 68

6.10 Massenerfassung von gleichartigen Daten 69

6.11 Freitext-Kommentare 71

INHALT


UI DESIGN COOKBOOK

7 Validierung 74

7.1 Allgemeine Richtlinien zur Validierung 75

7.2 Texteingaben (TextBox) validieren 77

7.3 Zwingende Eingabe validieren (Required Input) 79

7.4 Eingabedialoge mit mehreren Controls validieren 82

7.5 Abhängige Controls über mehrere Eingabedialoge validieren 83

7.6 Validierungen mit Windows Forms 85

7.7 Validierungen mit ASP.NET 91

7.8 Validierungen mit ASP.NET MVC 92

8 Layout 94

8.1 Übersicht von komplexen Fachdaten 95

8.2 Darstellung von komplexen Fachdaten 97

8.3 Status- & Umgebungsinformationen 101

8.4 ListView, Alternative zu Grids 103

8.5 Gruppierte Elemente 105

9 Anwenderunterstützung 108

9.1 Kontexthilfe 109

10 Berechtigungen 112

10.1 Daten mit Benutzerberechtigungen 113

10.2 Funktionen mit Benutzerberechtigungen 116

11 Anhang 118

11.1 Autoren 119

UI DESIGN COOKBOOK


1 EINLEITUNG

Dieses Booklet enthält allgemeine Ratschläge zur

Konstruktion eines User Interface, aber auch kon-

krete Vorschläge zu bestimmten Themen. Es um-

fasst das gesammelte Know-how der Autoren,

welche die Vorschläge bereits implementiert und

erprobt haben, und erleichtert somit dem Neuling

auf diesem Gebiet den Einstieg erheblich.


UI DESIGN COOKBOOK

UI DESIGN COOKBOOK


TECHNOLOGIEABHÄNGIGKEIT

Die hier vorgestellten Ratschläge gelten zwar allgemein für alle

verwendeten Plattformen und Technologien, doch gibt es immer

Ausnahmen, bei denen das Konzept entweder nicht auf die Platt-

form umgesetzt werden kann, oder eine neue Technologie bringt

Einschränkungen bzw. Möglichkeiten mit sich, die andere Ansätze

benötigen. Daher wurden die konkreten Lösungsvorschläge mit fol-

genden Symbolen versehen, die Auskunft über ihre Einsatztauglich-

keit in der entsprechenden Technologie geben:

WinForms WPF Silverlight ASP.NET

UI DESIGN COOKBOOK


2 GENERELLE TIPPS

Bevor man sich an die Arbeit begibt, um ein neues

GUI zu entwerfen, sollte man einige Dinge im Vor-

aus abgeklärt haben.

UI DESIGN COOKBOOK


Entwurf eines GUI

Danach setzt man sich am besten nicht an den Computer, sondern

geht mit Papier und Bleistift auf Abstand zum Bildschirm, bis man

schliesslich einen ersten Prototypen implementieren kann. Doch al-

les der Reihe nach.

Vorabklärung

Folgende Dinge müssen bekannt sein, um ein UI so umzusetzen,

dass es dem Benutzer den grössten Nutzen bringt:

1. Kenne den Kunden. Wenn möglich, sollte man mit dem Kun-

den reden oder wenigstens mit Leuten, die mit dem Kunden in

Kontakt stehen. Ergründe, was die eigentlichen Ziele, Wünsche

und Ängste des Kunden im Umgang mit der Applikation sind.

Aussagen wie «Der Kunde weiss das sowieso nicht» sollte mit

Ideenskizzen entgegengewirkt werden, und das «Der-Kunde-will-

alles»-Syndrom kann mit geschicktem Hinterfragen geheilt wer-

den.

2. Vorgaben durch den Auftraggeber. Sind gewisse Bedienungsmus-

ter oder Bibliotheken vorgeschrieben, so muss man diese kennen-

lernen.

3. Vorgaben durch das Projekt. Ziemlich sicher handelt es sich bei

dem vorgängigen Produkt nicht um die einzige Applikation, dann

wird man sich auf Vorgaben durch das Projekt bezüglich Schnitt-

stellen, Nomenklatur usw. einstellen müssen.

4. Styleguides der Zielplattform. Microsoft hat zum Zeitpunkt, da

dieser Text geschrieben wurde, den Support von Windows XP SP2

bereits aufgekündigt. Moderne Plattformen, egal ob im Desktop-

oder im mobilen Bereich, werden immer bunter, und man kann

viele angestaubte UI-Komponenten und -Konzepte über Bord kip-

pen. Hersteller wie Microsoft oder Apple bieten Styleguides an, in

UI DESIGN COOKBOOK


denen UI-Komponenten erklärt, spezifiziert und ihre besten Ein-

satzgebiete aufgezeigt werden. Bevor man sein Wissen aus Win-

dows-95-Zeiten in den neuen Entwurf einfliessen lässt, muss man

sich über die neuen Vorgaben der Hersteller informieren.

Vorarbeit

Man sollte eine genaue Vorstellung davon haben, wie es im und

um das Programm herum aussehen soll. Ganz Verwegene setzen

sich direkt an den Computer und beginnen draufloszupinseln. Es

empfiehlt sich jedoch, sich mit Papier (Flipchart) und Bleistift (dicke

Filzschreiber), wenn möglich auch mit einem oder zwei Kollegen,

ins stille Kämmerchen zurückzuziehen und die einzelnen Seiten und

Abläufe zu skizzieren. So entsteht das funktionale Design:

1. Erste Design-Ideen aufzeichnen. Auch wenn dies höchstens Ver-

satzstücke sind, so kann man diese später umformen und einflies-

sen lassen.

2. Grobe Einteilung festlegen. In den meisten Programmen gibt es

Bereiche für Menü, Service-Information und Inhalt, auch wenn

diese nicht immer als solche sichtbar sind.

3. Einfügen von Inhalt in das grobe Grundraster. Elemente sind nach

Logik, nicht nach technischer Umsetzung zu strukturieren.

4. Bedienkonzepte erarbeiten. Es lohnt sich durchaus, sich weiter-

gehende Gedanken zu verschiedensten Navigations- und Infor-

mationsanzeigen zu machen. Diese sollte man ebenfalls aufzeich-

nen und mit einem Papier-Prototypen durchspielen. Es kann wie

eine lustige Bastelstunde aussehen, wenn Ingenieure mit Papier,

Filzstift, Schere und Kleber UIs zusammenbauen, aber es zeigt be-

reits erste Mängel von Konzepten, die man sonst erst nach stun-

denlanger Prototypenimplementierung gefunden hätte.

UI DESIGN COOKBOOK


5. Diskussion mit Kunden und Auftraggeber. Die bis jetzt entstande-

nen Skizzen (man kann sie auch mit Tools wie Balsamiq Mockups

oder Expression Blend «Sketch» nachzeichnen) mit Benutzern

und Auftraggeber in kurzen, kreativen Workshops durchgehen.

Hier sind die Fehler noch am einfachsten zu korrigieren.

Die Punkte 3 bis 5 wiederholen, bis man sicher ist, dass die Konzep-

te den ersten Benutzerkontakt überleben.

Umsetzung

Mit dem funktionalen Design könnte man anfangen zu implemetie-

ren, doch noch fehlt der rote Faden, wie das Programm aussehen

soll. Deshalb geht es weiter in Richtung Styleguide und Screende-

sign. Es lohnt sich, einen eigenen Styleguide zu erstellen, um dem

Entwickler eine Vorgabe zu geben, wie gross einzelne Elemente

sein sollen, wonach ausgerichtet werden soll, welche Bilder einge-

baut werden und wie Interaktionen ablaufen sollen.

My Styleguide

Folgende Punkte sollte man in einem eigenen Styleguide finden:

1. Farben, Formen, Schriften. Diese Grundelemente sollten jedem

Entwickler und Designer weiterhelfen, einen gemeinsamen Nen-

ner zu finden. Im Hinblick auf die Applikation kann man hier all-

gemeingültig Schemas festlegen, wann welche Form, Farbe oder

Schrift eingesetzt wird.

2. Fläche/Format. Vorgaben für den verfügbaren Platz bzw. gesperr-

te Flächen, aber auch Standard-Dialoggrössen tragen dazu bei,

dass die Applikation wie aus einem Guss wirkt.

3. Raster bringen Abstände und Grössen. Jeder, der ein UI mit un-

terschiedlichsten Button-Grössen und Abständen sieht, weiss,

UI DESIGN COOKBOOK


dass diese eigentlich sehr einfache Aufgabe die meisten Entwick-

ler zu überfordern scheint. Am besten legt man das Raster fest,

in welchem sich die einzelnen Elemente befinden dürfen. Ein Bild

mit einem Beispiel-Screenshot und Bemassung hilft. Hier gibt man

rudimentär vor, dass z. B. Buttons entweder 100 oder 140 px breit

sein dürfen, bei einem Abstand von 8 px, und schon werden 90

Prozent der Screens mit Buttons konsistenter aussehen.

4. Komposition. Welche Information soll welchen Platz einnehmen,

das heisst, wo sind Menüs, Navigation, Inhalt und Service-Berei-

che platziert? Je nach Art und Wichtigkeit der Information muss

diese mehr oder weniger Platz und Aufmerksamkeit bekommen.

5. Dynamik. Sollen Animationen gezeigt werden, Überblenden oder

Umblättereffekte einen Wechsel darstellen oder der Fortschritt

angezeigt werden, so gehört dies ebenfalls in einen Styleguide.

Diese Liste ist nicht abschliessend, doch sollte man es auch nicht

übertreiben.

Damit haben die Entwickler und Requirements nun genügend Ma-

terial, um mit ihren Tätigkeiten loszulegen. Allmählich kann man

sich auch um Verfeinerungen und Details kümmern, denn es folgen

die nächsten Schritte unter dem Titel «Informationsdesign», in dem

sich alles um die verständliche Darstellung von Information dreht.

Informationsdesign soll Klarheit schaffen, nicht Einfachheit. Klarheit

zeigt die Information, Einfachheit lässt diese weg.

Und genau hier sollen die nächsten Kapitel helfen.

UI DESIGN COOKBOOK


3 ARCHITEKTUR

Die Zeiten monolithischer Applikationen sind

schon lange vorbei, und trotzdem sieht man diesen

Ansatz immer wieder auch im UI aufblühen. Dabei

kann man die Logik sehr einfach von den reinen

Anzeigeroutinen trennen, und eigene User-Con-

trols bieten die Möglichkeit, kleine logische Einhei-

ten zu bilden.

UI DESIGN COOKBOOK


Wichtig ist dabei die Trennung von UI und Logik, auch solcher Logik,

wie innerhalb eines Formulars die verschiedenen Elemente intera-

gieren sollen. Gerade beim letzten Punkt muss aber von Fall zu Fall

entschieden werden, wo die Trennung liegt. Die Schnittstelle des

UI sollte dabei möglichst neutral in Bezug auf komponentenspezi-

fische Datentypen bleiben. Dies erleichtert einerseits die Unittests

der Logik wie auch andererseits den Austausch von Komponenten.

Aber auch die dem UI vorgelagerte Logik (Presenter oder View-

Model genannt) sollte von jeglicher Datenverarbeitung getrennt

werden. Es wird manchmal darüber gelästert, dass diese Schicht

lediglich ein Durchlauferhitzer ist, was so ja auch stimmt, aber sie

verändert die Daten der Business Domain in eine Form, welche die

Weitere Informationen findet man in einschlägigen Publikationen

unter Namen wie MVP, Passive View oder MVVM.

Abbildung 3-1: UI-Schichten

UI DESIGN COOKBOOK


Verarbeitung für den Benutzer einfacher macht. In genau dieser

Schicht werden Daten zusammengetragen und geordnet, in lesbare

Texte, Bilder und Farben übersetzt und für die Eingaben verarbeitet.

Der Presenter kann gegenüber der Logik auch dadurch getrennt

sein, dass diese auf einem anderen Thread läuft, eine Lücke, welche

mit dem bbv.common.EventBroker relativ elegant und ohne grösse-

re Probleme übersprungen werden kann.

UI DESIGN COOKBOOK


Kommen wir nun zu typischen Basis-Komponen-

ten, die man kennen muss, bevor wir auf konkre-

tere Detailprobleme und ihre Lösungen eingehen.

4 KOMPONENTEN

UI DESIGN COOKBOOK


4.1 MENÜS (MENÜ, TOOLBAR, TASKPANE, RIBBON,

OUTLOOK-BAR)

Das zentrale Element, um dem Benutzer die verschiedensten Funk-

tionen zu offerieren, ist in vielen Applikationen immer noch das

Menü. Doch vor allem in neueren Applikationen gibt es auch al-

ternative Arten, um Funktionen aufzurufen. Nebst dem Menü sind

dies Toolbars, Taskpane, Ribbon und Outlook-Bar.

Menü

Das klassische Menü wird auch weiterhin noch verwendet, vor al-

lem dank der folgenden Eigenschaften:

• Geringer Platzbedarf

• Einfache Programmierung

• Auf nahezu allen Plattformen verfügbar

• Korrekte Strukturierung wesentlich einfacher als bei Ribbons

Die grösste Herausforderung ist bei der Strukturierung der Menüein-

träge zu finden, wobei man sich für viele Applikationen an den

propagierten Standards orientieren kann. Hier ein nach Microsofts

Vorschlag aufgebautes Menü:

UI DESIGN COOKBOOK


Abbildung 4-1: Menüs strukturiert nach

Microsoft

Toolbar

In Kombination mit einem Menü ist häufig auch eine Toolbar zu fin-

den. Diese zeigt die wichtigsten Funktionen als Buttons mit Grafik

an. Vom Benutzer wird erwartet, dass er diese seinen eigenen Be-

dürfnissen anpassen kann, auch wenn die ursprüngliche Auswahl

bereits 95 Prozent aller Benutzer zufriedenstellen sollte.

Taskpane

Die Taskpane (z. T. auch Explorer-Bar genannt) findet man ab und

zu in Windows-Dialogen, wesentlich seltener in Applikationen.

UI DESIGN COOKBOOK


Abbildung 4-2: Taskpane aus Windows 7

Eine Taskpane zeigt ein verhältnismässig kleines Set an Kommandos

und benötigt doch einiges an Platz. Wenn verschiedene Taskpa-

nes abhängig vom derzeitigen Fensterinhalt angezeigt werden, ist

zwingend darauf zu achten, dass die Zusammenhänge dem Benut-

zer ersichtlich sind.

Ribbon

Das Menü wird trotz anfänglicher Akzeptanzprobleme immer mehr

durch die Ribbons à la Office abgelöst. Diese weisen einige wirkli-

che Vorteile auf, vor allem im Bereich der Usability:

• Galerien erlauben eine bessere Vorschau des angestrebten

Resultats.

• Grosse Icons sprechen Benutzer auf grafische Weise an, man

muss weniger lesen.

• Logik und Funktion sind wichtiger als programmiertechnische

Zusammengehörigkeit.

UI DESIGN COOKBOOK


• Kontextsensitive Ribbons können je nach derzeitigem Programm-

schritt oder -inhalt hinzugefügt werden.

• Verbreitung nimmt stark zu, sie gehören bereits zum Standard

von Windows-Applikationen.

• Verhalten und Aussehen werden von Microsoft weitgehend

vorgegeben, dem Wildwuchs bei Komponentenherstellern sind

somit einige Grenzen gesetzt.

Bevor man aber zum Ribbon greift, sollte man unbedingt vorher

die Lizenzbestimmungen von Microsoft durchlesen, denn es gibt

eine kleine Einschränkung, bei welchen Tools Ribbons verwendet

werden dürfen.

Derzeit sind die Lizenzinformation und der Ribbon-Styleguide auf

folgender Seite zu finden:

http://msdn.microsoft.com/office/aa973809.aspx

Outlook-Bar

Eine weitere Art, um Kommandos und andere Funktionalitäten an-

zuzeigen, ist wie in Microsoft Outlook ein Panel, bestehend aus

mehreren Bereichen, die wechselseitig angezeigt werden können

und diverse Controls beinhalten. Ein Outlook-Bar kann sowohl mit

Menü/Toolbar wie auch mit Ribbons gemischt werden und bietet

weiter noch folgende Vorteile:

• Einfache Umschaltung von Betriebsmodi und Paletten

• Komplexe Controls wie Treeviews und Kalender können gut plat-

ziert werden

• Grössere Grafiken als in Menüs möglich

UI DESIGN COOKBOOK


4.2 PANELS MIT DOCKS UND ANCHORS – UI BAUEN

LEICHT GEMACHT

Wie bereits in den vorherigen Kapiteln angesprochen, sollte man

nicht mehr alle Controls einfach so auf dem Formular verteilen.

Stattdessen gilt die Empfehlung, die Formularfläche in kleinere Flä-

chen zu unterteilen und Controls zu gruppieren. Das folgende Bei-

spiel zeigt eine mögliche Unterteilung.

Abbildung 4-3: Panels mit Dock und

Anchor

Die Einteilung geschieht hauptsächlich über Panels, die mittels

Dock-Eigenschaft in einen Bezug zueinander gestellt werden. In-

tern werden die darauf platzierten Elemente mit Anchors an die

Ränder angeheftet, sodass die Elemente an einem bestimmten Ort

verharren und/oder ihre Grösse entsprechend anpassen. Wenn alle

Einstellungen richtig gesetzt wurden, kann man das Formular ohne

UI DESIGN COOKBOOK


Bedenken vergrössern oder verkleinern. Die Randabstände sollten

konstant bleiben, und es dürften keine Elemente verschwinden.

Doch wie funktionieren diese beiden Eigenschaften im Detail?

Dock

Wenn ein Control an sein hierarchisch darüberliegendes Parent-Con-

trol gedockt wird, übernimmt es automatisch dessen Dimensionen

und Position oder Teile davon und füllt den entsprechenden Platz

aus. Gedockte Elemente können sich nicht überschneiden. Wird

nun vom Benutzer das Formular vergrössert oder verkleinert, wer-

den die gedockten Controls gleich wieder passend zurechtgerückt.

Docks eignen sich vor allem für grossflächige Controls wie z. B. List-

View, TreeView, Panels etc. Bei Textfeldern, Buttons und anderen

eher kleinen Controls sind Anchors oft der bessere Weg.

Anchors

Mit Anchors setzt man den Abstand vom Control zu dessen hier-

archisch darüberliegendem Parent-Control als feste Grösse, d. h.,

wenn das Formular vom Benutzer vergrössert wird, bleiben die per

Anchor gesetzten Abstände bestehen, alles andere wird als flexibel

betrachtet.

Setzt man den Anchor auf «left», so verbleibt das Control links (im

Beispiel unten der Skype-Name) und ändert auch die Grösse nicht.

Wäre der Anchor auf «right» gesetzt, würde das Control sich am

rechten Rand orientieren (siehe E-Mail). Ist der Anchor auf «left,

right» gestellt, so wird die Grösse sich ändern, der rechte bzw. linke

Abstand zur Kante wird dagegen konstant bleiben (siehe Name).

UI DESIGN COOKBOOK


Mit diesen beiden Eigenschaften kann man folgendes Beispiel ganz

einfach an jede beliebige Grösse anpassen. Aber vielleicht will man

gar nicht jede Grösse erlauben. Daher empfiehlt es sich, eine mini-

male Grösse für das Formular zu definieren, sobald man abschätzen

kann, was noch Sinn macht.

Flexibel oder fixe Grösse

Damit man nun die korrekten Eigenschaften setzen kann, muss aber

erst bekannt sein, wie sich das UI bei Grössenänderungen verhalten soll.

Generell kann man bei reinen Eingabemasken auf Flexibilität ver-

zichten, da man lediglich leere Flächen unterhalb des letzten Ein-

trags sehen würde. Bei Grids, ListViews, mehrzeiligen Texteingaben

erlaubt eine flexible Grössenänderung, bei verfügbarem Bildschirm-

platz mehr Information darzustellen oder das Fenster zugunsten ei-

ner anderen Applikation kleiner darzustellen.

Abbildung 4-4: Auswirkungen von

Anchors

UI DESIGN COOKBOOK


Zusammenfassung

Dieses Kapitel lässt sich auf folgende Punkte zusammenfassen:

• Definiere feste und dynamische Bereiche

• Docks oder Anchors setzen

• Minimale Fenstergrösse definieren

UI DESIGN COOKBOOK


5 INTERNATIONALISIERUNG UND LOKALISIERUNG

UI DESIGN COOKBOOK


5.1 PSEUDOLOKALISIERUNG


Problemstellung / Situation

Für Projekte, die lokalisiert werden sollen, sollte man bereits wäh-

rend der Entwicklung die Lokalisierbarkeit sicherstellen. Auch für

die Lokalisierbarkeit gilt der Grundsatz, dass ein Problem teurer

wird, je später man es entdeckt.

Lösungsvorschlag

Die Pseudolokalisierung ist eine kostengünstige Möglichkeit, die Loka-

lisierbarkeit zu überprüfen. Dabei wird das zu lokalisierende Material

von einem Skript oder Tool durch identifizierbare Pseudodaten ersetzt.

Die Pseudolokalisierung kann bei verschiedenen Problemen helfen:

• Identifikation von hart kodierten Texten

• Identifikation von zu lokalisierendem Material, das nicht für die

Lokalisierung bereitgestellt wird

• Identifikation von Material, das fehlerhafterweise lokalisiert wird

(z. B. Produktenamen)

• Platzprobleme bei Elementen der Benutzeroberfläche mit fixer

Grösse

• Layout-Probleme bei Elementen der Benutzeroberfläche, die sich

an ihren Inhalt anpassen

• Tauglichkeit der gewählten Schriftart und Grösse für verschiede-

ne Zeichensysteme

• Fehlerhafte Rechts-nach-links-Darstellung (Pseudo-Mirroring)

UI DESIGN COOKBOOK


• Fehlende oder fehlerhafte Internationalisierung (z. B. fixes Da-

tumsformat)

• Feature-Fehler (z. B. fehlerhaftes Data-Mining)

Es gibt verschiedene Formen der Pseudolokalisierung von Texten:

Greeking

Alle Zeichen werden durch ein vorzugsweise nicht lesbares Zeichen

ersetzt. Dies ist ein simpler Test für generelles Layouting und die

Identifikation von nicht übersetztem Material.

Abbildung 5-1: Greeking

Diakritika

Diakritische Zeichen sind kleine Zeichen (Punkte, Kreise, Striche u.

a.), die den Buchstaben für eine besondere Aussprache hinzugefügt

werden. In der deutschen Sprache haben die Buchstaben Ä, Ö und

Ü diakritische Zeichen. Für die Pseudolokalisierung werden Vokale

zufällig mit diakritischen Zeichen versehen. So bleibt das originale

Wort lesbar, ist jedoch auch klar als Übersetzung erkennbar.

UI DESIGN COOKBOOK


«Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt

mollit anim id est laborum.»

Lorem Ipsum

Lorem Ipsum ist ein bedeutungsloser pseudolateinischer Blindtext,

der seit dem 16. Jahrhundert für das Schriftsetzen verwendet wird.

Bei der Pseudolokalisierung kommt zwar nicht zwangsläufig der ori-

ginale Lorem-Ipsum-Text zum Einsatz. Bedeutungsloser Blindtext im

Generellen ist jedoch eine wirkungsvolle Methode, um Layouting zu

testen, und wird häufig bei Desktop-Publishing-Programmen ver-

wendet.

Pseudo localization Psëëùùdøø løøçåålîîzååtîîøøñ

Abbildung 5-2: Lorem-ipsum-Text

UI DESIGN COOKBOOK


IDs

Die Texte werden durch eindeutige IDs ersetzt. Dies dient vor allem

dazu, die Texte für allfällige Korrekturen schnell wiederzufinden.

Diese Methode wird häufig mit einer weiteren kombiniert.

Zufallsübersetzung

Das Material wird zufällig in Zeichen oder Worte der Zielsprache

übersetzt. Für diese Methode ist eine fortschrittliche Tool-Unter-

stützung notwendig. Dafür ist es mit ihr relativ einfach möglich,

ungewöhnliche Zeichensysteme (asiatisch, arabisch etc.) zu prüfen.

Maschinelle Übersetzung

Heutzutage gibt es für viele Sprachen die Möglichkeit einer ma-

schinellen Übersetzung. Die Qualität ist häufig ziemlich unbefriedi-

gend, für eine Pseudolokalisierung jedoch vollständig ausreichend.

Abbildung 5-3: Zufällig generierter

chinesischer Text

UI DESIGN COOKBOOK



Tastaturlayouts sind länderspezifisch. Sie unterscheiden sich in der

Bedeutung, Bezeichnung und der Anzahl der verfügbaren Tasten.

Die Anordnung der Navigationstasten (Cursor, Home, PgUp, PgDn,

End) ist sogar produktabhängig. Ein numerischer Eingabeblock ist

nicht zwangsläufig vorhanden. Eine internationalisierte Anwen-

dung muss dies berücksichtigen.

Nowadays gives for many languages the possibility of a machine translation. The quality is often quite dissatisfactory, for a Pseudo localisation, nevertheless, completely enough.

Abbildung 5-4: Automatisch

übersetzter Text

Bemerkungen

• Die Pseudolokalisierung von anderem Material ausser Text ist et-

was aufwendiger. Man sollte dieses Material jedoch nicht ignorie-

ren. Eine Methode wie das Greeking bei Texten sollte einfach und

kostengünstig genug sein, um auch eine grobe Überprüfung des

restlichen Materials sicherzustellen.

• Im Rahmen der agilen Softwareentwicklung hat die Pseudoloka-

lisierung an Bedeutung gewonnen. Sie ist ein halbautomatischer

Test, der bereits in frühen Entwicklungsphasen eingesetzt wer-

den kann.

5.2 TASTATUR


UI DESIGN COOKBOOK


Lösungsvorschlag

Das Betriebssystem ist verantwortlich für die Behandlung unter-

schiedlicher Tastaturlayouts. Normalerweise sind keine weiteren

Aktionen durch die Anwendung nötig. Trotzdem gibt es einige

Punkte zu beachten:

• Physikalische oder inhaltliche Interpretation

Bei der Interpretation von gedrückten Tasten muss man immer

klar unterscheiden, ob die physikalische Identität der Taste

(z. B. Scan-Code) oder die inhaltliche Bedeutung (z. B. Char)

relevant ist.

• Tastatur-Shortcuts

Shortcuts sollten nur auf Tasten verknüpft werden, die auf allen

Standard-Tastatur-Layouts vorkommen.

• Mnemonics

Mnemonics sind nicht internationalisierbar. Sie beziehen sich auf

ein einzelnes Zeichen eines lokalisierten Texts. Mit einer russi-

schen Tastatur kann man zum Beispiel ein Mnemonic ALT-T nicht

ausführen, indem man einfach die Taste verwendet, wo auf einer

englischen Tastatur das T wäre.

• Übersetzung von Tastenkombinationen

Beziehen sich der Bildschirmtext oder die Bedienungsanleitung

auf Tastenkombinationen, müssen diese inhaltlich lokalisiert

werden. Verschiedene Lösungsansätze für dieses Problem:

• Die Tastenkombination wird während der Lokalisierung ange-

passt (z. B. Mnemonics). Trotzdem sollte sich auch in diesem

Fall der Übersetzer nicht alleine für einen Ersatz entscheiden.

• Die Tastenkombination ist definiert durch die Position der Tas-

te und nicht durch deren Bedeutung (z. B. CTRL+A wird unab-

hängig von der implizierten Bedeutung All in allen Sprachen

mit denselben Tasten ausgeführt).

• Die Tastenkombinationen sind benutzerdefiniert.

UI DESIGN COOKBOOK


• Tastaturemulatoren

Es gibt Eingabemedien, die sich wie eine Tastatur verhalten, um

sich möglichst einfach in textverarbeitende Anwendungen zu

integrieren. Barcode-Scanner sind ein Beispiel dafür. Da solche

Geräte Scan-Codes liefern, sind die Daten, welche die Anwen-

dung schliesslich erreichen, abhängig vom eingestellten Tastatur-

layout.

Beispiel:

• Auf dem Barcode-Scanner wird als Start- und Endzeichen ein

Hash (#) konfiguriert.

• Ein Barcode 123 wird gescannt -> Barcode-Scanner schickt

#123# an Anwendung.

• Der Barcode-Scanner verwendet den Scan-Code des en-US-

Tastaturlayouts

• Die Anwendung verwendet das de-CH-Tastaturlayout -> Der

eintreffende Barcode ist *123*, da auf der deutschen Tasta-

tur der Hash (#) mit einer anderen Tastenkombination erreicht

wird.

Input Method Editor (IME)

Es gibt Sprachen, die nicht durch die Tastatur alleine abgebildet

werden können. Chinesisch zum Beispiel besteht aus viel zu vielen

Zeichen, als dass man sie mit einzelnen Tasten eingeben könnte.

Für diese Aufgabe stellt Microsoft Input Method Editors (IME) zur

Verfügung. Relevant für eine Anwendung ist hierbei vor allem, dass

in einem IME üblicherweise ganze Worte oder sogar Satzfragmente

vorbereitet werden und als Ganzes an die Anwendung gelangen.

Dies kann die Reihenfolge und Art der auftretenden Events in der

Anwendung stark verändern.

UI DESIGN COOKBOOK


Abbildung 5-5: Input Method Editor

Abbildung 5-6: Kyrillische Tastatur

Abbildung 5-7: Arabische Tastatur

Tests

Windows bietet als Eingabehilfe eine virtuelle Tastatur. Das Layout

dieser Tastatur entspricht dem eingestellten Layout des Betriebssys-

tems. Damit ist es relativ einfach, manuelle Smoke-Tests mit ver-

schiedenen Layouts auszuführen.

UI DESIGN COOKBOOK


5.3 UNICODE UND FONTS


Problemstellung/Situation

Kaum eine Font unterstützt den gesamten Unicode-Zeichensatz

(bekannte Ausnahme: Arial Unicode MS). Für die Lokalisierung sind

jedoch die Zeichensätze der jeweiligen Zielsprachen nötig.

Lösungsvorschlag

Mit WPF hat sich die Problematik der zu unterstützenden Fonts der

Anwendung stark entschärft. WPF verwendet das Konzept einer

Composite Font, welche sich aus mehreren Fonts zusammensetzt.

Damit ist es möglich, als Font Family nur eine Composite Font anzu-

geben, statt sie dynamisch zu setzen oder zu lokalisieren.

Ausserdem hat eine WPF-Anwendung Zugriff auf Standard Com-

posite Fonts, welche bereits für eine Internationalisierung zusam-

mengestellt sind:

• GlobalMonospace.CompositeFont

Zeichen werden in einer Monospace Font gerendert (z. B. Cou-

rier New für lateinische Zeichen)

• GlobalSansSerif.CompositeFont

Zeichen werden in einer Sans Serif Font gerendert (z. B. Arial für

lateinische Zeichen)

UI DESIGN COOKBOOK


• GlobalSerif.CompositeFont

Zeichen werden in einer Serif Font gerendert (z. B. Times New

Roman für lateinische Zeichen)

• GlobalUserInterface.CompositeFont

Zeichen werden in einer Default Font gerendert (z. B. Times New

Roman für lateinische Zeichen)

Die GlobalUserInterface.CompositeFont ist die Fallback Font, falls

die von der Anwendung gewünschte Font auf dem System nicht

verfügbar ist oder falls die angewendete Font die gewünschten Zei-

chen nicht darstellen kann. Damit sollte eine WPF-Anwendung nie

in die Verlegenheit kommen, ein Zeichen nicht anzeigen zu können.

Man kann auch eine eigene Composite Font definieren, um zum

Beispiel einen Satz produktspezifischer Fonts zu verwenden. Sollte

es sich dabei aber nicht um Standard-Fonts handeln, müssen sie

natürlich auf dem Zielsystem installiert werden.

5.4 SCHRIFTGRÖSSE



Die minimale Schriftgrösse, die noch lesbar ist, hängt von der

Schriftart und dem zu verwendenden Zeichensystem ab.

UI DESIGN COOKBOOK


Besonders Microsoft Clear Type ist bei asiatischen Zeichen und klei-

nen Schriftgrössen mehr hinderlich als nützlich, da einzelne Striche

ineinander verschwimmen.

Lösungsvorschlag

Minimale Schriftgrösse bestimmen

Man kann natürlich anhand der Zielsprachen die minimale noch les-

bare Schriftgrösse bestimmen. Dazu sollte man jedoch unbedingt

Personen zuziehen, die die Zielsprache als Muttersprache haben.

Ein Zeichen einer Fremdsprache kann uns als unlesbar erscheinen.

Jemand mit der entsprechenden Muttersprache könnte es jedoch

unter Umständen problemlos aus dem Kontext erkennen.

Schriftgrösse dynamisch

Mit einer Zoomfunktion wäre es möglich, Informationen grösser

darzustellen. Dafür hat man weniger Platz zur Verfügung. Dies

stellt jedoch eine nicht zu unterschätzende Anforderung an das

Screen-Layouting zur Laufzeit.

Minimale Schriftgrösse abhängig von der Sprache

Der Vorteil gegenüber einer dynamischen Schriftgrösse ist die klei-

nere Anzahl Testfälle. Sehr wahrscheinlich kommt eine Anwendung

mit zwei Schriftgrössen aus. -> Nur zwei Layouts müssen getestet

werden.

Abbildung 5-8: Lateinische, arabische und chinesische Schriftzeichen in derselben Schriftgrösse

UI DESIGN COOKBOOK


Embedded Bitmaps

Bei asiatischen Fonts ist das Problem mit kleinen Schriftgrössen

schon lange bekannt. Ein Lösungsansatz sind Embedded Bitmaps.

Ab einer bestimmten Schriftgrösse wird die Schrift nicht mehr ska-

liert, sondern mit vorgerenderten Bitmaps dargestellt. Dies erlaubt

bei kleinen Schriftgrössen eine optimale Schärfe.

Bemerkungen

• Die Problematik der verschwimmenden Schriftzeichen bei Clear-

Type wurde für WPF im .Net Framework 4.0 stark verbessert.

• Embedded Bitmaps werden von WPF erst ab .Net Framework 4.0

unterstützt.

5.5 SORTIERUNG



Die Sortierung von Daten ist abhängig von regionalen Einstellungen

und Besonderheiten.

Beispiele:

• Schwedisch: Z vor Æ, Deutsch: Æ vor AK

• Keine Gross-/Kleinschreibung in verschiedenen Sprachen

• Sortierung nach Aussprache oder Strichzahl (z. B. Chinesisch)

• Standardmässige Sortierung nach Vornamen bei Personendaten

UI DESIGN COOKBOOK


Lösungsvorschlag

Microsoft bietet eine solide Unterstützung für die regionsabhän-

gige Verarbeitung von Daten, sowohl im .Net Framework als auch

in den Elementen der Benutzeroberfläche. Trotzdem gibt es einige

grundsätzliche Punkte zu beachten:

Linguistische Sortierung und logische Sortierung

Manchmal müssen Daten nicht nach sprachlichen Eigenschaften,

sondern nach Inhalten sortiert werden. Häufig ist dies der Fall für

eine Aufzählung von Zuständen wie zum Beispiel: ready, proces-

sing, finished. Für eine erfolgreiche Internationalisierung ist es wich-

tig, dass keine impliziten logischen Sortierungen existieren. Zum

Beispiel wären die Zustände active, processing, terminated auch

nach einer linguistischen Sortierung in der erwarteten Reihenfolge.

Nach einer Übersetzung ins Deutsche könnte die Sortierung dann

aber so aussehen: Abgeschlossen, Aktiv, In Verarbeitung.

Kontextabhängige Sortierung

Die regionalen Einstellungen der Betriebssysteme decken nicht im-

mer alle regionalen Eigenheiten der Länder ab. Kontextabhängig

kann es übergeordnete Sortierungsregeln geben, die über eine rein

linguistische Sortierung hinausgehen. Ein typisches Beispiel ist die

Sortierung von Personendaten. Nicht in jedem Land wird standard-

mässig nach dem Nachnamen sortiert. In manchen Ländern sind

bestimmte Nachnamen so häufig, dass ausserdem auch nach weite-

ren Daten sortiert werden muss. Natürlich ist eine Berücksichtigung

jeder lokalen Eigenheit nicht umsetzbar. Eine Alternative ist das

Speichern der Sortiereinstellung. So kann der Kunde die Anwen-

dung auf die lokalen Bedürfnisse anpassen.

UI DESIGN COOKBOOK


Mehr als eine Regel für die Sortierung

Gewisse Sprachen (vor allem asiatische) haben häufig mehr als eine

Art der Sortierung, da sich ihre Schriften nicht aus Lauten oder

Silben, sondern aus Piktogrammen mit konkreten Bedeutungen

zusammensetzen. Darum ist es nicht immer der einfachste Weg,

Daten nach ihrer Aussprache zu recherchieren. Alternativ verwen-

den solche Sprachen eine Sortierung nach der Zeichenform (z. B.

Anzahl Striche). Unterstützt die Benutzeroberfläche nur eine dieser

Sortierungen, ist der Nutzen für solche Länder stark eingeschränkt.

Datenbank-Sortierung

Während das .Net Framework und die entsprechenden Elemente

der Benutzeroberfläche üblicherweise Sprache und regionale Ein-

stellungen ohne weitere Aktionen unterstützen, sieht es bei einer

Datenbank etwas anders aus. Findet die Sortierung nur auf gelade-

nen Daten statt, mag dies keine Rolle spielen. Für einen Paging-Me-

chanismus zum Beispiel ist es jedoch notwendig, die Daten direkt

in der Abfrage sortiert zu erhalten. Moderne Datenbanken ermög-

lichen einem meist eine Auswahl von Sprache und Region. Unter

Umständen wird dies sogar durch die für den Datenbankzugriff

eingesetzte Komponente gekapselt. Es lohnt sich jedoch, bereits in

einer frühen Phase entsprechende Abklärungen zu treffen.

Manuelle Sortierung

Sortierungen direkt im Code berücksichtigen üblicherweise Spra-

che und Region. Dies ist nicht immer erwünscht. Bei sicherheitsrele-

vantem Code eröffnet dies zum Beispiel eine Eingriffsmöglichkeit

von aussen, die zu einer Sicherheitslücke führen könnte. Selbst falls

es keinen negativen Einfluss auf die Anwendung gibt, kann eine

unnötige Berücksichtigung von Sprache und Region die Fehlersuche

oder Wartung des Codes erschweren. Darum sollte man das .Net

UI DESIGN COOKBOOK


Framework grundsätzlich mit der Invariant Culture verwenden, so-

lange eine Culture Awareness nicht ausdrücklich nötig ist.

Keine Hacks

Workaround-Code für Sortierungen führt häufig zu Problemen bei

der Internationalisierung. Ein typischer Fall ist die linguistische Sor-

tierung von numerischen Werten.

Abbildung 5-9: Inkorrekte Sortierung

1

10

11

2

3

4

5

6

7

8

9

Ein Workaround ist das Voranstellen von Nullen. Dieser Ansatz wird

für Sprachen fehlschlagen, die keine Null verwenden.

Bemerkungen

Beispiele für die Auswahl der Sprache und Region bei Datenbanken:

• SQL Server -> COLLATE

• Oracle -> NSL_LANGUAGE, NSL_TERRITORY

UI DESIGN COOKBOOK


5.6 BIDIREKTIONALE OBERFLÄCHEN



Es gibt Sprachen mit anderen Leserichtungen als links -> rechts.

Lösungsvorschlag

WPF unterstützt bidirektionale Benutzeroberflächen mit der Flow-

Direction. Die FlowDirection definiert sowohl die Richtung

des Textes als auch des Layouts. Es gibt einige Punkte, die beim

Einsatz der FlowDirection berücksichtigt werden sollten:

• Es gibt nur die Richtungen Links -> Rechts und Rechts -> Links.

Vertikale Schriftsysteme werden nicht unterstützt.

• Die FlowDirection wird nicht automatisch durch die Sprache

und die Region bestimmt, sondern muss manuell gesetzt wer-

den.

• Die FlowDirection wird im WPF-Objektbaum grundsätzlich

vererbt.

• Auf Elementen der Benutzeroberfläche, welche nicht direkt Teil

der Hierarchie sind (z. B. Kontext-Menüs) wird die FlowDirec-

tion nicht automatisch übernommen.

• Auf Images wird die FlowDirection nicht automatisch über-

nommen. Der Grund dafür ist, dass Bilder gespiegelt nicht

zwangsläufig richtig dargestellt werden (z. B. Produktelogos).

• Nur Texte in Sprachen mit einer Rechts-Links-Leserichtung (z. B.

Hebräisch) werden auch tatsächlich von rechts nach links ge-

UI DESIGN COOKBOOK



schrieben. Texte mit lateinischen Schriftzeichen werden z. B. nur

nach rechts gegliedert, aber immer noch von links nach rechts

geschrieben.

• Bei einer BAML-Lokalisierung muss die FlowDirection bewusst

auf Links -> Rechts gesetzt werden (obwohl dies der De-

fault-Wert ist). Nur so wird sie als lokalisierbarer Wert exportiert.

• CultureInfo.CurrentUICulture.TextInfo.IsRightToLeft enthält die

Information über die gewünschte Leserichtung. So kann die

FlowDirection auch programmatisch gesetzt werden.

• Ein korrektes Setzen der FlowDirection ist für gewisse Featu-

res unerlässlich. So werden Zahlen in einem FlowDocument nur

dann in der korrekten arabischen Schreibweise dargestellt, wenn

Sprache und FlowDirection richtig gesetzt sind.

5.7 LOKALISIERUNG IN WPF


Für die Lokalisierung von WPF-Benutzeroberflächen gibt es grund-

sätzlich zwei verschiedene Ansätze:

• Lokalisierung des BAMLs (compiled XAML)

• Lokalisierung über Ressource-Dateien

Um eine Lokalisierung effizient durchführen zu können, ist es rat-

sam, sich bereits in einem frühen Stadium des Entwicklungsprozes-

ses für eine der Varianten zu entscheiden.

UI DESIGN COOKBOOK


Lösungsvorschlag: BAML-Lokalisierung

Die BAML-Lokalisierung ist der von Microsoft vorgeschlagene Weg,

um WPF-Benutzeroberflächen zu lokalisieren. Er basiert auf dem

folgenden Konzept:

• Entwicklung der Oberfläche -> XAML

• Identifikation der lokalisierbaren Elemente im XAML (Uids, auto-

matisiert möglich)

• Compile -> Auslagerung der lokalisierbaren Informationen in ein

Satellite Assembly

• Mit locbaml (Beispiel Anwendung von Microsoft zur Lokalisie-

rung von BAML-Daten) die lokalisierbaren Informationen aus

dem Satellite Assembly in eine CSV-Datei exportieren

• Übersetzen

• Mit locbaml die übersetzten Informationen in weitere Satellite

Assemblies konvertieren

Separiert Entwicklungs- und Lokalisierungsprozess

Während der Entwicklungsphase sind grundsätzlich keine beson-

deren Vorkehrungen für die Lokalisierung notwendig. Man kann

die Anwendung für die Default Culture fertigstellen und danach

basierend auf den XAML-Daten eine Lokalisierung durchführen. Es

gibt wenige Ausnahmen. Zum Beispiel exportiert locbaml nur dieje-

nigen Werte, welche im XAML auch gesetzt werden. Default-Werte

werden also nicht lokalisiert. Dies ist jedoch nur in seltenen Fällen

relevant.

Performance zur Laufzeit

Die lokalisierten XAML-Daten werden als Ganzes und nicht als ein-

zelne Werte geladen.

UI DESIGN COOKBOOK


Keine offizielle Unterstützung

Das Tool locbaml von Microsoft für die BAML-Lokalisierung ist nur

eine Beispielanwendung und wird weder offiziell unterstützt noch

weiterentwickelt.

Automatisierung ist aufwendig

Der automatisierte Einsatz von locbaml wird durch viele kleine

Unzulänglichkeiten erschwert. Zum Beispiel muss die Anwendung

direkt im Verzeichnis der ausführbaren Datei des Projekts gestar-

tet werden. Ausserdem ist es nur möglich, ein Satellite Assembly

pro Aufruf zu generieren. Natürlich kann man solche Probleme mit

Batch-Dateien oder MSBuild Task beheben. Der damit verbundene

Aufwand ist aber nicht zu unterschätzen.

Keine inkrementelle Aktualisierung der Übersetzung

Die Lokalisierung mit locbaml funktioniert am besten, wenn sie

einmalig am Ende des Projekts stattfindet. Das Tool locbaml un-

terstützt kein inkrementelles Update der zu lokalisierenden Daten.

Das bedeutet, dass beim Exportieren die CSV-Datei immer über-

schrieben wird. Dasselbe gilt auch für das Generieren der Satellite

Assemblies. Will man nur einige neue Texte übersetzen und die

bereits existierenden übernehmen, ist man selbst für die Zusam-

menführung verantwortlich.

CSV-Export kann viele überflüssige Daten enthalten

Damit der Entwickler nicht bei jedem XAML-Element entscheiden

muss, ob es lokalisiert wird, kann er automatisch alle für die Loka-

lisierung markieren (msbuild /t:updateuid). Dies führt jedoch dazu,

dass der CSV-Export auch Daten wie Height, Width, Alignement

etc. enthält. Dies kann zwar auch von Vorteil sein, üblicherweise ist

es jedoch nur Ballast für den Übersetzer. Alternativ kann der Ent-

UI DESIGN COOKBOOK


wickler die zu lokalisierenden Daten im XAML auch manuell mar-

kieren. Damit fällt aber ein entscheidender Vorteil gegenüber der

Lokalisierung mit Resx-Dateien weg.

Kein Fallback bei einzelnen Werten

Bei der BAML-Lokalisierung werden immer alle markierten Infor-

mationen des entsprechenden XAML lokalisiert. Es gibt keinen Fall-

back, wenn ein einzelner Wert fehlt. Nehmen wir an, wir hätten

Satellite Assemblies für die Default Culture en-US, für die Neutral

Culture de und die Specific Culture de-CH. Für alle Assemblies müs-

sen alle Werte vorhanden sein. Es wäre nicht möglich, für de-CH

nur für die Schweiz unterschiedliche Übersetzungen (z. B. ss statt

ß) zu definieren.

Keine Lokalisierung von binären Daten

Die BAML-Lokalisierung unterstützt nur die Lokalisierung von Text.

Binäre Informationen wie Bilder, Audio- und Video-Daten müssen

separat lokalisiert werden.

Kombination mit Resx schwierig

Für ein Projekt kann es notwendig sein, dass parallel zur BAML-Lo-

kalisierung auch herkömmliche Ressourcen (resx) lokalisiert werden

müssen. Die Lokalisierung mit locbaml unterstützt diesen Fall nicht

direkt. Es ist zwar möglich, mit dem Assembly Linker die Satellite

Assemblies der BAML- und der Resx-Lokalisierung zusammenzufüh-

ren. Dies ist jedoch keine simple Aktion.

UI DESIGN COOKBOOK


Lösungsvorschlag: Resx-Lokalisierung

Ressource-Dateien bieten die Möglichkeit, unterschiedlichste Ressour-

cen zu lokalisieren. Dies funktioniert nach folgendem Konzept:

• Hinzufügen deiner Ressource-Datei zum Visual Studio Projekt ->

Strong Typed Resource-Klasse wird erzeugt.

• Erfassen der Ressource-Daten (Texte, Bilder etc.)

• Zugriff auf die Ressourcen über den ResourceManager oder die

Strong Typed Resource-Klasse.

• Kopieren und Bezeichnung auf gewünschte Lokalisierung anpas-

sen (Resources.resx -> Resources.de-CH.resx)

• Übersetzen

• Satellite Assemblies werden während des Builds durch das Visual

Studio erstellt

Die Lokalisierung über Ressourcen ist voll im Visual Studio integriert

und war schon vor WPF im Einsatz. Sie weist weniger Einschrän-

kungen bezüglich binärer Ressourcen auf und wird von 3rd-Par-

ty-Produkten gut unterstützt. Aus solchen und anderen Gründen ist

diese Form der Lokalisierung auch für WPF immer noch sehr beliebt.

Die direkte Integration in WPF ist jedoch nicht vorgesehen. Es gibt

jedoch verschiedene Varianten, wie Ressourcen trotzdem für die

WPF-Lokalisierung verwendet werden.

Static Bindings

xmlns:res=“clr-namespace:SomeNamespaceContainingResources“

...

<Label Content=“{x:Static res:Resources.SomeText}“ />

UI DESIGN COOKBOOK


Hier nützt man ein Static Binding auf die vom Visual Studio erzeug-

te Strong Typed Resource-Klasse, um an die lokalisierbaren Inhalte

zu gelangen.

Einfach

Es sind keine externen Tools oder eine spezielle Markup-Syntax nö-

tig. Ressourcen werden vom Visual Studio und von 3rd-Party-Loka-

lisierungen unterstützt.

Effizient

Static Bindings produzieren wenig Overhead für die Aktualisierung.

Typensicher

Der Compiler kann für Static Bindings eine Typenprüfung durch-

führen.

Keine Type Converter

Static Bindings unterstützen keine Type Converter -> Nur das Bin-

ding von Texten ist wirklich einfach.

Manuelle Definition der zu lokalisierenden Daten

Alle zu lokalisierenden Daten müssen manuell mit einem Static Bin-

ding versehen werden.

Kein Designer-Support

Die Static Bindings müssen direkt im XAML-Code gesetzt werden.

Es gibt keinen Designer- oder Blend-Support.

Nur für Dependency Properties

Da es sich um Bindings handelt, können nur Dependency Proper-

ties lokalisiert werden.

UI DESIGN COOKBOOK


Custom Markup Extension

Statt Static Bindings zu verwenden, kann man das Binding auch

selbst kontrollieren und dazu eine Markup Extension schreiben. Von

der Open Source Community gibt es bereits eine beträchtliche An-

zahl solcher Extensions. Ein theoretisches Beispiel:

<Label Content=“{res:ResourceBinding ResId=SomeText,

Default=Hello}“ />

Hier würde die Custom Markup Extension ResourceBinding eine

ID entgegennehmen, über einen ResourceManager die Ressource

mit dieser ID laden oder den Default-Wert verwenden, sollte die ID

nicht existieren.

Flexibilität

Da die Markup Extension das Binding bestimmt, hat man je nach

Komplexität der Extension Möglichkeiten wie Default-Werte, Type

Converter oder eigene Resource Manager.

Standardwerte für Designer oder Blend

Designer oder Blend reagieren empfindlich auf fehlende Ressourcen.

Gerade Blend hat Schwierigkeiten, wenn Ressourcen ausschliesslich

in Satellite Assemblies untergebracht sind. Unterstützt die Markup

Extension Default-Werte kann man dieses Problem umgehen.

Sprache zur Laufzeit änderbar

Da es mit Markup Extensions möglich ist, eine Aktualisierung der

gebundenen Properties zu erzwingen, lässt sich mit ihnen ein

Wechsel der Sprache zur Laufzeit ohne erneutes Laden der Benut-

zeroberfläche umsetzen.

UI DESIGN COOKBOOK


Referenz auf Markup Extension Assembly

Das Assembly mit der Markup Extension muss von allen, welche

diese Extension anwenden wollen, referenziert werden.

Kein Standard

Attached Property Binding

Ressourcen können über ein Attached Property mit XAML ver-

knüpft werden. Auch dazu gibt es bereits einige Lösungen von der

Open Source Community. Solch ein Attached Property (z. B. Lo-

calization.ToBeLocalized) würde allen zu lokalisierenden Elementen

zugewiesen.

Wenn es dann beim Initialisieren gesetzt wird, löst dies die Aktuali-

sierung mit den lokalisierten Werten aus. Dazu erstellt der Attached

Property Code einen Key aus der Uid des Elements und den Bezeich-

nungen der übrigen Properties (z. B. labelExampleContent) und ver-

sucht, mit diesem Key die entsprechende Ressource zu laden.

<Label x:Uid=“labelExample“ res:Localization.ToBeLocalized=“True“

Content=“DefaultText“/>

UI DESIGN COOKBOOK


Keine Type Converter

Es gibt keinen direkten Zugriff auf die Dependency Properties und

ihre Type Converter.

Effizienz

Die Ressourcen müssen nach den konstruierten Keys durchsucht

werden. Da es mehr nicht lokalisierte Properties als lokalisierte gibt,

kann dies zu einer Performanceeinbusse führen.

Vereinfachte Verknüpfung mit XAML

Es ist nur ein Attached Property pro Element nötig. Im Gegensatz

dazu müssen Static Bindings und Custom Markup Extensions pro

gebundenes Property gesetzt werden.

Robust für Designer und Blend

Abgesehen vom Attached Property ist das XAML unberührt von der

Lokalisierung -> Kompatibilitätsprobleme mit Designer und Blend

sind minimiert. Ausserdem kann das Attached Property auch direkt

aus Designer oder Blend gesetzt werden.

Kann Entwicklungs- und Lokalisierungsprozess separieren

Während der Entwicklungsphase sind keine besonderen Vorkehrun-

gen für die Lokalisierung notwendig. Das Attached Property kann

nachträglich einfach hinzugefügt werden.

UI DESIGN COOKBOOK


Bemerkungen

• Da es für Custom Markup Extensions und Attached Properties

verschiedenste Lösungen gibt, müssen nicht zwangsläufig alle

aufgeführten Vor- bzw. Nachteile zutreffen.

• Die Auswahl einer Variante ist ebenfalls stark abhängig von den

einzusetzenden 3rd-Party-Lokalisierungs-Tools (z. B. Catalyst).

• Natürlich gibt es auch andere Arten der Lokalisierung (z. B. Da-

tenbank). In diesem Kapitel geht es jedoch nur um die verschie-

denen Varianten der Lokalisierung mit Satellite Assemblies.

• Den fehlenden Fallback einzelner Werte bei einer BAML-Lokali-

sierung darf man nicht mit dem Fallback der Cultures selbst ver-

wechseln. Bei einer Default Culture en-US, einer Neutral Culture

de und einer Specific Culture de-CH gäbe es bei einer verlangten

Culture de-DE immer noch einen Fallback auf de bzw. bei einer

verlangten Culture fr-FR einen Fallback auf en-US.

5.8 LOKALISIERUNG IN ASP.NET



Für die Lokalisierung von ASP.NET-Benutzeroberflächen gibt es ver-

schiedene Ansätze:

• Lokalisierung über Ressource-Dateien

• Lokalisierung über externe XML-Dateien

• Lokalisierung über Datenbank

UI DESIGN COOKBOOK


Um eine Lokalisierung effizient durchführen zu können, ist es rat-

sam, sich bereits in einem frühen Stadium des Entwicklungsprozes-

ses für eine der Varianten zu entscheiden.

Lösungsvorschlag: Resx-Lokalisierung

Ressource-Dateien bieten die Möglichkeit, unterschiedlichste Res-

sourcen zu lokalisieren. Dies funktioniert nach folgendem Konzept:

• ASPX/ASCX erstellen wie gewohnt.

• Pro ASPX/ASCX-Seite kann via Menü eine Ressourcedatei erstellt

werden. Alle Controls werden via IDs verlinkt.

• Erfassen der Ressource-Daten (Texte, Bilder etc.).

• Die Ressourcen der Controls (Label, Tooltips etc.) werden auto-

matisch in der aktivierten Sprache geladen.

• Zudem Zugriff auf die Ressourcen über den ResourceManager

oder die Strong Typed Resource-Klasse möglich.

• Kopieren und Bezeichnung auf gewünschte Lokalisierung anpas-

sen (Resources.resx –> Resources.de-CH.resx).

• Übersetzen

• Satellite Assemblies werden während des Builds durch das Visual

Studio erstellt.

Die Lokalisierung über Ressourcen ist voll im Visual Studio integriert.

Sie weist weniger Einschränkungen bezüglich binärer Ressourcen

auf und wird von 3rd-Party-Produkten gut unterstützt. Aus solchen

und anderen Gründen ist diese Form der Lokalisierung auch für

ASP.NET immer noch sehr beliebt.

UI DESIGN COOKBOOK


• Voll in Visual Studio integriert.

• Sprache und Übersetzungen ohne Neukompilieren erweiterbar.

• 3rd-Party-Tools für Übersetzung, Export und Import vorhanden.

• Einfacher Export und Import für Übersetzungen.

• Sprache und Übersetzungen ohne Neukompilieren erweiterbar.

• Flexibel, da eigenes Format.

• Viele einzelne Files

• Performance

Lösungsvorschlag: Lokalisierung via externe XML-Dateien

Alle Texte und lokalisierten Texte werden in externen XML-Dateien

abgelegt. Beim Laden einer Seite werden die Texte in der entspre-

chenden Sprache aufgrund der Spracheinstellung des Clients aus

der XML-Datei geladen.

• Eigenes Tool und Logik notwendig.

• Kein Standard.

• Performance.

UI DESIGN COOKBOOK


• Alle Texte an zentraler Stelle in DB verwaltet.

• Einfacher Export und Import für Übersetzungen.

• Sprache und Übersetzungen via DB ohne Codeanpassungen

erweiterbar.

• Performance.

• Texte können ohne Tool nicht oder schlecht übersetzt werden.

• Eigenes Tool und Logik notwendig.

• Kein Standard.

Lösungsvorschlag: Lokalisierung via Datenbank

Alle Texte und lokalisierten Texte werden vollständig in

einer Datenbank verwaltet. Beim Laden einer Seite wer-

den die Texte in der entsprechenden Sprache aufgrund der

Spracheinstellung des Clients direkt aus der DB geladen.

UI DESIGN COOKBOOK


6 DATENVERWALTUNG

UI DESIGN COOKBOOK


6.1 DATENSUCHE



Klassische datenbankbasierte Anwendungen sind oftmals unüber-

sichtlich in der Bedienbarkeit. Vielerorts ist während der Bedienung

nicht klar, wonach gesucht werden soll oder welche Daten nach

einer Suche angezeigt werden. Mit einfachen Suchmasken und klar

strukturierten Suchseiten soll der Benutzer seine Daten finden bzw.

editieren können.

Lösungsvorschlag

Für eine ASP.NET-Seite ist es sinnvoll, eine möglichst klare und

schlanke Struktur zu wählen. Eine Suche nach Daten kann daher

folgende Struktur haben (ASP.NET-Suchseite mit GridView ohne

Stylesheet):

Abbildung 6-1: Datensuche einer ASP.

NET-Seite (unformatiert)

UI DESIGN COOKBOOK


• Die Sucheingaben sind im oberen Bereich der Seite. Sinnvoll ist

eine Suche über die ID für erfahrene Anwender.

• Die Validierungsfehler werden unter den Suchfeldern angezeigt.

• Die Suche wird mittels Search-Knopf gestartet.

• Anzeige der gefundenen Daten mittels GridView.

Ein formatiertes Beispiel:

Abbildung 6-2: Datensuche einer ASP.NET-Seite (formatiert)

Bemerkungen

Um dieses Ziel zu erreichen, müssen die Suchfelder klar struktu-

riert sein. Der Benutzer muss durch die Bezeichnung der Suchfelder

wissen, nach welchen Begriffen die Suche erfolgreich ist. Mit zu-

sätzlichen Eingabehilfen (Thema «Formatierte Werte») kann dem

Benutzer die Eingabe nochmals erleichtert werden.

Link zum Thema «Master-Detail-Pattern» mit Beispielen: http://desig-

ningwebinterfaces.com/designing-web-interfaces-12-screen-patterns

UI DESIGN COOKBOOK


Abbildung 6-3: Dateneditierung einer ASP.

Net-Seite (unformatiert)

6.2 DATENEDITIERUNG



Wie sollten nach einer erfolgreichen Suche die Daten editiert wer-

den? Bei einfachen Dateninhalten kann es durchaus Sinn machen,

die Daten direkt im Suchresultat zu editieren. Bei komplexen Inhal-

ten wird dies jedoch schnell unübersichtlich. Daher empfiehlt sich in

diesen Fällen eine Detailansicht der Daten.

Lösungsvorschlag

Durch Anklicken einer Row der gesuchten Inhalte werden dem Be-

nutzer die Details angezeigt. Mithilfe der ASP.Net FormView kön-

nen diese Daten einfach dargestellt und editiert werden (ASP.Net-

Editierseite mit FormView ohne Stylesheet).

UI DESIGN COOKBOOK


• Die Felder können editiert werden.

• Interaktion mit Speichern Knopf.

• Validierung soll, wenn möglich, sofort (clientseitig) stattfinden

und angezeigt werden.

Bemerkungen

Es gibt verschiedene Varianten, die Daten zu editieren. Bei einer Web-

anwendung ist es entscheidend, dass dem Benutzer während des

Editierprozesses bewusst ist, wann die Daten geändert werden sol-

len. Bei der FormView ist dies durch den «Update»-Button sofort

ersichtlich. Sinnvollerweise werden die gespeicherten Daten danach

entweder in der FormView oder bereits in der GridView des Such-

resultates aktualisiert angezeigt. Beim Drücken des Cancel-Buttons

sollte der Benutzer wieder zum Suchergebnis zurückgelangen.

6.3 DATENERFASSUNG



Beim Erfassen von komplexen Datenbeständen (z. B. eines Kunden

mit diversen Adressen, Beziehungen, Rollen, Nummern etc.) geht

bei einfachen Forms oft die Übersicht verloren, da sehr viele Einga-

befelder angezeigt werden. In vielen Fällen findet die Validierung

erst beim Speichern der Daten statt, dem Benutzer wird ein Fehler

angezeigt, er findet diesen häufig aber nicht, da die Form komplett

überladen ist.

UI DESIGN COOKBOOK


Lösungsvorschlag

Bei einer solch komplexen Datenerfassung ist die Erfassung mittels

eines Wizards eine gute Sache. So kann der Benutzer schrittweise

die Daten erfassen und Beziehungen erstellen. Bevor der gesamte

Prozess abgeschlossen wird, kann in einem Wizard zum Schluss eine

Zusammenfassung angezeigt werden. Dies erleichtert die Überprü-

fung der Daten (ASP.Net Wizard ohne Stylesheet).

Abbildung 6-4: Datenerfassung einer ASP.

Net-Seite 1/2 (unformatiert)

Die Daten werden im Wizard erfasst. Mithilfe von verschiedenen

Controls können auch komplexe Prozesse übersichtlich verarbeitet

werden. In diesem Beispiel wird ein Kunde anhand des Namens und

der Stadt beim Drücken des «Next Button» gesucht. Ist der Kunde

bereits erfasst, kann der Benutzer den jeweiligen Kunden auswäh-

len und zum nächsten Schritt weitergehen.

UI DESIGN COOKBOOK


Abbildung 6-5: Datenerfassung einer ASP.

Net-Seite 2/2(unformatiert)

Am Schluss des Erfassungsprozesses werden die Daten dem Benutzer

nochmals übersichtlich dargestellt, bevor die Daten persistiert werden.

Bemerkungen

Die Anwendung des Wizards ist nicht immer sinnvoll. Wenn die Ein-

gabe sehr trivial ist, ist ein Wizard sicher nicht notwendig. Bei kom-

plexen Datensätzen wirkt jedoch die Datenerfassung mithilfe des

Wizards deutlich übersichtlicher.

6.4 DATENSUCHE

ASP.NET MVC 2


Der Aufbau einer ASP.Net-MVC-Seite gestaltet sich anders als in

einer klassischen ASP.Net-Seite. Die Daten werden nicht über einen

UI DESIGN COOKBOOK


Event einer Datasource geladen, sondern beim Aufbau der Seite in

die View injiziert. Daher fällt bei einer ASP.Net-MVC-Suchseite die

eigentliche Suche weg – sodass die Daten grundsätzlich schon in

einem Grid oder in einer Tabelle geladen sind. Damit der Benutzer

aber trotzdem nach bestimmten Daten suchen kann, empfiehlt es

sich, einen Filter zu implementieren.

Lösungsvorschlag

Bei der Implementation einer ASP.Net-MVC-Applikation kann

grundsätzlich alles unabhängig von ASP.Net Controls verwirklicht

werden. Klassische ASP.Net Controls können nicht eingesetzt wer-

den (!), jedoch sind die Daten, die angezeigt werden sollen, jeweils

in der View vorhanden. Daher sind die Möglichkeiten sehr umfang-

reich, die Implementation muss jedoch in HTML umgesetzt werden

und ist deshalb auch aufwendig. Aus diesem Grund entspricht das

Layout eines «Grids» in einer ASP.NET-MVC-Applikation oft einer

HTML-Table. Mit dem Einsatz eines guten Stylesheets kann jedoch

eine simple Table einen ansprechenden und übersichtlichen Ein-

druck machen.

Abbildung 5-6: Datenanzeige einer ASP.Net-MVC-Seite

UI DESIGN COOKBOOK


ASP.Net MVC existiert zurzeit in der zweiten Version und wird in-

tensiv weiterentwickelt. Daher gibt es auch kommerzielle Controls,

die bereits eine Filterung der Daten vorsehen. Ein Beispiel eines

Grids für ASP.Net MVC (http://demos.telerik.com/aspnet-mvc/):

Abbildung 6-7: Beispiel eines Datagrids

für ASP.Net MVC 2

Lösungsvorschlag

Die Dateneditierung mit dem ASP.Net MVC-Pattern entspricht ei-

nem ähnlichen Design wie jenem der klassischen ASP.Net-Seite.

Pro Property wird jeweils ein Label mit einer dazugehörigen Text-

box angezeigt, in der ein Text editiert werden kann. Gespeichert

werden die Daten mit dem Aufruf eines «Submit»- oder «Save»-

Buttons. Das Editieren der Daten oder das Erfassen der Daten ist in

6.5 DATENEDITIERUNG UND DATENEINGABE

ASP.NET MVC 2

UI DESIGN COOKBOOK


ASP.Net MVC gleich aufgebaut. Sehr erwähnenswert ist das Vali-

dierungskonzept in ASP.Net MVC. Mithilfe eines Attributs jeweils

auf den Properties einer Model-Klasse n ASP.Net MVC können die

Daten validiert werden:

Abbildung 6-8: Dateneditierung und Datenerfassung einer

ASP-.NET -MVC2-Seite

Lösungsvorschlag

Eine Suche nach einem Datensatz mit einem eindeutigen Fach-

schlüssel kann sehr einfach und platzsparend über ein einzelnes

6.6 SCHNELLSUCHE


UI DESIGN COOKBOOK


Eingabefeld und eine Suchschaltfläche angeboten werden. Die

erweiterte Suche wird über ein Popup mit allen gewünschten Kri-

terien ermöglicht.

Abbildung 6-9: Datendialog mit Schnell-

suche und erweitertem Suchdialog

Einen eindeutigen Treffer kann die Programmlogik direkt verwen-

den und z. B. zu einer Tabelle hinzufügen. Liefert die Schnellsuche

hingegen keinen oder keinen eindeutigen Treffer, so wird automa-

tisch die erweiterte Suche in einem Popup-Fenster geöffnet und

allfällige Suchresultate angezeigt. In diesem Suchdialog kann der

Sachbearbeiter wiederholt mit verschiedenen Kriterien suchen, bis

er den gewünschten Datensatz identifiziert und selektiert hat.

Bemerkungen

Diese sehr platzsparende Schnellsuche ist nur dann sinnvoll, wenn

der Sachbearbeiter in nahezu allen Fällen einen Datensatz mit ei-

nem ihm bekannten, eindeutigen Fachschlüssel suchen möchte. Die

UI DESIGN COOKBOOK


erweiterte Suche kann zusätzlich über eine separate Schaltfläche

direkt neben der Schnellsuche angeboten werden.

Fachdaten in einer Applikation müssen oftmals nach bestimmten

Kriterien formatiert angezeigt werden. Zusätzlich wünscht der An-

wender, dass er die Eingabe nicht nur korrekt formatiert, sondern

auch (teilweise) unformatiert erfassen kann.

6.7 FORMATIERTE WERTE


Abbildung 6-10: Eingabe & Darstellung

eines formatierten Werts

Lösungsvorschlag

Neben der reinen Erfassung und Anzeige solcher Werte müssen

häufig in der Fachlogik mit den Werten Berechnungen angestellt

oder eine spezielle Logik angewandt werden, oder es muss einfach

nur eine Validierung erfolgen.

UI DESIGN COOKBOOK


Aus diesem Grund sollte man formatierte Werte, wenn immer

möglich, in der Datenhaltung ohne Format ablegen. Dies ermög-

licht die uneingeschränkte Bearbeitung der Daten und vereinfacht

oft auch die Struktur der Datenhaltung.

Für die Anzeige der Werte müssen die Daten nach dem vorgegebe-

nen Muster formatiert werden. Dazu eignet sich die Präsentations-

schicht der Applikation. In bestimmten Fällen kann auch schon eine

Formatierung innerhalb einer Datenbankabfrage sinnvoll sein, wenn

z. B. die Daten direkt an eine Dokumentkomponente ohne Forma-

tierungsmöglichkeiten weitergegeben werden.

Die Eingabe der Werte kann über ein maskiertes Textfeld erfolgen.

Sollte dies aus Regelgründen nicht möglich sein, kann auch ein sim-

ples Textfeld mit nachfolgender Formatierung der Eingabe funktio-

nieren. In diesem Fall muss der Datenwert für die Speicherung je-

doch wieder behandelt und das Format entfernt werden.

Bemerkungen

Diese Lösung bedingt, dass es klare Regeln zur Formatierung der

Daten gibt. Es muss nicht eine einzige Regel sein, jedoch sollten die

Regeln zusammen eindeutige Resultate liefern. Abhängigkeiten zu

anderen Fachdaten erschweren die Umsetzung, verhindern diese

jedoch nicht grundsätzlich.

UI DESIGN COOKBOOK



Ein Fachdatenformular enthält Werte mit unterschiedlichen Einhei-

ten, die dem Sachbearbeiter unverwechselbar angezeigt werden

müssen.

6.8 DARSTELLUNG VON EINHEITEN


Abbildung 6-11: Verschiedene Varianten

zur Anzeige von Einheiten

Lösungsvorschlag: Bezeichnung

Als Standardlösung hat sich das Anfügen der Einheit in der Eingabe-

feld-Bezeichnung bewährt. In diesem Fall folgt nach dem beschrei-

benden Text die Einheit, oftmals in eckigen Klammern eingefasst.

Diese Variante ist sehr platzsparend und kann in nahezu allen Fällen

verwendet werden.

UI DESIGN COOKBOOK


Lösungsvorschlag: Freistehende Einheit

Alternativ zu der obigen Lösung wird in dieser Variante die Einheit

in einem zusätzlichen Bezeichnungsfeld vor oder nach dem Einga-

befeld angezeigt. Je nach Situation ist diese Darstellung angeneh-

mer als obige Lösung. Es ist jedoch zu beachten, dass das Layout

der Benutzeroberfläche dadurch unruhig werden kann.

Lösungsvorschlag: Tooltip

Neben der permanenten Anzeige der Einheit mittels Bezeichnungs-

feldern kann in speziellen Fällen auch die Verwendung von Tooltips

bzw. deren Alternativen (z. B. Info-Bereich) verwendet werden. Dies

ist jedoch nur dann geeignet, wenn der Sachbearbeiter durch die

permanente Anzeige in seiner Arbeit behindert werden würde und

die darzustellende Information nicht permanent sichtbar sein muss.

Lösungsvorschlag: Formatierte Anzeige

Für Eingabefelder bedingt, für die reine Anzeige jedoch sehr gut

geeignet ist die Variante mit direkt formatierten Werten. Mit dieser

Lösung ergibt sich für den Anwender ein sehr natürliches Bild. In

der Praxis hat sich das formatierte Eingabefeld oftmals als zu um-

ständlich erwiesen, sodass sehr oft ein normales Eingabefeld ver-

wendet wird und die Eingabewerte programmatisch geparst und

formatiert werden.

6.9 OPTIMALE LÖSUNG

Die optimale Lösung für das hier beschriebene Problem ergibt sich

schlussendlich durch die spezifischen Bedürfnisse der Applikation

und deren Anwender. Bitte beachten Sie auch die speziellen Kapitel

zur Error! Reference source not found.

UI DESIGN COOKBOOK



Der Anwender möchte eine grössere Menge von gleichartigen Da-

ten zu einer bestimmten Datenentität erfassen, ohne dabei nach

jedem Wert eine Eingabebestätigung oder einen Feldwechsel aus-

führen zu müssen.

6.10 MASSENERFASSUNG VON GLEICHARTIGEN DATEN


Abbildung 6-12: Massenerfassung von

gleichartigen Daten über einen Spezialdialog

Lösungsvorschlag

Gleichartige Daten werden im Normalfall in einer Liste oder Tabelle

verwaltet und dargestellt. Die Erfassung solcher Daten in grossen

UI DESIGN COOKBOOK


Mengen kann aber über die dabei angebotene Hinzufügen-Funk-

tionalität sehr mühsam und zeitraubend ausfallen.

Soll im Arbeitsprozess eine Massenerfassung vorgesehen werden,

kann hierzu eine zusätzliche Eingabemöglichkeit angeboten wer-

den, welche die Daten in einem einzigen Schritt entgegennimmt (z.

B. ein mehrzeiliges Textfeld), nach bestimmten Regeln zerlegt und

diese nach einer Validierung in die Liste oder Tabelle abfüllt. Der

Anwender bekommt als Quittung die Liste der verarbeiteten und,

falls erwünscht, von nicht verarbeiteten Daten. Ein nachträgliches

Bearbeiten oder Löschen von einzelnen Werten erfolgt mit den üb-

lichen Listen-/Tabellen-Bearbeitungsfunktionen.

Dieser Arbeitsschritt sollte nicht in den normalen Arbeitsdialog ein-

gebettet werden, sondern deutlich getrennt, z. B. über einen Wi-

zard oder mithilfe eines Popups, angeboten werden. Dem Anwen-

der muss klar sein, dass dies eine reine Eingabeunterstützung ist

und seine Daten weiterhin an den üblichen Orten in der Applikation

gespeichert/angezeigt werden.

Bemerkungen

Diese Art der Massenerfassung eignet sich besonders für eindeutig

erkennbare Daten wie Identifikationen in einem definierten Format

(z. B. ID27-09), Datums- oder Zeitangaben, Zahlenbeträge oder an-

dere, einfach strukturierte alphanumerische Eingaben. Unter Um-

ständen können auch Kombinationen dieser Daten verarbeitet wer-

den, wenn sie deutlich voneinander getrennt werden können (z. B.

ein Semikolon als Trennzeichen). Wichtig ist, dass die Applikation

die Eingabe parsen und in einzelne Werte zerlegen kann. Nur so ist

eine Massenverarbeitung realisierbar.

UI DESIGN COOKBOOK



Der Anwender möchte zu einer bestimmten Datenentität einen

Freitext-Kommentar erfassen können.

6.11 FREITEXT-KOMMENTARE


Abbildung 6-13: Kommentarerfassung über ein Eingabefeld

und Popup

Lösungsvorschlag Eingabefeld

Im einfachsten Fall erlaubt man die Erfassung von Kommentaren mit

einem direkt in der Oberfläche eingebetteten mehrzeiligen Text-

feld. Für die erweiterte Bearbeitung können auch spezielle Controls

wie RTF-Editoren verwendet werden.

UI DESIGN COOKBOOK


Diese direkte Art der Dateneingabe ist für kürzere Texte geeignet,

da das Eingabefeld direkt in die aktuelle Oberfläche eingebunden

ist und entsprechend Platz einnimmt.

Lösungsvorschlag Kommentar-Registerkarte

Erlaubt das Applikationsdesign die Verwendung von Registerkar-

ten, kann für längere Kommentare das Textfeld aus dem obigen

Lösungsvorschlag in eine eigene Registerkarte ausgelagert werden.

Dies ermöglicht unter Umständen sehr umfangreiche Kommentare

und die Verwendung von erweiterten Editor-Controls. Ein auf diese

Weise erfasster Kommentar ist jedoch nicht mehr auf einen Blick

ersichtlich. Um den Anwender auf einen vorhandenen Kommentar

hinzuweisen, kann die Tab-Beschriftung mit einem kleinen Hinweis

versehen werden. Diese strenge Trennung kann jedoch auch ver-

wendet werden, um Zugriffe über Benutzerberechtigungen gezielt

zu erlauben bzw. zu verhindern.

Lösungsvorschlag Popup

Eine weitere elegante Variante präsentiert sich als kleines Popup-

Fenster mit eingebettetem Eingabe- oder Editor-Control, welches

über eine kleine Schaltfläche abgerufen wird. Die Schaltfläche bein-

haltet in optimaler Weise ein leeres Dokumentsymbol für nicht aus-

gefüllte Kommentare und ein beschriftetes Dokumentsymbol für

erfasste Kommentare.

Dieser Lösungsvorschlag enthält die Vorteile der Registerkarten-Va-

riante und ermöglicht deren Verwendung auch ohne ein karten-

basiertes Applikationsdesign.

UI DESIGN COOKBOOK


Bemerkungen

Freitext-Kommentare werden von den Anwendern sehr oft verlangt

oder gewünscht. Es besteht jedoch die Gefahr, dass besonders bei

Applikationen, die im Zusammenhang mit Kundenkontakten be-

nutzt werden, personenbezogene Hinweise erfasst werden. Es soll-

ten deshalb bereits beim Design der Applikation Überlegungen zum

Datenschutz angestellt werden.

UI DESIGN COOKBOOK


7 VALIDIERUNG

UI DESIGN COOKBOOK



Der Anwender möchte möglichst ohne Störungen durch die Erfas-

sung geführt werden und nur korrekte Daten eingeben. Er möchte

bei der Bedienung der Applikation bzw. bei der Bearbeitung von

Daten aktiv unterstützt werden und mit kurzen, situativ passen-

den Anweisungen versorgt werden.

7.1 ALLGEMEINE RICHTLINIEN ZUR VALIDIERUNG


Abbildung 7-1: Validieren Textbox

mit Ballon

UI DESIGN COOKBOOK


Lösungsvorschlag

Allgemeine Richtlinien zur Validierung:

• So früh wie möglich validieren.

• Controls verwenden, die auf gültige Werte eingeschränkt sind, z. B.

DropDown-Boxes, Radiobuttons, Listboxen, Datum-Controls etc.

• Angemessene Default-Werte setzen.

• Default-Werte so setzen, dass eine Eingabemaske ohne Eingabe

und ohne Fehler gespeichert werden kann.

• Benutzereingaben so schnell wie möglich validieren und Fehler

so nahe wie möglich bei der Eingabe anzeigen.

• Für die Anzeige von Eingabeproblemen unabhängige Tooltipps,

Ballons oder In-place-Fehleranzeige verwenden.

• Falsche Zeichen direkt bei der Eingabe verhindern, unterdrücken.

• Ballons oder «In-Place»-Fehlermeldungen zur Anzeige von Ein-

gabefehlern bei Textfeldern verwenden.

• Validieren von abhängigen Feldern eines Dialogs beim Klick auf

Button «Next», «Speichern» etc.

• Validieren von abhängigen Feldern über mehrere Eingabedialoge

so früh wie möglich, sobald das Problem ermittelt werden kann.

• Modale Fehleranzeigen wie Dialogforms oder Messageboxes für

alle anderen Fehler, die sich ereignen, wenn der Anwender auf

den «Commit»-Button klickt: Gemeint sind Fehler wie Eingabe-

fehler über mehrere Controls, Nichteingabefehler oder nicht im

Zusammenhang stehende Fehler.

• Falls Eingabefehler gefunden und gemeldet werden, so ist der

Fokus auf das erste Control mit falschen Daten zu setzen. Wenn

notwendig ist das Control in den sichtbaren Bereich des Bild-

schirms zu scrollen.

• Für die Konsistenz des Programmes ist es wichtig, dass möglichst

die gleichen Methoden zur Anzeige der Validierungen verwendet

werden.

UI DESIGN COOKBOOK



Der Anwender möchte möglichst ohne Störungen durch die Erfas-

sung geführt werden und nur korrekte Daten eingeben. Er möchte

bei der Eingabe von Daten in Textfelder aktiv unterstützt werden

und mit kurzen, situativ passenden Anweisungen versorgt werden.

7.2 TEXTEINGABEN (TEXTBOX) VALIDIEREN


Abbildung 7-2: «In place»-Error-Anzeige nach Eingabe von ENTER

UI DESIGN COOKBOOK


Lösungsvorschlag/Empfehlung

Weil Texteingabefelder in der Regel nicht nur gültige Eingaben ak-

zeptieren, müssen Eingaben validiert und alle möglichen Probleme

behandelt werden. Die verschiedenen Arten von Eingabefehlern

sind wie folgt zu behandeln:

• Wenn der User ein falsches Zeichen eingibt, das Zeichen ignorie-

ren und einen Eingabeproblem-Ballon anzeigen, der die gültigen

Eingabezeichen beschreibt.

• Im obigen Beispiel 7-3 meldet der Ballon ein ungültiges Zeichen

für ein numerisches Feld.

• Wenn die Eingabedaten einen ungültigen Wert oder ein falsches

Format haben, ist ein Eingabeproblem-Ballon anzuzeigen, wenn

der Fokus das Feld verlässt.

• Wenn die Eingabedaten inkonsistent mit den anderen Feldern

der Eingabemaske sind, ist eine Fehlermeldung anzuzeigen,

wenn alle Eingaben abgeschlossen sind. Wie zum Beispiel, wenn

der User auf den OK-Button eines Eingabedialogs klickt.

• Falsche Eingabedaten sind nicht zu löschen, damit der Anwen-

der die Fehler einfach korrigieren kann. Dies ermöglicht dem

Anwender, die Daten zu korrigieren, ohne dass er nochmals alles

eingeben muss. Auf der anderen Seite sind Passwörter und Pins

zu löschen, weil diese nicht einfach korrigiert werden können.

Abbildung 7-3: Validieren Textbox

mit Ballon

UI DESIGN COOKBOOK



Der Anwender möchte möglichst schnell und umfassend erkennen

können, welche Eingaben zwingend notwendig sind.

7.3 ZWINGENDE EINGABE VALIDIEREN (REQUIRED INPUT)


Abbildung 7-4: Beispiel für Anzeige von

zwingenden Eingabefeldern


Um dem Anwender anzuzeigen, welche Eingaben zwingend not-

wendig sind, gibt es je nach Situation verschiedene Varianten, die

zu empfehlen sind: Wenn die meisten Eingaben optional sind oder

wenn es unwahrscheinlich ist, dass der Anwender Eingaben über-

springt: Nicht alle notwendigen Eingaben direkt anzeigen, aber feh-

UI DESIGN COOKBOOK


lende Eingaben, die zwingend sind, mit Fehlermeldungen anzeigen.

Diese Variante verhindert einen unübersichtlichen Dialog, und es

werden weniger Fehlermeldungen angezeigt.

Abbildung 7-5: Empfehlung, wenn die

meisten Eingaben optional sind

Wenn die meisten Eingaben im Dialog zwingend sind und es nicht

zu viele Eingabe-Controls gibt:

• Die zwingenden Eingabe-Controls mit einem roten Stern am

Anfang des Labels markieren und die roten Sterne mit einer der

folgenden Varianten erklären:

• Eine Fussnote unterhalb des Eingabebereichs:

«* Zwingende Eingabe»

• Ein Tooltip auf dem Stern mit dem Text: «Zwingende Eingabe»

UI DESIGN COOKBOOK


Abbildung 7-6: Empfehlung, wenn die

meisten Eingaben zwingend sind

Wenn alle Eingabe-Controls im Dialog zwingend sind:

• An prominenter Stelle am Anfang der Eingabedialoge ein Hin-

weis: «Alle Eingaben sind zwingend».

• Diese Variante verhindert einen unübersichtlichen Dialog für die-

sen speziellen Fall.

Wenn die meisten Eingaben im Dialog zwingend sind:

• Die optionalen Eingabe-Controls mit dem Text «optional» am

Ende des Labels markieren.

Für die Konsistenz des Programms ist es wichtig, dass möglichst die

gleiche Methode zur Anzeige der zwingenden Eingaben verwendet

wird.

UI DESIGN COOKBOOK



Der Anwender möchte, dass ein Dialog mit mehreren Eingabefel-

dern beim Verlassen korrekt validiert wird. Da die Controls ab-

hängige Daten enthalten, kann erst beim Verlassen des Dialogs

validiert werden (z. B. OK- oder Next-Button).


Verwenden von modalen Fehleranzeigen wie «Dialogforms» oder

Messageboxes für alle Fehler, die sich ereignen, wenn der Anwen-

der auf den «Commit»-Button klickt.

Gemeint sind Fehler wie:

• Eingabefehler über mehrere Controls

• Nichteingabefehler oder

• «Nicht im Zusammenhang» stehende Fehler.

Falls Eingabefehler gefunden und gemeldet werden, so ist der Fo-

kus auf das erste Control mit falschen Daten zu setzen. Wenn not-

wendig ist das Control in den sichtbaren Bereich des Bildschirms zu

scrollen.

7.4 EINGABEDIALOGE MIT MEHREREN CONTROLS

VALIDIEREN


UI DESIGN COOKBOOK


Abbildung 7-7: Dialog mit Validierung

über mehrere Controls


Der Anwender möchte, dass abhängige Felder über mehrere Dia-

loge korrekt validiert werden.

7.5 ABHÄNGIGE CONTROLS ÜBER MEHRERE

EINGABEDIALOGE VALIDIEREN


UI DESIGN COOKBOOK



Zur kontrollierten Validierung über mehrere Controls und Dialoge

werden Wizards oder Dialoge mit Tabs empfohlen. Auch hier gilt,

dass abhängige Felder so früh wie möglich validiert werden, sobald

das Problem ermittelt werden kann.

Verwenden von modalen Fehleranzeigen wie Dialogforms oder

Messageboxes für alle Fehler, die sich ereignen, wenn der Anwen-

der auf den «Commit»-Button klickt.

Gemeint sind Fehler wie:

• Eingabefehler über mehrere Controls

• Nichteingabefehler oder

• «Nicht im Zusammenhang» stehende Fehler

Falls Eingabefehler gefunden und gemeldet werden, so ist der Fo-

kus auf das erste Control mit falschen Daten zu setzen. Wenn not-

wendig ist das Control in den sichtbaren Bereich des Bildschirms zu

scrollen.

Abbildung 7-8: Verwendung von Wi-

zards zur kontrollierten Validierung über mehrere

Controls und Dialoge

UI DESIGN COOKBOOK



Wenn Benutzer Daten in Ihre Anwendung eingeben, möchten Sie

vielleicht überprüfen, ob die Daten gültig sind, bevor sie von der

Anwendung verwendet werden. Beispielsweise kann es erfor-

derlich sein, dass bestimmte Textfelder nicht die Länge 0 haben,

dass ein Feld als Telefonnummer oder als ähnlich wohlgeformtes

Datenformat formatiert wird oder dass eine Zeichenfolge keine

unsicheren Zeichen enthält, die die Sicherheit einer Datenbank be-

einträchtigen könnten. Windows Forms bietet mehrere Möglich-

keiten, um Eingaben in der Anwendung zu überprüfen.

Validierung mit dem MaskedTextBox-Steuerelement

Wenn Sie Benutzereingaben in einem wohlgeformten Format benö-

tigen, beispielsweise im Telefon- oder Teilenummernformat, lässt

sich dies schnell und mit wenig Programmieraufwand realisieren.

Sie verwenden dazu das MaskedTextBox-Steuerelement. Eine Mas-

ke ist eine Zeichenfolge aus Zeichen in einer Maskingsprache, durch

die festgelegt wird, welche Zeichen an einer bestimmten Position

im Textfeld eingegeben werden dürfen. Über das Steuerelement

werden dem Benutzer eine Reihe von Aufforderungen angezeigt.

Wenn der Benutzer eine falsche Eingabe macht, also beispielsweise

einen Buchstaben eingibt, während eine Ziffer benötigt wird, wird

die Eingabe vom Steuerelement automatisch zurückgewiesen.

7.6 VALIDIERUNGEN MIT WINDOWS FORMS


UI DESIGN COOKBOOK


Die von MaskedTextBox verwendete Maskingsprache ist sehr flexi-

bel. Sie ermöglicht es Ihnen, obligatorische Zeichen, optionale Zei-

chen, literale Zeichen wie Bindestriche und Klammern, Währungs-

zeichen und Datumstrennzeichen festzulegen. Das Steuerelement

funktioniert auch, wenn es an eine Datenquelle gebunden ist. Das

Format-Ereignis für eine Datenbindung kann auch zum Neuforma-

tieren eingehender Daten entsprechend der Maske und das Par-

se-Ereignis zum Neuformatieren ausgehender Daten entsprechend

den Spezifikationen des Datenfeldes verwendet werden.

Weitere Informationen finden Sie unter MaskedTextBox-Steuerele-

ment (Windows Forms).

Ereignisgesteuerte Validierung

Wenn die Validierung vollständig programmgesteuert ablaufen soll

oder wenn umfangreiche Validierungen erforderlich sind, sollten

Sie die Validierungsereignisse verwenden, die in die meisten Win-

dows-Forms-Steuerelemente integriert sind. Jedes Steuerelement,

das formfreie Benutzereingaben akzeptiert, verfügt über ein Va-

lidating-Ereignis, das eintritt, sobald das Steuerelement eine Daten-

validierung erfordert. In der Validating-Ereignisbehandlungsmetho-

de können Sie Benutzereingaben auf mehrere Weisen überprüfen.

Wenn Sie beispielsweise über ein Textfeld verfügen, das eine Post-

leitzahl enthalten muss, können Sie die Validierung auf folgende

Arten ausführen:

• Wenn die Postleitzahl einer bestimmten Gruppe von PLZ-Codes

angehören muss, können Sie einen Zeichenfolgenvergleich für die

Eingabe ausführen, um die vom Benutzer eingegebenen Daten

zu überprüfen. Wenn sich die Postleitzahl beispielsweise in der

Menge {10001, 10002, 10003} befinden muss, können Sie zur

Validierung der Daten einen Zeichenfolgenvergleich verwenden.

UI DESIGN COOKBOOK


• Wenn die Postleitzahl in einem bestimmten Format vorliegen muss,

können Sie zur Validierung der vom Benutzer eingegebenen Da-

ten reguläre Ausdrücke verwenden. Um beispielsweise das Format

##### oder #####-#### zu überprüfen, können Sie den regulären

Ausdruck ^(\d{5})(-\d{4})?$ verwenden. Um beispielsweise das For-

mat A#A #A# zu überprüfen, können Sie den regulären Ausdruck

[A-Z]\d[A-Z] \d[A-Z]\d verwenden. Weitere Informationen zu regu-

lären Ausdrücken finden Sie unter «Reguläre Ausdrücke» von .NET

Framework und dazu Beispiele für reguläre Ausdrücke.

• Wenn die Postleitzahl eine in den USA gültige Postleitzahl sein

muss, können Sie einen Postleitzahlen-Webdienst aufrufen, um

die vom Benutzer eingegebenen Daten zu überprüfen.

• Für das Validating-Ereignis wird ein Objekt des Typs Cancel-

EventArgs bereitgestellt. Wenn Sie feststellen, dass die Daten des

Steuerelements ungültig sind, können Sie das Validating-Ereignis

abbrechen, indem Sie die Cancel-Eigenschaft dieses Objekts auf

true festlegen. Wenn Sie die Cancel-Eigenschaft nicht festlegen,

geht Windows Forms davon aus, dass die Validierung für dieses

Steuerelement erfolgreich war, und das Validated-Ereignis wird

ausgelöst.

• Ein Codebeispiel, durch das eine E-Mail-Adresse in einer TextBox

überprüft wird, finden Sie unter Validating.

Datenbindung und ereignisgesteuerte Validierung

Die Validierung ist sehr hilfreich, wenn Sie Steuerelemente an eine

Datenquelle, z. B. eine Datenbanktabelle, gebunden haben. Mit-

hilfe der Validierung können Sie sicherstellen, dass die Daten des

Steuerelements das Format aufweisen, das von der Datenquelle be-

nötigt wird, und dass keine Sonderzeichen wie Anführungszeichen

und umgekehrte Schrägstriche enthalten sind, die sich als unsicher

erweisen könnten.

UI DESIGN COOKBOOK


Wenn Sie die Datenbindung verwenden, werden die Daten im

Steuerelement während der Ausführung des Validating-Ereignis-

ses mit der Datenquelle synchronisiert. Wenn Sie das Validating-

Ereignis abbrechen, werden die Daten nicht mit der Datenquelle

synchronisiert.

Wichtig

Wenn Sie über eine benutzerdefinierte Validierung verfügen, die

nach dem Validating-Ereignis stattfindet, wirkt sich dies nicht auf

die Datenbindung aus. Wenn Sie beispielsweise über Code in einem

Validated-Ereignis verfügen, der versucht, die Datenbindung aufzu-

heben, bleibt die Datenbindung weiterhin bestehen. Um in diesem

Fall eine Validierung im Validated-Ereignis auszuführen, ändern Sie

die Datenquellen-Aktualisierungsmodus-Eigenschaft des Steuerele-

ments (unter (Databindings)\(Advanced)) von OnValidation in Never

und fügen dem Validierungscode Con-trol.DataBindings [„<YOUR-

FIELD>“].WriteValue() hinzu.

Implizite und explizite Validierung

Wann werden die Daten eines Steuerelements überprüft? Dies

hängt vom Entwickler ab. Sie können entweder die implizite oder

die explizite Validierung verwenden, je nachdem, welche Anforde-

rungen Sie an Ihre Anwendung stellen.

Implizite Validierung

Bei der impliziten Validierung werden die Daten überprüft, wenn

sie vom Benutzer eingegeben werden. Sie können die Daten wäh-

rend der Eingabe in ein Steuerelement überprüfen, indem Sie die

Tastatureingaben lesen oder, was häufiger der Fall ist, verfolgen,

wann der Benutzer den Eingabefokus von einem Steuerelement

zum nächsten verschiebt. Dieser Ansatz ist hilfreich, wenn Sie dem

UI DESIGN COOKBOOK


Benutzer während der Arbeit direktes Feedback zu den Daten ge-

ben möchten.

Wenn Sie die implizite Validierung für ein Steuerelement verwenden

möchten, müssen Sie die AutoValidate-Eigenschaft dieses Steuerele-

ments auf true festlegen. Wenn Sie das Validating-Ereignis abbrechen,

richtet sich das Verhalten des Steuerelements nach dem Wert, den Sie

AutoValidate zugewiesen haben. Wenn Sie Enable-PreventFocusChange

zugewiesen haben, bewirkt das Abbrechen des Ereignisses, dass das Va-

lidated-Ereignis nicht eintritt. Der Eingabefokus verbleibt beim aktuellen

Steuerelement, bis der Benutzer die Daten in eine gültige Eingabe än-

dert. Wenn Sie EnableAllow-FocusChange zugewiesen haben, tritt das

Validated-Ereignis beim Abbrechen des Ereignisses nicht ein, der Fokus

wird jedoch trotzdem an das nächste Steuerelement übergeben.

Indem Sie Disable zur AutoValidate-Eigenschaft zuweisen, wird die

implizite Validierung grundsätzlich verhindert. Um Steuerelemente

zu überprüfen, müssen Sie die explizite Validierung verwenden.

Explizite Validierung

Bei der expliziten Validierung werden die Daten zu einem bestimm-

ten Zeitpunkt überprüft. Sie können die Daten in Reaktion auf eine

Benutzeraktion überprüfen, z. B. das Klicken auf eine Schaltfläche

zum Speichern oder auf einen weiterführenden Link. Wenn die Be-

nutzeraktion eintritt, können Sie die explizite Validierung auf eine

der folgenden Arten auslösen:

• Rufen Sie Validate auf, um das letzte Steuerelement zu überprü-

fen, das den Fokus hatte.

• Rufen Sie ValidateChildren auf, um alle untergeordneten Steuer-

elemente in einem Formular- oder Containersteuerelement zu

überprüfen.

UI DESIGN COOKBOOK


• Rufen Sie eine benutzerdefinierte Methode auf, um die Daten in

den Steuerelementen manuell zu überprüfen.

Standardverhalten für Windows-Forms-Steuerelemente bei der impli-

ziten Validierung: Windows-Forms-Steuerelemente verfügen jeweils

über unterschiedliche Standardwerte für die AutoValidate-Eigen-

schaft. In der folgenden Tabelle werden die am häufigsten verwen-

deten Steuerelemente mit ihren Standardwerten aufgeführt.

Steuerelement Standardverhalten für die Validierung

ContainerControl Inherit

Form EnableAllowFocusChange

PropertyGrid In Visual Studio nicht verfügbar gemachte

Eigenschaft

ToolStripContainer In Visual Studio nicht verfügbar gemachte

Eigenschaft

SplitContainer Inherit

UserControl EnableAllowFocusChange

Schliessen des Formulars und Überschreiben der Validierung

Wenn ein Steuerelement den Fokus behält, weil die enthaltenen

Daten ungültig sind, kann das übergeordnete Formular nicht auf

eine der üblichen Weisen geschlossen werden:

• Durch Klicken auf die Schaltfläche Schließen

• Durch Auswählen von Schließen im Systemmenü

• Durch programmgesteuertes Aufrufen der Close-Methode

In einigen Fällen soll der Benutzer jedoch möglicherweise das For-

mular unabhängig davon schliessen können, ob die Werte in den

UI DESIGN COOKBOOK


Steuerelementen gültig sind. Die Validierung kann überschrieben

und ein Formular mit ungültigen Daten geschlossen werden, wenn

Sie einen Handler für das Closing-Ereignis des Formulars erstellen.

Legen Sie für das Ereignis die Cancel-Eigenschaft auf false fest. Da-

durch wird das Formular in jedem Fall geschlossen. Weitere Infor-

mationen und ein Beispiel finden Sie unter Form.Closing.

7.7 VALIDIERUNGEN MIT ASP.NET



Bei der Erstellung von ASP.NET-Webseiten für Benutzereingaben ist

ein wichtiger Aspekt zu beachten: Es muss möglich sein, die vom

Benutzer eingegebenen Informationen auf ihre Gültigkeit zu über-

prüfen. ASP.NET stellt eine Reihe von Validierungssteuerelementen

bereit, die eine benutzerfreundliche, aber leistungsstarke Mög-

lichkeit bieten, Formulare auf Fehler zu überprüfen und bei Bedarf

Fehlermeldungen an den Benutzer auszugeben. Im folgenden Ab-

schnitt werden die Validierungssteuerelemente und ihre Verwen-

dung beschrieben.

Validierung mit ASP.NET

Die folgenden Links führen zur MSDN-Page von Microsoft, mit gu-

ten Beschreibungen und mit Beispielen und How Tos zu den Mög-

lichkeiten der Validierung in ASP.NET

UI DESIGN COOKBOOK


ASP.NET-Validierungssteuerelemente

Stellt eine Liste mit Themen für die verschiedenen ASP.NET-Vali-

dierungssteuerelemente und -Validierungsverfahren bereit, die auf

ASP.NET-Webseiten verwendet werden können.

• Überprüfen der Benutzereingabe in ASP.NET-Webseiten

• What‘s New in Validation

• Arten der Validierung für ASP.NET-Serversteuerelemente

• Angeben von Validierungsgruppen

• Clientseitige Validierung für ASP.NET-Serversteuerelemente

• Validierungsergebnisse für ASP.NET-Serversteuerelemente in

Sonderfällen

• Layout von Validierungsfehlermeldungen für ASP.NET-Server-

steuerelemente

• Gewusst wie: Programmgesteuertes Testen der Validierung für

ASP.NET-Serversteuerelemente

• Gewusst wie: Deaktivieren der Validierung für ASP.NET-Server-

steuerelemente

• Gewusst wie: Programmgesteuertes Validieren für ASP.NET-Ser-

versteuerelemente

7.8 VALIDIERUNGEN MIT ASP.NET MVC



Der Entwickler möchte mit ASP.NET MVC einfache und gut bedien-

bare Eingabedialoge mit umfangreichen Validierungen erstellen.

UI DESIGN COOKBOOK


Validierung mit ASP.NET MVC

In ASP.NET MVC können die unter 6.7 beschriebenen Techniken

angewendet werden, zudem gibt der folgende Link eine Beschrei-

bung, wie man mit JQuery und ASP.NET MVC komfortable Dialoge

erstellen kann.

http://code-inside.de/blog/2009/10/12/howto-eingabenvalidie-

rung-in-asp-net-mvc/

ASP.NET MVC Frameworks zur Validierung

Es stehen für ASP.NET MVC zwei Frameworks für die Validierung

zur Verfügung:

xVal – Validation Framework für ASP.NET MVC:

ein Framework, welches serverseitig und clientseitig validieren

kann.

http://xval.codeplex.com/

fluentValidation:

eine kleine .Net Library zum Validieren.

http://fluentvalidation.codeplex.com/

UI DESIGN COOKBOOK


8 LAYOUT

UI DESIGN COOKBOOK



Komplexe Fachdaten werden oftmals über verschiedene Dialoge ver-

teilt bearbeitet. Dem Sachbearbeiter fehlt jedoch ein schneller und

aussagekräftiger Überblick über das entsprechende Fachobjekt.

8.1 ÜBERSICHT ÜBER KOMPLEXE FACHDATEN


Abbildung 8-1: Übersichtsdialog als

Zusammenfassung der wichtigsten Daten

UI DESIGN COOKBOOK


Lösungsvorschlag

Wurde der Ansatz von Registerkarten, Navigationsbereich oder

Modulen zur Strukturierung der Applikation gewählt, kann dem

Anwender mit einer Übersichtsebene eine Zusammenfassung der

Fachdaten angezeigt werden. Dazu wird ein zusätzlicher Dialog er-

stellt, welcher alle Registerkarten/Module in einer extrem kompri-

mierten Form zusammenfasst. In einem zwei- oder dreispaltigen

Design werden die wichtigsten Daten in separaten Bereichen dar-

gestellt.

Die einzelnen Bereiche können den Sachbearbeiter bei Doppelklick

oder einer ähnlichen Aktion, sofern es die gewählte Technologie

erlaubt, direkt auf die entsprechende Registerkarte/Modul navigie-

ren lassen.

Die Übersicht kann direkt in die verteilte Darstellung als zusätzliche

Ebene integriert werden oder als eigenständiger Applikationsbe-

reich angezeigt werden. Einige Anwender bevorzugen die separate

Darstellung, da in komplexen Umgebungen das Laden der komplet-

ten Daten etwas Zeit in Anspruch nehmen kann. Für einen schnellen

Blick reicht ihnen aber bereits die komprimierte Übersicht.

Bemerkungen

Es muss genau darauf geachtet werden, dass wirklich nur notwen-

dige Daten in der Übersicht dargestellt werden. Der Dialog wird

durch seine Natur grundsätzlich sehr überfrachtet wirken. Dieser

Eindruck kann für den Sachbearbeiter jedoch entschärft werden,

indem die einzelnen Bereiche keine endlosen Listen oder Tabellen

mit horizontalen Bildlaufleisten enthalten. Ausserdem darf in die-

sem Dialog keine Bearbeitung der Daten möglich sein.

UI DESIGN COOKBOOK



Die Applikation verwaltet sehr komplexe und umfangreiche Fachda-

ten und muss in der Lage sein, diese dem Sachbearbeiter in einer

übersichtlichen und angenehmen Weise darzustellen.

Lösungsvorschlag Allgemein

Komplexe Fachdaten können in nahezu allen Fällen in kleinere Ein-

heiten bzw. Kategorien zerlegt werden. Diese für den Sachbear-

beiter sinnvolle Aufteilung wird genutzt und ein Dialog mit meh-

reren Ebenen erstellt. Auf diese Weise wirkt die Oberfläche nicht

überfrachtet, und der Benutzer wird durch die Applikation geführt

und seine Aufmerksamkeit Ebene für Ebene auf wenige, fachlich

zusammengehörende Werte gelenkt. Die Darstellung der Ebenen

kann auf vielfältige Weise erfolgen.

Lösungsvorschlag Registerkarten

Die Darstellung der Ebenen durch Registerkarten mit Laschen an

der Ober- oder Unterseite ist eine weit verbreitete Variante. Das

Fachobjekt wird normalerweise komplett geladen und in allen Re-

gisterkarten abgefüllt.

8.2 DARSTELLUNG VON KOMPLEXEN FACHDATEN


UI DESIGN COOKBOOK


Abbildung 8-2: Applikationsdesign mit

Registerkarten

Lösungsvorschlag Navigationsbereich

Der Navigationsbereich, sinngemäss auch Registerkarten, jedoch mit

horizontal ausgerichteten Laschen in einem separaten Bereich, errei-

chen das gleiche Ziel. Es kann abhängig von der gewählten Technologie

das Verhalten von Registerkarten oder Modulen angewendet werden.

Abbildung 8-3: Applikationsdesign

mit Modulen

UI DESIGN COOKBOOK


Lösungsvorschlag Module

Möchte man die einzelnen Ebenen stärker voneinander trennen,

kann die Darstellung über separate Module erfolgen. In dieser Va-

riante werden die verfügbaren Module z. B. über eine Toolbar mit

Schaltflächen angeboten. Im Normalfall werden nur Fachdaten des

Moduls geladen und gespeichert. Ein Modul muss deshalb eine

komplette Entität abdecken, die unabhängig von anderen Modulen

dessen Daten validieren und speichern kann.

Lösungsvorschlag Ausblendbare Bereiche

Eine sehr kompakte Lösung stellt die Verwendung von ausblendba-

ren Bereichen dar. In dieser Variante werden die kompletten Fach-

daten in einem einzigen Endlosformular dargestellt und die einzel-

nen Ebenen in ausblendbare Elemente unterteilt. Auf diese Weise

kann der Sachbearbeiter genau die Ebenen geöffnet behalten, wel-

che für ihn momentan wichtig sind. Über die Titel der Bereiche kann

auf Validierungsfehler oder den aktuellen Bearbeitungszustand hin-

gewiesen werden.

Abbildung 8-4: Applikationsdesign mit

ausblendbaren Bereichen

UI DESIGN COOKBOOK


Lösungsvorschlag Wizard

Für die erstmalige Datenerfassung eignet sich auch ein Wizard, der

den Benutzer durch einen durch die Applikation bestimmten Ab-

lauf führt. Für die spätere Anzeige oder Nachbearbeitung ist diese

Lösung jedoch meist nicht sinnvoll, und es ist eine Oberfläche mit

einem der anderen Lösungsvorschläge notwendig.

Bemerkungen

Die Aufteilung von Fachdaten in Ebenen ist in vielen Fällen zur

Strukturierung der Applikation sehr hilfreich. Es muss jedoch be-

achtet werden, dass je nach Fachanforderungen ein Datensatz, der

über mehrere Ebenen verteilt wurde, übergreifend mit einer einzi-

gen Schlussvalidierung als komplette Einheit gespeichert werden

muss. Die Wahl der Lösung und die technischen Möglichkeiten der

verwendeten Technologie müssen diesen Umstand berücksichtigen.

Als zusätzliche Herausforderung müssen das Anzeigen von Validie-

rungsfehlern von aktuell nicht sichtbaren Ebenen, das temporäre

Speichern von Daten beim Seitenwechsel in webbasierten Applika-

tionen und das komplette Verwerfen von nicht gespeicherten Da-

ten in die Lösungswahl einbezogen werden.

UI DESIGN COOKBOOK



In komplexen Systemlandschaften, vielleicht sogar mit Diensten, wel-

che über externe Netzwerke angesprochen werden, ist es schwierig,

den aktuellen Status der Applikation zu erkennen.

8.3 STATUS- & UMGEBUNGSINFORMATIONEN


Abbildung 8-5: Darstellung von Informa-

tionen in einer Statusleiste

Lösungsvorschlag

Für die Darstellung von nicht kontextbezogenen Informationen wie

z. B. Versionsnummer, der Benutzername des angemeldeten An-

wenders, der verbundene WebServer und vielleicht sogar die aktu-

ell verwendete Datenbank-Instanz eignet sich die Statusleiste. Diese

befindet sich im Normallfall ganz am unteren Ende der Applikation

und ist zu jeder Zeit sichtbar.

Die Statusleiste selbst ist in separate Bereiche unterteilt und stellt in

jedem Abschnitt eine relevante Information dar. Diese Informatio-

nen sind teilweise so anschaulich, dass sogar auf eine Beschreibung

verzichtet werden kann und nur die Information selbst platzsparend

angezeigt wird.

UI DESIGN COOKBOOK


Neben den bereits erwähnten Benutzer- und Serverinforma-

tionen wird oftmals auch ein grösserer Bereich der Statusleiste

für den aktuellen Applikationsstatus verwendet. Hier kann die

Applikation laufzeitabhängig aktuelle Informationen ausgeben,

welche dem Benutzer den aktuellen Status aufzeigen. Läuft

z. B. eine komplexe Suche und der Anwender muss auf die Ant-

wort warten, so kann diese Tatsache als Status ausgegeben wer-

den. Ebenfalls sehr nützlich ist diese Art der Benachrichtigung

für Aktionen, welche keine andere optische Auswirkung auf

die Applikation haben. Ein typisches Beispiel dafür ist die Spei-

cher-Funktionalität, die nach erfolgreichem Abschluss dies über

die Statusleiste mitteilen kann.

Einige Applikationen erlauben über die Statuszeile auch die Steue-

rung der Anzeige, indem zwischen verschiedenen Layouts gewählt

und der Zoomfaktor bestimmt werden kann. Solche aktiven Be-

reiche müssen jedoch sehr genau analysiert werden und müssen

sich immer auf Funktionalitäten beziehen, welche für die gesamte

Applikation gültig sind.

Bemerkungen

Die Statusleiste ist nur für die Anzeige von Informationen geeig-

net, die keine Aktionen vom Anwender erwarten. Eine Dialogbox

mit einer Ja-Nein-Frage kann auf keinen Fall ersetzt werden. Aus-

serdem sollten die angezeigten Informationen von eher statischer

Natur sein, da sich ständig ändernde Informationen den Anwender

ablenken können.

Bekannte Beispiele für die aktive Verwendung der Statusleiste sind

Microsoft Word und Visual Studio. In diesen Programmen werden

permanent die aktuelle Eingabemarker-Position und/oder die mo-

UI DESIGN COOKBOOK


mentane Seite angezeigt. Die Vor- und Nachteile von sich dyna-

misch ändernden Informationen können dort sehr gut beobachtet

werden.


Müssen längere Listen mit Daten in einem Dialog angezeigt werden,

so geschieht dies oft in Tabellenform. Dies hat meist zur Folge, dass

ein Dialog sehr überfüllt erscheint und Funktionen enthalten sind,

die nicht benötigt werden bzw. nicht wie erwartet funktionieren. Si-

cher haben Grids ihre Berechtigung, aber manchmal sollte man sich

hinterfragen, warum Windows für den Datei-Explorer keine Grids

verwendet.

Lösungsvorschlag

ListViews erlauben dem Benutzer, auf einfache und gewohnte Art

und Weise Daten zu betrachten, zu filtern und zu sortieren sowie

einen oder mehrere Einträge zu selektieren. Des Weiteren kann von

Programmseite wie auch durch den Benutzer die Art der Anzeige den

jeweiligen Bedürfnissen angepasst werden.

8.4 LISTVIEW, ALTERNATIVE ZU GRIDS


UI DESIGN COOKBOOK


Abbildung 8-6: Listentyp: Details

Abbildung 8-7: Listentyp: Tiles

Besonders interessant sind die Ansichten Details und Tile, da in die-

sen weitere Daten angezeigt werden können. Es lohnt sich, her-

auszufinden, welche Daten die Benutzer eigentlich am häufigsten

brauchen, und dann nur diese darzustellen. Eine Gruppierung trägt

ebenfalls stark zur Übersichtlichkeit bei.

UI DESIGN COOKBOOK


Bemerkungen

Je nachdem kann es sinnvoll sein, auf eine einfachere Listbox aus-

zuweichen oder eine TreeView zu verwenden.

ListViews wie auch TreeView und Listbox sind vor allem zur Daten-

ausgabe konzipiert. Will man eine direkte Dateneingabe erlauben,

so kann man dann doch bei einem Grid verbleiben oder man ändert

das Konzept der Eingabe.

8.5 GRUPPIERTE ELEMENTE


Abbildung 8-8: Verschachtelt gruppierte

Elemente

UI DESIGN COOKBOOK



Sind mehrere Eingabemöglichkeiten und Texte thematisch einer

Gruppe zuzuordnen, möchte man diese auch optisch gruppieren.

Wenn man nun aber mehrere Gruppen (auch Groupbox genannt) auf

einem Dialog erhält und diese womöglich noch verschachtelt vorfin-

det, stören die Gruppen mehr als sie nützen.

Lösungsvorschlag

Die oben gezeigte Situation lässt sich wie folgt einfacher und über-

sichtlicher anzeigen. Die verschachtelten Gruppen werden aufgelöst

und durch passende Abstände voneinander getrennt. Um die Haupt-

gruppen leichter zu trennen, wird anstelle eines Rahmens um die

Gruppe eine Linie auf Höhe der Gruppenüberschrift angezeigt. Und

Abbildung 8-9: Vereinfachte Gruppierung

UI DESIGN COOKBOOK


auch wenn es verlockend klingt, haben Controls wie eine Combobox

auf der Gruppenumrandung nichts verloren. Einzige Ausnahme wäre

eine Checkbox, um die ganze Gruppe ein- bzw. auszublenden. Die hier

gezeigte Lösung ersetzt die umschaltbare Gruppe durch Tabs.

Abbildung 8-10: Visuelle Gruppierung

Bemerkungen

Gruppen sind auch in den UX-Guidelines beschrieben. Auch wenn MS

früher häufig Gruppen eingesetzt hat, geht der Trend bei Gruppierun-

gen derzeit hin zu Abständen und leeren Flächen anstelle von vielen

Linien. Im Allgemeinen soll die Groupbox nur noch verwendet werden,

wenn keine andere Lösung möglich scheint.

UI DESIGN COOKBOOK


9 ANWENDERUNTERSTÜTZUNG

UI DESIGN COOKBOOK



Der Anwender möchte bei der Bedienung der Applikation bzw. bei

der Bearbeitung von Daten aktiv unterstützt werden und mit kurzen,

situativ passenden Anweisungen versorgt werden.

9.1 KONTEXTHILFE


Abbildung 9-1: Anwenderunterstützung

mit einem Tooltip

Lösungsvorschlag Tooltip

Eine einfache Möglichkeit zur Anwenderunterstützung bietet sich mit

dem Einsatz von Tooltips an. Dies sind kleine Popup-Fenster mit sehr

kurzen Sätzen oder Stichworten, die erscheinen, wenn der Anwen-

der eine kurze Zeit mit der Maus über dem zugeordneten Bereich der

Oberfläche verweilt.

Tooltips eignen sich besonders für Eingabefelder und Schaltflächen,

um die genaue Bedeutung oder Eingabe-Hinweise anzuzeigen bzw.

um auf Validierungsfehler hinzuweisen. Es muss jedoch beachtet

werden, dass die Texte nicht zu lang sein sollten, weil die Popups

UI DESIGN COOKBOOK


dadurch zu viel von der Oberfläche verdecken oder über den Rand

der Applikation hinausreichen. Ausserdem werden geübte Anwen-

der sich mit der Zeit an den ständig aufpoppenden Tooltips stören.

Abbildung 9-2: Anwenderunterstützung über einen Info-Bereich

Lösungsvorschlag Info-Bereich

Hilfestellungen in einem Info-Bereich unterstützen den Anwender,

indem in einem reservierten Bereich auf der Oberfläche die Texte

angezeigt werden. Sie werden analog den Tooltips über die Position

der Maus gesteuert.

Der Info-Bereich kann beliebig komplexe Hilfestellungen enthalten,

so auch Bilder und formatierte Texte. Der dafür notwendige Platz

muss jedoch beim UI-Design berücksichtigt werden und reduziert

die verfügbare Fläche der Applikation. Für den Info-Bereich stehen

keine technologischen Hilfsmittel zur Verfügung, sie müssen durch

den Entwickler vollständig programmiert werden.

UI DESIGN COOKBOOK


Lösungsvorschlag Hilfe

Sehr umfangreiche und bebilderte Anleitungen werden idealerwei-

se als eigenständiges Hilfe-Dokument in einem Popup-Fenster dar-

gestellt und über die Taste F1, einen Hilfe-Menüeintrag oder kon-

textspezifische Menüs einzelner Oberflächenbereiche abgerufen.

Ein eigenständiges Hilfe-Dokument erlaubt eine umfassende Be-

schreibung der Applikation und erlaubt spezielle Bereiche der

Oberfläche sehr detailliert zu beschreiben. Das Erstellen eines sol-

chen Dokumentes verlangt geeignete Autoren mit entsprechendem

Fachwissen und redaktionellen Fähigkeiten. In letzter Zeit konnte

beobachtet werden, dass solche Dokumentationen vermehrt nur

noch online verfügbar sind und über ein Browser-Steuerelement in

die Applikation eingebunden werden.

Abbildung 9-3: Anwenderunterstützung

mit einer Hilfe

Bemerkungen

Diese Lösungsvorschläge lassen sich auch kombinieren. Schlussend-

lich bestimmt die Art der Applikation, der angestrebte Anwender-

kreis und die Arbeitsumgebung die Wahl der Anwenderunterstüt-

zung.

UI DESIGN COOKBOOK


10 BERECHTIGUNGEN

UI DESIGN COOKBOOK



Die Applikation enthält Daten, die aus Datenschutz- oder Sicherheits-

überlegungen nur einer bestimmten Benutzergruppe zur Verfügung

stehen sollen.

10.1 DATEN MIT BENUTZERBERECHTIGUNGEN


Abbildung 10-1: Präsentation der

vollständigen Daten inklusive der ausblend-

baren Bereiche

Abbildung 10-2: Präsentation ohne

geschützte Daten in aus-geblendeten Bereichen

UI DESIGN COOKBOOK


Lösungsvorschlag für zu schützende Zusatzdaten

Handelt es sich bei den zu schützenden Daten um eine kleine Unter-

menge einer grösseren Datenentität, eignen sich ausblendbare oder

nicht direkt einsehbare Bereiche.

Soll z. B. in einer Kundenverwaltung ein persönlicher Kommentar

des Sachbearbeiters erfasst werden, dieser Text jedoch nur von ihm

selbst und seinen Vorgesetzten einsehbar sein, könnte ein Freitext-

Kommentar über ein benutzerberechtigtes Kommentar-Popup er-

fasst werden.

Handelt es sich bei den zu schützenden Daten um eine etwas kom-

plexere Struktur, können diese in einer ausblendbaren Gruppe oder

einer ausblendbaren Registerkarte dargestellt werden.

Lösungsvorschlag für komplette Datenentitäten

Im Gegensatz zur Lösung mit öffentlichen Daten und geschützten

Einzelwerten muss bei komplett zu schützenden Datenentitäten da-

für gesorgt werden, dass diese unberechtigten Personen als kom-

plette Einheit nicht zur Verfügung stehen.

Sollen z. B. in einer Kundenverwaltung Einträge der eigenen Mitar-

beiter nur dem Supervisor angezeigt werden, den restlichen Sach-

bearbeitern jedoch nicht, müssen diese Entitäten bereits bei der

Suche berechtigungsabhängig herausgefiltert werden.

Abhängig von der Applikation kann unter Umständen darauf hin-

gewiesen werden, dass eine bestimmte Anzahl von Datensätzen

gefiltert wurde. Dies kann einem unberechtigten Anwender bereits

relevante Anhaltspunkte geben.

UI DESIGN COOKBOOK


Die Gründe für eine Nichtberechtigung von kompletten Datensät-

zen können sehr vielfältig und fachbedingt sehr unterschiedlich sein.

So können Daten z. B. nach Stadtkreisen, Einkommensstufen oder

Promi-Faktoren verschiedenen Benutzergruppen zugeteilt werden.

Lösungsvorschlag für schreibgeschützte Daten

Sollen die Daten zwar angezeigt, jedoch berechtigungsabhängig

der Schreibzugriff verweigert werden, kann dies für Einzeldaten

über gesperrte Eingabefelder und für komplette Datenentitäten

über eine gesperrte Speicherfunktion erreicht werden.

Bemerkungen

Um Daten über eine Berechtigungsverwaltung zu schützen, müs-

sen spezielle Vorkehrungen getroffen werden. So muss z. B. bei

benutzerspezifischen Kommentaren festgehalten werden, welcher

Sachbearbeiter oder welche Berechtigungsgruppe diesen konkre-

ten Kommentar erfasst hat.

Komplette Datenentitäten können über eine Sicherheitsklassifizie-

rung oder andere gruppierende Eigenschaften für den Schutz ge-

kennzeichnet werden.

Abhängig von der Architektur der Applikation muss der Schutz der

Daten bereits auf einem sehr tiefen Level der Layer angesetzt wer-

den. Das berechtigungsabhängige Userinterface ist in vielen Fällen

nicht ausreichend und dient mehrheitlich dem optimierten Anwen-

dererlebnis.

UI DESIGN COOKBOOK



Die Applikation enthält Daten, die aus Datenschutz- oder Sicherheits-

überlegungen nur einer bestimmten Benutzergruppe zur Verfügung

stehen sollen.

10.2 FUNKTIONEN MIT BENUTZERBERECHTIGUNGEN


Abbildung 10-3: Präsentation der

vollständigen Daten inklusive der

ausblendbaren Bereiche

Abbildung 10-4: Permanent geschützte

Funktionalitäten

Lösungsvorschlag für permanent geschützte Funktionalitäten

Stehen einem Benutzer gewisse Funktionalitäten permanent nicht

zur Verfügung, können die dazugehörigen Menüeinträge, Eingabe-

felder, Befehlsschaltflächen und Registerkarten in der Benutzerober-

fläche komplett ausgeblendet werden.

UI DESIGN COOKBOOK


Auf diese Weise ist die Applikation für den Benutzer schlank und

optimiert, und er hat nicht das Gefühl, von gewissen Bereichen aus-

geschlossen zu sein.

Lösungsvorschlag für datenabhängig geschützte

Funktionalitäten

Müssen Funktionalitäten abhängig von den aktuellen Daten ge-

sperrt werden, wird dies normalerweise über das Deaktivieren der

Menüeinträge, Befehlsschaltflächen etc. erreicht.

Auf diese Weise kann z. B. die Speicherung von einer Datenentität

durch einen Sachbearbeiter verhindert werden, da diese bereits von

einem Benutzer visiert wurde, der eine Vorgesetztenfunktion ausübt.

Für datenabhängigen Schutz werden im Normalfall die Bedienele-

mente nicht ausgeblendet und nur deaktiviert, da sich die Oberflä-

che dem Benutzer gegenüber nicht übermässig dynamisch verän-

dern sollte.

Bemerkungen

Um Funktionen über Benutzerberechtigungen schützen zu können,

muss die Applikation ein geeignetes System anwenden. Beson-

ders wichtig ist es hierbei, dass nicht nur die Benutzeroberfläche

die Funktionalitäten vor unberechtigten Zugriffen schützt. Abhän-

gig von der Architektur müssen auch darunterliegende Layer den

Schutz der Funktionalitäten implementieren.

Ein komplexer Berechtigungsschutz erfordert oft eine saubere Spe-

zifikation der geschützten Funktionalitäten in den verschiedenen

Applikationsteilen, den geplanten Benutzergruppen und in den ver-

schiedenen Zuordnungen.

UI DESIGN COOKBOOK


11 ANHANG

UI DESIGN COOKBOOK


11.1 AUTOREN

Michael Albertin

Roland Gelzer

Adrian Krummenacher

Risto Kyburz

Urs Pfirter

www.bbv.ch · [email protected]

MAKING VISIONS WORK.

Unsere Booklets und vieles mehr finden Sie unter

www.bbv.ch/publikationen

Beratung

Ausbildung

Engineering LösungenERFOLG

bbv Software Services AG ist ein Schweizer Soft-

ware- und Beratungsunternehmen, das Kunden

bei der Realisierung ihrer Visionen und Projek-

te unterstützt. Wir entwickeln individuelle

Softwarelösungen und begleiten Kunden mit

fundierter Beratung, erstklassigem Software

Engineering und langjähriger Branchenerfah-

rung auf dem Weg zur erfolgreichen Lösung.

Documents

UI DESIGN COOKBOOK BOOKLET - bbv.ch · · [email protected] MAKING VISIONS WORK. Unsere Booklets und vieles mehr finden Sie unter Beratung Ausbildung Engineering ERFOLG Lösungen