With the last manager leaving the area, I offered and recently became co-manager of the Central PA Flash User Group (CPFUG). Frankly, based on the last few meetings, CPFUG was dying, but I hope it’s something I can help reverse. I’m not much for managerial positions (especially with my time about to be soaked up by a new baby next month), but my time attending FlashCodersNY meetings made me appreciate the wealth of a dedicated user group community.

I have a few ideas that I hope can help spurn interest, but I also hope to reach out to the local Flash/Flex community and determine what it is that would make the meetings more valuable.

To start, we’re moving our meeting location–and considering a revolving meeting place. In the past, meetings have been held at JPL and PSECU. I don’t know about you, but by the end of the day, I’m not interested in sitting in another meeting room, and I think a casual setting’s just the right place.

Our next meeting is scheduled for 6-8pm today at Appalachian Brewing Company in Harrisburg (upstairs). We’re going to start a series of meetings covering “Actionscript 3.0 Animation: Making Things Move!” by Keith Peters. Attendance is free, though you’re encouraged to bring a copy of the book and a laptop with Flash installed (if you have either).

Also, feel free to bring Flash-related questions or suggestions you may have for group. Hope to see you there!

Designing my own portfolio has always been one of the most time-consuming projects because I, like any other designer, become my own harshest critic.

While I still intend to redo my company’s site in Flash, I decided in the meantime to redo my portfolio in an iPhone-friendly format by using only HTML, CSS, and Javascript (For those that might have come across my guest post on Fathom’s blog, I’m sure this must come off as an about-face). I didn’t really use HTML 5-specific tags like <header>, <footer>, etc., since my site needed to remain accessible, and I relied heavily on JQuery for the animation. Up until this point, I’ve read the complaints for and against both Flash and HTML 5, but this gave me the opportunity to guinea pig my own site and experience the issues firsthand.

Development Environment Differences

The first big difference I noticed was the work environment. JavaScript wasn’t really intended as an object-oriented language, and the work process felt much messier than building the site in classes (ala ActionScript). Furthermore, since many of the divs were hidden on page load, I felt that I wasn’t able to quickly preview elements during development. I ended up relying heavily on the Firefox Firebug plugin and going back-and-forth between the browser and the code.

Search Engine Accessibility

From a search engine standpoint, the differences between the two technologies feels somewhat of a wash. Both sites would have a page title and meta tags, so there’s no big advantage for either here. On the plus side for HTML, absolutely everything can be interpreted by all major search engines. Had I done the site in Flash, only Google would have been able to partially parse the SWF file. On the other hand, I couldn’t take advantage of separate URL paths or page titles like I could with Flash (with the addition of the SWFAddress). the only way I could have done this would be to force a page refresh–an interruption in the experience I really didn’t want to occur. Actually, Asual has the JQuery Address plug-in, which does the same thing as SWFAddress. Thanks @kweerious.

Font Options

The decision of HTML over Flash heavily impacted my font choices as well, since HTML pages are reliant upon client machines having the font installed. Flash, on the other hand, can simply embed the font. Granted, there’s alternatives, like SiFR and Cufón, however, I didn’t want to use Flash replacement text and don’t like the fact that Cufón doesn’t allow for text selection (neither of these options, by the way, seem to be intended for extensive font use).

Another option is to use the @font-face call with the Web Open Font Format (WOFF). This format places font files on the server for the HTML page to reference, and is currently the frontrunner for inclusion in the HTML 5 spec. WOFF is certainly the most elegant (see the recently-designed splash page I completed for metalledwith for example), however, because the font files are available on the server, the file can easily be downloaded illegally. Not wanting to infringe upon the license I have for Futura and not wanting to make all of the text into images, i simply used a safe system font (Trebuchet).

Browser Inconsistencies

A good front end designer ensures that their Website renders consistently across a variety of browsers. In the case of Flash, there’s really no need to test, as the plug-in ensures consistency across browsers and platforms. In my case, Internet Explorer protested to using transparent PNG files, so it required additional code. Furthermore, while the code I used to generate an image reflection is proven to work in IE7, it didn’t want to work with how I built the reflection into the JQuery Cycle plug-in. I’m sure there would have been a way to make it work, but frankly, I didn’t feel it was worth the time–besides, IE users should already be accustomed to limitations.

Performance

Performance-wise, I was a little surprised to see that the animations were sluggish on the iPad and iPhone in comparison to their desktop counterparts. Granted, JQuery isn’t the fastest JavaScript framework on the market, but I was expecting at least slightly better performance compared to how Flash performs on Android devices. Overall, I suppose it only reinforced my agreement with Apple that intense animations in Flash would yield poor performance on their mobile devices.

My biggest issue with the end product, though, is how the site downloads. I’ve seen it before–JavaScript-based sites can’t preload animations or elements well, and therefore animations start playing before all of the elements have downloaded. The reason for this is because the HTML page attempts to download all of the elements contained in it–even if they are set not to display.

I’m a firm believer that you don’t tax the user with downloading content they haven’t requested, so I tried implementing the LazyLoader plug-in to ease the site download. I honestly don’t have complete faith in this plugin, but fortunately, the site is relatively small. Regardless, Flash currently blows HTML out of the water with its programmatic ability to queue and download content without requiring a page refresh.

Conclusion

I’m sure that the development tools will continue to evolve and I’m not claiming that my implementation of the all the various plug-ins was constructed in perfect harmony (anyone out there, please correct me if there’s a better approach). In the end, this endeavor opened my eyes to some of the things JavaScript can replace Flash for, but HTML 5′s inability to create a length presentation (without a page refresh or complete asset download) makes me believe that Flash isn’t going anywhere for a long time.

Personally, I had a lot of fun at BarCamp Harrisburg 2, and got to meet a lot of people in-person for the first time, which was great (I hope to see everyone again next year!).

I noticed there were a lot of tagged mentions on my topic, and I feel like I need to set the record straight. Most of the tags said something along the lines of “HTML 5 – the death of Flash” when they should have said “HTML5 – The Death of Flash?”

The idea to present on this topic revolved around Apple’s decision to omit Flash from their mobile products. In some ways, I think it’s a good decision for the iPhone but childish for the iPad. While researching the topic, I was actually surprised to discover how much HTML5 actually could replace Flash. As a Flash designer/developer, I’d love to see a standardized video format hit the Web (though, unfortunately, it looks like OGG won’t be it.

In my presentation, I predicted that Adobe will either make Flash export to an HTML5 canvas or will build a new tool that does just that. Besides that, my conclusion was that Flash isn’t going anywhere for a long time. Some of the reasons:

• Better production tools (HTML5 will catch up)
• Bigger community (HTML5 will catch up)
• Ubiquity and consistency (HTML5 will catch up, but browsers will take years to meet standards consistently, plus the HTML5 spec won’t be finalized until 2022)
• Creativity – <canvas> doesn’t appear to support filters, or tie in effects with video like Flash does
• Video cue points – not built into H.264
• Fonts – there’s the Web Open Font Format and TypeKit, but neither are a part of the HTML5 spec. Me, personally, I’d rather use sIFR over images of custom fonts.
• Browser independence – I’m not talking about Adobe AIR (which, aside from Tweetdeck, seems silly due to the double install), but Flash runs on a variety of devices in standalone form and needn’t sit in a Web page
• Code privacy – perhaps not such a good thing, but compiled SWF files protect their authoring code from being viewed. A <canvas> element would be available via view source. It makes me wonder how long an HTML page will become with really complicated HTML5 canvas-based apps…

In the end, we all ultimately choose the best tool for the job, and my ultimate point was that if you look at the evolution of the Web, innovation isn’t standard.

There’s been a lot of talk regarding the future of Adobe Flash thanks to the blockade generated by Apple on the iPad and iPhone. It’s been covered extensively by the news media and blogs, but I figured as a Flash developer/designer, I’d chime in.

To paint a picture of my stance, I will say that:

1. I hope open-source OGG format replaces Flash video. Flash has standardized a ubiquitous video format for the Web, and it’s wonderful evolution we can’t deny. Gone are the days of multiple encodings for Quicktime, Real Player, and Windows Media, and I doubt supervision excluding a for-profit company would have succeeded. That said, I think the Web has evolved, and the fact that HTML 5 has dropped OGG as the definitive format is a politically-driven mistake. We, as the creators of the Web, should be embracing an open video format.
2. I’m not an Adobe fanboy. Flash provides a format of expression unlike any other, and while I admit that Flash work is my bread-and-butter (and that I’m coincidentally wearing Adobe-branded apparel as I write this), I recognize Adobe is a company that answers to its shareholders. Frankly, their Open Screen Project and claims of Flash being an “open” platform register strictly as propaganda to me, and I felt the need to point out this stance because of the opinions I’ve encountered at some Adobe user groups.
3. I don’t believe HTML 5 is the Messiah. I support universal formats that ensure consistency between browsers. However, formats, while well-intentioned, don’t always reach the Web–they are ultimately dictated by the market. If that wasn’t the case, we’d all be discussing XHTML 2.0 instead of HTML 5 and be visiting .MOBI sites instead of using Webkit on our phones.
4. Flash isn’t going anywhere. Flash is used for more than just the Web–it’s great for standalone applications, and its games can’t be successfully emulated with HTML + JS. Furthermore, it allows for data without browser refreshing, and provides a more media-rich interactive experience. Regarding standards, see #3.
5. I want to see Flash Player on the iPad and the iPhone, but I believe this responsibility falls to Adobe.

I think something many in the Flash community fail to realize is that Flash Player doesn’t play well on mobile, and it’s not exclusive to Apple products. I know firsthand, as I considered purchasing a Nokia N900 as a result of Apple’s embargo. I checked out Flash Player 9.4 on the N900′s browser while stopping in at NYC’s Nokia Store, and the performance was nothing short of atrocious. YouTube videos were so choppy that they weren’t viewable, and simple Flash sites crashed the browser.

I should mention that the N900 is powered by the same ARM Cortex-A8 processor as the iPhone 3GS (the 3GS is underclocked to 600 Mhz). Sure, there are videos of Google’s Nexus One playing Flash Player 10.1, however, I wouldn’t be surprised if the Nexus One’s Snapdragon 1 GHz processor is concealing Flash Player’s inherent memory issues.

Reinforcement for this argument is Mozilla’s decision to drop Flash Player support for their mobile Firefox browser just prior to launch. I’m still amazed that this hasn’t garnered as much press as the iPad announcement.

This brings me back to the title of this topic–the Future of Adobe Flash.

Personally, I wonder if Adobe might have lost its way. Their community support is excellent, and I use their industry-standard tools every day, however, they’ve seemingly become obsessed with supporting a proprietary platform instead of focusing on building excellent tools, and their evangelists seem to point outward for blame rather than looking within. As I mentioned in #5, I want to see Flash Player arrive on all of Apple’s products, however, I think this falls upon Adobe improving the player’s performance. As for my predictions:

1. Flash Player goes truly open source and somehow gets included in the HTML 5 spec. Sadly, this is unlikely, as Adobe licenses proprietary video codecs for HE-AAC and h.264. More importantly, it’d likely affect Adobe’s bottom line.
2. Adobe publishes an API for Actionscript that supports gestures. Gestureworks is already providing this, and Adobe’s not far behind. Personally, I’m holding my breath for official Flash SWF support.
3. Adobe starts building applications that publish content for HTML 5 and mobile platforms.

Obviously, #1 and #2 are less predictions than #3, but I think it’d be refreshing for Adobe to begin exploring these new mobile outlets as opportunities to provide new software. Can you imagine a software that publishes iPhone, Blackberry, and MeeGo apps–without doing translations from Flash? Now that would truly be interesting . . .

I figured I’d dedicate a post to this topic since I just wrapped up a rather painful learning experience with skinning Shopify (the Ruby on Rails-based shopping cart service) with a complete Flash frontend. Judging from the lack of documentation online, I’m willing to bet I’m one of the first crazy enough to take on such a challenge, and I’d hope to save some other poor developer some time.

Shopify tools

For starters, here’s a few of the tools Shopify provides for skinning:

• Shopify’s API, which allows you to communicate with the inventory, products, collections, and cart on Shopify.com
• Vision, a toolkit for creating a Shopify theme.

Working with Vision

If you're wondering how to access Shopify's API for your store--and your store only, check this link in your Shopify admin.

I  started with Vision, which is this handy application that you can run locally, modify Rails/HTML theme files, and then test in a browser. Once ready, you simply zip up the theme’s contents and upload it via your Shopify store’s browser-based admin. A nice setup, though I came across a few technicalities–

• As of this writing, Vision themes are limited a 40 MB size limit, and rightly so, since it’s a browser-based file upload. I happened to be working with a site with roughly 300 MB worth of photos, so I was forced to host the assets on a different site.
• Shopify’s admin allows you to individually edit theme files, but if you want to upload a replacement you have to first delete the existing file. This made it very time consuming, since SWF files can’t be edited in a text editor.
• Themes are broken down into three folders:
  1. assets – files associated with your theme. Think images, javascript, swf files, etc.
  2. layout – this contains the theme.liquid file, which is basically the wrapper in which all of the templates are loaded
  3. templates – this contains a variety of necessary pages for a shopping cart site, like a product page, cart page, etc.

  A few things to note here: Unfortunately, I learned that the assets folder can’t contain subfolders, which lead me to a rather messy site structure. Your Shopify site will require all of the default template files. Since I was essentially rebuilding these all in Flash, I embedded my main SWF in theme.liquid and HTML-commented the include calls in theme.liquid.

Getting ActionScript working with Shopify’s API

The key here is authentication, as described in Shopify’s API. The API spits out XML, which is easy enough to parse in ActionScript, however, since API calls look like this:

https://API_KEY:SOME_PASSWORD@some-shop.myshopify.com/admin/orders.xml

they shouldn’t be queried from within Flash directly, as this exposes the shop owner’s API Key and password. Instead, it’s safer to create a server-side script, open the XML, and then feed it to Flash.

Once I got past this, it was pretty straightforward, with one exception–I couldn’t find the cart contents in the API documentation. After doing some asking around, I discovered that the cart contents can be found at your-shop.myshopify.com/cart.js. Now, unlike the API, this list of products contained in the cart is not XML, but Javascript Object Notation (JSON). Sure, I could have taken the time to write a JSON parser for ActionScript 3, but thankfully the good people at Adobe have already written one. It’s in as3corelib, which is hosted on Google Code.

Security and crossdomain goodness

Anytime a SWF file attempts to access content from a URL other than the one it’s on it first checks for a crossdomain policy. This is basically an XML file named crossdomain.xml that is hosted on the root level of the server (You can catch the dry documentation on this here and here).

Fortunately, Shopify has crossdomain.xml files prepared, however, it’s still a bit tricky.

Since they don’t want anyone hacking their main site, there’s no policy file on *.shopify.com. Granted, your-shop.myshopify.com has a policy, but there’s no way to pull your theme files.

In the end, I explicitly referenced all of my SWF files from static.shopify.com and relied on the crossdomain policy file on your-shop.myshopify.com, which looks like this:

<cross-domain-policy>
<allow-access-from domain="*.shopify.com"/>
<allow-access-from domain="*.myshopify.com"/>
<allow-access-from domain="www.mydomain.com"/>
</cross-domain-policy>


So that’s it in a nutshell. If you’re out there using Flash as a complete skin for Shopify, drop a comment and let me know that I wasn’t alone!

I’m building an accordion menu for a current Actionscript 3.0 Flash project and have decided to use the … rest parameter in my accordion-building function to allow for a variable list length. The catch I’ve found is that while …rest is an array type, simply passing an array into the argument will treat it as a single String. An example:

function myFunction(... rest):void {
   trace(rest.length + ": " + rest);
   trace(rest[2]);
}
var myArray:Array = new Array("this","is","my", "list", "of", "arguments");
myFunction(myArray);
/*
OUTPUTS:
1: this,is,my,list,of,arguments
undefined
*/

You’ll notice that the length of the argument array is 1 and that querying a specific key beyond the argument length yields undefined.

If you want to instead submit the array as a series of arguments (and take advantage of …rest) do this instead:

function myFunction(... rest):void {
   trace(rest.length + ": " + rest);
   trace(rest[2]);
}
var myArray:Array = new Array("this","is","my", "list", "of", "arguments");
myFunction.apply(this, myArray);
/*
OUTPUTS:
6: this,is,my,list,of,arguments
my
*/

I finally found some free time at the beginning of the month to work with the AS3 Go Tween platform. It’s still in its infancy, but I hope to continue to build/contribute to it. Donovan Adams already has started an object syntax Go Tween class, but I could imagine a filter class, volume class, physics class, etc.

So, why am I still fiddling with this instead of using the perfectly satisfactory Tweener or TweenLite, you ask? Check the benchmarks.

Honestly, it’s not just the benchmarks, it’s the philosophy this project provides. Oh, and it also has built-in sequencing, something I’ve really missed from my AS2 + Fuse days.

Anyway, here’s a simple colorTransform tween class I quickly threw together. Hopefully, someone’ll find this and integrate it into something better…
/**
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
package com.hauckinteractive.tween {
import flash.display.DisplayObject;
import org.goasap.items.LinearGo;
import flash.geom.ColorTransform;
/**
* Simple Tween class that changes the tint of a DisplayObject.
* @author Rich Hauck
* @version 2008-01-07
*/
public class ColorTransformTween extends LinearGo{
protected var _target : DisplayObject;
protected var _targetTint : Number;
protected var _startColor:ColorTransform;
protected var _endColor:ColorTransform;
/**
* Constructor.
* @param target DisplayObject
* @param tint Hexidecimal value (0xFFFFFF)
* @param delay Delay in seconds before performing tween
* @param duration Number of seconds for animation to play
* @param easing type of easing
* */
public function ColorTransformTween(target:DisplayObject = null, tint:Number=NaN, delay:Number = NaN, duration:Number = NaN, easing:Function = null){
super(delay, duration, easing);
_target = target;
_targetTint = tint;
}
/**
* Instantiates and auto-starts class.
* */
public static function go(target:DisplayObject = null, tint:Number=NaN, delay:Number = NaN, duration:Number = NaN, easing:Function = null):void {
var ctTween:ColorTransformTween = new ColorTransformTween(target, tint, duration, delay, easing);
ctTween.start();
}
/**
* Begins tween.
* @return Boolean true if _target is defined.
* */
override public function start():Boolean{
if (!_target){
return false;
}
_startColor = _target.transform.colorTransform;
_endColor = new ColorTransform();
if(!isNaN(_targetTint)){
_endColor.color = _targetTint;
}
return (super.start());
}
/**
* Loop performing tween.
*
* */
override protected function onUpdate(type:String) : void {
_target.transform.colorTransform = interpolateColor(_startColor, _endColor, _position);
}
/**
* Mixes between starting colorTransform and target ending colorTransform.
* @param start current colorTransform of DisplayObject
* @param end target colorTransform of DisplayObject
* @param t incrementing value from 0 to 1
* @ return ColorTransform instance.
* */
private function interpolateColor(start:ColorTransform, end:ColorTransform, t:Number):ColorTransform {
var result:ColorTransform = new ColorTransform();
result.redMultiplier = start.redMultiplier + (end.redMultiplier - start.redMultiplier)*t;
result.greenMultiplier = start.greenMultiplier + (end.greenMultiplier - start.greenMultiplier)*t;
result.blueMultiplier = start.blueMultiplier + (end.blueMultiplier - start.blueMultiplier)*t;
result.alphaMultiplier = start.alphaMultiplier + (end.alphaMultiplier - start.alphaMultiplier)*t;
result.redOffset = start.redOffset + (end.redOffset - start.redOffset)*t;
result.greenOffset = start.greenOffset + (end.greenOffset - start.greenOffset)*t;
result.blueOffset = start.blueOffset + (end.blueOffset - start.blueOffset)*t;
result.alphaOffset = start.alphaOffset + (end.alphaOffset - start.alphaOffset)*t;
return result;
}
}
}


First off, I apologize for such an SEO-friendly title to this post, but I want to make sure that no one else suffers through the searching I recently went through.

I recently worked on a site where I was using Flash 9 with AS 3.0 to build the primary menu for a Web site. The code was some simple drop back and pass (sorry, playing too much Madden these days):

private function onClick(event:Event):void {
    //_urlArray is a list of page links
    var request:URLRequest = new URLRequest(_urlArray[urlID]);
navigateToURL(request, "_self");
}

So, the site launches, and soon after, I’m getting calls from the client that the navigation links don’t do anything. It works fine in my tests, so I contact some friends to try the site. No problems. So, to see this firsthand, I go to my client’s office to test the issue, only to discover that we can’t adequately replicate the issue. I check my .htaccess, the site’s PHP framework, and conclude that it’s a DNS issue (since the site recently tranferred hosts).

The problem still occurs a day later.

So, I stop back in, and quickly discover that the Flash works fine from http://www.site.com but fails silently when the user is on http://site.com. Thanks to my trusty Flash Debugger Player, I find out it’s error 2137.

After exhaustively learning about the new Flash Player 9 security, I learn that the only thing I have to do is place the following in the <object> and <embed>:

<param name="allowScriptAccess" value="always" />
<EMBED src="file.swf" AllowScriptAccess=""></EMBED>

Alternatively, if you use SWFObject like me, you would use the following:
so.addParam("AllowScriptAccess", "always");

So what was the problem? Well Adobe integrated a new feature into ActionScript 3.0 security where setting the window type of “_self” in navigateToURL() is only allowed from the same domain. In my case, www.site.com and site.com aren’t the same domain (btw, IP != domain, either). In order for a Website to declare trust to an SWF, it has to provide it in in the HTML.

Anyhow, I hope this saves someone the time I took scrambling through Adobe Flash security docs.

I just got back from Adobe’s On AIR tour seminar in New York City. Overall, I think AIR is a really exciting project as it empowers Flash, Flex, and AJAX developers to easily create and deploy desktop applications. I think Adobe has gone in the right direction by providing the SDK for free (take that, Silverlight!). The ActionScript-built Web browser demo was impressive, and Adobe should seriously consider having new hire Lee Brimelow do all of evangelistic Keynote presentations.

All that said, I have to ask, how many applications does the average user currently use that require an Internet connection? I guess what my point is is that while I’m interested in seeing what the development community comes up with, I really can’t see AIR replacing most Web-based services or revolutionizing an industry. What I can see is easier deployment of, say, sales applications for both offline and online purposes, and what I hope to not see are uninspired renditions of the typical “VIRAL-Social-Networking” media player running on the desktop. I’m sure to be delightfully surprised with what everyone comes up with, but I figured I’d just throw a grain of salt along with the excitement of the show.

I should also mention that they tantalized the crowd with talks of an Adobe standalone Video Player (finally!) and AIR mobile (I tried to get more information out of Mike Chambers, but no dice).

Well, my friend Moses has announced Go for ActionScript 3.0. No, it’s not Fuse 3–actually, I think it leapfrogs the standard ActionScript animation library idea, and I hope it’s successful at getting people to work together on coding concepts, rather than release their own flavors of tween engines and hope for industry stardom.

I’ve been privileged to beta test Go, and the benchmarks alone are pretty impressive. I won’t let any cats out of the bag, but will say that it’s challenged me to wonder if subclassing is more ideal than using a decorator pattern. Personally, I lean towards subclassing since it requires some preplanning. Furthermore, decorators provide runtime changes, functionality that for some reason I wouldn’t feel comfortable with unless absolutely necessary. What do you think, though?