Blog

  • ActionScript 3 Components?

    What’s out there?

    The following list is what I know of currently.

    1. Flex 2 SDK
    2. Flash CS3 Components
    3. Jumpeye
    4. AsWing
    5. Razorberry

    If you know of any, please add them to the list. I’m looking for more alternatives, if any.

  • if u were my Aeris

    Cos-play + Craig’s list weirdness. Safe for work.

    Dude, she’s dead, get over it. Tifa for the win!

    Via her majesty & Something Awful (not always safe for work).

  • When Do You Let Go of 8?

    When is the right time to stop publishing to Flash Player 8 and start publishing to Flash Player 9? I’m struggling with this at work right now. All of my peers at work say “now” from engineering, design, and upper management. Engineering says it mainly from the variety of benefits Flash Player 9 gives us on the video player front:

    • run-time skinning more easily coded
    • easier to generate SWF’s server-side
    • ActionScript 3 is a better language for engineers to contribute

    Just because you move to Flash Player 9 doesn’t mean you have to use ActionScript 3. However, there isn’t much of a point if you have a team of engineers. If you’re alone, sure, you can stop getting compile warnings for Stage.displayMode, and run h.264 run-time video with confidence, all using AS2 or AS1. You can even upgrade legacy content with a simple re-compile.

    Design says it mainly from lessons learned in the past. By designing for the hear and now vs. the future, you limit your scope of what you can accomplish. By the time your efforts are done, the future is already here. Meaning, choosing not to take advantage of Flash Player 8’s design features because of your most recent Google Analytics & other tracking mechanisms was not necessarily the best choice because by the time the endeavors were done, customers were already massively upon Flash Player 8 adoption. Ease of run-time skinning helps as a motivator as well. Both Design and Engineering agree that you are not “excluding the 25%” that doesn’t have 9. Rather, the majority of them are on IE, and those that are can use Express Install without rebooting their browser. That means that those potential customers actually do the upgrade, and thus you don’t lose a whopping 25%, rather you only potentially lose a small amount OF that 25%. I’ve never seen Express Install work on my Mac, but it does work on PC, and that’s what’s important, hehe.

    Management bases it on the short life-cycles of existing content. Clients typically want new additions to existing players. Modifying the code bases to these players already underway, with new features being added, why not upgrade them to the new stuff while your adding new features anyway? Customers will soon start asking for h.264 for valid reasons (the video quality isf’ing sick and doesn’t cost the unreasonable bling that On2 asks)… and start asking for “Flash Player 9” for unreasonable reasons. Either one, however, is a valid business reason (for the most part). Customer wants, customer gets.

    So, I pretty much stand alone in my stance to remain, at least for the next 4 months, using Flash Player 8, ActionScript 2. We have a lot of legacy content that is in Flash Player 8 and below that will never go away and will continue to be supported. New stuff, however, created for a better future based on lessons learned is contentious right now since soo much is at stake. Therefore, it deserves multiple discussions, pro’s and con’s to be laid out, and ultimately up to management to drive the version decision to a conclusion. My stance is that:

    • Flash Player 8 still is king in viewership, 7 much more so
    • Clients who use our API(s) and/or component sets may be at the AS1 to Flash 6 level of coding skills; we need to provide for those customers
    • Clients who are at the ActionScript 3 and/or Flex level, we can support that code base in tandem

    Though my reasons are few, I think they are valid enough to be a strong argument, or at worst a decent devils’ advocate. For the first, the latest numbers of 86% of Flash Player 9 viewership aren’t enough to compel me.

    For the second, most blogs I read and most Flash devs working in the agency world or doing small RIA scope work keep repeating the same thing: “I can’t wait till I get an AS3 project.” Meaning, they aren’t getting AS3 projects. Meaning, those clients they work for aren’t deploying Flash content on Flash Player 9 AND ActionScript 3. The key here is Flash Player 9 AND ActionScript 3. Any Flash user who doesn’t know ActionScript 3 can easily publish for Flash Player 9 in ActionScript 1. It’s the dual requirements here that clearly set the tone. In my opinion, most Flash devs will get AS3 no problem. Package & class name instead of just class name, addChild instead of attachMovie, and stricter strong-typing. Woop dee doo; for some, 4 days, for others, 3 weeks. Both to me are reasonable time frames to get up to speed, especially in the faster paced worlds a lot of Flash devs live in. Let me ad the caveat that I think those are the few, and the rest won’t use ActionScript 3. Either that, or they won’t know that their timeline code is magically being converted to classes. :: shrugs ::

    So, by satisfying that market of customers still using ActionScript 1 and 2 code bases as well as also providing a solution for the ActionScript 3 + Flex world, the only cost is that we have 2 code bases targeted at different needs. Remember, they aren’t the same code bases; 1 written in ActionScript 2 and 1, whilst another written in ActionScript 3. Rather, 1 targets the programmers, and 1 targets the hybrids and designer crowd. To me, that seems the most conservative approach.

    To buttress this argument, Flash’ success was built on it’s scripting being added to support minor interactivity in animations. While ActionScript 1 allowed us to create full blown applications, that was a tipping point for Flash development where a lot of paths diverged. Animators, Developers, Designers… we all used the same product, but in different ways. The one thing we all had in common was lightweight scripting helped us accomplish our goals. Over the time, the developers were the ones who demanded more, especially when the scope of the projects increased, as did expectations, which in turn increased the scope. Awesome cycle.

    If you look at what Microsoft is doing with Silverlight, they are providing the very same scenario, only for a version 1 product. I can’t honestly say what Flash had in 1 and 2 in terms of scripting, but I do know it was enough. If you’ve seen anything in Silverlight 1.0, it’s more than enough. It’s JavaScript, it’s approachable, and it’s strictly targeted at the same market a lot of us Flash Developers came from. The “my animation needs some minor interactivity” market. The download API Sliverlight has is exactly like AJAX on purpose. Both Adobe and Microsoft realized (Microsoft sooner than Adobe) that they couldn’t fight the AJAX market, so instead embraced it. Microsoft knows that while a lot of the hardcore .NET guys who do full-time C# or VB aren’t going the touch the 1.0 version of Sliverlight with a 10 foot pole, there are tons who will. JavaScript never stopped the Ruby on Rails revolution, nor the rest of the swathes of AJAX programmers out there, a lot who also do heavy server-side development.

    The point is, non-strongly typed languages who support animation & rich design systems are a valid run-time environment. They are worth building tool sets and frameworks around as a business model. People will purchase them, and use them in projects. Aka, they aren’t going away. ActionScript 2 and 1 aren’t going away anytime soon, regardless of how many people upgrade to Flash Player 9. While the counter point is that it’ll be easier to find a Java chick and train her on ActionScript 3 vs. finding a Java chick and training her on ActionScript 2, this isn’t a cut and dry argument on just language semantics; it’s about target demographics, and how that demographic uses and perceives code in contributing to their projects.

    All the Flex guys have moved on from Flex 1.5 to 2. With Papervision3D’s (I am Jack’s desire for brrr) success, agency’s are using that as a hopeful tipping point to move to Flash Player 9 (Flash Player 8’s font engine was the tipping point for 7). Programmers from a variety of backgrounds are building ActonScript 3 libraries like crazy. However, I still argue Flash Player 8 to Flash Player 9 migration isn’t as cut and dry as it was in the past.

    1. I was in high-school, didn’t use computers.
    2. I was in high-school, didn’t use computers
    3. I played with it, went back to fabrication & Ultima Online…
    4. I was using Director
    5. I was using Director, but then saw Expert mode, and dropped Director like a ton of bricks; attachMovie vs. sprite channels? Um, no brainer. == yes
    6. Dude, built-in FLEM (aka, dynamic attaching of events to MovieClip’s via code) == hell yes
    7. Uh… middle mouse, fake CSS, and TextSnapshot only for FlashPaper? Well, they DID optimize XML for the 3rd time, has external FLV loading, and it has getNextHighestDepth, so… == yes!
    8. MOTION BLUR!!! Hot fonts, and new Garbage Collector. == yes
    9. Er… faster code? Less RAM usage? Run-time exceptions? I hear programmers like those things, not me, hrm. Dude, why can’t my 9 SWF talk to my 8 SWF? == no …but in Flex, my code actually scales on projects == yes!

    Obviously this entry is skewed toward my job, and my target market. Regardless, I still think the 8 to 9 bridge isn’t cut and dry. It’s complex, and more of a dramatic jump. I think we all agree it’s worth it, it’s just that you can’t assume you’ll never see F8/AS2 & AS1 content ever again, nor have to support it. If you develop API’s for other developers, this is a big deal.

    Are you a Flash Developer that’s let go of 8? How? Why?

  • Silverlight Controls

    Check out these Silverlight control examples for both JavaScript (v1) and C# (v1.1) by Tim Heuer. I hate code behind, specifically the Flex implementation of the idea of separating your View from its implementation. The idea is you layout your GUI in MXML, and code it’s functionality in ActionScript. Gross.

    However, I have an inkling most traditional programmers love it specifically because when it comes to Design vs. OOP, they’ll side with OOP. Not to mention .NET I think… like… works this way, hehe. I side with Design because of my Flash background. Either way, after seeing the example code in these posts, I have a much better appreciation for code behind and how it relates to Sliverlight’s implementation. Specifically how the View’s GUI layout is done in XAML, and that XAML can be used in both Design and Blend. Hotness.

    If the Adobe CS suite would ever catch the heck up, we could be doing stuff like this. Imagine it:

    – Designer makes comps in Photoshop or Fireworks
    – Designer can animate and layout screens in Flash
    – Flex or Flash Developer could then program ActionScript around those screens.

    Vice-versa, the designer could design around the programmer’s implementation of screens. Agency vs. software shop work-flow, but either way. For now, us in the Adobe camp muddle through our production art / break up, and can only look on with envy.

    Via Russell Myers.