Gedanken zu Thermo

Juten Tach,

nachdem ich auf der Adobe MAX in Barcelona nun auch mal die Gelegenheit hatte, Demos von Thermo live zu sehen, spukt mir diese Idee von besseren Workflows zwischen Designern und Entwicklern auch im Kopf herum. Einen schönen Blog Post hierzu mit ebenso interessanten Kommentaren hat ja schon Grant vor einiger Zeit geliefert.

Zunächstmal erinnert mich Thermo und die Idee, dass dabei hinten ein Flex Projekt rauskommt, sehr stark an (ich spüre schon den Zorn vieler) Visual Studio und Blend. Jetzt kann natürlich gleich wieder die Diskussion losgehen, wie toll Blend ist oder nicht, aber darum geht es ja gar nicht. Fakt ist, dass man auch ziwschen Blend und Visual Studio Projekte hin- und herschieben kann und Blend ist auch eher an Designer gerichtet (ja ja, ich will nichts hören) und man kann damit Oberflächen kreieren. Im Detail habe ich mich auch noch nicht mit dem Workflow zwischen Blend und Visual Studio beschäftigt, aber auch Blend erzeugt seinen Kram in XAML, sowie ja Thermo wiederum MXML generieren wird. Also man kann – denke ich – schon sagen, dass sich die Konzepte hier sehr ähneln.

Und warum auch nicht, die Idee macht ja auch Sinn. Wenn man möchte, dass Designer und Entwickler besser zusammenarbeiten, dann braucht man dafür auch die richtigen Tools. Die wichtigste Frage dabei ist, wo macht man am sinnvollsten den Cut, sprich, wo hört der Job des Designers auf, wo fängt er beim Entwickler an? Und, wie stark soll eine Überlappung stattfinden, denn das muss auch klar sein, eine vollkommende Abtrennung kann es nicht geben, denn im Bereich des Interaktionsdesigns spielen Design und Funktion nun mal ineinander.

Dies im Blick finde ich den gewählten Cut bei Thermo gut gewählt. Designer können die komplette Oberfläche aufbauen, können das Look&Feel der Interkationsmöglichkeiten der Oberfläche bestimmen und können sogar bestimmen, wie dynamische Oberflächen sich verhalten. Damit haben Sie alle Möglichkeiten, um die Gestaltung und das Verhalten der Oberfläche zu bestimmen.

Das ist aber auch gleich schon der Knackpunkt. Designer können damit eben auch das Verhalten einer Oberfläche bestimmen. Bisher lief das bei den Designern, die ich kenne, nicht so. Da hörte die aktive Umsetzung für den Designer bei der PSD auf. Danach konnte er sich allenfalls noch neben den Programmierer setzen und ihn mit Sätzen wie “langsamer, nee, ein bisschen schneller schon noch” nerven.

Mit Thermo könnte er das Verhalten der Oberfläche selbst bestimmen. Da tun sich für mich zwei Fragen auf:

1. Wird sich ein normal ausgebildeter Designer in der Lage fühlen, das komplette Verhalten einer Oberfläche zu bestimmen (inklusive aller Stati, die ein Webapplikation so annehmen kann), oder braucht man dafür entsprechend ausgebildete Interaktionsdesigner? Die Frage kann ich nicht beantworten, weil ich nicht weiß, was Designer so alles lernen und können (höchstwahrscheinlich wesentlich mehr, als ich bornierter Entwickler mir vorstellen kann).

2. Wie kann sichergestellt werden, dass der durch Thermo generierte Code in die vom Entwickler anvisierte Struktur passt? Und das ist für mich natürlich interessant.

Bei den Demos, die ich bisher zu Thermo gesehen habe, kam mir gleich der Gedanke: “Wie muss eigentlich eine Photoshopdatei oder eine Illustrator Datei strukturiert sein, damit der Designer in Thermo möglichst einfach eine interaktive Oberfläche bauen kann, die zudem noch in eine möglichst gut strukturierte (was auch immer das heisst) MXML mündet?”. Hier wird eins schon erkennbar, Designer und Entwickler müssen sich überhaupt erstmal darauf einigen, wie sie zusammenarbeiten und das ist ein wichtiger Punkt, wenn man über Thermo urteilt. Denn ein Tool kann nicht bestimmen, wie die Zusammenarbeit zwischen Personen zu erfolgen hat, das müssen die Personen schon selber tun. Das Tool kann dann helfen, die abgestimmte Zusammenarbeit zu untersützen. Sprich, um Thermo erfolgreich nutzen zu können, müssen Designer und Entwickler zusammen klären, wie die Basisdaten, wie z.B. Photoshopdateien, Illustrator Dateien etc. aufgebaut sein müssen, in welcher Art und Weise diese in Thermo importiert werden, in welcher Art und Weise dann die Interaktion in Thermo erstellt wird und was dort zu berücksichtigen ist, damit das generierte Ergebnis dann einen Kompromiss bildet zu dem, was der Entwickler benötigt, um darauf aufbauend die Anwendung zu bauen.

Und Kompromisse wird man eingehen müssen, denn ein automatisierter Generierungsprozess, wie Thermo ihn anbieten wird – wie auch immer der final aussehen wird – wird natürlich nie exakt so aussehen, wie man sich das wünscht, dazu sind die Vorstellungen von Oberflächenstrukturen bei Entwicklern (Gottseidank) zu unterschiedlich.

Thermo kann also meiner Ansicht nach nicht die grundsätzliche Notwendigkeit auflösen, dass Designer und Entwickler zusammen einen Arbeitsprozess entwickeln müssen, der Ihre Zusammenarbeit regelt, aber wenn der erstmal steht, kann Thermo bestimmt helfen, diesen Prozess zu unterstützen.