Der alte Workflow
In den Fällen, in denen die Gestaltung einer Anwendung vorgenommen
wurde, sah der Prozess in der Regel folgendermaßen aus: Der
Entwurf eines Designs wird typischerweise mit einern Grafikprogramm
vorgenommen, das mit der späteren Zieltechnologie nichts
zu tun hat. Häufig wird versucht, mit solchen Prototypen einen
möglichst überzeugenden visuellen Eindruck zu vermitteln, da ein
visueller Eindruck oftmals darüber entscheidet, wer den Auftrag
schlussendlich erhält. Technische Realisierbarkeit wird meist außer
Acht gelassen und die Problematik der Machbarkeit für den Fall
einer Auftragsvergabe aufgespart.
Bekommt man nun den Zuschlag, wird versucht, das Versprochene
so gut es geht in die Tat umzusetzen. Da die einzige Schnittstelle für
den Einsatz in der Software Exporte in Pixelformat darstellen, ist
das in der Prototyping-Phase entstandene Material nicht direkt verwertbar.
Der Weg führt immer über zurechtgeschnittene Exporte,
die in der Regel Pixelmaterial auswerfen. Einmal exportiert ist das
Material nicht mehr in das Ursprungsformat zurückführbar, daher
wird diese unwiderruflich materialverändernde Vorgehensweise
destruktives Exportieren genannt. Abbildung 1.9 zeigt den Ablauf
eines Designprozesses einer Anwendung. Dabei ist der Übergang
Abbildung 1.9: Der alte Workflow mit destruktiven Exportschnittstellen
Abbildung 1.10: Ein grafisches Design einer Webseite, das einige Tücken für die Realisierung beinhaltet
vorn Grafikprogramm (hier Photoshop) zur Realisierungsplattform
(hier Flash und Visual Studio) destruktiv. Das heißt, das exportierte
Material kann nicht mehr in seinen bearbeitbaren Ursprungszustand
zurückgeführt werden.
Viele Arbeitsschritte müssen zudem redundant erneut vollzogen
werden: Farben, Schriftart und -größe müssen anhand der Prototypen
recherchiert und manuell in der Entwicklungsumgebung
gesetzt werden.
Viele grafische Details bleiben in der Realisierungsphase auf der
Strecke. Einige Vorstellungen des Designers lassen sich schlichtweg
nicht umsetzen, einige nur mit zu großem Aufwand, andere nicht in
der angedachten Form, da funktionale Aspekte womöglich Änderungen
am Ursprungsdesign erfordern.
Abbildung 1.10 zeigt exemplarisch ein grafisches Design einer
Webseite. Bei der Gestaltung hat der Designer alle Register einer
herkömmlichen Designsoftware gezogen.
Würde man versuchen, den Entwurf tatsächlich genau so als Webseite
zu programmieren, stieße man auf einige Schwierigkeiten, wie
Abbildung 1.11 zu entnehmen ist.
SELFPHP
SELFPHP OHG, info@selfphp.de, Impressum, Kontakt