Eigentlich alles ganz einfach, oder? Nein. Anscheinend nicht. Usability aus dem Alltag.

Für mich ist  dieser Parkticket-Automat (aufgenommen auf einer kleinen kroatischen Insel) ein wirklich gelungenes Beispiel dafür, wie problematisch Usability sein kann. Wen auch immer ich dabei beobachtet habe, wie er ein Parkticket lösen wollte: keiner machte es auf Anhieb richtig (auch ich war erstmal stutzig, das gebe ich zu)  egal woher er kam. Eigentlich ist alles ganz einfach und eigentlich steht alles da. Trotzdem hat man damit seine Probleme? Wie kann das sein?

Eine wesentliche Information ist auf diesem Bild vielleicht nicht zu sehen: Unterhalb der Piktogramme findet sich ein langer, natürlich auf Kroatisch verfasster Text mit Hinweisen zu den Kosten. Der Tourist macht genau, was jeder erwarten würde: er hangelt sich mühsam und ohne ein Wort zu verstehen, durch diesen Text bis hin zur wertvollen Information: pro Stunde 5 Kuna und legt los. Die Piktogramme werden dabei … übersehen!

Das erste Problem: wir sind es offenbar nicht gewohnt, einen solchen Prozess starten zu müssen. Egal ob Parkautomat oder Parkuhr (gibts sowas noch?): Geld rein startet “ich kauf mir ein Ticket”. Die meisten Leute versuchten auch genau das, ohne vorher Start zu drücken. Dann allerdings passiert nichts, - das Geld wird einbehalten, man muss Cancel drücken.

Das zweite Problem, eher technisch: das Display steht so ungünstig zur Sonne, das man kaum etwas lesen kann. - Hier geht es weiter auf Kroatisch, man erfährt, wie lange man für das bereits eingeworfene Geld parken darf. Sobald das so passt, beendet man mit Stop (für Ticket-Drucken).
Das nächste Problem: Start und Stop sind auf einem einzigen Knopf belegt. Schlimmer aber noch: dieser Knopf ist grün umrandet. Grün für Stop? Nee… Da dies gegen wirklich alle Konventionen verstößt, führt es wohl auch dazu, dass die meisten Menschen, die ich beobachtet habe, zunächst an dieser Stelle auf Cancel drücken - und  von vorne anfangen dürfen.

Nein - keiner hier war zu dumm, zu begreifen, wie es funktionieren würde. Die ungewohnte Kombination aus Knöpfen, deren Anordnung und deren Beschriftung, der vorgegebene Ablauf und die notwendige Aufnahme zusätzlicher Information in einer fremden Sprache ist das Problem.

Ich glaube, es gibt hier etliche, die einfach frustriert aufgeben. Als ich den Automaten gestern fotografiert habe (genau für diesen Artikel), schien er kaputt. Leider war auch das nicht sofort ersichtlich - das Geld wurde nämlich einbehalten, man bekam es erst via Cancel wieder zurück. Das hat dann auch jeder verstanden, nur leider erst nach einigen frustrierenden Fehlversuchen.

Mir sagte dann jemand, das sei doch alles nicht so schlimm. Beim zweiten Mal wisse man es ja. Das ist verständnisvoll gemeint und stimmt auch (nachdenken muss man allerdings auch beim zweiten Mal noch!). Nur leider haben wir bei vielem, wo es ebenso und noch mehr auf Usability ankommt, keine zweite Chance (das mag eine Website genauso sein wie ein Produkt), können uns nicht auf das Verständnis der User verlassen und haben dadurch sicherlich mehr Verlust als ein paar Kuna täglich.

Im Moment beschäftigen wir uns viel mit einem wirklich wunderbaren Magnet-Spielzeug. Es besteht aus kleinen Kugeln und aus verschiedenfarbigen, transparenten Dreiecken und Quadraten mit jeweils magnetischen Ecken.

Man kann damit nicht nur interessante Gebilde bauen (und dabei -wenn man 6 Jahre alt ist- beispielsweise lernen, dass es gleichseitige und gleichschenklige Dreiecke gibt und welche geometrischen Körper man damit bauen kann), die Bauwerke geben auch ein tolles Fotomotiv ab, mit dem ich nach diesem Foto noch nicht am Ende bin.

Es passiert, dass sich genau an dieser Stelle für den Webmacher die Frage stellt: Setzen wir mit diesen neuen Anforderungen überhaupt aufs richtige CMS? Wäre ein Wechsel das Richtige?

Ich möchte diese Frage, die sicher jedem mal unterkommt, an einem Beispiel durchüberlegen.

Das IST und die Anforderungen

Bisher stand nicht zur Debatte, das System zu wechseln. Es gibt jedoch einige ganz grundlegende, zusätzliche Anforderungen an die neue Website: neben dem Layout, das ich an dieser Stelle zunächst außen vor lassen möchte, und der nötigen Umstrukturierung von Inhalten, das ich auch für ein geringes Problem halte, geht es vor allem um folgende große Themen:

• Die Website soll mehrsprachig werden, wobei mehrsprachig in diesem Fall wirklich international ist und fast den gesamten europäischen Sprachraum abdeckt
• Es soll Mitglieder geben, die von nicht-registrierten Benutzern nach verschiedenen Kriterien gesucht und gefunden werden sollen
• Gleichzeitig gibt es ein Dokumentenmanagement, das in Zukunft mehr genutzt werden soll, insbesondere auch im Hinblick auf geschützte Dokumente.
• Insgesamt wünscht man sich ein suchmaschinenfreundlicheres Konzept (wobei ich hier mal alle Aufgaben hinsichtlich des Inhalts zunächst außer Acht lasse)

Das alles bedeutet in diesem Fall:

• Komponenten auswählen, die in sich stimmig zusammenarbeiten
• Komponenten konfigurieren, gegebenenfalls bei bekannten Stolperfallen
• gegebenenfalls Layout-Anpassungen im Detail

Was nun, wenn es alternativ ein System gibt, das alle diese Funktionen bereits mitbringt? Ist ein Wechsel sinnvoll und rechnet er sich?
Was bedeutet ein CMS-Wechsel allgemein und im Speziellen, vor allem aber: wie berate ich einen Kunden, denn der entscheidet?

Pro und Contra CMS Wechsel

Ein CMS Wechsel hat immer erstmal zwei recht offensichtliche große Nebeneffekte, im Wesentlichen wirken diese erst einmal nachteilig:

• Inhalte wollen migriert werden
• Nutzer wollen geschult werden

Die positiven Faktoren (man kann nicht behaupten, es handle sich bei den oben genannten Notwendigkeiten um etwas, das der Websitebetreiber ohne Bedenken gerne in Kauf nimmt), hingegen sind zum Teil langfristige Benefits, die abgewogen werden wollen, insbesondere, wenn sich wie hier eine Kann-Situation auftut, jedoch keine Notwendigkeit zum Systemwechsel:

• die Entwicklungskosten können sinken (sie müssen nicht!), trotz Migration von Inhalten
• die Stabilität des Systems und damit die Nachhaltigkeit der Website können zunehmen
• Qualitätssicherung kann einfacher werden
• die Laufzeitkosten können sinken

Im Speziellen habe ich natürlich vor allem die Aufgabe, eingehend und objektiv zu beraten (wissentlich, dass es gerade mit der Objektivität so eine Sache ist). Man kommt zunächst nicht umhin, genau die angesprochenen Themen wie Migration und Schulung anzusprechen. Neben diesen natürlich durchaus kritischen Aspekten kann man aber im Idealfall mit einigen vernünftigen Pros aufwarten.

Eine Demonstration des gewünschten, neuen Systems kann dabei helfen, potenzielle Bedenken zu überwinden und im Vergleich die Benefits eines Systemwechsels herauszustellen. Hier gibt es neben rein technischen und finanziellen Überlegungen sicherlich auch “weiche” Faktoren wie Look & Feel oder Bedienbarkeit.

Konkret

Konkret ging es in diesem Fall darum eine bestehende Joomla Website zu erweitern oder dabei einen Systemwechsel vorzunehmen (vielleicht war das schon zu erahnen). Ich habe lange darüber nachgedacht, ob ich meinem ersten Impuls Contao nachgeben sollte oder es doch lieber sein lassen und mich der Herausforderung Joomla stellen sollte. Ich habe mich schließlich dazu entschlossen, den Systemwechsel doch zum Thema zu machen, weil ich es neben dem ersten Implus aus verschiedenen Gründen für die richtige und langfristig erfolgversprechendere Lösung halte.

• Contao kann mehrsprachige Websites problemlos und hat alles on Board, zusätzlich zu einigen Drittanbieter-Erweiterungen, die sich nahtlos integrieren.
• Mitglieder und Mitgliedergruppen sind bei Contao kein Problem, weil auch on Board und allein schon die Mitgliederliste tut ihr Übriges.
• Der Schutz von Seiten, vor allem eine zielgruppenorientierte Adressierung von Inhalten ist in Contao einfach nur elegant machbar
• Über Suchmaschinenfreundlichkeit als Basis braucht man sich bei Contao so wunderbar keine Gedanken zu machen.

Es ist in diesem Fall also damit zu rechnen, dass die Integration der einzelnen Komponenten mit Contao (in diesem Fall also einfach eine Frage der Contao-Konfiguration plus einiger kleiner Drittanbieter-Helferlein) relativ zügig machbar sein sollte. Ein Pluspunkt? Natürlich kommt es auf die Erfahrung an, die man bereits mitbringt.

Es bleibt vor allem eines, das es im Vorfeld zu planen gibt: der Umzug eines bestehenden Systems mit - sagen wir - durchschnittlich vielen Inhalten (die Übersetzung der Inhalte und die Pflege dieser Übersetzungen ist ein separater Schritt). Da gleichzeitig so oder so eine Umstrukturierung der Inhalte notwendig wird, sehe ich kaum Chancen für einen automatisierten Prozess, dafür aber die Chance, mit einem aus HTML-Sicht technisch und semantisch einwandfreien System zu starten.
Dann wären da noch die verschiedenen Typen von Joomla-Usern. Auch die wollen umgezogen werden. Hier ist es je nach Datenmenge durchaus eine Überlegung, eine Routine zu schreiben, die  aus den Joomla Daten die nötigen Contao Daten erzeugt.

Ich freue mich jedenfalls auf diese Aufgabe und werde sicherlich über einzelne Schritte dieses Prozesses berichten.

Das Schöne: es gibt kaum etwas zu beachten!

Die Ausgangssituation

Aus welchen Gründen auch immer: die Website, um die es geht, nutzt das CSS-Framework weitestgehend gar nicht. Ich habe meine eigenen fe_page Vorlagen für einzelne Seitenlayouts, ich habe CSS-Dateien, die ich nicht über das Seitenlayout sondern über die Vorlagen per Link einbinde. Und ich habe eine Menge eigener Layoutpositionen.
Ansonsten verbirgt sich hinter der Website ein ganz normales TYPOlight und das muss nun endlich zu Contao werden.

Backup…

Erster Schritt: Backup. Die Backup-pflichtigen Dateien bleiben die üblichen Kandidaten:

• das templates-Verzeichnis
• das Verzeichnis tl_files
• die Konfigurationsdateien unter system/config

Also bitte nicht vergessen!

Vorbereitungen

Meine wesentliche Nebenbedingung des Updates ist, die Website so kurz wie möglich offline zu haben. Das erreiche ich mit ein paar Vorbereitungen, die in diesem Fall allerdings besonders wichtig sind:

Eigene Seitenvorlagen

Meine fe_page_x - Templates sind zunächst das Wichtigste: Da sich diese Vorlage seit Contao 2.9.0 geändert hat, sind hier Änderungen nötig, beispielsweise was die Einbindung von Mootools oder Google Analytics betrifft. Ich hatte das damals schon recht simpel gemacht, indem ich den Header der Standard fe_page mehr oder weniger übernommen habe. Das kann ich nun wieder machen, nur die eigenen Stylesheets werden separat eingebunden, so wie es vorher auch war. Die Google Analytics werden inzwischen über ein Template eingebunden, auch das muss natürlich angepasst werden: die passende Java-Script Anweisung am Ende vor body kann einfach gelöscht werden, das erledigt jetzt die Anweisung <?php echo $this->mootools; ?>.

Nochmal im Einzelnen:

• Die Pfade auf individuell eingebundene Stylesheets müssen erhalten bleiben
• Die Einbindung von Mootools wird aus der neuen Vorlage fe_page übernommen
• Google Analytics werden nun über die Vorlage moo_analytics.tpl eingebunden

Optional: Google Analytics

Neu ist seit Contao 2.9.0 das Handling von Google Analytics. Wer das nutzen möchte, muss zwangsläufig das Template moo_analytics an seine Gegebenheiten anpassen und dort seine eigene Tracking ID eintragen. Wie das geht, steht direkt im Template beschrieben.

In der Zeile 16

_gaq.push(['_setAccount', 'UA-XXXXX-X']);

muss UA-XXXXX-X lediglich durch die eigene Tracking ID ersetzt werden. Es kann losgehen.

Ein Templates-Verzeichnis fürs Theme

Meine bestehenden und neuen Templates(auch das neue moo_analytics) lege ich bereits vor dem eigentlichen Update auf dem Live System in ein Unterverzeichnis von /templates ab und benenne es nach meinen Wünschen.

Update über die Live Update ID

Es gibt kaum Gründe für ein manuelles Update, denn das Update mit der Live Update ID geht derartig schnell, dass sich die paar Euro im Jahr auf jeden Fall lohnen.

Es gilt also lediglich, in den System-Einstellungen den Update-Button zu klicken und die Routine durchlaufen zu lassen. Zum Schluss muss lediglich noch das durch Contao automatisch neu angelegte Theme wissen, woher es die Templates beziehen muss. Diese Konfigurationseinstellung nimmt man direkt im Theme selbst vor.

Das war es dann auch schon! Das Update dauert weniger als 30 Sekunden und das neue Theme ist auch schnell konfiguriert. Kleiner Hinweis: Wer das Skript für Google Analytics eingebunden hat, loggt sich nun noch schnell im Backend aus, um zu überprüfen, dass auch das funktioniert hat.

Update manuell

Beim manuelle Update ist die Datensicherung, also das Backup, noch wichtiger.

Man kann es sich einfach machen und einfach ein entzipptes Contao 2.9.1 (derzeit aktuell) einspielen und dabei alle bestehenden Dateien schlicht überschreiben.
Der nächste Schritt ist dann natürlich, die vorab gesicherten Konfigurationsdateien wieder auf den Server zu laden und auch zu überprüfen, ob noch alle Templates und die Dateien unter /tl_files noch alle verfügbar sind. Idealerweise hat man auch in diesem Fall wie unter “Vorbereitungen” beschrieben bereits die neuen Seitentemplates erstellt und in einem Unterverzeichnis von /templates abgelegt.

Dann geht es in die Installationsroutine unter http://www.meineDomain.de/contao/install.php. Hier gilt es nämlich noch, die Datenbank zu aktualisieren.

Das sollte es dann auch hier gewesen sein: aus TYPOlight ist Contao geworden, die Website ist aktuell.

Fazit

Die Situation “TYPOlight/Contao ohne CSS-Framework” ist nahezu identisch mit Szenarien, in denen die Website eines oder mehrere eigene Templates nutzt (eine Standardsituation also) und gestaltet sich ingesamt unkompliziert.

In jedem Fall wird beim Update automatisch aus Modulen, Seitenlayouts und CSS-Stylesheets ein Theme - es bleibt die Konfiguration des Themes selbst und die Anpassunge der Seiten-Templates. Das einzig wirklich Wichtige ist die Vorab-Überprüfung und die Anpassung eigener Templates und zur Zeitersparnis das Hochladen auf den Server, bevor man mit dem Update beginnt.

Meine “unabhängige” Konfiguration garantiert mir beispielsweise, dass ich CSS-Stylesheets über einen Editor wie Coda problemlos und bequem bearbeiten kann, was mir vielleicht etwas Zeit spart. Mehr aber auch nicht. Ich überlege daher, ob es nicht jetzt an der Zeit ist, das Layout umzustellen und lieber doch komplett auf das Contao-Framework zu setzen. Ich habe in diesem Fall verschiedene Seitenlayouts und kann mir seit Contao überlegen, ob das nicht ein Fall fürs Theme ist.

Wenn ich Lust habe, meine CSS-Stylesheets nun doch übers Backend zu verwalten, kann ich sie einmalig importieren und muss danach lediglich sicherstellen, dass ich die Einbindung der Stylesheets in meinen Seiten-Vorlagen noch anpasse.
Um auf die Standard fe_page zu setzen, blieben natürlich eine Menge weiterer Aufgaben.

Dass Contao so robust gegenüber individuellen Alleingängen ist, ist für mich wieder einmal eine Bestätigung dafür, dass ich auf das richtige CMS setze.

Keine Angst jedenfalls vor dem TYPOlight zu Contao Update: es geht schnell und lohnt sich!

Ich hatte irgendwie, ohne auf das Wetter schimpfen zu wollen, gar nicht mehr damit gerechnet, diesen August noch ein sommerlich-sonniges Foto hinzubekommen.

Dank unserer ungefähr 2,50 Meter hohen Sonnenblume (ein wirklich riesiges Exemplar) und den ersten Sonnenstrahlen seit Tagen wurden es dann doch noch was.

Was gibt es dort zu lesen?

Natürlich freue ich mich zunächst mal über jeden, der sich für das Contao Praxisbuch interessiert. Wer gerne ein bisschen reinschnuppern möchte, findet dort beispielsweise ein kommentiertes Inhaltsverzeichnis oder kann sich Inhaltsverzeichnis wie auch die ersten beiden Kapitel direkt als PDF herunterladen.

Mit einem Blog zum Buch habe ich mir ein weiteres Blog-Projekt aufgemacht: Hier soll es vor allem ums Buch gehen, aber natürlich auch um Contao. Noch ist es dort etwas leer, aber in Zukunft möchte ich dort auch das ein oder andere Thema aufgreifen, das das Buch ergänzt - beispielsweise rund um Layout und Themes.

Eine andere Sache liegt mir sehr am Herzen: die Erweiterungen. Contao ist kein CMS, für das es tausende Erweiterungen gibt. Das ist gut so, denn irgendwo muss die Qualität leiden (so meine Erfahrung mit einem anderen großen CMS) und vor allem werden viele Erweiterungen nicht benötigt, weil Contao das sowieso schon kann.
Ich habe wiederholt die Erfahrung gemacht, dass gerade Einsteiger einfach mal installieren und probieren. Das ist ebenfalls gut so, denn nur so lernt man, aber wenn eine Site online geht, wird es Zeit auszumisten und wenn eine Site aktualisiert wird, ist es Zeit, seine Erweiterungen zu überprüfen. Gerade das geht schnell unter. Daher ein Thema, das ich mir vorgenommen habe: Erweiterungen. Insbesondere, weil ich durch den Switch vom TYPOlight zum Contao Praxisbuch nicht mehr sicherstellen konnte, dass alle von mir beschriebenen Erweiterungen bereits mit der Contao 2.9.0-1 mitgezogen haben und darüber etwas auf dem Laufenden halten möchte.

Ihr seht schon: ich habe mir viel vorgenommen…

Im Moment gibt es noch keine Kommentar-Funktion - ich werde die aber auf jeden Fall aktivieren, weil mir das Feedback meiner Besucher wichtig ist. Insgesamt wird die Seite natürlich wachsen, - jetzt aber muss erstmal das Buch herauskommen und das wird laut Verlag wohl nächste Woche soweit sein.

Naja - und dann freue ich mich insgesamt auf Feedback zum Buch, denn egal wie die Kritik ausfällt, kann man nur so besser werden!

Vielleicht lesen wir uns ja dort? Es würde mich freuen! Wenn das Buch kommt, bin ich allerdings erstmal weg. Es sind Ferien, die Kinder wollen Action und das Meer ruft… Danach kommt dann mit neuem Elan eine weitere meiner Websites dran: medanova bekommt nicht nur einen neuen Anstrich, sondern endlich auch ein paar neue Inhalte. Ich bin schon dran ;-)

Da war ich dann doch etwas verwundert, …
…als ich kürzlich ein Word Dokument unter Version 2007 als HTML speichern musste (ich weiß, ich weiß, das macht man nicht, ich war auch nicht am HTML eines großzügig mit seltsamen Formatierungen ausgestatteten Word Dokuments, sondern an den vielen im Word eingebundenen Bildern interessiert, die ich mir nicht mühsam herausziehen wollte) und mit diesem Warnhinweis konfrontiert wurde…

Na gut, sicher ist sicher… oder nicht?
Und ich erschrecke fast ein wenig, finde ich doch gerade in den webbigen Untiefen in irgendeiner Statistik, dass der eine Browser noch einen Anteil von 0.2%, der andere sogar von 1.1% haben soll!? Aber was sagen uns solche Statistiken schon… Mit den aktuellen Zahlen ist es gar nicht so einfach.

Es war am 30. Juni 2009 als ich das Angebot bekam, ein Buch zu schreiben und es dauerte nicht lange, bis ich anfing, mir Gedanken zu machen, Ideen zu sammeln und Konzepte zu entwickeln. Im Nachhinein kann ich nicht sagen, was von diesen Anfängen übrig geblieben ist. Aber hinter mir liegt ein Jahr, in dem ich viel gelernt habe, vor allem aber: ein Buch zu schreiben macht Spaß und ist eine großartige Erfahrung!

Von Seiten

Anfangs habe ich gerechnet: wie viele Seiten pro Tag muss ich schreiben, damit ich “hinkomme”und wie kann ich in der Zwischenzeit die Kinder und den Job organisieren? Eine sinnlose und vor allem wenig realitätsnahe Überlegung. Geschrieben habe ich manchmal wochenlang gar nichts, dafür an anderen Tagen zig Seiten - in diesen Wochen allerdings habe ich viel gedacht. Manchmal hat meine Umgebung gar nicht gemerkt, dass ich schreibe, manchmal haben um mich herum wohl eher alle geflucht (wobei ich das innerhalb einer Schreiborgie gar nicht so realisiert habe oder es vor allem meine Mutter geschickt schaffte, alles von mir abzuwenden, was hätte störend sein können).

Schreiben, das habe ich gelernt, kann man nicht auf Knopfdruck. Oder anders: ich bewundere jeden Autor, der das Schreiben zum Beruf gemacht hat, denn der muss sich ständig motivieren und ständig an seiner kreativen Ader arbeiten. Andererseits: Wenn man im Schreiben ist, kommt dabei oft mehr heraus als man vorher für möglich gehalten hätte. Als Freelancer ein Buch zu schreiben, hat in gewisser Weise Vorteile: ich habe mir Auszeiten genommen, wenn ich das für richtig gehalten habe. Eine Gratwanderung, denn für Auszeiten von 3-4 Tagen muss man erstmal alles Jobtechnische abgearbeitet und keine Baustellen offen gelassen haben.

Buchschreiben: Das erfordert Planung, Disziplin und vor allem viel, viel Ruhe… Es ist müßig zu sagen, dass das alles sowieso nicht so klappt.

Von Emotionen

Manchmal befällt einen beim Schreiben die Angst. Kann ich das? Ist es wirklich gut? Verständlich? Sachlich genug und trotzdem peppig? Nicht zu flapsig, aber auch nicht zu trocken? Man ist mehr auf Feedback angewiesen, als man es vielleicht wahr haben möchte. Natürlich möchte man gute Kritik. Irgendwann lernt man aber, wie wichtig sachliche und auch negative Kritik ist, denn es gibt Momente, in denen man sich verrennt oder gefangen ist, in seinem eigenen Denken, das ja nicht unbedingt dem der Leser entsprechen muss.
Und manchmal befällt einen eine ganz wichtige Routine. Klar. Wieder die Systematik der letzten Kapitel in Varianten, wieder eine dieser so oft durchdachten Ideen. Screenshots hiervon und davon.
Und dann gibt es noch die Euphorie. Es klappt gerade prima. Die Sätze hacken sich wie von selbst in die Tasten, man hat neue Ideen und man möchte alles, aber auch alles noch irgendwie unterbringen.
Daneben steht dann die Realität: nein, es muss ein Ende haben, das Buch kennt eine Grenze. Und es soll ja auch noch die Möglichkeit für eine zweite Auflage geben ;-)

Wer schreibt, darf sich durchaus mal von Emotionen leiten lassen, aber nicht zu viel.

Vom Endspurt

Was ich ganz klar unterschätzt habe, war das Finish und hier waren die beiden Varianten, einmal als TYPOlight und einmal als Contao vielleicht sogar hilfreich: beim zweiten Mal war ich wesentlich cooler. Insgesamt jedoch dauert der Endspurt. Ich habe das Manuskript ausgedruckt, wieder ausgedruckt und allen möglichen Menschen zum Lesen gegeben. Ich habe begonnen, mir alles zu Herzen zu nehmen und über alle Aspekte nachzudenken. Allein, das fertige Buch noch einmal Korrektur zu lesen, dauert einfach seine Zeit - und es finden sich immer noch Kleinigkeiten. Hier ein Komma, da ein “e” zuviel und lauter solche Sachen, die Word mit seiner Auto-Korrektur nicht findet (Danke an meine Korrektorin!). Dann wollen alle Stichwörter fürs Inhaltsverzeichnis nochmal überprüft werden. Man muss jedes Bild noch einmal ansehen. Und so weiter.

Jede Phase eines Buchs will organisatorisch geplant sein, - auch wenn von vorneherein klar ist, dass diese Organisation immer wieder spätestens mangelnder Kreativität zum Opfer fallen wird.

Von Familie

Was ich aber vor allem beim nächsten Buch mehr ins Kalkül ziehen würde, ist die Reaktion meiner Umwelt. Vielleicht ist es ja ein Irrsinn, alleinerziehenderweise mit drei Kindern im Schlepptau ein Buch schreiben zu wollen? Ich wollte das unbedingt (wie hat Frau Rowling mit Ihren Harry Potters das nur gemacht?). Erst spät habe ich gemerkt, wie “Mama, schon wieder dein Buch” zu einem fast geflügelten Wort geworden ist und ich manchmal schon selbst nicht mehr genau wusste, wie ich das eigentlich tagtäglich so hinbekomme. S. sagt, ich sei mit und ohne Buch ein anderer Mensch… Ich freue mich unheimlich, dass meine Kinder mich so unterstützt haben und so verständnisvoll waren. Dieser Tage war letzter Schultag in Bayern. Wir werden jetzt alles nachholen und ich freue mich drauf!

Ich konnte mir des Rückhalts meiner “Leute” sicher sein. Das ist wichtig. Nicht nur wegen der Belastung sondern auch, weil man oft jemanden zum Anlehnen braucht! Es ist einfach gelegentlich anstrengend.

Und von Erleichterung

Tja. Der Drucktermin naht. In der zweiten Augusthälfte kommt das Buch heraus. Wann, das weiß ich noch nicht genau, auch wenn es mich natürlich wahnsinnig neugierig macht und ich Druckerei und Lieferanten gerne anschieben würde. Ich freue mich darauf, das Buch in Händen halten zu dürfen. Sicherlich fallen mir sofort Dinge ein, die ich bei einer weiteren Auflage anders machen würde… ich kenn mich doch. Aber erstmal hoffe ich natürlich, dass es meinen Lesern gefallen wird. Im Moment bin ich nur einfach glücklich! Ich habe es geschafft!

Eine Website zum Buch wird es übrigens geben, an der ich ab dem Wochenende intensiv arbeiten werde und außerdem wird die Beispielwebsite aus dem Buch auch im Web verfügbar sein. Beides gibt es passend zum Erscheinungstermin.

Ja! Ich würde übrigens (wenn auch nicht sofort) auf jeden Fall ein weiteres Buch schreiben. Es hat wirklich Spaß gemacht. Spaß gemacht zu lernen, nachzudenken, immer zu wissen, dass man anderen etwas geben kann und seine Ideen in die Tat umzusetzen. Ich habe gelernt, mit allen Herausforderungen umzugehen, die ein solches Mammutprojekt neben Job und Familie so mit sich bringt. Ich bin sicherlich ein bisschen gewachsen und freue mich jetzt schon darauf, meine bisherigen und kommenden Erfahrungen in ein nächstes solches Projekt zu stecken!

Worauf ich mich jetzt freue? Endlich wieder mehr Zeit für meine Familie, für meine Kinder, ein bisschen mehr Freizeit, aufs Fotografieren, aufs Lesen und aufs Bloggen!

Hinter mir liegt mehr oder weniger ein ganzes Jahr Arbeit, über 600 Seiten Manuskript und ein Buch, das bereits schon einmal fast so weit war wie heute und damals noch den Namen TYPOlight Praxisbuch trug - so lange ist das übrigens noch gar nicht her.
Leo Feyer und sein Contao Team haben zur Umbenennung des Systems von TYPOlight in Contao wirklich tolle Arbeit geleistet: vieles ist noch benutzerfreundlicher geworden und mit den Themes kommen natürlich ganz neue Möglichkeiten dazu. TYPOlight ist als Contao ist erwachsen geworden. Und das in einer Wahnsinnsgeschwindigkeit.

Ich freue mich jetzt erstmal über meinen ganz persönlichen, kleinen Erfolg, ein Buch über dieses wunderbare System geschrieben zu haben und bin natürlich sehr gespannt auf alles, was da kommen möge.

An dieser Stelle ist jetzt auch mal Zeit, Leo dafür zu danken, dass ich den “Schock” des TYPOlight zu Contao nicht so arg zu spüren bekommen habe und (wie übrigens auch andere betroffene Autoren) zügig an der Buchüberarbeitung Richtung Contao weiterarbeiten konnte, ohne dabei täglich die Nightly Builds durchforsten zu müssen.
Irgendwie wurde mir während des Schreibens übrigens immer mehr und noch einmal neu klar, was Community bedeutet (etwas, das ich natürlich auch aus Joomla Zeiten schon kannte). Schön!

Vielleicht war es ja fatal, irgendwann den DAU in den Raum zu stellen. Den DAU - es gibt ihn nicht. User sind natürlich nicht dumm(ein netter Artikel von Björn Seibert). Aber weil keiner dieser imaginäre dümmste User sein möchte und landläufig der DAU gern in einem Satz mit Usability genannt wird, liegt auch folgender Trugschluss schnell nah: Usability ist nur was für die Dummen oder anders herum: Wenn wir für intelligente Menschen designen, können wir erwarten, dass die dann auch mitdenken und “das sowieso schon checken”, oder? Natürlich ist der Umkehrschluss genauso falsch!

Ein weiterer recht kritischer Begriff rund um Usability ist, wenn ich es genau bedenke, der der Zielgruppe, denn: er ist viel zu allgemein und führt zum Schubladendenken und zur Überbewertung einiger klassischer Eigenschaften statt klassicher Nutzungsszenarien. Man kann nicht einzig aufgrund klassischer Eigenschaften wie jung oder alt, groß oder klein, dick oder dünn und natürlich auch nicht aufgrund von intelligent und weniger intelligent Schlüsse auf notwendige Usability Manßnahmen und benutzerfreundliches Design ziehen. Allgemeine (Gruppen-) Eigenschaften sind also kein hinreichendes Kriterium für Usability Fragen. Insbesondere aber sind Grundsätze wie “Wir designen hier für Akademiker, da müssen wir uns nicht so viele Gedanken machen!” (gepaart mit allen positiven und negativen Vorurteilen und Schnellschuss-Einschätzungen) ein fataler Trugschluss. Es fehlt der Kontext. Zielgruppe als Inspiration für die Persona?

Was Personas so interessant macht

Was eine Persona ist, kann man sehr schön bei Wikipedia nachlesen, nämlich:

eine Art Prototyp für eine spezielle „Spezies von Nutzern“ dar. Unter einer Persona versteht man daher ein imaginäres Modell einer Person mit allerdings sehr konkreten (Charakter-) Eigenschaften oder etwa Nutzungsverhalten.

und ich glaube, genau das reicht für den Anfang, denn es beschreibt genau, auf was es ankommt. Mit Personas kommen die Menschen einer Zielgruppe besser zur Geltung, sie bekommen sozusagen ein Gesicht, einen Charakter. Plötzlich kann man andere Aspekte herausarbeiten. Für mich besonders interessant:

• Welchen Einfluss haben beispielsweise Stress oder Zeitdruck auf die Bedienung einer Software oder einer Website?
• Wie unterscheiden sich Nutzer, die etwas freiwillig oder lustvoll machen von solchen, die aus welchen Gründen auch immer unter Zwang stehen und demzufolge weniger Spaß an der Sache haben?

Welche Aufgaben erfüllen sie also konkret:

• Personas bringen statt reiner Theorie ganz reale Aspekte des täglichen Lebens in die Sache.
• Sie definieren relativ konkret, für wen eigentlich entwickelt wird.
• Sie helfen bei der Entwicklung des Designs (und natürlich auch dabei, Fehler zu finden).

Wie man die richtigen Personas entwickelt

Nett zu wissen, was man sich von Personas erwartet, nur: wie kommt man an die richtigen Personas? Meist ist die Frage nach einer Zielgruppe ja verhältnismäßig einfach (manchmal sogar so einfach, dass man schnell sagt “inhomogen”…).

“Empathy Comes from Experiencing: Putting Yourself in Their Shoes” habe ich bei UX Matters gelesen (lesenswert natürlich der ganze Artikel!) und trotzdem kann man falsch liegen.

Einen Einstieg, seine Personas zu hinterfragen, gibt beispielsweise auch How to create personas your design team will believe in: Interessant finde ich die 7-Kriterien-Regel und damit Checkliste, die unter angegebenem Link ausreichend, wenn auch englischsprachig erläutert wird:

P is for Primary research

E is for Empathy

R is for Realistic

S is for Singular

O is for Objectives

N is for Number

A is for Applicable

Aufwand, oder nicht?

Wenn ich mir vorstelle, ich würde grundsätzlich Personas einsetzen wollen, würde ich allein schon wegen des Aufwands wahrscheinlich den ein oder anderen Kunden vergraulen. Ich stelle mir also wie üblicherweise vor, ob das ein oder andere UX Pattern denn auch für kleine Projekte brauchbar sind und muss hier wieder einmal feststellen: So wie in der Theorie sicherlich nicht. Was ich nämlich bisher noch nicht geschrieben habe - aber was sicherlich klar ist: man muss (in der Theorie) die Arbeit mit Personas ja auch dokumentieren, Ergebnisse festhalten, Designgrundsätze überdenken, neue Schlüsse ziehen und so weiter.

Wir können das im kleinen Projekt sicherlich nicht leisten, wir können uns aber das Wesentliche herauspicken und uns zum Vorbild nehmen, um Usability und UX auch in kleinen Projekten mit weniger Zeit und Budget zu verbessern, im Wesentlichen:

• Es ist sicherlich legitim, sich an an realen Personen zu orientieren (natürlich nicht nur Verwandten, Freunden und Bekannten).
• Charaktere machen den Wert aus, wir dürfen uns nicht von Annahmen und Wunschdenken leiten lassen.
• Wir müssen keine Papierberge an Dokumentation erzeugen, wir brauchen keine “Personalakte”.

Und das Wunderbare an diesen menschlichen Personas ist doch, dass man sie genau deshalb so toll kommunizieren kann - auch wenn man sich dadurch zunächst vor allem inspirieren lässt, oder nicht? Der erste Schritt natürlich ist allerdings immer: wir machen uns über Usability generell Gedanken.

Weiterlesen zum Thema? Bitteschön!

Personas and the Role of Design Documentationauf Boxes and Arrows

Erst kürzlich übrigens habe ich ja Alan Coopers About Face vorgestellt. Alan Cooper ist sozusagen der Erfinder von Personas.

Über das Für und Wider von Personas und den Wert von Personas für das eigene Projekt kann man bei Joshua Porter einen interessanten Artikel lesen.

Eine Menge von Internet-Ressourcen zum Thema.

Dass es manchmal gar nicht so einfach ist, mit den Zielen, beschreibt Playful User Experience auf UX Matters.

User Experience geht Hand in Hand mit Service Design. Überlegungen zu einem Rundrum Ansatz plus einiger (neuer) interessanter Einstiegsstellen zum Weiterlesen und Weiterlernen.

UX und Service Design sind hier immer mal wieder Thema. Grundsätzlich nichts Neues. Trotzdem tut sich natürlich etwas, so dass es sich lohnt, das Ganze immer wieder mal aufzugreifen.

Insbesondere aber finde ich es sehr spannend, sich zu überlegen, in wie fern beides für den Webdesigner interessant ist und welche Aspekte wirklich wichtig sind.

Nochmal: UX - User Experience

User Experience geht einen Schritt weiter als Usability: es ergänzt den recht nüchternen Aspekt der Usability um die weniger gut messbare, deshalb aber nicht weniger wichtige Frage nach dem “Wie fühlt es sich an?” und gibt dem, was wir mit knallharten Zahlen fassen können, ein bisschen Menschlichkeit und damit sicherlich auch einen irrationalen Faktor.

Was gibt es Schöneres als nicht nur sagen zu können, man habe das bekommen, was man sich wünscht, das gemacht, was man machen oder das gelesen, was man wissen wollte, sondern es sei auch ein echtes Erlebnis gewesen?

Wahrscheinlich denken wir viel zu sehr in iPhone-Kategorien, wenn wir an User Experience denken, wahrscheinlich haben wir noch viel zu viel Mühe, das Prinzip der reinen Usability an den Mann oder die Frau zu bringen.  Vielleicht aber ist Service Design der Schlüssel genau dazu…

Nochmal: Service Design

Service Design beschäftigt sich mit der “Gestaltung” von Dienstleistungen. Ganz offenbar geht es dabei darum, großartige Services anzubieten. Zum Thema Service Design gibt es eine Reihe interessanter Definitionsansätze und Erklärungsversuche - leider übrigens nur wenig Deutschsprachiges. Ein sicherlich guter Einstieg ist Introduction to Service Design.

Das wirklich interessante ist, dass Service Design bei genauer Betrachtung eigentlich zur User Experience für unsere Kunden wird.  Und noch weiter gedacht, kann das, was wir als Produkt oder Dienstleistung anbieten, nämlich ganz grob gesagt Webentwicklung, Websites und Strategien fürs Web nur dann für den Endnutzer (das sind einfach mal wir, die das Internet und seine Angebote nutzen) ein Erlebnis werden, wenn auch der Entstehungsprozess ein Erlebnis ist.

Service Design + User Experience = Service Experience?

Fragen, die wir uns stellen sollten und Werkzeuge, die zur Verfügung stehen

User Experience und Service Design im “Web-Design” bedeutet also zweierlei:

• Welche Prozesse und Hilfsmittel stehen uns zur Verfügung, um Produkte (Websites, Webanwendungen, Shops…) zu entwickeln, die uns (!) zu einem echten Erlebnis verhelfen?
• Welche Strategien und Werkzeuge stehen uns andererseits zur Verfügung, um den Entstehungsprozess so transparent, verständlich, benutzer (kunden-) orientiert wie möglich zu machen? Wie wird das Ziel “User Experience” plastischer und praxisnäher?

Letzteres ist deshalb so wichtig, weil oft einfach das Vorstellungsvermögen fehlt, weil vielleicht das einschneidende Erlebnis fehlt und damit irgendwie nie so ganz sichergestellt werden kann, dass aus einem guten Konzept dauerhaft auch ein lebendiges Ergebnis wird.

Schon einmal hatte ich beispielsweise auf die UX Deliverables hingewiesen: Dabei geht es um mögliche Schritte auf dem Weg hin zu mehr User Experience.

Parallel dazu stellt sich aber die Frage: Wie können wir diese Schritte einbringen? Wie kann man sie präsentieren? Wie werden sie verständlich? Wie vermitteln wir Wissen und Erfahrung, um sie für andere nutzbar zu machen?

Wir alle kennen beispielsweise das Problem, dass Sketches aller Art und auch das Prototyping zwar ein wichtiger Schritt im Entwicklungsprozess einer Website sind, die aber aber nicht immer problemlos verstanden werden, weil eine gewisse Fassbarkeit fehlt. Antworten wie “Sieht nett aus, aber ich kann mir das nicht so recht vorstellen! Können Sie bitte nicht einfach mal machen?” bis hin zu “Naja, die Website ist ja schon schön, aber die Blindtexte stören mich irgendwie” machen eigentlich klar, dass Theorie und Praxis einfach zwei verschiedene Dinge sind und wir uns viel mehr am Menschen orientieren müssen, als wir das manchmal aufgrund von “Man macht das so”-Scheuklappen sehen wollen.

Mehr als einen sehr guten Überblick über zur Verfügung stehende (Kommunikations-)Tools bietet Service Design Tools. Zugegeben: Die Liste der Werkzeuge und Methoden ist umfangreich und erschlägt auf den ersten Blick…

Und im Prinzip wird damit schnell klar: Arbeiten im, mit und fürs Netz hat verschiedene Ebenen, die nicht voneinander trennbar sind. Insbesondere aber müssen wir selbst unsere eigenen Strategien finden, denn ich glaube, niemand kann sich ernsthaft mit Fragen wie User Experience oder Service Design auseinandersetzen, wenn er sich nicht selbst so wohl fühlt wie er sich natürlich von denen wünscht, für die er etwas entwickelt.

Einen guten (wenn auch teils recht theoretischen) Einblick in das Zusammenspiel von User Experience und Service Design, die Gemeinsamkeiten aber auch Unterschiede und Grenzen bietet eine umfangreiche Präsentation von Sylvain Cotton: UX design, service design and design thinking.

Und dann möchte ich unbedingt noch auf eine weitere Slideshare Präsentation hinweisen, die mir dieser Tage unterkam und mich wirklich begeistert hat. Designing for tomorrows needs. Optisch wirklich toll gemacht, inhaltlich kurz und prägnant und insgesamt ein Anschau-Erlebnis mit Nachhaltigkeitseffekt.

Rework
Jason Fried & David Heinemeier Hansson
Crown Business (März 2010)

Die Autoren: Gründer von 37 Signals.
Die Essays: kurz und knackig mit neuen, unkonventionellen Methoden zum Erfolgreich-sein-und-werden.

Diese Einfachheit ist das, was begeistert. Haben wir uns nicht alle schon mal überlegt, endlich Schluss zu machen mit all den typischen “Must Do” des Business oder davon geträumt, diese gut gemeinten, althergebrachten Prinzipien über den Haufen zu schmeißen, ohne dabei auf Bewährtes zu verzichten? Endlich sagt uns jemand, dass das wirklich erlaubt ist und auch noch funktioniert. Wir müssen nicht mehr träumen, wir dürfen endlich machen! Wir bekommen kurz, kompakt, nüchtern  und doch in gewisser Weise humorvoll alle Facetten von Erfolg, Misserfolg und eigenem Selbstverständnis. Die Methoden haben nichts mit Geld und riesigem Aufwand zu tun sondern einfach nur mit Selbstverständnis und Elan. Und das noch elegant und locker geschrieben und in auflockernde Illustrationen gepackt. Was will man mehr…?

Und doch kommt da irgendwie Ärger auf. Eigentlich haben wir das alles schon mal irgendwo gelesen. Vielleicht auch bei 37 Signals selbst. Und eigentlich sind auch die Ideen nicht alle wirklich neu. Sie sind nur gebündelt und bekommen mit progressiven Überschriften einen provokanten Anstrich.

Aber vielleicht ist es genau das, was für mich auch den Reiz eines Buchs ausmacht: das sich daran reiben können, das sich ein bisschen aufregen können? Vielleicht auch gerade, weil es ein Anreiz ist, sich das ein oder andere mal so richtig zu Herzen zu nehmen?

Fazit: Lesenswert, allein schon aufgrund seiner Prägnanz und Klarheit. Eine Ergänzung auf jeden Fall zur eher staubtrockenen Businessplan-Notwendigkeit. Lesenswert auch, weil sich derlei auf Englisch so außerordentlich gut liest.

Rework: eine Investion, die man sicher immer wieder mal aus dem Bücherregal holt. Bei mir wird es noch länger auf dem Schreibtisch liegen.

Mein dauerhaftes Problem liegt weniger darin, dass ich Infopath nicht gerne bediene. Das Problem liegt vielmehr darin, dass ich trotz absoluter Routine oft nur schwer sagen kann, wie lange es denn nun dauern wird, denn die Fallstricke sind dann doch immens und lauern dort, wo man sie gar nicht vermutet. Ein Problem für alle die, die Infopath-Projekte relativ genau kalkulieren müssen oder wollen. Meiner Erfahrung nach geht das eigentlich kaum.

Meine Erfahrungen mit Infopath (ein Auszug)

Einige Probleme sind eigentlich schnell auf einen Nenner gebracht: das Layouten von Ansichten. Hier stößt Infopath an seine Grenzen und verhält sich, sagen wir mal, fast schon kontraproduktiv. Aber es gibt weitere Zeitkiller. Die Liste der Merkwürdigkeiten und weniger schönen Programmfunktionalitäten, die mir begegnet sind, ist lang. Beispielsweise:

• Copy und Paste ist nur bedingt möglich, vor allem aber nur innerhalb einer Infopath-Vorlage (auch wenn zwei Vorlagen jeweils ein identisches Schema zugrunde liegt). Alle XPath Informationen gehen verloren. - Man muss das einfach wissen.
• Copy und Paste kann dazu führen, dass Formatierungen ebenfalls mit übernommen werden, es kann aber auch dazu führen, dass die Formatierung nicht mit übernommen wird. Eine Auswahl, wie man sie aus Word kennt (Zielformatierung) ist nicht möglich. Hier hilft gelegentlich nur Try and Error
• Manchmal passiert es, dass eine vom Entwickler vorgegebene Schriftformatierung schlicht gar nicht übernommen wird, sich dafür aber die Formatierung an anderer Stelle ändert.
• Ein Carriage Return (sprich das Einfügen eines neuen Absatzes) kann dazu führen, dass sich eigenmächtig die Formatierung einzelner, anderer Absätze ändern.
• Die Änderung einer Schriftart über eine gesamte Ansicht kann zu überraschenden zusätzlichen Abständen führen (sic!)
• Infopath erzeugt nach wiederholbaren Abschnitten gerne Leerraum, der sich nicht um alles in der Welt entfernen lassen möchte (außer über die Quelldatei im Texteditor, aber das ist sehr umständlich und zeitaufwändig)
• Es gibt keine Default-Einstellungen, die Vorlagen-übergreifend für alle so genannten Ansichten gültig sind. So müssen Seiten-Einstellungen für jede Ansicht neu vorgenommen werden.
• Es kann der Fall eintreten, dass vom Entwickler vorgenommen Einstellungen nach Wechseln der Ansicht in eine andere plötzlich (und wie von Zauberhand) wieder zurückgängig gemacht wurden.
• Die Verwendung “abweichender” Schriftarten (Verdana ist hier Default) ist mit Vorsicht zu genießen und sollte in den Einstellungen zu Ansicht für jedes Text-Element gesondert gesetzt werden (sonst wird man die Verdana nie los)
• Nicht jedes Element, für das man eine automatische Höhe, angepasst an den Inhalt, vorgegeben hat, hält sich auch an diese Anweisung. Dies gilt insbesondere für Abschnitte.
• …

Man mag nun meinen, Infopath wäre absolut ungeeignet, um damit etwas sinnvolles zu machen. Ich muss dem ganz entschieden widersprechen. Das Wichtige ist lediglich, sich zu Beginn eines Projekts ausreichend Gedanken zu machen und den Projektablauf ausreichend zu planen - nicht nur technisch/inhaltlich. Mit einigen Best Practices wird das Arbeiten mit Infopath so auf jeden Fall um einiges leichter.

Bedenkenswertes zur Projektplanung

Damit ein Infopath Projekt weder zum Zeitkiller noch zur nervlichen Zerreißprobe wird, ist es sinnvoll, sich an ein paar Kleinigkeiten zu halten und auch zu kommunizieren.

Die Grundeinstellung

Alle Beteiligten müssen vorab wissen, dass Infopath nicht die Möglichkeiten von Word oder anderen Textverarbeitungsprogrammen mitbringt und sich hinter Infopath und Word auch unterschiedliche Produkte und Konzepte verbergen. Es mag der Punkt kommen, an dem man Abstriche hinnehmen muss. Dieser Aspekt ist ganz, ganz wichtig: Alles andere macht unglücklich.

Wer als Entwickler mit Infopath arbeitet, sollte alles vergessen, was er bisher über Standards, HTML und CSS gelesen, gehört oder gelernt hat. Infopath erzeugt seinen eigenen Code, dem man sich fügen sollte. Idealismus ist beim Arbeiten mit Infopath nur dann gefragt, wenn es um ein funktiontüchtiges, benutzerfreundliches Produkt geht.

Ein paar Tipps

• Wer effizient arbeiten möchte, setzt, soweit dies möglich ist, trotz allem auf Copy & Paste der Inhalte insbesondere druckbarer Ansichten.  Dies bedeutet, mit der komplexesten, wiederverwendbaren Ansicht anzufangen und von dort gegebenenfalls Elemente zu kopieren.
• Falls Layout-Probleme auftreten sollten, ist es sinnvoll, zunächst eine Ansicht zu optimieren. Änderungen, die sich durch Fehlerfortpflanzung ergeben haben, sind echte Zeitfresser.
• Sollen für eine Infopath Vorlage viele Druckansichten erstellt werden, ist es unter Umständen sinnvoll, die Zeit ausschließlich in die Erstellung von XSLT-Transformationen und Stylesheets für Word zu stecken.
• Insbesondere ist das Zusammenspiel im Office Umfeld etwas, das von Anfang an zum Thema gemacht werden sollte. Nachrüsten geht, ist aber mit hohen Kosten verbunden.
• Abhängig vom XML-Schema können zur Darstellung von Information viele XPath Abfragen nötig sein, die durch das grafische User-Interface und seine vielen Klicks gelegentlich viel Zeit kosten.
• Die Formatierung von Schreiben mit einer großen Mischung aus Fließtext, wiederholbaren Abschnitten und wiederholbaren Tabellen erfordert einiges Fingerspitzengefühl. Sobald eine Formatierung wie gewünscht funktioniert, sollte man sich die Einstellungen genau notieren, denn Nachschauen kostet immens viel Zeit.
• Jede (auch eine kopierte!) Formatierung sollte unbedingt im Vorschau-Modus überprüft werden. Das dauert zwar, erspart aber Ärger und ist im Endeffekt doch Zeitersparnis.
• Das Arbeiten mit Layout-Tabellen macht das Layouten leichter - elegant ist der von Infopath generierte Code in jedem Fall nicht. Keep it simple. Layout-Tricksereien mit Infopath sind kaum möglich.
• Die Angabe von Texteigenschaften in der Ansichtskonfiguration ist zwar nicht zwingend nötig und ebenfalls zeitaufwändig, schützt aber deutlich vor unerwünschten Überraschungseffekten.
• Mehr noch als bei anderen (Office)-Produkten sollte man sich des Ziel-Druckers annehmen: Seitenränder behandelt Infopath schlicht anders als beispielsweise Word.
• Vor der Veröffentlichung liegt immer ein letzter, sehr ausführlicher Check aller Funktionen und des gesamten Layouts, insbesondere der Druckansichten.

Die wichtigste Regel aber ist: Infopath ist ein mächtiges Werkzeug - und trotzdem ist mit Infopath nicht alles machbar. Wann immer die Anforderungen nicht auf den ersten Blick ganz klar umsetzbar sind, sollte man eine Machbarkeitsanalyse durchführen (auch wenn das ärgerlich für alle Beteiligten ist).

Wer insbesondere die Grundeinstellungen beherzigt, sich die Grenzen, Probleme und Zeitkiller bewusst macht und sich anderweitig auch darüber im Klaren ist, in welche Abhängigkeiten er sich durch die Verwendung eines proprietären Produkts wie Infopath begibt, wird alles in Allem dann doch schnell Erfolgserlebnisse haben.

Richtig hip nennt man das Smoothie, wenn man es fertig kauft, zahlt man dafür wahrscheinlich verhältnismäßige Unsummen, - aber man kann sich das Ganze auch selbst machen und das haben die Kids doch schon ganz gut raus: Erdbeer, Banane, Kiwi.

An den richtigen Farben zur Fußball-WM arbeiten wir übrigens noch…