Tweeter button
Facebook button
Linkedin button
Delicious button
Digg button

Archiv für die Kategorie 'Flash'

Flo

HTML5 Banner

Die letzten Tage habe ich mich an ein Experiment gewagt, nämlich einen HTML5-Banner zu bauen – ein Kunde war gezwungen das von uns zu verlangen, da auf dem Banner ein populärer Tablet-Computer einer Amerikanischen Firma abgebildet wird ;-)

Die Ausgangssituation: Eine fertig produzierte Online-Kampagne, wie üblich in Flash mit GIF-Fallback, nach einigen Runden durch die Marketing- und Rechts-Abteilung letztendlich auch freigegeben. Dann aber die Botschaft: Es muss in HTML5 produziert werden, ohne aber dass es einen optischen Unterschied gibt. Und wie kann man das erreichen? Hier mein Lösungs-Ansatz:

  1. Das bestehende SWF mittels Swiffy exportieren. Aber Vorsicht, das unterstützt im wesentlichen nur Flash 8 und AS2 – in meinem Fall jedoch nicht so schlimm weil es sich ohnehin nur um eine Timeline-Animation handelte und die wenigen Dinge, die im Code umgesetzt waren, habe ich kurzerhand in eine Timeline-Animation umgewandelt mit kaum merkbaren Unterschieden zur Original-Fassung. Ich habe übrigens nicht den Online-Konverter sondern das Plug-In für die Flash IDE verwendet, so habe ich die Fehler- und Warn-Meldungen direkt im Output-Panel von Flash gesehen.
  2. Einen Anbieter finden, bei dem man so einen HTML-Banner auch ausliefern kann.
    1. Flashtalking: Ging recht simpel. Einfach das vom Swiffy-Plug-In generierte HTML-File nehmen, ein paar Zeilen Template-Code drunter schreiben und fertig. Das Ad war dank Flashtalking-Template auch klickbar, keine weiteren Anpassungen nötig.
    2. DoubleClick Studio: Habe ich dann letztendlich verwendet, da alle Kampagnen unseres Kunden darüber ausgeliefert werden. Hier bin ich dann etwas mehr in die Tiefe gegangen und habe ein Polite-Loading HTML5-Ad mit Flash- und GIF-Fallback angelegt. Dabei sind einige Dinge zu beachten gewesen, die ich nun zusammenfassen möchte.

Zunächst muss man verstehen, dass der Swiffy-Export und die dazugehörige swiffy.js insgesamt ca. 200KB groß ist, also etwa 5x so groß, wie das original SWF. Zwar wird die swiffy.js Google gehostet, muss aber ja doch zur Gesamt-Datenmenge des Ads dazu gezählt werden. Ich habe mich daher entschieden diese Library mit bei DoubleClick als Asset des Ads zu hosten. Bei dieser Datenmenge musste ich nun aber auf jeden Fall das Polite-Loading verwenden, um die initiale Datenmenge klein zu halten. Nach dem Page-Loaded-Event lade ich dann nach und nach alle Assets nach. Erst das CSS, dann die swiffy.js und zuletzt eine JS-Datei mit ein paar DoubleClick-spezifischen Dingen (z.B. ClickThrough) und letztlich dem Swiffy-Object, das ich mir aus dem Export hier her kopiert habe. Der Kern der initialen HTML-Datei sieht also so aus:

if (Enabler.isInitialized()) {
 init();
} else {
 Enabler.addEventListener(studio.events.StudioEvent.INIT, init);
}

function init() {
 if (Enabler.isPageLoaded()){
 politeInit();
 } else {
  Enabler.addEventListener(studio.events.StudioEvent.PAGE_LOADED, politeInit());
 }
}

function politeInit() {

 var extCSS=document.createElement('link');
 extCSS.setAttribute("rel", "stylesheet");
 extCSS.setAttribute("type", "text/css");
 extCSS.setAttribute("href", Enabler.getFilename("DCRM_HTML5_inPage_Polite_300x250.css"));
 document.getElementsByTagName("head")[0].appendChild(extCSS);

 var extJavascript = document.createElement('script');
 extJavascript.setAttribute('type', 'text/javascript');
 extJavascript.setAttribute('src', Enabler.getFilename('swiffyRuntime.js'));
 document.getElementsByTagName('head')[0].appendChild(extJavascript);

 var extJavascript = document.createElement('script');
 extJavascript.setAttribute('type', 'text/javascript');
 extJavascript.setAttribute('src', Enabler.getFilename('DCRM_HTML5_inPage_Polite_300x250.js'));
 document.getElementsByTagName('head')[0].appendChild(extJavascript);

 document.getElementById("container_dc").style.opacity=1;
 document.getElementById("container_dc").style.display = "block";

}

Neben diesem JS-Code befinden sich noch folgende HTML-Elemente in der Datei:

<div id="container_dc">
 <button id="background_exit_dc"/>
 <div id="content_dc">
  <div id="swiffycontainer"/>
 </div>
</div>

Ausrichtung und Größe der Elemente geschieht in einer ähnlich spektakulären CSS-Datei, auf die ich glaube ich nicht weiter eingehen muss.

In dem ‘DCRM_HTML5_inPage_Polite_300x250.js’ befindet sich dann der eigentliche Content, dieses File sieht im wesentlichen so aus:

var container;
var content;
var bgExit;
var swiffyobject = {[hier befindet sich das swiffyobject aus dem export]};

delayed_init = function() {

 container = document.getElementById('container_dc');
 content = document.getElementById('content_dc');
 bgExit = document.getElementById('background_exit_dc');

 addListeners();

 container.style.display = "block";

 var stage = new swiffy.Stage(document.getElementById('swiffycontainer'), swiffyobject);
 stage.start();

}

addListeners = function() {
 bgExit.addEventListener('click', bgExitHandler, false);
}

bgExitHandler = function(e) {
 Enabler.exit('HTML5_Background_Clickthrough');
}

setTimeout (delayed_init, 500);

Das Timeout am Ende musste ich noch mit aufnehmen, weil andernfalls Swiffy offenbar noch nicht ordentlich initialisiert war und der Banner somit einfach leer geblieben ist. Außerdem muss in der initialen Datei auf jeden Fall der Hinweis auf die Codierung enthalten sein, ansonsten gehen bei DoubleClick während des Uploads und Parsings nämlich die Sonderzeichen verloren. Das Einfügen dieses Meta-Tags hat aber die gewünschte Wirkung gehabt:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Ganz am Schluss muss man dann nur noch beachten, in welcher Reihenfolge die Ads in DoubleClick Studio hoch geladen werden:

  1. Erst das Flash-Ad (ggf. ebenfalls mit Polite-Loading-Komponente)
  2. Dann Das HTML5-Ad samt seiner Assets
  3. Dann noch das GIF oder JPG fürs Fallback

Das ganze läuft dann als ganz gewöhnliches InPage Ad und wir über einen einzigen Tag ausgeliefert, der Mediamanager kann dann später entscheiden, welche Browser (-Versionen) welches Ad zu sehen bekommen.

Bei Flashtalking war der ganze Prozess etwas einfacher. Dort habe ich in der von Swiffy exportierten HTML-Datei nur folgendes ergänzt:

<script src="http://cdn.flashtalking.com/frameworks/js/api/2/html5API.js"></script>
<script>
	var myFT = new FT,
	container = FT.query("#swiffycontainer");
	myFT.applyClickTag(container);
</script>

Und dann zusammen mit einer “manifest.js” mit folgendem Inhalt als ZIP-Datei hoch geladen:

FT.manifest({
 "filename":"300x250.html",
 "width":320,
 "height":250,
 "clickTagCount":1
});

Hier hat man dann auch selber noch die Kontrolle über die Browser, auf denen das Ad angezeigt werden soll, so z.B. können alle Opera-Browser und alle Internet-Explorer Version 8 oder kleiner ausgeschlossen werden:

"hideBrowsers":["ie8", "opera"]

Einziger Wermutstropfen bei Flashtalking: Noch ist für HTML5-Ads noch kein polite loading möglich, nach kurzer Rückfrage beim Support ist das aber bereits in Arbeit und sollte mit dem nächsten Release der API zur Verfügung stehen.

Hier findet sich übrigens eine schöne Auflistung, welche Browser in welcher Version den von Swiffy generierten Code unterstützen:
http://www.google.com/doubleclick/studio/swiffy/gettingstarted.html#support
Wer zu faul zum klicken und lesen ist merkt sich das hier:

  • Chrome 18
  • Safari 5.1
  • Mobile Safari 5
  • Android Browser ab 4.0.3
  • Firefox 11
  • InternetExplorer 9
  • Opera 11.60

Wobei man vor allem beim Einsatz von Filtern beachten muss, dass die nur in Chrome, Firefox und Opera angezeigt werden. Alle anderen Einschränkungen beziehen sich auf Sound und dynamischen Text, beides hat aber in gewöhnlichen Banner-Kampagnen keine Relevanz.

Zusammenfassung:
Sofern es das Media-Budget hergibt eine Rich-Media statt eine gewöhnlichen Kampage auszuliefern, und sofern man sich auf Timeline-Animationen mit wenig Code und das dann auch noch in AS2 beschränkt, ist Swiffy eine gute Alternative zur kompletten Neu-Erstellung in anderen Tools wie Edge oder Hype, zumal auch diese Tools mit ihren eignen JS-Bibliotheken daher kommen die ebenfalls eine Auslieferung als Rich-Media erfordern würden. Das gleiche gilt für Wallaby, das darüber hinaus zu keinem befriedigenden Ergebnis geführt hat. Auch Online-Tools zur Erstellung von HTML-Ads wie der “HTML5 Banner Maker” erzeugen bei mäßiger Optik riesige Files die ebenfalls nicht als Standard-Ad laufen könnten. Das einzige also, was Swiffy für diesen Einsatz das Wasser reichen könnte bleibt echte Handarbeit. Dann allerdings wird das Ergebnis mit Sicherheit optisch nicht mehr mit einem SWF vergleichbar sein, über den zusätzlichen Produktionsaufwand möchte ich ja gar nicht nachdenken, schließlich wird man für eine Vielzahl der Browser nach wie vor Flash-Banner benötigen und wird somit um die Erstellung von SWFs so wie so nicht drumherum kommen.

Flo

Play!

Gerade ein Ticket gekauft:

Freu mich schon :-) Danke an die Flex User Group München für die 20% Nachlass!

Die letzten Tage habe ich mich mal wieder mit der erstellung von MXP Extensions beschäftigt, das letzte mal, dass ich das getan habe, liegt schon ein paar Jahre zurück. Ein paar interessante Dinge haben sich geändert:

Neues Format
Neben “MXP” gibt es nun auch “ZXP” Extensions, der einzige Unterschied ist aber, dass man dort eine digitale Signatur zur Identifizierung des Herausgebers integrieren kann

(Einigermaßen) automatische Updates
In dem MXI File, welches die Basis für die Erstellung der Extension darstellt, kann auch eine URL zum Aktualisieren der Extension hinterlegt werden. Allerdings muss man immer der Extension-Manager explizit starten um zu sehen, ob von einer Extension ein Update verfügbar ist. Lieder meldet sich die Extension nicht von alleine, wenn eine Aktualisierung zur Verfügung steht.

Mit diesem Wissen habe ich mich nun an eine konkrete Aufgabe gemacht: Eine Extension entwickeln, die bei der Erstellung von Online-Kampagnen für einen expliziten Kunden helfen soll. Was gehört also alles dazu?

  1. Template FLA Dateien
  2. Vordefinierte Filter
  3. Schriftarten
  4. eine Handvoll Klassen

Fangen wir mal von Vorne an. Zuerst benötigen wir einen Ordner, in dem wir alle Daten für die Extension sammeln wollen, den lege ich mir der Einfachheit halber auf dem Desktop an. Dort lege ich schon mal eine Kopie von einem Beispiel MXI-File rein, das ist das XML-Dokument, in dem meine Extension beschrieben wird. Eine Vorlage befindet sich im “Samples” Folder des Extension Managers.

Jetzt zu den Templates. Jeses FLA kann über “File > Save as Template…” gespeichert werden, die Datei landet dann in dem Benutzer-Ordner unter “Templates” (am Mac unter “<HardDisk>/Users/<userName>/Library/Application Support/Adobe/Flash CS5/<language>/Configuration/Templates/”, unter Windows XP unter “C:\Documents and Settings\<userName>\Local Settings\Application Data\Adobe\Flash CS5\<language>\Configuration\Templates\”, ab Vista “C:\Users\<userName>\AppData\Local\Adobe\Flash CS5\<language>\Configuration\Templates\”). Genau dort kopiere ich später die Teamplates mit Hilfe des MXP wieder hin, ich erstelle die FLAs aber trotzdem alle über “Save as Teamplate…”, weil man so noch eine Description in die Metadaten der Datei schreiben kann, die später im Dialog wieder angezeigt wird, wenn man eine neue Datei auf Basis dieses Teamplates erstellt. Also erst mal alle notwendigen Teamplates erstellen und dann in den selbern Ordner verschieben, in dem schon das MXI File liegt.

In den FLAs hatte ich übrigens Filter verwendet und diese über die Option “Presets > Save as…” im Filters-Panel gespeichert. Jeder auf diese Art gespeicherte Filter landet als XML Datei im Ordner “Filters” im oben beschriebenen “Configuration” Ordners, also direkt neben den Templates. Diese XML Dateien habe ich nun ebenfalls in den Ordner zum MXI File verschoben.

Alle Schriftarten, die in den Teamplates verwendet werden, kopiere ich ebenfalls in den Ordner zum MXI, außerdem noch den Ordner, in dem sich meine ActionScript Klassen befinden. Und genau hier habe ich besonders lange nach einer guten Lösung gesucht, denn es gibt leider keine Möglichkeit bei der Installation eines MXP automatisch einen neuen Classpath zu Flash hinzu zu fügen, also habe ich mich dazu entschieden, in den Templates selber einen Filebased-Classpath zu hinterlegen. Also alle Templates noch mal öffnen und unter “File > ActionScript Settings…” unter “Source path” den Eintrag “$(LocalData)/Classes/myClasses/” hinzu gefügt. Flash sucht die Klassen dann automatisch, je nach System, wieder in dem weiter oben beschriebenen “Cofigurations” Folder.

So. Jetzt sind alle Dateien schon mal vorbereitet und müssen vom MXP nur noch an die richtigen Stelle verschoben werden. Und das sieht im MXI so aus:

<files>
<file name=”My first Template.fla” destination=”$flash/Templates/My own Template Subfolder” />
<file name=”My Custom Filter.xml” destination=”$flash/Filters” />
<file name=”com” destination=”$flash/Classes/myClasses” />
<file name=”myFont.otf” destination=”$Fonts” />
</files>

Das war’s schon, jetzt noch schnell die Update-Funktion einbauen

<update url=”http://www.example.com/update.xml” />

Und folgendes in die update.xml auf dem Webserver schreiben:

<ExtensionUpdateInformation>
<version>1.5.0</version>
<download>http://www.example.com/myExtension.mxp</download>
<description url=”http://www.example.com/myDescription/”>
<![CDATA[The 1.5 version fixes known problems.<br>
New features include the ability to download updates.
]]>
</description>
</ExtensionUpdateInformation>

Im Extension-Manager muss man nun nur noch “File > Package MXP Extension” anklicken und das zuvor erstellte MXI File auswählen – fertig ist die eigene Extension. Dieses PDF hat mir bei meiner Arbeit an der Extension sehr geholfen:

http://help.adobe.com/en_US/extensionmanager/cs/using/MXI_tech_note.pdf

Eins noch: Problematisch wird’s, wenn Bestriebssystem und Flash nicht die selbe Sprache haben. Wenn z.B. das OS deutsch ist und Flash englisch, werden bei der Installation die Template-FLAs in den Ordner “de_DE” statt “en_US” kopiert (siehe oben bei der Beschreibung des Configuration-Folders der Platzhalter “<language>”) und daher in Flash nicht angezeigt. Eine Lösung für dieses Problem gibt es offenbar leider noch nicht.

Seit heute ist es endlich bestätigt, ich fahre nicht nur auf die Konferenz am 6. und 7. April sondern nehme am 8. April auch an einem der ganztägigen Workshops teil: Hercules – Flex 4 (Hero) Professional – von und mit Florian Salihovich. Das wird ein Fest. Alle, die noch kein Ticket haben schnell hier klicken, ein paar sind noch verfügbar!

Flo

HTML5 vs. Flash

Und schon wieder geht es um dasselbe Thema, der Titel hätte der gleiche sein können wir im letzten Beitrag, ich wollte aber etwas Abwechslung haben. Heute geht es mir wieder ein mal um das Missverständnis, dass HTML5 der “Nachfolger” von Flash sein wird oder könnte oder was auch immer. Ständig werde ich gefragt: Wie siehst du denn die Zukunft von Flash? Jetzt, wo es HTML5 gibt! Ich habe kürzlich einen Artikel gefunden, der mir aus der Seele spricht:

http://www.greensock.com/flash-html5/

Hier ein paar der Punkte:

  • Noch ist die Verbreitung von Browsern, die HTML5 vollständig unterstützen, nicht zu vergleichen mit der Verbreitung des Flash-Plug-Ins. Wer seinen Browser testen möchte kann das übrigens hier tun: http://html5test.com
  • Das Video-Tag ist toll, unterstützt aber weder Streaming noch DRM. Wer seine Inhalte also schützen will, wird um Technologien wie Flash oder Silverlight nicht herum kommen.
  • Fast schon ein wenig traurig aber absolut wahr: So lange es Werbung im Internet gibt, wird es auch Flash geben. Bei Bannern gibt es keine Konkurrenz – und das wird auch so bleiben. Und somit behält Flash und das SWF Format seine Relevanz. Ende.
Flo

Flash vs. HTML5

HTML5 muss nicht das Todesurteil für Flash sein wie viele es behaupten. Vielmehr können die beiden Technologien Hand in Hand funktionieren! Wer von Flash redet, meint ja häufig nur das kompilierte SWF File, aber man sollte künftig auch über die Flash IDE als Editor für HTML5 Animationen nachdenken, wie dieser Artikel zeigt:

http://insideria.com/2010/10/here-they-come—html5-css3-ti.html

Flo

Robotlegs

Wie an meinem letzten Artikel zu erkennen ist, beschäftige ich mich zur Zeit mit dem Robotlegs-Framework. Für alle, die das auch tun möchten, habe ich hier ein paar Links zusammengestellt die ich für überaus nützlich halte.

Robotlegs AS3 Micro-Architcture – Die Heimat des Frameworks
http://www.robotlegs.org

An Introduction to Robotlegs – Umfangreiche Einführung in das Framework von Joel Hooks
http://insideria.com/2010/06/an-introduction-to-robotlegs-a.html

Robotlegs Demos – Eine Sammlung von 11 Demo Applikationen
https://github.com/robotlegs/robotlegs-demos-Bundle

Best Practices
https://github.com/robotlegs/robotlegs-framework/wiki/best-practices

Robotlegs Einführung – Zweiteiliger (deutscher) Screencast von Florian Plag


YouTube Direkt


YouTube Direkt

Wer gerne seine Flash-Projekte in der Flash IDE bearbeiten und kompilieren möchte statt FlashBuilder zu verwenden, muss auf eine Kleinigkeit aufpassen, wenn er das Robotlegs Framework einsetzt:

In den Publish-Settings muss auf jeden Fall “Export SWC” markiert sein, andernfalls werden beim Kompilieren die Metadaten verworfen und es kommt zu Runtime-Errors. Mehr dazu hier:

http://knowledge.robotlegs.org/faqs/framework-core/is-robotlegs-compatible-with-the-flash-ide-cs3cs4

Vor wenigen Wochen wurde ich von Adobe eingeladen, am Beta-Test für “AIR for Android” teilzunehmen. Kaum 24h nachdem ich begonnen hatte mich damit zu beschäftigen, war meine eigentlich fürs iPhone entwickelte App “MiniZoo” schon für Android lauffähig. Genau genommen war sie das innerhalb von nur wenigen Minuten, ich habe nur eine Weile für die Installation der Tools, lesen der Dokus und fürs Organisieren eines Developer-Accounts sowie eines Zertifikats benötigt. Nun bin ich gerade dabei alle Schritte verständlich zu dokumentiren und werde diese auf der flashconference am Freitag im Vergleich mit dem Development-Prozess von iPhone-Apps präsentieren.

Lange habe ich darüber nachgedacht, ob mein geplanter Vortrag auf der flashconference noch Sinn macht, wo Apple doch Adobe gewaltig gegen den Karren gefahren ist und iPhone-Apps, die mit Flash erstellt wurden, durch die neuen Bestimmungen “aussperrt”. Hier das Ergebnis meiner Überlegungen:

  • Ich werde über iPhone-Apps sprechen, aber nicht ausschließlich im Zusammenhang mit Flash
  • Ich werde über Flash- und AIR-Applikationen für Mobile Devices sprechen, aber nicht im Zusammenhang mit Apple

Folglich hat sich der Titel des Vortrags auch geändert in “Creating and Publishing Mobile Apps with Adobe® Flash® CS5“. Spannend wird der Vortrag allemal, wo sich doch im Bereich der Mobile Apps bei Adobe in letzter Zeit einiges getan hat und man nun mit AIR und FlashLite 3 ganz neue Möglichkeiten hat.

Etwas anderes hat sich zusätzlich geändert, denn die flashconference findet nicht wie in den letzten beiden Posts angekündigt am 6. Mai statt, sondern wurde innerhalb der FMX auf den 7. Mai verlegt.

Nächste Einträge »