I recently noticed a thoughtful bit of User Experience while using my windshield wipers. Like most modern cars, mine has an intermittent wiper mode that includes a dial to control the frequency of wiper activation. What I noticed is that when you adjust the frequency so that the wipers activate more often (in shorter intervals), they also activate immediately regardless of where it was in the timing cycle. When decreasing the activation frequency this does not happen, and the wipers don’t activate again until the next interval is reached.

Now, you may be thinking who the hell cares, but I haven’t been able to get it out of my head since I noticed it. I think it shows quite a bit of thoughtfulness by whoever came up with the idea and managed to get it implemented. It’s not something anyone would complain about if it weren’t there, and it surely goes unnoticed by hundreds of thousands of people, but it shows a clear understanding of users’ intentions and acts on them. If you’re increasing the wiper activation frequency, it’s because the rain has picked up and you not only want the windshield cleared more quickly in the future, but you probably want it cleared now as well. After all, if the rain hadn’t built up on the windshield you’d have no reason to make the wipers go faster. Somebody recognized that and made sure that that desire, no matter how subtle, would be met.

The takeaway from this odd little post is hopefully that next time you are implementing a feature, think about not just what the user is doing, but why they’re doing it. If you do, you may be able to not only meet their expectations, but exceed them.

Just a quick note that I have changed hosts for this site. It should be seamless but please let me know if you encounter any issues. I can be reached at ben.clinkinbeard on Gmail.

Thanks,
Ben

A couple of weeks ago, I posted about a workflow I had devised that allowed me to utilize Flash library symbols but still write my code in Flex Builder. While Adobe apparently thinks this awkward hybrid approach qualifies as “integration”, I thankfully discovered a better process just a day or so after my posting. I discovered the main concept of this better workflow from Arpit Mathur’s blog.

What it basically boils down to is using Flash authoring to create a SWC that you then use as a library in your ActionScript project in Flex Builder. Getting Flash authoring to generate a SWC is as simple as checking a box in the Publish Settings dialog.

Then make your ActionScript project use the resulting SWC.

What you can then do is create ActionScript classes that extend the symbols in your Flash file. As long as you give your symbol a linkage name it will be available for extension (and will itself extend MovieClip by default), allowing you to add behaviors and logic using class-based ActionScript like developers expect and prefer to do. The convention I have settled on is to add “_Symbol” to the end of the class names specified in Flash authoring to make it completely clear where everything originates.

The other major advantage this approach has is that it renders the “Automatically declare stage instances” debate irrelevant. You can let the designers leave this setting off and write bits of timeline code if they need to and your classes that extend their symbols will still work. Regardless if they are specified manually in class files for the symbols themselves or Flash generates the classes automatically, the children of your symbols (text fields, child movie clips, etc.) will all be available to your code.

With this simple structure of a symbol in Flash:

You can write a class like this to control it.

The result is a functioning button that allows the designer to use the expressive, proven tools in Flash authoring to create the graphical assets while allowing the developer to use the mature code editing environment of Flex Builder. This process has proven valuable and efficient over the last two weeks and it addresses the major shortcoming of my previous post. That was an inability to use a proper debugger, and it also lets the designer and developer work in parallel, both in the environment most familiar to them. It lets each tool and each team member do what they do best.

While I developed this workflow (not that its an original one by any means, just new to me) due to my assignment on a project that could not use Flex, I actually think it could be valuable in Flex projects as well. For views that are highly detailed and/or non-standard it may very well be easier to let your designer create them in Flash than it would be to create some crazy MXML file that carefully layers exported images and animations that you then try to wire up and orchestrate with code. Simply write a class that extends your designer’s symbol and manipulates it as needed.

To me this seems like the best kind of workflow available today by far, and so its really disappointing and frustrating to think Adobe may not be taking things a step further in their next releases. We don’t need or want Flash Builder to compile and run our projects in Flash authoring. What we need are workflows that allow us to use tools that do their job well and that we’re comfortable with, and that simplify the inevitable round tripping between design and development. Having Flash Builder trigger compiles in Flash authoring may sell more licenses to the uninformed, but its a sad excuse for integration from a company that creates tools ranging from authoring to runtime.

All code and sample files for this post can be found in my Google Code repository.

I started receiving this error in a Flex library project tonight and did some Google-ing. Thanks to a comment by Eric Hélier on this bug I was able to quickly fix the issue.

Eric mentioned the marking of Flex SWCs as external, which I had recently done. In my case though, it seemed to be marking locale as external that messed things up. I deleted the following line from my .actionScriptProperties file and the error disappeared, and leaving the locale merged in does not seem to affect SWC size anyhow.

<libraryPathEntry kind="1" linkType="2" path="${PROJECT_FRAMEWORKS}/locale/{locale}"/>

I hope this helps somebody out of a jam, preferably late at night or right at crunch time.

Nostalgia and complaining

Years ago, before AS3 and Flex 2 were on the scene, I was a Flash developer. I dabbled in other things like PHP, JavaScript and the horrific “classic” ASP, but Flash development with AS2 was always more interesting to me. I worked with great designers who of course used Macs, while me and the rest of the developers were on PCs. (Don’t worry, I use a Mac now.) In order to preserve the designers’ fonts and hand crafted animations, we taught them how to assign linkage names to their symbols and would have them deliver a .swf to us that had nothing on the stage, allowing us to pull symbols out of the library as we needed. Using the fantastic MTASC compiler and an editor like PrimalScript, our class-based AS2 code would be injected into the designers’ .swf, bringing the site/game/whatever to life. Ahh, those were the days.

Fast forward to last week when I was assigned to my first ever non-Flex AS3 project and discovered that developing like we used to in Flash (tying AS classes to library symbols) is pretty painful these days. Or at least it was for me, until I constructed a very convenient workflow that you can probably guess at based on the title of this post. Now, I should probably explain what I mean by painful. You can write your AS3 classes in Flash authoring, and the process is very straightforward; just create classes whose names match the symbol linkage names and you’re done. Just like AS2. However, Flash authoring’s code editor is absolutely abysmal. I mean, I knew it was bad, but I was actually shocked at how bad it is. It won’t even create import statements for you when you create properties! If you have used Flex Builder or any other decent editor for more than 10 minutes, this is completely unacceptable. You could also write your code in Flex Builder, save, switch to Flash authoring and then test movie or publish from there. Honestly though, do you really want to do that 500 times a day? Me neither.

So, what is this better way you ask? Well, we use one improvement that did come with Flash authoring’s support of AS3, which is the document class construct. This means that you simply create a custom class to represent your application, make sure it extends MovieClip, and tell the .fla to use it. We don’t need any code at all in our .fla, unlike back in the day. This essentially means that your custom class is your root timeline, and adding display objects to it is like adding them to the stage.

Coding in Flex Builder

Since I use a Mac, Flex Builder and FDT are the only realistic options for AS3 editors, as far as I know. If you are on a PC, FlashDevelop is also a great program. Now, Flex Builder allows you to create ActionScript projects. In contrast to a Flex project, I assumed an ActionScript would be devoid of any reference to Flex SDKs, but this is not the case. Your ActionScript project will still reference an SDK in the compiler settings and in the build path dialog, but that is OK. Since you don’t reference any Flex classes, you will not be pulling the framework into your .swf. I think it is only referenced so Flex Builder knows where to find mxmlc, but I am not completely sure. In order to use library symbols as class instances, you will need to create corresponding classes (that extend MovieClip) for them that match the name specified in the their linkage field. Whether you need to add custom code or not, the classes must exist in order for you to reference them in Flex Builder. To reference their properties, like child text fields or buttons I declare those properties in the class and turn off “Automatically declare stage instances” in the .fla’s publish settings.

Compiling in Flash authoring

OK, none of that was revolutionary but now comes the hard part. How do you compile/test your project without having to switch back to Flash every time? The first piece of the puzzle is to use the flashcommand Python script that Mike Chambers posted a long time ago. (It is only for OS X in its current state but I would assume creating a PC-friendly version wouldn’t be too hard.) All this really does is open Flash if necessary, and compile the .fla(s) you tell it to, by writing JSFL to a temporary file and then running a line of AppleScript to execute the JSFL code. That is really great, but switching to Terminal every time I want to compile is no better than switching to Flash. I needed something I could trigger from within Flex Builder, so I naturally turned to Ant. All you need is a super simple build file, like this:

As you can see, it just sets up a couple of properties and asks Python to run the flashcommand script. The -e argument tells flashcommand to include doc.exportSWF() in the generated JSFL, which will publish the .swf to the location specified in the -o argument. If this is all you need to do, but want to then launch the newly created file in Flash Player, you can add the following to your build.xml file.

That was my initial approach but it makes viewing your traces kind of a pain. The easiest way I found was to tail your flashlog.txt file but that still kind of sucks. Its especially bad because a LOT of .swfs on the web still include trace statements, meaning your Terminal is flooded with statements generated by every banner ad running in your open browsers.

What I ended up doing was to edit flashcommand so that the -e argument also adds fl.getDocumentDOM().testMovie() to the generated JSFL, causing Flash authoring to execute a test movie action. I also added activate to the end of the generated AppleScript so that Flash’s test movie window would be brought into focus and ready for interaction. This allows you to use Flash’s built in Output panel to view your trace statements, and your trace statements only. (I tried making the test movie option a separate command line argument but couldn’t get it working correctly. If any Python hackers out there want to show me the way I’d be much obliged.)

Set up a keyboard shortcut in Flex Builder for running Ant and your workflow is almost identical to a Flex or code-only ActionScript project. Your .swf will be generated and published to whatever location you’ve specified, and will also be opened in Flash authoring for visual inspection and testing. I am probably not the first to come up with something like this, but I didn’t find any good links on the subject and other people expressed an interest in hearing about my workflow. If you have suggestions on further improvements (like how to use Flex Builder’s debugger for these projects) I would love to hear them. Regardless, I hope this is useful to other coders who find themselves needing to develop AS3 projects that associate custom classes with library symbols.

If you’d like to replicate this setup, you can download my modified version of flashcommand.

Enjoy!

If you subscribe to the RSS feed it should hopefully be seamless (don’t fail me now Feedburner), but I thought I should mention it here just in case. This blog is moving to benclinkinbeard.com, and returnundefined.com will be forwarded to the new domain. Please let me know at ben.clinkinbeard AT gmail.com if you encounter any issues. Thanks!

I have created a Google Group for the Flare data visualization library. Flare is currently hosted on SourceForge and their forums are terrible. I have started (and will continue for some time) working with Flare pretty extensively, so rather than suffer in silence (something I may in fact be incapable of doing) I decided to create a group somewhere better. Hopefully this better platform will help boost the level of discussion, because it is currently pretty low. If you know current or potential Flare developers, or are one yourself, please help spread the word and join the discussion.

I will soon be starting a series of posts about Flare, so if the library interests you be sure to check back soon.

If you’ve ever used an AdvancedDataGrid, chances are you’ve encountered HierarchicalCollectionView. If you’ve ever used an AdvancedDataGrid for anything remotely complex, chances are you’ve cursed and shaken your metaphorical fists at HierarchicalCollectionView.

There are likely myriad reasons to despise this class but the one that burned me was this gem: any filterFunction applied to your HierarchicalCollectionView is also applied directly to your underlying child collections. In case the ramifications of that are not immediately clear, what it means is that you cannot simultaneously have two distinct views of a single data set that you have wrapped into a HierarchicalCollectionView. In fact, once applied you will have to manually clear the filter from underlying collections in order to get them back to normal. Because of this, the class is of extremely limited utility, and I would submit that its name is highly misleading. The ‘View’ at the end of the name implies that it will be creating a “virtual” view of the underlying data, leaving the source intact. This is how the immensely useful ListCollectionView class works. Apparently, other languages/frameworks also have “collection view” classes that do not modify the underlying data, so this is quite a departure from convention, not to mention common sense.

If you happen to look at the docs for HierarchicalCollectionView you will notice that filterFunction isn’t even listed as a supported property. Maybe the thinking was if they don’t tell anyone about it, we’ll overlook how poorly implemented it is?

I don’t really want to get fully involved in the discussion being had by Ryan Stewart, Asa Dotzler and Simeon Bateman. However, in reading through each argument a few things Asa said struck me as particularly indicative of the fact that he, and I suppose maybe Mozilla as a whole, simply don’t get it. I am admittedly cherry picking here, but I couldn’t resist pulling out a few quotes.

Open is developing the protocols and specifications in a co-operative and participatory environment and then competing on implementations.

Replace “Open is” with “The colossal headache that is developing consistent experiences that are cross browser/platform and engaging to users is thanks to” and you’ve got a true statement. I use Firefox as my primary browser and think overall its a great application but unfortunately, telling a client their new site looks great in Firefox and like garbage in IE won’t exactly result in a lucrative career. Developing for “competing implementations” sucks, and its a large part of why Flash Player is so widely embraced and successful.

If I was in Adobe’s shoes, I’d give everything away, all of it. Hell, I’d pay people to develop on the Adobe platform and I’d encourage dozens of competing implementations of my platform across every type of device imaginable because, in the end, it’d be my platform and I’d decide how and when it evolved and to what ends.

See above for my thoughts on competing implementations.

So, all I can do in this battle for the future of the Web is to advocate for advances in real open Web standards from groups like ECMA, W3C, and WHATWG. It may be a bit slower to market, (hopefully not too much slower,)…

A bit slower? Seriously? Just a bit? Far as I can tell HTML 4.01 was finalized in December of 1999. Nineteen ninety freakin’ nine. Best I can tell the latest Flash Player back then was version 4. So in the 9 YEARS we’ve been stuck with HTML 4 there have been 5 full version releases of Flash Player. If thats a bit then I am just a bit shy of being a billionaire. Yes, Firefox has had a few releases in that time but it wasn’t adding any new capabilities, just improving its implementation of the same old spec.

So be patient everyone, for by 2011 you will almost certainly have a finalized HTML 5 spec and, not only that, your choice of no less than 4 major implementations of it to choose from!

Following Adam’s lead, again, I thought I would post the link to the feedback provided by people who attended my session last week in Atlanta. Tom and John rock the transparency vibe pretty hard so I figure its fitting for the speakers to do the same. This was my first time presenting at a conference and overall I was pretty happy with the outcome. I think the feedback stating it focused on FlexMDI a bit too much is probably valid and I apologize for that. My intention was simply to use it as a vehicle to illustrate the concepts I was discussing, I didn’t mean to showcase it in any way. I’d also like to repeat that I was/am not the only developer of FlexMDI. It was a joint effort between myself, Brian Holmes and Brendan Meutzner.

View the feedback

Thanks to everyone who attended, even if you didn’t provide feedback! Though I really like those of you who did