Colin Moock & ActionScript 3.0 - Mein Kommentar
Letzte Woche veröffentlichte O’Reilly auf seiner InsideRIA-Plattform einen Artikel von Colin Moock, der sich wie ein Lauffeuer verbreitet.
Moock äußert seine Gedanken zu der aktuellen Produktstrategie von Adobe im Bezug auf die Flash-Plattform. Neben der allgemeinen Situation geht Moock auf neun Aspekte von ActionScript 3.0 ein, die er als kritisch empfindet und bietet in Teilen gleich sehr durchdachte Verbesserungsvorschläge an.
Ich kann den Aussagen von Moock in der Regel zustimmen und sie in Teilen sogar erweitern. Nachdem ich in diesem Semester auch an der HAWK in Hildesheim in allen Kursen ActionScript 3.0 gelehrt habe, bekam ich einen zusätzlichen und sehr interessanten Blickwinkel auf die Flash-Plattform durch die Aussagen einiger Studenten.
Man selbst hat über die Jahre gelernt bzw. sich damit abgefunden, wie gewisse Dinge funktionieren. Für absolute Neueinsteiger ist die Messlatte ohne Frage insgesamt höher als früher, wobei ich da nicht ActionScript als Sprache als Probleme sehe, sondern viel mehr die schlechte IDE.
Aus meiner Sicht wurde einfach immer mehr an die IDE rangestrickt. In der nächsten Version wird es Support für „Inverse Kinematics“ geben, was viele Anwender freuen wird, aber ich bin gespannt, ob zum Beispiel Krücken wie der Editor, die Bibliothek oder auch die Verknüpfung mit externen Source-Dateien überarbeitet werden. Natürlich ist mir auch bewusst, dass sich aus Produktsicht solche Verbesserungen schlechter verkaufen lassen, als bessere Grafik- und Animationseffekte, aber im Alltag ist mir eine solide und logische IDE lieber als ein Tagesfeuerwerk. Und nur wenn ein Produkt in der täglichen Nutzung Freude macht, wird man es auf Dauer einsetzen.
Betrachtet man die Lehrpläne von Fachhochschulen und Universitäten, dann wird deutlich, dass man in der Lehre vermehrt auch auf Processing setzt, um vor allem auch Designer an das Thema Programmierung heran zu führen. Die reduzierte IDE, kombiniert mit einer vom Aufbau auf Designer ausgerichteten und dennoch sehr leistungsstarken Programmiersprache, stellt eine interessante Alternative für den Einstieg in die Entwicklung interaktiver Anwendungen dar. Auch Node-Based Development-Tools wie vvvv oder Max/MSP sind aufgrund ihrer visuellen Programmier-Umgebung nicht zu vernachlässigen.
Sicherlich verfolgen Proccesing, vvvv und Max/MSP andere Ziele, aber Adobe sollte nicht vergessen, dass man neben den Software-Architekten aus dem Java-Umfeld auch die kreativen Querdenker, Designer und Künstler bedienen sollte. Das Potenzial dieser Gruppen sollte man nicht außer Acht lassen, denn diese Personen erschaffen kreative interaktive Welten, die auch die Verkaufszahlen für ein Produkt enorm steigern können.
Ich bin jedenfalls gespannt, wie Adobe in Zukunft seine Produkte am Markt platzieren wird und welche Plattformen zum interaktiven Pulsgeber werden.
Und wie immer freue ich mich über Eure Kommentare.
25. July 2008
Abgelegt unter: Design, Flash, Publikationen
2 Comments Add your own
1. sascha/hdrs | July 27th, 2008 at 9:38 am
Hmm sehr interessanter Artikel! Als ‘Coder’ fasse ich die Flash IDE nur noch mit ner Zange an! Der AS Editor ist absolut unbrauchbar, frisst Code und macht impotent. Aber es gibt ja zum Glueck Alternativen wie Eclipse und FDT. Als Animation Tool find ich die IDE gar nicht so schlecht aber ich benutze sie meist nur um ladbare Libraries oder custom Components zu basteln.
2. ck | August 2nd, 2008 at 12:41 pm
Über dieses Thema mache ich mir derzeit ebenso Gedanken, allen voran interessiert mich dabei vor allem die Frage, wie (große) Projekte effektiv gestemmt werden können.
Ich kenne Flash seit Version 3 und mochte bereits damals die IDE nicht sonderlich. Vielleicht war das ein Grund mehr, hauptsächlich Flash Development zu betreiben. Nun setzte ich vorrangig Flex Builder ein, weshalb mich die IDE bis heute auch wenig stört.
In den letzten Jahren hat sich bei Flash ein ähnlicher Prozess vollzogen, wie bereits zuvor bei anderen Applikationen, beispielsweise 3D Anwendungen. Mit der steigenden Komplexität sind nun mehrere “Berufszweige” in Form von Flash Designer und Flash Developer entstanden.
Für den Erfolg von komplexen Flash-Projekten möchte ich daher zwei Fragen analog zu Collin Moock aufwerfen:
1. Was kann Adobe tun?
Hier kann ich dir in deiner Kritik an der IDE nur zustimmen. Aus meiner Erfahrung aus dem Studium an der Kunsthochschule Kassel, scheitern äußerst viele an der Oberfläche.
So blieb Flash in den Fachbereichen Grafikdesign und Trickfilm dann doch weit hinter seinen Möglichkeiten. Ich schließe mich hier den Befürwortern einer visuellen Programmierhilfe an. Ein simples Beispiel für solch eine Anwendung ist hier der Automator von Mac OS X.
Wünschen würde ich mir bei solch einer visuellen Programmierhilfe, eine Schnittstelle für externe ActionScript Libraries. Damit könnte man einen Workflow für Flash-Projekte generieren, der es ermöglicht, dass Developer entweder passend zu einem Projekt oder einfach für externe Libraries (z.B. Tweener, GoASAP Sequencer, PV3D etc.) einfach benutzbare visuelle Actions definieren, die dann durch Flash Designer auf die Flashinhalte angewendet werden.
Ich bin gespannt für wen “Thermo” letztlich interessant sein wird. Ob es “nur” zum Erstellen klassischer RIAs brauchbar sein wird, oder auch beispielsweise für einfache Flash Spiele. Und was machen dann Animationsfilmer, die interaktive Geschichten erzählen wollen. Nicht zuletzt würde auch für Autoren von Click-Dummies in Werbeagenturen eine einfache IDE Ressourcen sparen und mehr Zeit für Ideen freistellen.
2. Was können wir tun?
Auch wenn die IDE unkomfortabel ist, bedeutet das nicht, dass sich komplexe Projekte nicht trotzdem einigermaßen effektiv umsetzen lassen. Das wichtigste hierbei ist meiner Meinung nach, eine gute Kommunikation zwischen Flash Designer und Flash Developer. Das hört sich vielleicht etwas banal an, aber scheint mir doch häufig zu kurz zu kommen.
Ein Flash Designer hat im Regelfall keine Lust sich groß mit Scripting zu befassen. Seit AS3 erst recht nicht, denn der Overhead im Vergleich zu AS2, der beispielsweise für eine einfache Buttoninteraktion dabei entsteht, verdirbt ihm erst einmal die Laune.
Aus eigenen Erfahrungen im Lehren von Flash/ActionScript an der Kunsthochschule Kassel, ist es ein guter Weg, neben den Grunden den Benutzern einfache Befehle mitzugeben, mit denen Sie was anfangen können. Animationen sind beispielsweise mit TweenLite schnell erzeugt:
TweenLite.to(mc, 1.5, {x:300, ease:Sine.easeOut});
Was dahinter passiert interessiert den Designer nicht. Nun ist, das leider nicht ganz so komfortabel, wie ein visuelle Darstellung, aber immerhin entstanden in meinem Kurs jede Menge Animationen, ohne dass die Teilnehmer panikartig den Raum verließen.
Für Projekte, in denen es bestimmte projektspezifische Interaktionen geben soll, ist es daher sehr zu empfehlen, bei der Projektumsetzung mit dem Designer zu sprechen und genau festzulegen, was wann passieren und aufgerufen werden soll.
Am Ende werden Flash Design und die Sources zusammengepackt und das Spektakel kann beginnen. Voraussetzung hierbei ist allerdings, dass auch die Architektur, die hinter der Programmierung steckt, auch solide konzipiert wurde (MVC etc.). Grundvorraussetzung ist dabei, die Bedürfnisse der Designer zu kennen und nicht allein auf smarte Programmierarchitektur aus zu sein.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed