First, the obvious: Fnk is built with Adobe Flash technology, using the Actionscript language (version 3), as it’s meant to be an environment that can be ran on all kinds of computers, both from the user’s browser and as an application. When people think of Flash (or Actionscript), however, most think of Adobe’s proprietary Flash content IDE (nowadays called Flash CS3), and use it as an excuse to explain why the technology isn’t mature enough - it’s not “open”, it’s done for designers, it’s not available on Linux, its coding editing capabilities suck, and so on and so forth. Developers will also complain about how the “.FLA” format is not open (or at least not as open as the .SWF specifications), so developers are tied to the IDE currently available.

While all of these points are true, what many people don’t know or don’t realize is that Actionscript developers are not really restricted to Flash CS3, or commercial tools for that matter, and that .FLA files are irrelevant. And that is, actually, is the gist of this post.

First of all, as a framework for software development, the Flash Platform employs a real compiler that works very much like the compiler you’d find available for other languages - including working as a command line application. That compiler is called the Flex SDK, and is not only free, but open-source and available for all three major operational system platforms.

Second, while compilation is pretty easy as mentioned, editing is another question entirely. Without Flash CS3, how are developers supposed to create their Flash movies?

The answer to this question is a bit longer. Before anything, it’s important to notice that since the Flex SDK compiler take cares of creating the SWF for you - including embedding assets such as graphics, fonts and other kind of data - you can potentially use anything to develop Flash content, even Notepad. This means the question is not whether something can edit Flash projects - any text editor can - but rather how well can it help you create and maintain a Flash project.

Fortunately, there are tools better fit for the job than Notepad. These include commercial tools; with Adobe, other than Flash CS3 itself, there’s Flex Builder - which is a “programmer” IDE built on top of Eclipse - and there’s also FDT 3, which is another Flash-focused IDE built as an Eclipse plugin. There’s a also a number of wonderful free editors available, most notably FlashDevelop. The advantage of these editors is offering features for easier editing and debugging such as code completion, automatic importing, syntax highlighting and hinting, project management, and so on.

Back to the topic, what am I using for Fnk?

First of all, no, I’m not using Flash CS3. While I still do use it (in all real-world projects, in fact) I’d only use it to edit graphics assets and set their position on the movie. Since I wasn’t going to do that with Fnk - all graphics assets used (the application skin) would be dynamically applied - I didn’t need any of that content, so it could be fully edited on an external application.

At first, when I started the project late last year, I was using FlashDevelop for it, since it has been my environment of choice for any kind of Actionscript-related development for a while (if it isn’t obvious enough yet: even when I do all my work in Flash CS3, I use external editors to edit the code). So I’d edit all of my code in FlashDevelop, then quickly switch to the command line (yes, I’m oldschool like that) and run some Ant task that would take care of compiling and running my test application.

That worked pretty well. However, thanks to the influence from Francis Turmel from Firstborn, I decided to give FDT a test and installed a trial version of the software.

I was really, really overwhelmed at first. Since I had never used Eclipse before, the sheer amount of preferences and features available was enough to make me feel pretty dumb. I’m sure that for a seasoned Eclipse developer, FDT is pure bliss, but for me it was feeling more like a sort of a personal Java-based hell.

This didn’t last too long, though. Thanks to many resources available online, as well as some friend which I’m sure enjoyed my pestering immensely, I was able to quickly learn how to use that IDE for the basic tasks of Actionscript editing and, from that, start using some of the more advanced features FDT has to easen development (too many to list here).

Editing code with the Fnk project open

This also represented a decision on the way I wanted the Fnk project to develop. At first, I was interested in using only free software on it, as a sort of a proof of concept for Flash development - showing it’s possible to develop a mature project with free tools and stuff like that. However, while FlashDevelop is a very powerful tool and while it would be perfectly possible to develop this project using it, I was also starting to use FDT for some real-life work and didn’t want to keep switching between two different code editing environments depending on the project. The final decision was that FDT was good enough and I was sticking to it - even oppressed by the avalanche of options, I was more productive with it than without it. Even with its premium price tag, I do think the program is worth the money they charge for it, although I must confess I’ve been lucky in that regard - once the FDT trial has ended, I applied and got a free Open Source license that granted me a full license of FDT, sans tech support, for free (thanks, Simon Elschenbroich and FDT team!).

Running Fnk after compiling

Developing with FDT (as is the case with FlashDevelop honestly) is fairly easy - write your code, manage your project, then compile using whatever tasks you’ve setup to do so by typing whatever keystroke you’ve selected to do so. On Fnk’s case, pressing the typical CTRL+ENTER compiles the project and opens Fnk on a new application window (pictured above). This means you can develop Flash content like you would do with any other application programming language, like Java, C#, VB and so on (yes, I know this is obvious to Flash developers, but a lot of people still fail to understand that).

All compilation is done by Flex SDK and handled by Ant tasks. This brings me to those mentioned “changes” to the Fnk project that motivated this post: the fact that, while the currently available version of the Flash Platform is version 9, I’m compiling Fnk to Flash 10 already.

Explaining is easy: one of the advantages of Flash development is that, since the compiling tools are made available a long time before the updated editors (like the next version of Flash) are distributed, anyone can test new versions of the technology whenever he or she desires. All that is needed is an update version of the compiler, and the player API definition (a .swc file - think of it as the signature of the internally available Flash Player classes). Fortunately, both are publicly available online, and can be found here.

I’ve actually been targetting Flash 10 for a while, but not using any of the new features, as the IDE themselves are still lacking access to some features introduced by the newest version of the platform. What I did today, however, was do a full update of my project settings as well as the FDT environment (since there are now beta versions of FDT available which are more on sync with the new features) to allow me to fully exploit the new features even before new official editors are available. The practical result is that it’s working pretty flawlessly, and thanks to the API definition file, even code autocompletion works perfectly despite being part of some undocumented, unreleased version of the platform.

As a sort of a side note, I’ve been in a sort of an IDE limbo for the past couple of years, never being fully happy with any of the environments I’ve setup for myself and for my highly visual Flash development. But, in the past few months, I’ve grown really confortable with FDT, even though I’m pretty sure I’m still using just a small subset of the features it has; if anything, the only negative I saw in this adaptation process was the steep learning curve of the Eclipse IDE.

I think, however, that this will sort itself out in the future: there are projects like FDTKit (from which I’ve based part of my Flash project structure and most of my ant tasks) which aim to make development easier, and the FDT project itself has now a standalone version (which I still have to test, but that sounds awesome).

All in all, I guess no one has the excuse that there are no good IDEs for serious Actionscript development (specially complex applications) anymore. FDT, FlashDevelop and others have been around for a while to prove otherwise, and are only getting better.

The biggest change I’ve done to my project both on paper and in practice is related to usability testing. While this is something I had already planned (in a way), it wasn’t fully described on my thesis draft, and it was something mentioned during my final review by the college teachers as being one of the biggest holes on my proposal. Due to this, I’m spending some good time writing usability test guides, tasks and outlining its objectives that I’ll be using later this year.

Truth be told, this has been pretty enlightening. Not because it’s something I’ve never seen before: I’ve done formal usability tests in the past, as part of my academic course. But, with normal website interface development, my approach with usability and testing has, sadly, been the same as many other people in the field: work with intuition as you build, then do a few tests at the end of the development, internally and informally, and only change showstopping problems. Of course, nobody thinks this is ideal, but the truth is, it usually works when the client wants to see the website go live yesterday, so it’s the widely accepted norm when you’re not building something heavily based on usability guidelines, like a portal.

With Fnk, I’m doing things a bit more formally - academic style, but with a bit more openness to make use of the Internet - hence why thinking seriously about the task and writing actual test guides has been so interesting. As such, there will be two kinds of usability tests: a few closely directed tests, and public tests.

The first will be a number of tests I’ll conduct with test candidates - selected friends and colleagues who are willing to lend me a few hours of their time - with specific goals in mind and with full result reporting, as well as taping of the user experience process. User tasks will be guided and the goals will be pre-determined, all tied to the current development progress. This is actually what’s forcing me to have a very strictly outlined development schedule (which has also been rewritten); since I will be conducting those tests once a month, it’s important each of the tests are focused on new features and interface elements, or else sequential tests would lose their reason to be.

The public tests, on the other hand, will be a long round of public alpha-testing that will be ran by anyone willing to spend a few minutes trying Fnk. And since Fnk will be easily available on the website, this means anyone, really. People who do so will have the ability to send feedback on the software operation and interface, but I’m still outlining the details of how this will happen. This will be a lot more loosely guided than the other test, though, and there will be constant updates so this is not so much schedule-based.

While this change towards a more formal user experience-focused development (relying on test scenarios instead of intuition only) will cover the biggest sore point in my project, there’s also other thing that popped up during the review of my thesis: what was the reason for selecting the technology I’ve chosen (Flash)?

This is an interesting point because of two things. First, when doing work for college until today, I usually tried to avoid working with Flash as much as I could - the way I see it, there’s no point in doing something with a technology I already know, as the learning process wouldn’t be as effective as it could. That’s the reason why I’ve chosen to work with Max/MSP, Processing and vvvv during some work that didn’t require me to do so, while colleagues picked Flash instead. There’s actually very few works I’ve done using Flash for college, and all of them were selected due to reasons beyond my personal control (either because the course required it, or because the rest of my group wanted to use it).

Enter Fnk, and it’s a bit ironic that my last work done for college is finally based on Flash by my own choice; while I have looked into alternatives like Java (and even C# when I contemplated a different target), I decided on Flash specially because of the ubiquity of the player and the features I knew would be present in Flash Player 10. However, I figured that once I knew it was the best platform for the task, it wasn’t worth going to deep in explaining my reasoning; it just felt the obvious choice. This proved to be a problem during my review, and this brings me to my second point: because some teachers know I work with Flash, they tend to think I’d selected Flash solely because it was easier for me, not because I actually believe it’s the best choice for the specific task at hand. This was also pointed during my review, and that’s when I realized my defense of Flash on paper was too weak - barely mentioning the flash player penetration statistics, and also failing to mention the negative implications of this requirement.

The result of this all is that another new chapter of my thesis will be solely dedicated to explaining the selection of Flash as my platform of choice for this job, specially comparing it to alternatives such as using Java, JavaScript, and others. Should be an interesting read.

As a final note, it’s interesting that, when confronting the work you have planned - and which you’re sure will work - with the critical opinion of others, they’ll always find some important holes where you see none, even if they’re not so into the technology you’ll be working with, or if they don’t fully understand all parts of the project. My teachers might not be so Flash-savvy as I am, but they’re still intelligent people and had a bunch of valid points. This kind of confrontation is also interesting because it may help you understand your actual thought process - things you don’t even care a lot about might be the first thing some other teacher will mention, and it’s easy to misunderstand their point.

Anyway, before my final review last semester, I had the belief my project was pretty solid. I still think it is, but after those two points get explained in longer detail, I have no doubt it’ll be a full step ahead in terms of quality of the written content.

GPU acceleration isn’t exactly a feature that will magically make everything faster inside Flash, however; it can even make matters worse. It doesn’t use hardware-accelerated 3d rendering, either. Tinic Uro - Adobe Flash Player engineer extraordinaire - discusses this in What does GPU acceleration mean?, an article that tries to demystify this new feature and goes deep into the crazy world of the different wmodes used by the Flash Player.

One big downside to the new GPU features is that, differently from what was previously semi-announced via some developer blogs in the past, the new pixel shader features on Flash 10 will not be using hardware acceleration, as stated by Tinic in his Adobe Pixel Bender in Flash Player 10 Beta article. This will be somewhat limiting for the prospects of real-time image processing in Fnk, but I guess it’s a first step.

Still, some of the new GPU features are pretty positive and something Fnk may make use of in the future. I’ll have to test it out and see what perform best both during editing mode - when a patch is being edited, with results displayed on the nodes themselves - and during fullscreen mode, when just one of the nodes is used as the solo visual output for presentations (with no editing interface).

Last Friday (May 16) was the due date for this paper. It was a whole lot of work - and, worst of all, time I had to be away from actually working on developing Fnk itself - but I was able to finish the text and deliver it in time. I’ve added its content as an HTML link and as a PDF download to the About page, but it’s all in Brazilian Portuguese for now (I’ll translate it sometime in the future). I will also have to hold a small presentation on the project in two weeks from now, but for all purposes, this first stage is pretty much done.

More importantly, though: once this stage is complete, the remaining one is writing the final paper - which is only due later this year, when the project itself will be finished. This means I can dedicate all my academic time for the rest of this year in actually developing Fnk and having it work. Maybe I’m just too much of a hands-on kind of guy, but writing about what I’d do and how instead of actually doing it was killing me.

Anyway, one of the things I’ve done this weekend to get back in track is porting the existing Flash 9 project to a proper Flash 10 project, as it’s been all the rage for the past few days. Turns out this is a bit more complicated than it sounds, since there’s some features you can’t use yet - in short, existing editors won’t understand the new goodies used by Flash 10. You can compile to it, but editing it is another can of worms entirely.

I finally have some a function Flash 10 version of the project, and it’s working better than ever, even if I can’t make use of everything I want yet (like typed Arrays!) without having my editors puke on my face because of the syntax (more on the integrated development environment I use in the future - it’s not Flash itself). However, in the near future, some small tidbits - like being able to load files locally via the new FileReference - will make a hell of a difference in terms of project capabilities.

Also due to this, it’ll be sometime until I finally update the existing (very alpha) online version of Fnk, because I’ll want to do so with a more stable version. The current online version is already pretty out-of-date - it’s using build 485, while the newest one I have is 791 - but it’s because I’ve removed a few features (like moving nodes around) and I won’t update the online version until they’re working again, something which require me finishing the new selection features. Still, it’s looking - and running - better than ever. I can’t wait until I’m actually able to create some graphics (and sound!) there.

The Fnk project, since the beginning, was targetting Flash Player 10, as many of its new features were already known in advance and they would play a big part in the project. I’m building Fnk’s current test versions targetting Flash Player 9, though, since it’s what we have available; near the end of the year, however, as the project comes to the end of its Alpha phase, Flash Player 10 is the one I’ll be using. It probably won’t happen until I’m building some of the most advanced nodes, though.

Edit: I did not expect this, but Adobe has made updated versions of the Flex compiler and libraries available, so it is possible to create Flash Player 10 content publicly. Perfect; henceforth, Fnk will be compiled against Flash 10 only and will require this version for execution.

At first glance, this is a node-based programming environment with a lot of similarities to what I’m trying to do with Fnk. But instead of going with the simpler, more experimental side as I’m trying with Fnk, it has its own twists - like the ability to easily import any class and to write and compile code on the fly, as well as export the result - which definitely take this to another level.

Update: And because it’s so easy, people have actually ported the Processing IDE itself. There’s a XUL version of the IDE (to run it on Mozilla-based browsers, such as Firefox), and there’s a nifty editor here that’s more web-friendly (although the text editing itself is acting like crazy on my Firefox 3 Beta 5, so be warned).

Both those links come from this page, which has some interesting discussion about the topic. Although I somewhat disagrees with the author’s vision on Flash - I don’t think it’s a “market niche” that a canvas-drawing framework will replace; this to me is as incorrect as the comparison people usually draw between SVG and Flash - I do agree that there’s some hidden value indeed in running (most of) Processing within JavaScript. Let’s see what other nice things come out of it now.

Additionally, based on my script tests, Canvas drawing performance on Processing for JavaScript seems to be on par with actual Processing for Java performance, at least in regards to some repetitive 2d shape drawing. I can’t wait to see what happens when Tamarin is actually used in the next version of Firefox and ends up making it even faster.

As an additional reference, there’s also a video of last year’s MAX event at Chicago which shows a first sneak-peek at what the player will be capable of.