Session: Vom Sketch Flow zum Produktiv-Projekt

Lars Heinrich und Peggy Reuter
Peggy leitet in das Thema mit einer Beschreibung von den Grundsätzen zu Sketch Flow Prototypen ein.
Was ist ein Sketch Flow Prototyp?
  • Echte Applikationen die mit Blend erstellt werden
  • Für Designer, Usability Experten und Entwickler
Warum sollte man Sketch Flow Prototypen nutzen?
  • konstengünstiger und schneller als „reale“ Produkte
  • Nutzer Feedback
  • es wird EIN Prototyp erstellt an dem alle Beteiligten mitarbeiten können
Es folgt ein kurzer Abriss über die „normalen“ Prototypen.
Lars spricht jetzt über Probleme der „normalen“ Prototypen. Es ist überraschend was man von kreativen Leuten geliefert bekommt.. Klassiker wie das mischen von deutschen und englischen Namen oder die allseits beliebte Solution Application. Es gibt eine Demo eines WorstCase Szenarios, bei dem man den erstellten Prototypen nur noch verwerfen kann wenn daraus ein Finales Produkt werden soll.
Nach dem don’t do folgt nun das do.
Folgende Schritte werden vorgeschlagen:
  • Zielgruppen und Personas bestimmen
  • Anforderungen und Nutzerwünsche
  • ein Organigramm erstellen um die Kundenwünsche an den Programmierer heranzutragen.
  • aus den Ideen erstellt der Entwickler eine Solution-Architektur
  • Integration von ViewModels, anlegen von Views etc.
Dazu wird in einer kurzen Demo der Unterschied vom WorstCase zur guten Solution-Architektur gezeigt, mit einer Aufteilung zwischen prototypsichen Komponenten, Theme Komponenten und der Basisanwendung. Dabei ist es auch hier wieder wichtig auf die Blendability zu achten, denn Grafiker/Designer arbeiten nicht mit VS sondern mit Blend.
Es fällt die Frage wer als erstes aktiv wird? Antwort: Hier ist der Entwickler an der Reihe, denn die Probleme beginnen schon wenn man die ersten Elemente in ein von Blend erstelltes Projekt wirft mit generierten Klassen etc. Lars als Entwickler bezieht sich oft auf die Session vom Daniel, denn wenn man an dieser Stelle dem Designer die richtig vorbereiteten Grundlagen an die Hand gibt vermeidet man viele der genannten Fehler z.B. In dem man implizite Styles verwendet.
Weiter geht es mit Peggy, die Beispieldaten in die Solution integriert. Zur Anwendung in dem Prototypen kommen die richtigen Controls, so dass eine Checkbox nicht nur so aussieht als wäre sie eine, sondern eben eine Checkbox ist.Es gibt auch die Möglichkeit für den Kunden Feedback in den Prototypen zu schreiben und dieses als Datei an den Designer zu schicken damit er reagieren kann.
Der nächste Schritt geht nun wieder an Lars der die Sketch Styles zu Simple Styles ändert und den aufgeräumten Code wieder an Peggy weiter gibt.
Nun folgt die Umsetzung des Screendesigns über den Prototypen. Indem Peggy die Eigenschaften der einzelnen Controls, die Typografie und die Farben der Hintergründe verändert.
Lars übernimmt jetzt das Ruder und erklärt wie man nun vom gestyltem Sketch Flow Prototypen zur Grundlage des „echten“ Produkts kommen kann. Der Sketch Flow Rahmen wird solange wie möglich gehalten, um eventuelle Anforderungen die später kommen wieder mit einem Prototypen evaluiert werden kann. Aus dem Sampeldate werden entsprechende ViewModels angelegt, der NavigationManager wird verworfen. Dann kommt noch ein Fenster drum und schon kann es los gehen. In der Solution besteht dann die Möglichkeit die Anwendung als solche oder mit dem Rahmen von Sketch Flow zu starten.
Es kommt noch eine Frage zum Import von Illustrator hinzu XAML, was wohl automatisch geht, wovon aber abgeraten wird (ein Teilnehmer berichtet von Erfolg im eigenem Projekt mit der Importfunktion).