Die Zustandsdiagramme aus dem ersten Teil dieses Tutorials sind eine gute Basis für einen Prototyp der Benutzerführung. Eine genauere Beschreibung der einzelnen Zustände der Anwendung liefert dafür ein Storyboard. Das Storyboard kann sowohl eher konzeptionell sein als auch bereits einer grafischen Vorschau entsprechen und bei kleineren Projekte auch gleich mit dem Zustandsdiagramm verwoben werden.
Für den konzeptionellen Teil ähnlich einem Wireframe nutzen Konzeptoren gerne Microsoft PowerPoint wobei jede Folie einem Strukturpunkt oder in der HTML-Welt einer Seite entspricht. Für die Weiterverarbeitung in einem Click-Dummy kann PowerPoint über das Menü „Start -> Speichern unter -> andere Formate“ mit einer Reihe an Exportvarianten aufwarten, die auch den Export jeder einzelnen Folie als eine Sequenz von Einzelbildern erlauben. Gestalter bevorzugen anstelle von PowerPoint meist das Kreativwerkzeug Ihrer Wahl und liefern dann ebenfalls einzelne Bilddateien – selbst Scribbles mit Stift und Papier sind durchaus nicht ungewöhnlich.
Der Entwurf eines Zustandes der Anwendung in Expresion Design.
Sollte es sich bei dem Werkzeug z. B. um das zum Expression Studio gehörende und mit Expression Blend harmonierende Expression Design handeln, dann können Momentaufnahmen des Entwurfs für das Storyboard über das Menü „Datei -> Exportieren“ ausgegeben werden. Als Bildformat bietet sich erst einmal das verlustlose aber dennoch kompakte und leicht weiterzuverarbeitende PNG-Format an. Die Verwendung von XAML ist hier gerade in der Entwurfsphase nicht unbedingt zu empfehlen. Beispielsweise weil das deklarative XAML anders als ein Pixelformat wie PNG schon zur geplanten Test- oder Ausgabeumgebung passen muss und die Sprache selber wieder eine Quelle für Fehler ist.
Ganz egal wie man einen Prototyp oder ein ganzes Projekt entwirft und umsetzt, ist ein planvolles Vorgehen dabei empfehlenswert. Die gilt zwar meistens aber eben nicht immer: Denn auch das vordergründig manchmal unorganisiert wirkende Experimentieren und der eher virtuose Umgang mit Ideen und Technologien kann durchaus gewollt und zielführend sein. Schließlich benötigt man ja Phasen, in denen man Anforderungen erarbeitet und ausprobiert und hinsichtlich des zu erwartenden Ergebnis (also wie wirkt das eigentlich auf den Anwender), der Umsetzbarkeit (geht das überhaupt) und des Aufwandes (wie viel Zeit und Geld kostet das) bewertet. Doch auch das klappt nur dann, wenn dies nicht willkürlich sondern als Bestandteil des Entstehungsprozesses geplant wird.
Für das planvolle Vorgehen gibt es eine Vielzahl an Werkzeugunterstützung auf dem Markt. Für die Projektverwaltung, die sich u. a. um die Einteilung der Entwickler und um das Einhalten von Terminen kümmert, bietet sich beispielsweise bei größeren Projekten Microsoft Project an. Für die Planung der eigentlichen Inhalte sind jedoch andere Werkzeuge notwendig.
Der erste Entwurf auf dem Flipchart (gut, eine Kamera im Mobiltelefon zu haben).
Die Struktur eines Projektes lässt sich über Diagramme entwerfen – grundsätzlich kann dies mit einem Flipchart oder auch einem x-beliebigen Malprogramm geschehen. Wichtig ist ein gemeinsames Verständnis für die Bedeutung der Diagramme. Sprachen wie UML helfen dabei.
Der zweite Entwurf als Statechart in Visio.
Ein beliebtes Werkzeug ist hier Microsoft Visio – z. B. unter Verwendung eines Zustandsdiagramms (Statechart). Die Zustände im Diagramm entsprechen bei einer klassischen Website den einzelnen HTML Seiten, die Übergänge von einem Punkt zum nächsten stehen für ein meist benutzerdefiniertes Ereignis wie einen Mausklick. Bei Rich Applications oder auch Spielen ist so eine 1 zu 1 Beziehung oft nur mit komplexen Zuständen beschreibbar (komplexe Zustände sind Zuständen, die ihrerseits wieder aus Zuständen bestehen). Animationen ließen sich zwar ebenfalls mit einem Zustandsdiagramm entwerfen, doch hier reichen dank der linearen Abfolge einfachere beim Trickfilm auch Dope Sheet genannte Listen. Microsoft Excel kann hierfür als Alternative zu spezialisierten Werkzeugen herhalten.
Bereits diese Diagramme oder Listen zeigen, ob die geplante Anwendung schlüssig ist. Außerdem erhält man so ein Gefühl für den Umfang. Aber das Beste ist, dass dieses Diagramme eine hervorragende Grundlage für erste Prototypen der Benutzerführung sind. Dieser Prototyp kann dann Schritt für Schritt mit den Details „verschönert“ werden, so dass am Ende das fertige Produkt steht (denn es muss sich nicht unbedingt nur um einen Wegwerfprototypen handeln).
Im ersten und zweiten Teil des Flash Checkers habe ich eine einfache objektorientierte Flash-Erweiterung verfasst, um die Dokumenteneinstellungen einer FLA-Datei zu prüfen. In diesem Teil zeige ich Ihnen, wie Sie auf die Inhalte der Zeitleiste und Bibliothek zugreifen.
Als erstes wird das zu behandelnde Dokument (FLA) benötigt. Entweder man lädt ein Dokument oder man geht über die Liste aller geöffneten Dokumente oder man nimmt wie hier einfach das aktuell in Flash geöffnete und aktive Dokument.
1
| var currentDocument = fl.getDocumentDOM(); |
Die Zeitleiste (bei mehreren Szenen die Zeitleisten) der aktuellen FLA-Datei sind nun über dieses Dokument zugänglich.
1
2
3
| for (var i=0; i<currentDocument.timelines.length; i++) {
var currentTimeline = currentDocument.timelines[i];
} |
Und in der Zeitleiste werden die Ebenen verwaltet (zur Erinnerung: Hier wird der Quellcode, also die FLA-Datei, behandelt und nicht die kompilierte SWF-Datei, der diese Ebenen nämlich völlig unbekannt sind).
1
2
3
| for (var i=0; i<currentTimeline.layers.length; i++) {
var currentLayer = currentTimeline.layers[i];
} |
Ebenen enthalten Bilder und Schlüsselbilder. Wobei nur in den Schlüsselbildern relevante Informationen abgelegt sind, weshalb in erster Linie diese Schlüsselbilder (Keyframes) interessieren.
1
2
3
4
5
6
7
| for (var i=0; i<currentLayer.frames.length; i++) {
if (currentLayer.frames[i].startFrame == i) {
var currentKeyframe = currentLayer.frames[i];
} else {
continue;
}
} |
In den Schlüsselbildern liegen die Elemente der Anwendung. Mit Hilfe von JSFL (JavaScript für Flash) kann beispielsweise deren Position geprüft werden.
1
2
3
4
5
6
| for (var i=0; i<currentFrame.elements.length; i++) {
var currentElement = currentFrame.elements[i];
var topfraction = currentElement.top % 1;
var leftfraction = currentElement.left % 1;
if (topfraction != 0 || leftfraction != 0) fl.trace("Warning: Position is not snapped to pixels!");
} |
Für eine vollständige Prüfung eines Flash-Dokumentes reicht aber die Zeitleiste des Hauptdokuments nicht aus. Denn in der Bibliothek liegen noch viele weitere Inhalte, die überprüft werden müssen. Die Bibliothek ist dabei eine einfache Eigenschaft des Dokuments und verfügt ihrerseits über eine Liste von Inhalten (items).
1
| currentDocument.library.items |
Diese Inhalte können dann – im Falle von Symbolen wie MovieClips – ähnlich einem Dokument geprüft werden. Anders als ein Dokument haben sie aber nur genau eine Zeitleiste, denn nur Dokumente können in Szenen unterteilt sein.
1
2
3
4
5
| for (var i=0; i<currentDocument.library.items.length; i++) {
if (currentDocument.library.items[i].itemType == "movie clip") {
var currentTimeline = currentDocument.library.items[i].timeline;
}
} |
Die Komplette Erweiterung können Sie hier im Quellcode oder auch als fertige Flash Extension (MXP) zur einfachen Installation herunterladen.
Im ersten Teil des Flash Checkers habe ich eine einfache Flash-Erweiterung verfasst, die die Dokumenteinstellungen einer FLA-Datei prüft. Dem einen oder anderen mag es übel aufstoßen, dass diese Erweiterung für die Flash Entwicklungsumgebung in JavaScript verfasst wurde. Mal abgesehen davon, dass – wer unbedingt will – auch DLLs programmieren und als Erweiterung einbinden kann, ist JavaScript jedoch besser als sein Ruf: Beispielsweise die objektorientiere Programmierung ist durchaus möglich. Wenn auch nur Prototypen basiert. Das heißt, dass man bei JavaScript die Vererbung per Hand über sogenannte Prototypen erreicht. Denn jedes Objekt in der JavaScript-Welt verfügt über eine Prototyp-Eigenschaft, die auf ein anderes Objekt verweist. Und sollte eine Methode oder Eigenschaft nicht in einem Objekt verfügbar sein, dann wird halt im Prototyp nachgeschaut. Und sollte in diesem Objekt die Methode oder Eigenschaft ebenfalls nicht verfügbar sein, dann wird halt in dessen Prototyp nachgeschaut. Und so weiter und so fort…
Das Pendant zu einer Klasse erstellen Sie in JavaScript mit einer Funktion.
1
2
3
| function FlashChecker () {
this.property = "foo";
} |
Eine Instanz dieser „Klasse“ erzeugt das Schlüsselwort new, in dem erst ein neues Objekt angelegt und die Funktion ähnlich einem Konstruktor im Kontext dieses neuen Objektes ausgeführt wird (das Schlüsselwort this bezieht sich in diesem Fall auf das gerade neu erzeugte Instanzobjekt).
1
| var checker = new FlashChecker(); |
Es ist gängige Praxis, die Methoden einer „Klasse“ in das Prototyp-Objekt zu schreiben, damit die Methoden nur einmal deklariert und nur einmal im Speicher abgelegt werden.
1
2
3
4
5
6
7
8
9
10
11
12
| FlashChecker.prototype.checkDocumentSettings = function (currentDocument) {
var playerVersion = currentDocument.getPlayerVersion();
var asVersion = currentDocument.asVersion;
var fps = currentDocument.frameRate;
var height = currentDocument.height;;
var width = currentDocument.width;
if (playerVersion != "9") fl.trace("Warning: Wrong player version!");
if (asVersion != 3) fl.trace("Warning: Wrong ActionScript version!");
if (fps != 24) fl.trace("Warning: Wrong framerate!");
if (height != 800) fl.trace("Warning: Wrong height!");
if (width != 800) fl.trace("Warning: Wrong width!");
} |
Die Instanzen haben dann über den Prototyp implizit (also ohne dass man es extra hinschreiben muss) per __proto__-Eigenschaft Zugriff darauf, so dass der Verwendung durch die Instanzen nichts im Wege steht.
1
2
3
| var checker = new FlashChecker();
var currentDocument = fl.getDocumentDOM();
checker.checkDocumentSettings(currentDocument); |
Bei der Aufzeichnung unseres aktuellen Trainings kam Saban auf mich zu, da seine 3D-Versuche mit Rundungsfehlern zu kämpfen hätten. Und in der Tat, Math.sin(Math.PI) ergibt nicht die zu erwartende 0. Aber warum ist dieses Problem in älteren Projekten nie aufgefallen?
Meine Tests ergaben, dass Math.sin(Math.PI) nicht mehr nur 15 signifikante Stellen (wie z. B. auch Math.PI) sondern im aktuellen Flash Player ein paar Nachkommastellen mehr hat. Wenn ich die Genauigkeit nun einfach wieder auf das Verhalten älterer Flash Player ändere und Math.round(Math.sin(Math.PI)*1e15)/1e15 nutze, dann kommt auch wie erwartet 0 heraus. Eigentlich ist dieses Ergebnis ein gutes Zeichen, da die vom Flash Player verwendete Näherung für Sinus und Cosinus nun deutlich genauer zu arbeiten scheint (also mit mehr Stellen). Doch im Einzelfall kann diese Näherung auf Dauer zu Berechnungsfehlern führen, die es früher nicht gab – gerade bei umfangreichen 3D-Berechnungen sollte man das im Auge behalten.
Das Berechnen von Werten scheint sich aber auch an anderen Stellen seltsam zu verhalten. Bei Saban ergab beispielsweise trace(4.4 + 2.9) im Flash Player 10 den Wert 7.300000000000001. Woher auch immer die Nachkommastelle kommt. Und bei einem eigenen Versuch wurde aus 1.0000000000000005 (also der 5 auf der 16. Nachkommstelle) die Zahl 1.00000000000000004 (also eine 4 auf der 16. Nachkommstelle). Mit ActionScript 2 (also der alten AVM) passen die Werte jedoch auch im Flash Player 10 bzw. werden korrekt gerundet.
