This is how I do it.

The chart above is just a sample of one of the reasons I remain skeptical of HTML5 going into the future. The table above lists support for new form attributes. It’s hardly the only table of this sort with this many obvious conflicts. As a developer, how the hell can I be expected to navigate this sort of information? Headaches will abound…

It’s time to speak about a problem that’s been troubling me for quite a while now. Flash CS4 (and certainly versions that precede it) seems to have major problems consistently and accurately rendering text. I’ve prepared some screen captures that demonstrate the problem.

Text Field Properties

It all begins innocently enough. I’ve created a text field on the stage and I move over to the properties panel to toy with it. In this case, the text field uses Arial Regular at 12 points as its font. It’s anti-aliased for readabilty, and it’s selectable.

Embedded Characters

Although I don’t expect that any of my viewers will be without Arial, I embed the font all the same. I make a broad selection of characters that should cover most if not all of my use cases for this text field, without embedding everything.

Editing Text

Now that I’ve configured my text field, I select it on the stage and put in some standard lorem ipsum to test my application with. Everything up to this point seems fine…

How Text Renders

…until I finish editing the text. Now that I have it selected, but am no longer editing it, everything has changed. Compare this screen capture to the one that precedes it.

This problem is not new. It’s particularly pernicious when you’re trying to align other objects with on-screen text.

Perhaps you, like me, have had a need, at some point or another, to parse RSS feeds in Actionscript. If so, then perhaps you’ve also stumbled across the generally wonderful as3syndicationlib developed by Mike Chambers and Christian Cantrell. For those of you who aren’t in the know, allow me to provide the following excerpt from the project’s google code page:

Use the syndication library to parse Atom and all versions of RSS easily. This library hides the differences between the formats so you can parse any type of feed without having to know what kind of feed it is.

These claims actually hold up pretty well…once you get the code running.

The problem is that the codebase was written specifically for development in Flex. While Flex is a great platform for certain projects, many of us still use Flash for a lot of the work we do, so a toolkit that relies on packages that are only available to Flex just doesn’t do it.

This problem is also no secret. It’s listed as an accepted issue on its project page. The problem is that the codebase apparently hasn’t been updated since December of 2006.  That’s no joke kids.

Fortunately, a solution was pushed forth from outside the project by a Mr. Martin Legris in the form of a bare implementation of the missing “DateBase” class that the syndication library looks for, as well as an edit to an import statement buried down in ParsingTools.as.

So if you, like me, have a need to consume RSS/Atom Feeds in Flash and need a solution that works, look no further. I present, to you, an updated version of the as3 syndication library with the necessary changes in place to begin using it out of the box in your flash projects.

The files are all available here.

Today TechCrunch posted an image of the poster for the upcoming film about facebook entitled “The Social Network.” Now, I’m not posting this because I’m even remotely intrigued by the idea of a film about Mark Zuckerberg, but rather because the poster seemed very familiar to me. Check it out below:

Nice, right? Now check out the cover to the Criterion edition of Nicolas Roeg’s “The Man Who Fell to Earth” (starring David Bowie!).

This is pretty obvious, isn’t it? With the exception of the browser bar overlaid on the right of the poster for “The Social Network,” and the slight difference in typography, these are practically the same composition. For my part, I prefer both the typeface and the quality of the photography in the Bowie cover. I don’t know that I care for the “washed out” look of the Zuckerberg cover. Here’s a side-by-side comparison to assist. Bowie is on the left (I hope that’s obvious) and Zuckerberg is on the right.

I’ve always loved the original cover, and I’m glad to see that other people (clearly) do too.

I just had to bring attention to a packaging redesign I saw the other day that really impressed me. The product is 8th Continent Soymilk. Here’s a photo of the old packaging…

This is all quite standard. A nicely lit shot illustrating what you might use 8th Continent’s rich, luscious soymilk for. Perhaps in cereal? Perhaps even with berries? Why not just drink it straight? This just screams “Me Too!”

BOOOOOOORRRRRRIIIINNNNNGGGGGGG!

Here’s the new packaging:

Dig that retro style! I love the simplicity of the illustrations and color schemes. The typography has also been improved. How will I, in the supermarket, figure out what this product is? The way I see it, the attractive design is going to grab my attention and compel me to step closer and read the label. Nice. These designs are both more competent and more confident.

I don’t doubt that flexicious is, as their site claims, a “MUST HAVE” flex datagrid. What I do doubt is that many people will have a better idea than I do what the hell is going on when I look at their demo.

Ho. Lee. Crap. What we’re looking at is a very complicated DataGrid, the flash world’s version of the spreadsheet. Considering that most people’s entire experience with spreadsheets consists of, at most, viewing Excel documents this presentation is unnecessarily complicated.

Upon first glance, I have no idea what many of these controls are supposed to do. Clearly, this is a powerful spreadsheet. I think. I am kind of afraid to touch anything though. Admittedly, I don’t do as much work with large sets of data as some people certainly do, so perhaps its my limited experience with this volume of information that makes so much of this interface seem foreign and confusing to me.

Without jumping too far in depth as to what I found so confusing about Flexicious, I’ll just present my general reactions to it with a few accompanying screenshots. My reactions proceed as follows:

1. I don’t like this.
   
2. I DEFINITELY don’t like this.
   
3. This is pretty clever, but the layout makes me claustrophobic.
   
4. This seems wrong to me on many levels.
   

I understand that it’s hard to invent new visual metaphors for navigating data, especially as the volume of that data grows, but that’s all the more reason one should be extra careful not to go over the deep end and risk alienating users. I’m impressed by the amount of functionality that’s obviously built into flexicious, but at the same time I’m afraid to use it. What good is that?

Earlier today I posted about a strange bug I was encountering while trying to parse an RSS feed of my foursquare check-ins. I posted a complaint about the issue and received a prompt reply:

bauserdotcom replied 44 minutes ago

The dates in the RSS feed aren’t wrong, technically. They’re just not formatted according to best practices.

Foursquare’s RSS feed is using 2-digit numbers for years (which is valid, but not recommended, according to the RSS 2.0 Specification). How the RSS-reading agent interprets a 2-digit year is up to the agent. Whatever software you’re using decided to interpret it as 1910, which an interesting choice, since RSS didn’t exist in 1910.

So what we have is a case of two legal-but-unwise programming approaches creating a mess. Hard to say who’s most wrong, you know?

Fair enough. This is all well and good, and if I were simply reading the items one by one I would be quite able to understand that a year of “10″ actually means 2010. The problem rears its ugly head when I try to parse these dates in Flash. Consider this selection from the constructor for Flash’s built in Date class:

yearOrTimevalue:Object — If other parameters are specified, this number represents a year (such as 1965); otherwise, it represents a time value. If the number represents a year, a value of 0 to 99 indicates 1900 through 1999; otherwise all four digits of the year must be specified. If the number represents a time value (no other parameters are specified), it is the number of milliseconds before or after 0:00:00 GMT January 1, 1970; a negative values represents a time before 0:00:00 GMT January 1, 1970, and a positive value represents a time after.

As you can see, two digit dates in the constructor for Flash’s date class are interpreted as years since 1900, not 2000. The only fix available to me is to inspect every item of the feed I’m loading (since these are being aggregated into one giant list of items) to see if the publication date is sometime in the 20th century. Great.

Of course, I’m not all sour grapes. I just posted an “idea” on Foursquare’s “Get Satisfaction” page.

Today I was working on aggregating some RSS feeds for a project I’m working on using the wonderful (if dated) as3 syndication library when I ran into something very odd. I had just added my foursquare check in feed to the list of feeds to aggregate and was examining the dates and links for each feed item to verify that they were being sorted properly. Within a date sorted list, all of my foursquare check-ins (including ones from the last couple days) were at the bottom of the list.

Thu May 26 08:14:41 GMT-0800 1910 http://foursquare.com/venue/519340
Wed May 25 12:06:31 GMT-0800 1910 http://foursquare.com/venue/519340
Wed May 25 12:03:42 GMT-0800 1910 http://foursquare.com/venue/519340
Tue Mar 29 18:54:29 GMT-0800 1910 http://foursquare.com/venue/128782
Tue Mar 29 18:53:42 GMT-0800 1910 http://foursquare.com/venue/237966
Fri Mar 25 22:39:16 GMT-0800 1910 http://foursquare.com/venue/3540
Fri Mar 25 12:23:59 GMT-0800 1910 http://foursquare.com/venue/119722
Fri Mar 25 12:23:13 GMT-0800 1910 http://foursquare.com/venue/229509
Fri Mar 25 12:22:41 GMT-0800 1910 http://foursquare.com/venue/519340
Wed Mar 9 22:49:25 GMT-0800 1910 http://foursquare.com/venue/629305
Thu Mar 3 12:54:00 GMT-0800 1910 http://foursquare.com/venue/159429
Thu Mar 3 12:53:11 GMT-0800 1910 http://foursquare.com/venue/519340
Sat Feb 12 13:14:31 GMT-0800 1910 http://foursquare.com/venue/519340
Thu Feb 3 12:26:13 GMT-0800 1910 http://foursquare.com/venue/519340
Tue Feb 1 23:24:02 GMT-0800 1910 http://foursquare.com/venue/629305
Sat Jan 29 11:58:25 GMT-0800 1910 http://foursquare.com/venue/519340
Thu Jan 27 13:03:56 GMT-0800 1910 http://foursquare.com/venue/519340
Wed Jan 26 12:03:02 GMT-0800 1910 http://foursquare.com/venue/519340
Sun Jan 23 23:10:22 GMT-0800 1910 http://foursquare.com/venue/429251
Sun Jan 23 13:16:33 GMT-0800 1910 http://foursquare.com/venue/119650
Tue Jan 18 19:09:06 GMT-0800 1910 http://foursquare.com/venue/455620
Fri Jan 14 09:19:11 GMT-0800 1910 http://foursquare.com/venue/519340
Tue Jan 11 13:49:40 GMT-0800 1910 http://foursquare.com/venue/519340
Sat Jan 8 20:51:43 GMT-0800 1910 http://foursquare.com/venue/34011
Sat Jan 8 13:01:02 GMT-0800 1910 http://foursquare.com/venue/519340

Notice anything odd there? Why are all my foursquare feed items dated 1910? Am I really going to have to add an exception to add 100 years for any feed item from foursquare? Really? I reported the issue at Foursquare’s “Get Satisfaction” page. Maybe somebody will respond?

Today, as happens once in a blue moon, I was presented with a stack of flash banner ads along with a request that they be squeezed under a 50k file size limit. If you’ve ever worked on banner ads you’re probably familiar with these sorts of limitations, as well as those placed on duration and the use of rich media. You may also be aware of how frustrating and difficult a task it can be to squeeze banners, with all the aesthetic demands placed on them, under these arbitrary size thresholds.

After several years of dealing with these issues, I’ve come up with an array of tips and guidelines for reaching the file sizes that ad networks demand. Some techniques are more effective than others. Many of them may compromise the aesthetic integrity of the files you’re working with so it’s best to use a mixture of these strategies to suit your needs.

I’ve prepared a sample banner in a standard size (300×250) to use as an example. You can download the initial source files by clicking here.

We have what seems to be a very simple banner animation. Several pieces of text fade or slide into view, and bubbles are dynamically placed on the stage and flown from right to left. A number of different fonts are used (all variations of HelveticaNeue) and the image in the background is crisp and clear. It may not seem like it’s very complicated, but this SWF is actually 1.6mb. How can that be the case, and how can we fix it? Let’s look at a couple things we can change.

1. Embedded Fonts

The most significant factor contributing to the file size of this SWF right now is the large number of embedded characters. If we browse through the assets being used in the SWF, we can come up with a list of the following fonts being used:

1. Helvetica Neue LT Std 95 Black
2. Helvetica Neue LT Std 67 Medium Condensed Oblique
3. Helvetica Neue LT Std 77 Bold Condensed
4. Helvetica Neue LT Std 87 Heavy Condensed
5. Helvetica Neue LT Std 97 Black Condensed
6. Helvetica Neue LT Std 107 Extra Black Condensed
7. Helvetica Neue LT Std 73 Bold Extended

This may seem like a large number of fonts, but it’s not uncommon to receive compositions that use at least this many. This in itself, though, is not necessarily a problem. Where things get messy is when we look at how the fonts are embedded.

In the case of our original file, we’re embedding every character in every font we’re using. If you look at the screenshot above, that’s almost 100,00 characters per font, or nearly 700,000 characters total. Most of the characters we’re embedding are entirely unnecessary. How can we resolve this issue? There are three ways.

1. Embed a smaller subset of the font. I generally use the following.
   
2. Embed only the characters being used within each text field. This is a fine option for fields that won’t be changing. You can accomplish this by first clicking “Don’t Embed” to clear any groups you’ve already included, and then clicking “Auto Fill.”
   
3. Make your text fields static. Generally this works well, although sometimes static text renders in unpredictable ways. This is also roughly equivalent to option 2.
   

After going through the source file and correcting every dynamic text field (using option 2), our 1.6mb SWF is down to a sweet and slim 36kb.

2. Image Compression

Another way we can influence file size is by toying with the JPEG compression settings for our SWF. By default, Flash embeds bitmaps at 80% of their original quality. Most of the developers I know rarely if ever tweak this setting, and in most cases it’s not necessary to, but if you’re willing to toy around the the figures you can squeeze a few more kb out of your SWF quite easily.

You can modify image compression in two ways.

1. Modify the global compression settings for your SWF. You can find this control in the publish settings panel under the “Flash” tab.
   
2. Modify the compression settings for individual images. When it comes to fine tuning your application, this is a better way to go. You can access this menu by selecting a bitmap in the library panel, right clicking, and selecting “Properties.”
   

This method is far from flawless, and the results are often hard to predict. In the case of the SWF we’re working with above, I’ve created a demo showing what the platypus photo in the background looks like at various compression levels. Click and drag the slider to adjust the quality of the image (displayed in the field next to the slider).

You probably can’t even see a difference before getting down below 70. From there to 40 the changes are subtle, and they become more noticeable with each step from 30 down. Obviously you have to know where to draw the line when you’re sacrificing image quality for filesize, though in the example above I would be willing to go perhaps as low as 20 if the need were great enough.

In our original SWF, setting the JPEG quality to 20 brought our filesize down from 36kb (after modifying our fonts) to a tiny 24kb.

3. External Libraries

Depending on what you’re trying to accomplish in your banner, you may require external libraries for animation or data connectivity. It’s easy to forget that including these libraries can add to the overall file size of your published SWF.

In our sample SWF we’re using the TweenLite library to animate bubbles across the screen and to remove them when they’ve cleared the left edge. TweenLite is a wonderful library, and it’s already quite small, but you may not be aware that there is a smaller version of TweenLite available called TweenNano. TweenNano is packaged with TweenLite, and unless you intend to do something highly complex it has all the same basic functionality.

The code in our original file for animating bubbles looks like this.

//
TweenLite.to(bubble, Math.random()*10, { _x: -150, ease: Expo.easeOut, onComplete: killBubb, onCompleteParams: [bubble] });
//

To switch over to TweenNano, all we have to do is change the name of the static class we’re referring to, like so:

//
TweenNano.to(bubble, Math.random()*10, { _x: -150, ease: Expo.easeOut, onComplete: killBubb, onCompleteParams: [bubble] });
//

Switching the code in our application from TweenLite to TweenNano brought our file size down from 24kb to a miniscule 20kb.

4. Flash Player Version

The final fix I would recommend for our sample file requires an awareness of the environment you’re publishing to and the needs and capabilities of your project. While it may seem at first that it’s best to publish to the latest version of FlashPlayer, if your application isn’t taking advantage of newer features it may be in your best interests to hang back with an earlier version.

Our original application, after all the cuts we’ve already made, was clocking in at 20kb published for Flash Player 8. If we publish to Flash Player 7, we reduce the filesize even further down to an insane 16kb!

What do we lose for the bargain? In this case, the ability to specify anti-aliasing methods for our text fields. Because this animation is simple, and nothing dramatic happens with text, we can part with those capabilities quite comfortably.

Of course, there are trade offs here as well. You may think that it’s better to publish to Flash Player 9 than 10 if your project doesn’t require features like native 3D support, but perhaps you could achieve some performance benefit by replacing your Arrays with Vectors?

Which version of Flash Player you choose to publish to will depend on your unique needs, but it’s worthwhile to remember that the latest is not necessarily the greatest.

Conclusion

After applying the above techniques to our original swf with a filesize of 1.6mb, we were able to reduce it to only 16kb. That’s a 99% reduction, and it’s sure to make clients and advertising networks happy. The new, shrunken files, can be found by following this link.

Keep these tips in mind and let me know if you have any other tricks for putting the squeeze on bloated SWFs.