UI Design Cookbook by bbv Software Services

BOOKLET

UI DESIGN COOKBOOK

PROFITIEREN SIE VON UNSERER ERFAHRUNG!

Kontakt Schweiz bbv Software Services AG Blumenrain 10 6002 Luzern Telefon: +41 41 429 01 11 E-Mail: info@bbv.ch Kontakt Deutschland bbv Software Services GmbH Agnes-Pockels-Bogen 1 80992 München Telefon: +49 89 452 438 30 E-Mail: info@bbv.eu

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

INHALT 1 Einleitung

Generelle Tipps

3 Architektur

4 Komponenten

4.1

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

4.2

Panels mit Docks und Anchors, UI bauen leicht gemacht

Internationalisierung und Lokalisierung

5.1 Pseudolokalisierung

5.2 Tastatur

5.3

Unicode und Fonts

5.4 Schriftgrösse

5.5 Sortierung

5.6

Bidirektionale Oberflächen

5.7

Lokalisierung in WPF

5.8

Lokalisierung in ASP.NET

6 Datenverwaltung

6.1 Datensuche

6.2 Dateneditierung

6.3 Datenerfassung

6.4 Datensuche

6.5

Dateneditierung und Dateneingabe

6.6 Schnellsuche

6.7

Formatierte Werte

6.8

Darstellung von Einheiten

6.9

Optimale Lösung

6.10

Massenerfassung von gleichartigen Daten

6.11 Freitext-Kommentare

UI DESIGN COOKBOOK

7 Validierung

7.1

Allgemeine Richtlinien zur Validierung

7.2

Texteingaben (TextBox) validieren

7.3

Zwingende Eingabe validieren (Required Input)

7.4

Eingabedialoge mit mehreren Controls validieren

7.5

Abhängige Controls über mehrere Eingabedialoge validieren 83

7.6

Validierungen mit Windows Forms

7.7

Validierungen mit ASP.NET

7.8

Validierungen mit ASP.NET MVC

8 Layout

8.1

Übersicht von komplexen Fachdaten

8.2

Darstellung von komplexen Fachdaten

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

Berechtigungen

112

10.1

Daten mit Benutzerberechtigungen

113

10.2 Funktionen mit Benutzerberechtigungen

116

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 konkrete Vorschläge zu bestimmten Themen. Es umfasst 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

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 Plattform 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 folgenden Symbolen versehen, die Auskunft über ihre Einsatztauglichkeit 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 Voraus 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 alles 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 Kunden 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-willalles»-Syndrom kann mit geschicktem Hinterfragen geheilt werden. 2. Vorgaben durch den Auftraggeber. Sind gewisse Bedienungsmuster oder Bibliotheken vorgeschrieben, so muss man diese kennenlernen. 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 Schnittstellen, 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 Desktopoder im mobilen Bereich, werden immer bunter, und man kann viele angestaubte UI-Komponenten und -Konzepte über Bord kippen. Hersteller wie Microsoft oder Apple bieten Styleguides an, in 8

UI DESIGN COOKBOOK

denen UI-Komponenten erklärt, spezifiziert und ihre besten Einsatzgebiete aufgezeigt werden. Bevor man sein Wissen aus Windows-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 Versatzstücke sind, so kann man diese später umformen und einfliessen 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 weitergehende Gedanken zu verschiedensten Navigations- und Informationsanzeigen zu machen. Diese sollte man ebenfalls aufzeichnen 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 bereits erste Mängel von Konzepten, die man sonst erst nach stundenlanger Prototypenimplementierung gefunden hätte.

UI DESIGN COOKBOOK

5. Diskussion mit Kunden und Auftraggeber. Die bis jetzt entstandenen 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 Konzepte den ersten Benutzerkontakt überleben. Umsetzung Mit dem funktionalen Design könnte man anfangen zu implemetieren, doch noch fehlt der rote Faden, wie das Programm aussehen soll. Deshalb geht es weiter in Richtung Styleguide und Screendesign. 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 eingebaut 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 Nenner zu finden. Im Hinblick auf die Applikation kann man hier allgemeingültig Schemas festlegen, wann welche Form, Farbe oder Schrift eingesetzt wird. 2. Fläche/Format. Vorgaben für den verfügbaren Platz bzw. gesperrte 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 unterschiedlichsten Button-Grössen und Abständen sieht, weiss, 10

UI DESIGN COOKBOOK

dass diese eigentlich sehr einfache Aufgabe die meisten Entwickler 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-Bereiche 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 Material, 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-Controls bieten die Möglichkeit, kleine logische Einheiten zu bilden.

UI DESIGN COOKBOOK

Weitere Informationen findet man in einschlägigen Publikationen unter Namen wie MVP, Passive View oder MVVM.

Abbildung 3-1: UI-Schichten

Wichtig ist dabei die Trennung von UI und Logik, auch solcher Logik, wie innerhalb eines Formulars die verschiedenen Elemente interagieren 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 komponentenspezifische 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 ViewModel 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 COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

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össere Probleme übersprungen werden kann.

UI DESIGN COOKBOOK

4 KOMPONENTEN Kommen wir nun zu typischen Basis-Komponenten, die man kennen muss, bevor wir auf konkretere Detailprobleme und ihre Lösungen eingehen.

UI DESIGN COOKBOOK

4.1 MENÜS (MENÜ, TOOLBAR, TASKPANE, RIBBON, OUTLOOK-BAR) Das zentrale Element, um dem Benutzer die verschiedensten Funktionen zu offerieren, ist in vielen Applikationen immer noch das Menü. Doch vor allem in neueren Applikationen gibt es auch alternative 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 allem 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üeinträ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 finden. Diese zeigt die wichtigsten Funktionen als Buttons mit Grafik an. Vom Benutzer wird erwartet, dass er diese seinen eigenen Bedü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 Taskpanes abhängig vom derzeitigen Fensterinhalt angezeigt werden, ist zwingend darauf zu achten, dass die Zusammenhänge dem Benutzer ersichtlich sind. Ribbon Das Menü wird trotz anfänglicher Akzeptanzprobleme immer mehr durch die Ribbons à la Office abgelöst. Diese weisen einige wirkliche 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. 18

UI DESIGN COOKBOOK

• Kontextsensitive Ribbons können je nach derzeitigem Programmschritt 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 anzuzeigen, 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 platziert 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 Beispiel 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. Intern 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 20

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-Control 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, werden die gedockten Controls gleich wieder passend zurechtgerückt.

Docks eignen sich vor allem für grossflächige Controls wie z. B. ListView, 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 hierarchisch 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). COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

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 minimale Grösse für das Formular zu definieren, sobald man abschätzen kann, was noch Sinn macht.

Abbildung 4-4: Auswirkungen von Anchors

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 verzichten, da man lediglich leere Flächen unterhalb des letzten Eintrags sehen würde. Bei Grids, ListViews, mehrzeiligen Texteingaben erlaubt eine flexible Grössenänderung, bei verfügbarem Bildschirmplatz mehr Information darzustellen oder das Fenster zugunsten einer anderen Applikation kleiner darzustellen. 22

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

WinForms

WPF

Silverlight

ASP.NET

Problemstellung / Situation Für Projekte, die lokalisiert werden sollen, sollte man bereits während 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 Lokalisierbarkeit 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 verschiedene Zeichensysteme • Fehlerhafte Rechts-nach-links-Darstellung (Pseudo-Mirroring) COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

UI DESIGN COOKBOOK

• Fehlende oder fehlerhafte Internationalisierung (z. B. fixes Datumsformat) • 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. 26

UI DESIGN COOKBOOK

Pseudo localization

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

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 originale 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 verwendet.

Abbildung 5-2: Lorem-ipsum-Text

«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.»

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-Unterstützung notwendig. Dafür ist es mit ihr relativ einfach möglich, ungewöhnliche Zeichensysteme (asiatisch, arabisch etc.) zu prüfen.

Abbildung 5-3: Zufällig generierter chinesischer Text

Maschinelle Übersetzung Heutzutage gibt es für viele Sprachen die Möglichkeit einer maschinellen Übersetzung. Die Qualität ist häufig ziemlich unbefriedigend, für eine Pseudolokalisierung jedoch vollständig ausreichend.

UI DESIGN COOKBOOK

Abbildung 5-4: Automatisch übersetzter Text

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

Bemerkungen • Die Pseudolokalisierung von anderem Material ausser Text ist etwas aufwendiger. Man sollte dieses Material jedoch nicht ignorieren. 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 Pseudolokalisierung an Bedeutung gewonnen. Sie ist ein halbautomatischer Test, der bereits in frühen Entwicklungsphasen eingesetzt werden kann. 5.2 TASTATUR

WinForms

WPF

Silverlight

ASP.NET

Problemstellung / Situation 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 Anwendung muss dies berücksichtigen. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

UI DESIGN COOKBOOK

Lösungsvorschlag Das Betriebssystem ist verantwortlich für die Behandlung unterschiedlicher 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 russischen 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 angepasst (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 Taste und nicht durch deren Bedeutung (z. B. CTRL+A wird unabhängig von der implizierten Bedeutung All in allen Sprachen mit denselben Tasten ausgeführt). • Die Tastenkombinationen sind benutzerdefiniert. 30

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 Anwendung schliesslich erreichen, abhängig vom eingestellten Tastaturlayout. 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-USTastaturlayouts • Die Anwendung verwendet das de-CH-Tastaturlayout -> Der eintreffende Barcode ist *123*, da auf der deutschen Tastatur 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

Tests Windows bietet als Eingabehilfe eine virtuelle Tastatur. Das Layout dieser Tastatur entspricht dem eingestellten Layout des Betriebssystems. Damit ist es relativ einfach, manuelle Smoke-Tests mit verschiedenen Layouts auszuführen.

Abbildung 5-6: Kyrillische Tastatur

Abbildung 5-7: Arabische Tastatur

UI DESIGN COOKBOOK

5.3 UNICODE UND FONTS

WinForms

WPF

Silverlight

ASP.NET

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 anzugeben, statt sie dynamisch zu setzen oder zu lokalisieren. Ausserdem hat eine WPF-Anwendung Zugriff auf Standard Composite Fonts, welche bereits für eine Internationalisierung zusammengestellt sind: • GlobalMonospace.CompositeFont Zeichen werden in einer Monospace Font gerendert (z. B. Courier New für lateinische Zeichen) • GlobalSansSerif.CompositeFont Zeichen werden in einer Sans Serif Font gerendert (z. B. Arial für lateinische Zeichen) COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

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 Zeichen 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

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Die minimale Schriftgrösse, die noch lesbar ist, hängt von der Schriftart und dem zu verwendenden Zeichensystem ab.

UI DESIGN COOKBOOK

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

Besonders Microsoft Clear Type ist bei asiatischen Zeichen und kleinen 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 lesbare 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 kleinere Anzahl Testfälle. Sehr wahrscheinlich kommt eine Anwendung mit zwei Schriftgrössen aus. -> Nur zwei Layouts müssen getestet werden.

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 skaliert, sondern mit vorgerenderten Bitmaps dargestellt. Dies erlaubt bei kleinen Schriftgrössen eine optimale Schärfe. Bemerkungen • Die Problematik der verschwimmenden Schriftzeichen bei ClearType 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

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation 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ängige 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, processing, finished. Für eine erfolgreiche Internationalisierung ist es wichtig, 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 immer 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 standardmässig nach dem Nachnamen sortiert. In manchen Ländern sind bestimmte Nachnamen so häufig, dass ausserdem auch nach weiteren 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 Anwendung 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 verwenden 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 Einstellungen ohne weitere Aktionen unterstützen, sieht es bei einer Datenbank etwas anders aus. Findet die Sortierung nur auf geladenen Daten statt, mag dies keine Rolle spielen. Für einen Paging-Mechanismus zum Beispiel ist es jedoch notwendig, die Daten direkt in der Abfrage sortiert zu erhalten. Moderne Datenbanken ermöglichen 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 Sprache und Region. Dies ist nicht immer erwünscht. Bei sicherheitsrelevantem 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 38

UI DESIGN COOKBOOK

Framework grundsätzlich mit der Invariant Culture verwenden, solange 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 Sortierung von numerischen Werten.

1 10 11 2 3 4 5 6 7 8 Abbildung 5-9: Inkorrekte Sortierung

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

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Es gibt Sprachen mit anderen Leserichtungen als links -> rechts. Lösungsvorschlag WPF unterstützt bidirektionale Benutzeroberflächen mit der FlowDirection. 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 werden. • 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 übernommen. 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 ge40

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 Features 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

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Für die Lokalisierung von WPF-Benutzeroberflächen gibt es grundsä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 ratsam, sich bereits in einem frühen Stadium des Entwicklungsprozesses 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, automatisiert möglich) • Compile -> Auslagerung der lokalisierbaren Informationen in ein Satellite Assembly • Mit locbaml (Beispiel Anwendung von Microsoft zur Lokalisierung 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 besonderen 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 diejenigen 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 einzelne 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 gestartet 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 unterstützt kein inkrementelles Update der zu lokalisierenden Daten. Das bedeutet, dass beim Exportieren die CSV-Datei immer überschrieben 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 Zusammenfü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 Lokalisierung 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 EntCOPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

UI DESIGN COOKBOOK

wickler die zu lokalisierenden Daten im XAML auch manuell markieren. 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 Informationen des entsprechenden XAML lokalisiert. Es gibt keinen Fallback, 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üssen 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-Lokalisierung 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ühren. Dies ist jedoch keine simple Aktion.

UI DESIGN COOKBOOK

Lösungsvorschlag: Resx-Lokalisierung Ressource-Dateien bieten die Möglichkeit, unterschiedlichste Ressourcen 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 anpassen (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ä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 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“ ...

UI DESIGN COOKBOOK

Hier nützt man ein Static Binding auf die vom Visual Studio erzeugte 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-Lokalisierungen unterstützt. Effizient Static Bindings produzieren wenig Overhead für die Aktualisierung. Typensicher Der Compiler kann für Static Bindings eine Typenprüfung durchführen. Keine Type Converter Static Bindings unterstützen keine Type Converter -> Nur das Binding von Texten ist wirklich einfach. Manuelle Definition der zu lokalisierenden Daten Alle zu lokalisierenden Daten müssen manuell mit einem Static Binding 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 Properties lokalisiert werden. 46

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 Anzahl 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 Benutzeroberfläche umsetzen. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

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 verknüpft werden. Auch dazu gibt es bereits einige Lösungen von der Open Source Community. Solch ein Attached Property (z. B. Localization.ToBeLocalized) würde allen zu lokalisierenden Elementen zugewiesen.

Wenn es dann beim Initialisieren gesetzt wird, löst dies die Aktualisierung mit den lokalisierten Werten aus. Dazu erstellt der Attached Property Code einen Key aus der Uid des Elements und den Bezeichnungen der übrigen Properties (z. B. labelExampleContent) und versucht, mit diesem Key die entsprechende Ressource zu laden.

UI DESIGN COOKBOOK

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 Vorkehrungen für die Lokalisierung notwendig. Das Attached Property kann nachträglich einfach hinzugefügt werden. 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.

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. Datenbank). In diesem Kapitel geht es jedoch nur um die verschiedenen Varianten der Lokalisierung mit Satellite Assemblies. • Den fehlenden Fallback einzelner Werte bei einer BAML-Lokalisierung darf man nicht mit dem Fallback der Cultures selbst verwechseln. 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

WPF

Silverlight

ASP.NET

Problemstellung/Situation Für die Lokalisierung von ASP.NET-Benutzeroberflächen gibt es verschiedene 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 ratsam, sich bereits in einem frühen Stadium des Entwicklungsprozesses für eine der Varianten zu entscheiden. Lösungsvorschlag: Resx-Lokalisierung Ressource-Dateien bieten die Möglichkeit, unterschiedlichste Ressourcen 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 automatisch 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 anpassen (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. • 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 entsprechenden Sprache aufgrund der Spracheinstellung des Clients aus der XML-Datei geladen. • Einfacher Export und Import für Übersetzungen. • Sprache und Übersetzungen ohne Neukompilieren erweiterbar. • Flexibel, da eigenes Format. • Eigenes Tool und Logik notwendig. • Kein Standard. • Performance.

UI DESIGN COOKBOOK

Lösungsvorschlag: Lokalisierung via Datenbank Alle Texte und lokalisierten Texte werden vollständig in einer Datenbank verwaltet. Beim Laden einer Seite werden die Texte in der entsprechenden Sprache aufgrund der Spracheinstellung des Clients direkt aus der DB geladen. • 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.

UI DESIGN COOKBOOK

6 DATENVERWALTUNG

WPF

UI DESIGN COOKBOOK

6.1 DATENSUCHE

Silverlight

ASP.NET

Problemstellung/Situation Klassische datenbankbasierte Anwendungen sind oftmals unübersichtlich 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 strukturiert sein. Der Benutzer muss durch die Bezeichnung der Suchfelder wissen, nach welchen Begriffen die Suche erfolgreich ist. Mit zusätzlichen Eingabehilfen (Thema «Formatierte Werte») kann dem Benutzer die Eingabe nochmals erleichtert werden. Link zum Thema «Master-Detail-Pattern» mit Beispielen: http://designingwebinterfaces.com/designing-web-interfaces-12-screen-patterns 56

WPF

UI DESIGN COOKBOOK

6.2 DATENEDITIERUNG

Silverlight

ASP.NET

Problemstellung / Situation Wie sollten nach einer erfolgreichen Suche die Daten editiert werden? Bei einfachen Dateninhalten kann es durchaus Sinn machen, die Daten direkt im Suchresultat zu editieren. Bei komplexen Inhalten 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 Benutzer die Details angezeigt. Mithilfe der ASP.Net FormView können diese Daten einfach dargestellt und editiert werden (ASP.NetEditierseite mit FormView ohne Stylesheet).

Abbildung 6-3: Dateneditierung einer ASP. Net-Seite (unformatiert)

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 Webanwendung ist es entscheidend, dass dem Benutzer während des Editierprozesses bewusst ist, wann die Daten geändert werden sollen. 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 Suchresultates aktualisiert angezeigt. Beim Drücken des Cancel-Buttons sollte der Benutzer wieder zum Suchergebnis zurückgelangen. 6.3 DATENERFASSUNG

WPF

Silverlight

ASP.NET

Problemstellung/Situation 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 Eingabefelder 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). 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ählen und zum nächsten Schritt weitergehen.

Abbildung 6-4: Datenerfassung einer ASP. Net-Seite 1/2 (unformatiert)

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 Eingabe sehr trivial ist, ist ein Wizard sicher nicht notwendig. Bei komplexen Datensätzen wirkt jedoch die Datenerfassung mithilfe des Wizards deutlich übersichtlicher. 6.4 DATENSUCHE

ASP.NET MVC 2

Problemstellung/Situation Der Aufbau einer ASP.Net-MVC-Seite gestaltet sich anders als in einer klassischen ASP.Net-Seite. Die Daten werden nicht über einen 60

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 werden (!), jedoch sind die Daten, die angezeigt werden sollen, jeweils in der View vorhanden. Daher sind die Möglichkeiten sehr umfangreich, 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 Eindruck machen.

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

UI DESIGN COOKBOOK

ASP.Net MVC existiert zurzeit in der zweiten Version und wird intensiv 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

6.5 DATENEDITIERUNG UND DATENEINGABE

ASP.NET MVC 2

Lösungsvorschlag Die Dateneditierung mit dem ASP.Net MVC-Pattern entspricht einem ähnlichen Design wie jenem der klassischen ASP.Net-Seite. Pro Property wird jeweils ein Label mit einer dazugehörigen Textbox 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 62

UI DESIGN COOKBOOK

ASP.Net MVC gleich aufgebaut. Sehr erwähnenswert ist das Validierungskonzept 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

6.6 SCHNELLSUCHE

WinForms

WPF

Silverlight

ASP.NET

UI DESIGN COOKBOOK

Eingabefeld und eine Suchschaltfläche angeboten werden. Die erweiterte Suche wird über ein Popup mit allen gewünschten Kriterien ermöglicht. Einen eindeutigen Treffer kann die Programmlogik direkt verwenden und z. B. zu einer Tabelle hinzufügen. Liefert die Schnellsuche hingegen keinen oder keinen eindeutigen Treffer, so wird automatisch 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 einem ihm bekannten, eindeutigen Fachschlüssel suchen möchte. Die Abbildung 6-9: Datendialog mit Schnellsuche und erweitertem Suchdialog

UI DESIGN COOKBOOK

erweiterte Suche kann zusätzlich über eine separate Schaltfläche direkt neben der Schnellsuche angeboten werden. 6.7 FORMATIERTE WERTE

WinForms

WPF

Silverlight

ASP.NET

Fachdaten in einer Applikation müssen oftmals nach bestimmten Kriterien formatiert angezeigt werden. Zusätzlich wünscht der Anwender, dass er die Eingabe nicht nur korrekt formatiert, sondern auch (teilweise) unformatiert erfassen kann.

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. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

UI DESIGN COOKBOOK

Aus diesem Grund sollte man formatierte Werte, wenn immer möglich, in der Datenhaltung ohne Format ablegen. Dies ermöglicht 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 vorgegebenen Muster formatiert werden. Dazu eignet sich die Präsentationsschicht 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 Formatierungsmö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 simples Textfeld mit nachfolgender Formatierung der Eingabe funktionieren. In diesem Fall muss der Datenwert für die Speicherung jedoch 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

6.8 DARSTELLUNG VON EINHEITEN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Ein Fachdatenformular enthält Werte mit unterschiedlichen Einheiten, die dem Sachbearbeiter unverwechselbar angezeigt werden müssen.

Abbildung 6-11: Verschiedene Varianten zur Anzeige von Einheiten

Lösungsvorschlag: Bezeichnung Als Standardlösung hat sich das Anfügen der Einheit in der Eingabefeld-Bezeichnung bewährt. In diesem Fall folgt nach dem beschreibenden 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 Eingabefeld angezeigt. Je nach Situation ist diese Darstellung angenehmer 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 Bezeichnungsfeldern 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 umständlich erwiesen, sodass sehr oft ein normales Eingabefeld verwendet 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

6.10 MASSENERFASSUNG VON GLEICHARTIGEN DATEN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Anwender möchte eine grössere Menge von gleichartigen Daten zu einer bestimmten Datenentität erfassen, ohne dabei nach jedem Wert eine Eingabebestätigung oder einen Feldwechsel ausführen zu müssen.

Abbildung 6-12: Massenerfassung von gleichartigen Daten über einen Spezialdialog

UI DESIGN COOKBOOK

Mengen kann aber über die dabei angebotene Hinzufügen-Funktionalität sehr mühsam und zeitraubend ausfallen. Soll im Arbeitsprozess eine Massenerfassung vorgesehen werden, kann hierzu eine zusätzliche Eingabemöglichkeit angeboten werden, 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 üblichen Listen-/Tabellen-Bearbeitungsfunktionen. Dieser Arbeitsschritt sollte nicht in den normalen Arbeitsdialog eingebettet werden, sondern deutlich getrennt, z. B. über einen Wizard oder mithilfe eines Popups, angeboten werden. Dem Anwender 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 andere, einfach strukturierte alphanumerische Eingaben. Unter Umständen können auch Kombinationen dieser Daten verarbeitet werden, 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

6.11 FREITEXT-KOMMENTARE

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Anwender möchte zu einer bestimmten Datenentität einen Freitext-Kommentar erfassen können.

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 Textfeld. Für die erweiterte Bearbeitung können auch spezielle Controls wie RTF-Editoren verwendet werden. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

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 Registerkarten, 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 verwendet werden, um Zugriffe über Benutzerberechtigungen gezielt zu erlauben bzw. zu verhindern. Lösungsvorschlag Popup Eine weitere elegante Variante präsentiert sich als kleines PopupFenster mit eingebettetem Eingabe- oder Editor-Control, welches über eine kleine Schaltfläche abgerufen wird. Die Schaltfläche beinhaltet in optimaler Weise ein leeres Dokumentsymbol für nicht ausgefüllte Kommentare und ein beschriftetes Dokumentsymbol für erfasste Kommentare. Dieser Lösungsvorschlag enthält die Vorteile der Registerkarten-Variante und ermöglicht deren Verwendung auch ohne ein kartenbasiertes 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 benutzt werden, personenbezogene Hinweise erfasst werden. Es sollten deshalb bereits beim Design der Applikation Überlegungen zum Datenschutz angestellt werden.

UI DESIGN COOKBOOK

7 VALIDIERUNG

UI DESIGN COOKBOOK

7.1 ALLGEMEINE RICHTLINIEN ZUR VALIDIERUNG

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Anwender möchte möglichst ohne Störungen durch die Erfassung 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 passenden Anweisungen versorgt werden.

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 Eingabefehlern 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 Eingabefehler ü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 Bildschirms zu scrollen. • Für die Konsistenz des Programmes ist es wichtig, dass möglichst die gleichen Methoden zur Anzeige der Validierungen verwendet werden. 76

UI DESIGN COOKBOOK

7.2 TEXTEINGABEN (TEXTBOX) VALIDIEREN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Anwender möchte möglichst ohne Störungen durch die Erfassung 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.

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

UI DESIGN COOKBOOK

Abbildung 7-3: Validieren Textbox mit Ballon

Lösungsvorschlag/Empfehlung Weil Texteingabefelder in der Regel nicht nur gültige Eingaben akzeptieren, 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 ignorieren 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 Anwender 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. 78

UI DESIGN COOKBOOK

7.3 ZWINGENDE EINGABE VALIDIEREN (REQUIRED INPUT)

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Anwender möchte möglichst schnell und umfassend erkennen können, welche Eingaben zwingend notwendig sind.

Abbildung 7-4: Beispiel für Anzeige von zwingenden Eingabefeldern

Lösungsvorschlag/Empfehlung Um dem Anwender anzuzeigen, welche Eingaben zwingend notwendig 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 überspringt: Nicht alle notwendigen Eingaben direkt anzeigen, aber fehCOPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

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 Hinweis: «Alle Eingaben sind zwingend». • Diese Variante verhindert einen unübersichtlichen Dialog für diesen 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

7.4 EINGABEDIALOGE MIT MEHREREN CONTROLS VALIDIEREN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Anwender möchte, dass ein Dialog mit mehreren Eingabefeldern beim Verlassen korrekt validiert wird. Da die Controls abhängige Daten enthalten, kann erst beim Verlassen des Dialogs validiert werden (z. B. OK- oder Next-Button). Lösungsvorschlag/Empfehlung Verwenden von modalen Fehleranzeigen wie «Dialogforms» oder Messageboxes für alle Fehler, die sich ereignen, wenn der Anwender 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 Fokus auf das erste Control mit falschen Daten zu setzen. Wenn notwendig ist das Control in den sichtbaren Bereich des Bildschirms zu scrollen.

UI DESIGN COOKBOOK

Abbildung 7-7: Dialog mit Validierung über mehrere Controls

7.5 ABHÄNGIGE CONTROLS ÜBER MEHRERE EINGABEDIALOGE VALIDIEREN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Anwender möchte, dass abhängige Felder über mehrere Dialoge korrekt validiert werden.

UI DESIGN COOKBOOK

Lösungsvorschlag/Empfehlung 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 Anwender 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 Fokus auf das erste Control mit falschen Daten zu setzen. Wenn notwendig ist das Control in den sichtbaren Bereich des Bildschirms zu scrollen.

Abbildung 7-8: Verwendung von Wizards zur kontrollierten Validierung über mehrere Controls und Dialoge

UI DESIGN COOKBOOK

7.6 VALIDIERUNGEN MIT WINDOWS FORMS

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation 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 erforderlich 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 beeinträchtigen könnten. Windows Forms bietet mehrere Möglichkeiten, 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 Maske 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.

UI DESIGN COOKBOOK

Die von MaskedTextBox verwendete Maskingsprache ist sehr flexibel. Sie ermöglicht es Ihnen, obligatorische Zeichen, optionale Zeichen, literale Zeichen wie Bindestriche und Klammern, Währungszeichen und Datumstrennzeichen festzulegen. Das Steuerelement funktioniert auch, wenn es an eine Datenquelle gebunden ist. Das Format-Ereignis für eine Datenbindung kann auch zum Neuformatieren eingehender Daten entsprechend der Maske und das Parse-Ereignis zum Neuformatieren ausgehender Daten entsprechend den Spezifikationen des Datenfeldes verwendet werden. Weitere Informationen finden Sie unter MaskedTextBox-Steuerelement (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 Windows-Forms-Steuerelemente integriert sind. Jedes Steuerelement, das formfreie Benutzereingaben akzeptiert, verfügt über ein Validating-Ereignis, das eintritt, sobald das Steuerelement eine Datenvalidierung erfordert. In der Validating-Ereignisbehandlungsmethode können Sie Benutzereingaben auf mehrere Weisen überprüfen. Wenn Sie beispielsweise über ein Textfeld verfügen, das eine Postleitzahl 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. 86

UI DESIGN COOKBOOK

• Wenn die Postleitzahl in einem bestimmten Format vorliegen muss, können Sie zur Validierung der vom Benutzer eingegebenen Daten 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 Format 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 regulä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 CancelEventArgs 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. Mithilfe der Validierung können Sie sicherstellen, dass die Daten des Steuerelements das Format aufweisen, das von der Datenquelle benötigt wird, und dass keine Sonderzeichen wie Anführungszeichen und umgekehrte Schrägstriche enthalten sind, die sich als unsicher erweisen könnten. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

UI DESIGN COOKBOOK

Wenn Sie die Datenbindung verwenden, werden die Daten im Steuerelement während der Ausführung des Validating-Ereignisses mit der Datenquelle synchronisiert. Wenn Sie das ValidatingEreignis 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 aufzuheben, bleibt die Datenbindung weiterhin bestehen. Um in diesem Fall eine Validierung im Validated-Ereignis auszuführen, ändern Sie die Datenquellen-Aktualisierungsmodus-Eigenschaft des Steuerelements (unter (Databindings)\(Advanced)) von OnValidation in Never und fügen dem Validierungscode Con-trol.DataBindings [„<YOURFIELD>“].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 Anforderungen 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ährend 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 88

UI DESIGN COOKBOOK

Benutzer während der Arbeit direktes Feedback zu den Daten geben möchten. Wenn Sie die implizite Validierung für ein Steuerelement verwenden möchten, müssen Sie die AutoValidate-Eigenschaft dieses Steuerelements 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 Validated-Ereignis nicht eintritt. Der Eingabefokus verbleibt beim aktuellen Steuerelement, bis der Benutzer die Daten in eine gültige Eingabe ändert. 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 bestimmten 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 Benutzeraktion 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 Steuerelemente in einem Formular- oder Containersteuerelement zu überprüfen. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

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 impliziten Validierung: Windows-Forms-Steuerelemente verfügen jeweils über unterschiedliche Standardwerte für die AutoValidate-Eigenschaft. In der folgenden Tabelle werden die am häufigsten verwendeten 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 Formular unabhängig davon schliessen können, ob die Werte in den 90

WPF

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. Dadurch wird das Formular in jedem Fall geschlossen. Weitere Informationen und ein Beispiel finden Sie unter Form.Closing. 7.7 VALIDIERUNGEN MIT ASP.NET

Silverlight

ASP.NET

Problemstellung/Situation 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 überprüfen. ASP.NET stellt eine Reihe von Validierungssteuerelementen bereit, die eine benutzerfreundliche, aber leistungsstarke Möglichkeit bieten, Formulare auf Fehler zu überprüfen und bei Bedarf Fehlermeldungen an den Benutzer auszugeben. Im folgenden Abschnitt werden die Validierungssteuerelemente und ihre Verwendung beschrieben. Validierung mit ASP.NET Die folgenden Links führen zur MSDN-Page von Microsoft, mit guten Beschreibungen und mit Beispielen und How Tos zu den Möglichkeiten der Validierung in ASP.NET

UI DESIGN COOKBOOK

ASP.NET-Validierungssteuerelemente Stellt eine Liste mit Themen für die verschiedenen ASP.NET-Validierungssteuerelemente 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-Serversteuerelemente • Gewusst wie: Programmgesteuertes Testen der Validierung für ASP.NET-Serversteuerelemente • Gewusst wie: Deaktivieren der Validierung für ASP.NET-Serversteuerelemente • Gewusst wie: Programmgesteuertes Validieren für ASP.NET-Serversteuerelemente 7.8 VALIDIERUNGEN MIT ASP.NET MVC

WPF

Silverlight

ASP.NET

Problemstellung/Situation Der Entwickler möchte mit ASP.NET MVC einfache und gut bedienbare 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 Beschreibung, wie man mit JQuery und ASP.NET MVC komfortable Dialoge erstellen kann. http://code-inside.de/blog/2009/10/12/howto-eingabenvalidierung-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

8.1 ÜBERSICHT ÜBER KOMPLEXE FACHDATEN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Komplexe Fachdaten werden oftmals über verschiedene Dialoge verteilt bearbeitet. Dem Sachbearbeiter fehlt jedoch ein schneller und aussagekräftiger Überblick über das entsprechende Fachobjekt.

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 erstellt, welcher alle Registerkarten/Module in einer extrem komprimierten Form zusammenfasst. In einem zwei- oder dreispaltigen Design werden die wichtigsten Daten in separaten Bereichen dargestellt. 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 navigieren lassen. Die Übersicht kann direkt in die verteilte Darstellung als zusätzliche Ebene integriert werden oder als eigenständiger Applikationsbereich angezeigt werden. Einige Anwender bevorzugen die separate Darstellung, da in komplexen Umgebungen das Laden der kompletten 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 notwendige 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 diesem Dialog keine Bearbeitung der Daten möglich sein.

UI DESIGN COOKBOOK

8.2 DARSTELLUNG VON KOMPLEXEN FACHDATEN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Die Applikation verwaltet sehr komplexe und umfangreiche Fachdaten 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 Einheiten bzw. Kategorien zerlegt werden. Diese für den Sachbearbeiter sinnvolle Aufteilung wird genutzt und ein Dialog mit mehreren 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 Registerkarten abgefüllt.

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, erreichen 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 Variante 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 ausblendbaren Bereichen dar. In dieser Variante werden die kompletten Fachdaten in einem einzigen Endlosformular dargestellt und die einzelnen Ebenen in ausblendbare Elemente unterteilt. Auf diese Weise kann der Sachbearbeiter genau die Ebenen geöffnet behalten, welche für ihn momentan wichtig sind. Über die Titel der Bereiche kann auf Validierungsfehler oder den aktuellen Bearbeitungszustand hingewiesen 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 Ablauf 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 beachtet werden, dass je nach Fachanforderungen ein Datensatz, der über mehrere Ebenen verteilt wurde, übergreifend mit einer einzigen 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 Validierungsfehlern von aktuell nicht sichtbaren Ebenen, das temporäre Speichern von Daten beim Seitenwechsel in webbasierten Applikationen und das komplette Verwerfen von nicht gespeicherten Daten in die Lösungswahl einbezogen werden.

100

UI DESIGN COOKBOOK

8.3 STATUS- & UMGEBUNGSINFORMATIONEN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation In komplexen Systemlandschaften, vielleicht sogar mit Diensten, welche über externe Netzwerke angesprochen werden, ist es schwierig, den aktuellen Status der Applikation zu erkennen.

Abbildung 8-5: Darstellung von Informationen in einer Statusleiste

Lösungsvorschlag Für die Darstellung von nicht kontextbezogenen Informationen wie z. B. Versionsnummer, der Benutzername des angemeldeten Anwenders, der verbundene WebServer und vielleicht sogar die aktuell 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 Informationen sind teilweise so anschaulich, dass sogar auf eine Beschreibung verzichtet werden kann und nur die Information selbst platzsparend angezeigt wird. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

101

UI DESIGN COOKBOOK

Neben den bereits erwähnten Benutzer- und Serverinformationen 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 Antwort warten, so kann diese Tatsache als Status ausgegeben werden. 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 Speicher-Funktionalität, die nach erfolgreichem Abschluss dies über die Statusleiste mitteilen kann. Einige Applikationen erlauben über die Statuszeile auch die Steuerung der Anzeige, indem zwischen verschiedenen Layouts gewählt und der Zoomfaktor bestimmt werden kann. Solche aktiven Bereiche 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 geeignet, die keine Aktionen vom Anwender erwarten. Eine Dialogbox mit einer Ja-Nein-Frage kann auf keinen Fall ersetzt werden. Ausserdem 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 mo102

UI DESIGN COOKBOOK

mentane Seite angezeigt. Die Vor- und Nachteile von sich dynamisch ändernden Informationen können dort sehr gut beobachtet werden. 8.4 LISTVIEW, ALTERNATIVE ZU GRIDS

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation 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. Sicher 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.

103

UI DESIGN COOKBOOK

Abbildung 8-6: Listentyp: Details

Abbildung 8-7: Listentyp: Tiles

Besonders interessant sind die Ansichten Details und Tile, da in diesen weitere Daten angezeigt werden können. Es lohnt sich, herauszufinden, welche Daten die Benutzer eigentlich am häufigsten brauchen, und dann nur diese darzustellen. Eine Gruppierung trägt ebenfalls stark zur Übersichtlichkeit bei. 104

UI DESIGN COOKBOOK

Bemerkungen Je nachdem kann es sinnvoll sein, auf eine einfachere Listbox auszuweichen oder eine TreeView zu verwenden. ListViews wie auch TreeView und Listbox sind vor allem zur Datenausgabe 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

WinForms

WPF

Silverlight

ASP.NET

Abbildung 8-8: Verschachtelt gruppierte Elemente

105

UI DESIGN COOKBOOK

Problemstellung/Situation 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 vorfindet, stören die Gruppen mehr als sie nützen. Lösungsvorschlag Die oben gezeigte Situation lässt sich wie folgt einfacher und übersichtlicher anzeigen. Die verschachtelten Gruppen werden aufgelöst und durch passende Abstände voneinander getrennt. Um die Hauptgruppen 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

106

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 Gruppierungen 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.

107

UI DESIGN COOKBOOK

9 ANWENDERUNTERSTÜTZUNG

108

UI DESIGN COOKBOOK

9.1 KONTEXTHILFE

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation 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.

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 Anwender 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 COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

109

UI DESIGN COOKBOOK

dadurch zu viel von der Oberfläche verdecken oder über den Rand der Applikation hinausreichen. Ausserdem werden geübte Anwender 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.

110

UI DESIGN COOKBOOK

Lösungsvorschlag Hilfe Sehr umfangreiche und bebilderte Anleitungen werden idealerweise als eigenständiges Hilfe-Dokument in einem Popup-Fenster dargestellt und über die Taste F1, einen Hilfe-Menüeintrag oder kontextspezifische Menüs einzelner Oberflächenbereiche abgerufen. Ein eigenständiges Hilfe-Dokument erlaubt eine umfassende Beschreibung der Applikation und erlaubt spezielle Bereiche der Oberfläche sehr detailliert zu beschreiben. Das Erstellen eines solchen 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. Schlussendlich bestimmt die Art der Applikation, der angestrebte Anwenderkreis und die Arbeitsumgebung die Wahl der Anwenderunterstützung.

111

UI DESIGN COOKBOOK

10 BERECHTIGUNGEN

112

UI DESIGN COOKBOOK

10.1 DATEN MIT BENUTZERBERECHTIGUNGEN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Die Applikation enthält Daten, die aus Datenschutz- oder Sicherheitsüberlegungen nur einer bestimmten Benutzergruppe zur Verfügung stehen sollen.

Abbildung 10-1: Präsentation der vollständigen Daten inklusive der ausblendbaren Bereiche

Abbildung 10-2: Präsentation ohne geschützte Daten in ausgeblendeten Bereichen

113

UI DESIGN COOKBOOK

Lösungsvorschlag für zu schützende Zusatzdaten Handelt es sich bei den zu schützenden Daten um eine kleine Untermenge 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 FreitextKommentar über ein benutzerberechtigtes Kommentar-Popup erfasst werden. Handelt es sich bei den zu schützenden Daten um eine etwas komplexere 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 dafür gesorgt werden, dass diese unberechtigten Personen als komplette Einheit nicht zur Verfügung stehen. Sollen z. B. in einer Kundenverwaltung Einträge der eigenen Mitarbeiter nur dem Supervisor angezeigt werden, den restlichen Sachbearbeitern 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 hingewiesen werden, dass eine bestimmte Anzahl von Datensätzen gefiltert wurde. Dies kann einem unberechtigten Anwender bereits relevante Anhaltspunkte geben.

114

UI DESIGN COOKBOOK

Die Gründe für eine Nichtberechtigung von kompletten Datensätzen 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üssen spezielle Vorkehrungen getroffen werden. So muss z. B. bei benutzerspezifischen Kommentaren festgehalten werden, welcher Sachbearbeiter oder welche Berechtigungsgruppe diesen konkreten Kommentar erfasst hat. Komplette Datenentitäten können über eine Sicherheitsklassifizierung oder andere gruppierende Eigenschaften für den Schutz gekennzeichnet werden. Abhängig von der Architektur der Applikation muss der Schutz der Daten bereits auf einem sehr tiefen Level der Layer angesetzt werden. Das berechtigungsabhängige Userinterface ist in vielen Fällen nicht ausreichend und dient mehrheitlich dem optimierten Anwendererlebnis.

115

UI DESIGN COOKBOOK

10.2 FUNKTIONEN MIT BENUTZERBERECHTIGUNGEN

WinForms

WPF

Silverlight

ASP.NET

Problemstellung/Situation Die Applikation enthält Daten, die aus Datenschutz- oder Sicherheitsüberlegungen nur einer bestimmten Benutzergruppe zur Verfügung stehen sollen.

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, Eingabefelder, Befehlsschaltflächen und Registerkarten in der Benutzeroberfläche komplett ausgeblendet werden. 116

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 ausgeschlossen zu sein. Lösungsvorschlag für datenabhängig geschützte Funktionalitäten Müssen Funktionalitäten abhängig von den aktuellen Daten gesperrt 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 Bedienelemente nicht ausgeblendet und nur deaktiviert, da sich die Oberfläche dem Benutzer gegenüber nicht übermässig dynamisch verändern sollte. Bemerkungen Um Funktionen über Benutzerberechtigungen schützen zu können, muss die Applikation ein geeignetes System anwenden. Besonders wichtig ist es hierbei, dass nicht nur die Benutzeroberfläche die Funktionalitäten vor unberechtigten Zugriffen schützt. Abhängig von der Architektur müssen auch darunterliegende Layer den Schutz der Funktionalitäten implementieren. Ein komplexer Berechtigungsschutz erfordert oft eine saubere Spezifikation der geschützten Funktionalitäten in den verschiedenen Applikationsteilen, den geplanten Benutzergruppen und in den verschiedenen Zuordnungen. COPYRIGHT © 2015, BBV SOFTWARE SERVICES AG

117

UI DESIGN COOKBOOK

11 ANHANG

118

UI DESIGN COOKBOOK

11.1 AUTOREN Michael Albertin Roland Gelzer Adrian Krummenacher Risto Kyburz Urs Pfirter

119

bbv Software Services AG ist ein Schweizer Software- und Beratungsunternehmen, das Kunden bei der Realisierung ihrer Visionen und Projekte unterstützt. Wir entwickeln individuelle Softwarelösungen und begleiten Kunden mit fundierter Beratung, erstklassigem Software Engineering und langjähriger Branchenerfahrung auf dem Weg zur erfolgreichen Lösung.

Beratung

Engineering

ERFOLG

Lösungen

Ausbildung

Unsere Booklets und vieles mehr finden Sie unter www.bbv.ch/publikationen

MAKING VISIONS WORK. www.bbv.ch · info@bbv.ch