Frisch abgeschlossen haben wir ein Theming-Projekt für Philips Technologie GmbH. Dass das Feedback hinsichtlich Leistung und Zusammenarbeit durchweg positiv war, ist zwar schön für uns, aber wenig nützlich für Sie, liebe Leser. Daher folgt hier ein größere Artikel dazu, warum Theming super ist, wie ein Theme gemacht wird, worauf man achten sollte und mit welchem Aufwand zu rechnen ist.

 

Was ist Theming?

Theming bedeutet im technischen HokusPokus dahinter, dass durch das Ansteuern einer entsprechende Theming-Xaml-Datei, Standard-Controls einen eigene Skin bekommen. Man spricht hier im Unterschied zu den expliziten Styles von impliziten Styles. Implizit sind diese Styles mit den entsprechenden Control-Templates dadurch, dass ein Style auf einer Control wirksam wird, nur weil die Control vom Typ einer bestimmten Controlart ist. So erhält also ein Button, eine CheckBox aber auch eine komplexe Controls wie ListViewer oder die CalenderControl eine eigene Optik, nur dadurch dass sie vom entsprechenden Typ ist. Legt also ein Programmierer dann später eine Control in eine XAML-Maske, die an dieses Theme angebunden ist, hat diese Control schon mal ein eigenes Design. Er braucht also, wenn mit Theming gearbeitet wird, weder nur mit Standard-Controls zu leben, noch irgendwelche expliziten Styles auf jede einzelne Control auf der Maske anwenden.

 

Wie haben wir das Theme erstellt?

Die Grundlage zur Erstellung des Themes waren Screendesigns der Komplett-Applikation im Illustrator. Daraus haben wir die verwendeten Controls abgeleitet und erst mal im Illustrator ein kleines Set angelegt. Fehlende Standardcontrols haben wir noch hinzu designed, damit der Kunde, wenn er später noch etwas na die Applikation anstricken möchte, alle Möglichkeiten hat.

Das Volumen der Standdard-Controls, die ein Theme abdeckt, hängt von ein paar Faktoren ab:
Silverlight oder WPF. Version 3 oder 4. Ohne zugeladenene Toolkits oder mit.
Die größtmögliche Menge an zu skinnenden Standardcontrols ergibt sich in WPF 4 mit Toolkits. Die erheblich kleinere in Silverlight 3 ohne Toolkit. Das gilt es vorher in den Anforderungen zu definieren. Unsere Aufgabe war Silverlight mit ein paar Toolkit-Controls und noch on top ein paar impliziten Styles sowie das Skinning einiger UserControls.

 

Anlage der Designfiles

Dieses Basisset haben wir dann auch noch in allen States durch dekliniert, damit nicht nur der Normalstate, sondern auch alles weitere abgedeckt ist. Die States sind zumeist Normal, MouseOver, Pressed, Disabled. Dann kommt noch der Fokus-Visual Style dazu und der Fehler-Meldungstyle. Viele Controls haben auch noch Selected States, Checked oder ähnliche Anzeichen der Unterscheidung  zwischen “ist ausgewählt oder nicht”. Da die States bekannter Maßen ein Teil der einzelnen Control sind, macht es Sinn, sich über die Optik im Vorfeld Gedanken gemacht zu haben und sie schon im Design entsprechend zu deklarieren. Die Styles in einer zweiten Welle zu behandeln oder unvollständig zu sein, ist Zeitverschwendung. Bei Designen ist die Konsistenz der Elemente auch zueinander und innerhalb ihrer Aktivierungsstates sehr wichtig aus zwei Gründen: Erstens mögen die Benutzer Konsistenz und finde sich besser zurecht in konsistenten Applikationen. Zweitens sind die Standard-Controls auf die im Theming aufgesetzt wird, sehr schlau gestrickt und bedürfen für eine korrekte Umsetzung schon im Design einer Einzel-Control-Übergreifenden Denkweise.

 

Technische Grundanlage

In der XAML-Umsetzung ist es so gelaufen, dass die Entwicklung als Basis ein sehr geniales Setup angelegt hat. Für die Umsetzung in XAML wurden zwei kleine Solutions in ein Projekt gepackt und in einer XAML-Maske eine Tabelle eingesetzt, die in zwei Spalten geteilt ist. In beiden Spalten lag ein Stackpanel, in die die Blenderin einfach die Controls rein arbeiten konnte. In der einen Spalte ist das Theme wirksam, in der anderen nicht. Das heißt, dass in der einen Spalte klassische mausgraue Standard-Controls-Abgelegt wurden, in er anderen die gestalteten.

Die Grundlage des Designs im XAML war eine Anlage der verwendeten Farben und Verläufe. Die Schriften wurden eingebunden  und aus den verschiedenen Einsatzarten dann eine Typoset gestrickt, das eine Standard-Schrift-Definition aufwies und diverse Styles die zweckgebunden sind wie z. B. Headline, Subline usw. Diese Textstyles müssen dann bis auf die Standards und die in den Standardexplizit gesetzt werden. Gleiches habe ich auch mit grafischen Layout-Elementen gemacht. Diese wurden als Flächen mit entsprechenden expliziten Styles versehen, die die Entwickler beim Kunden dann nur noch zuweisen mussten. So bleibt eine optische Konsistenz gewahrt und der Code bleibt klein.

Umsetzung des Designs in XAML erfolgte so, dass wir die Standard-Controls auf die Bühne geholt habe, eine neuen Style durch Anlegen einer Copy des Standards erzeugt habe und diesen komplett auf das neue Design angepaßt haben. Innerhalb von Blend haben wir uns durch die Styles gehangelt und alle Properties gesetzt, die von oben definitert wie z. B. Farben, Größe usw. werden konnten. Dann sind wir in die Templates gegangen und haben dort das strukturelle Design angelegt. In der nächsten Instanz haben wie die States (MouseOver, Pressed, Disabled usw.) bearbeitet und die jeweilige Designs angelegt. Also Krönung haben manche die Controls noch Animationen bekommen.

Nicht alles kann man mit Standard-Controls abdecken. Da aber die Grundlagen durch das Theme und die expliziten Styles schon gelegt waren, ist es schlussendlich relativ leicht gewesen auch individuell von den Entwicklern angelegte User Controls entsprechend mit Design, einem eigenen passenden Style und Template zu versehen, weil das eine auf dem anderen basierte.

Also besonderes Bonbon an den Kunden hat Lars noch ein Control programmiert, die es so in Silverlight eigentlich nicht gibt. Dummerweise sehen Silverlight-Buttons ein Ändern der Vordergrundfarbe eines in den Content integrierten Vektors nicht vor wie man es von WPF kennt. Man hätte eigentlich viele Buttonsstyle machen müssen, wenn man Icon-Buttons mit einer Umfärbung beim Statewechsel haben will, was uns aber nicht gefielt. Dadurch, dass wir ein bisschen im C# gestrickt haben und die Grafik die XAML-Übersetzung des Vektorpfades in den Content gepackt hat – als Text quasi –  konnte hier ein schöner universeller Iconbutton gemacht werden.

 

Wo lag der Aufwand?

Insgesamt knapp 12 Tage haben wir für dieses Theme gebraucht auf der XAML-Seite. Wenn dem natürlich noch ein Entwurf zugrunde liegen soll, käme das noch als Posten hinzu – als CI-gerechtes Theme kaum höher als bei 5 Tagen. Das kann man dann auch noch in einen Styleguide gießen für alle Zukunft, was 3-5 Tage Aufwand je nach Detailgrad darstellt. Der Kosten-Nutzen-Effekt sowie auch der Verkürzen von Timelines in der Produktionszeit durch die Nutzung von derart individuellen Standards (verrücktes Wort) ist also sehr hoch. Auch auf die Qualität hat es sowohl optisch als auch in der Programmierung gute Auswirkungen, da sich Entwickler nicht als Grafiker versuchen müssen und andererseits Grafiker sich nicht im Code austoben. Fragt man also nach dem Nutzen, ist der auf allen drei Ebenen des magischen Dreiecks Kosten-Nutzen-Qualität sehr hoch.

 

Aber Vorsicht:

Theming ersetzt nicht Konzeption, Usability, Mood-Entwicklung und Layout. Aber es macht das Leben halt nur leichter, weil man sich um das Thema CI-gerechter Controls in hoher grafischer wie programmatischer Qualität nicht mehr kümmern muss.