Build, steal, buy, or borrow… These would be the four basic ways you can make your applications a reality, pretty much regardless of the language you develop in. Flash and Flex development is no different in this regard.

Building will get you what you want, provided you have the skills to do it, but could take a load of time. Time obviously equals money. Stealing source code is of course unethical and I would never endorse it, for the obvious immediate moral implications. But furthermore, it is simply not a commercial option when developing work for clients due to long term legal issues. Buying code or components is often a great way to rapidly make progress that would otherwise take a long time to build. Borrowing code or the closest parallel I could think of, using open or free libraries, components, frameworks or APIs, is often the smartest thing to do when building an application of scale or one that requires a short timeline to deployment. (more…)

At The Iona Group we have hundreds, probably thousands of videos that we have shot or somehow acquired from client asset libraries, etc. These videos are stored and logged in a pretty big legacy database (Don’t laugh, I think it’s Access). We also have some clients where stored their video assets in a big fat digital asset management system, (DAM) (One in Cumulus, the others proprietary, I believe). These tools make it easier to access the vast array of clips, tapes, etc. we have amassed over the years. Often though, all we have in the record or DAM is one lonely thumbnail image, some timecode info, the log notes about content, acquisition information (date, location, shooter, etc) and maybe, if we are lucky, a short preview clip. This makes selecting stuff for B-Roll or determining what archival footage might be needed a bit tough. Certainly time consuming, too. (more…)

I recently had the pleasure of spending a full day at a client’s site along with some representatives from Adobe. It was great day for networking, introductions and demonstrations. A number of technologies were shown, from Acrobat 3D to LiveCycle, to InDesign/InCopy and finally Flex with Data Services. This client is already using Flash on their site in a number of presentational media methods, and also in their eLearning initiatives. I wold be willing to bet this profile fits a lot of large corporations current state of media affairs. They have recently begun transitioning from some other print publishing tools to the Adobe Creative Suite. They really haven’t tapped into using Adobe tools for business applications yet though.

I have a couple theories on that reluctance. Much of that is due to their long entrenched legacy systems, built using a myriad of technologies. Some of it though is due to what I am dubbing the “Flash Hangover”. You know what I mean, right? The hangover from the type of Flash that caused Jakob Nielsen to write the Flash: 99% Bad article so long ago. You know the type. The Skip Intro Flash. The extra beepy or seizure inducing Flash. The un-backbutton friendly un-search engine friendly un-content management system friendly Flash content we’ve all come to know and loathe. Flash is either viewed as a acceptable annoyance or a toy.

It’s clear to everyone deep in the industry that Flash Player 9 and the current state of affairs in the Flash ecosystem is a little bit past that, but for people that are only tangentially involved in the electronic publishing aspects of a large corporation, the A-HA moment has probably not happened yet. I witnessed it happen for a room full of people the other day, and I’m sure there are many many companies out there may need that moment to push them away from the tired old HTML powered apps they currently have a towards true RIA development.

Silverlight does not have this hangover to recover from, and I must say, we had many of the people at the event asking about a comparison to Siverlight in regards to the data services we were seeing displayed in the very cool Flex visualizations.

It should be an interesting next couple of years.

Last April, I wrote a post listing some reasons why I felt Silverlight would not succeed. That post garnered a lot of visits, comments and a few trackbacks. It’s still a highly trafficked post of mine. Furthermore, that post is the number one Google result for “silverlight IDE” and ranks pretty highly for a number of Silverlight related phrases like “silverlight penetration”, “silverlight market penetration”, and a few others along those lines. I’d like to revisit some of those points to see how things have changed in the past year. I was inspired to revisiti this after reading Robert Scoble’s friendfeed topic on this subject. Read on to see the progress. (more…)

I work at a small shop. We work smart. Pretty agilely, for the most part. We have also built up a large repository of code, both AS2 and AS3 amongst other platforms (PHP, ASP .Net, etc) and do benefit a lot from intelligent reuse of assets and a very cool custom LCMS we have built that integrates with a really well developed modular Flash front end for e-learning content… however, we don’t have every conceivable interaction type, UI widget, data parsing doohicky and whatever else could come to a client’s mind lurking around on our servers. Sometimes, we have to go to the web and find or even buy components. When it’s a question of buying a component for low price or spending a large amount of hours to replicate that functionality with custom code, oftentimes we really don’t have much of a choice. When deadlines loom or other projects are pressing, it’s just a easy decision to make. We buy the component. We probably have a library of about a dozen components or extensions for Flash we have purchased at one point or another.

Here’s my gripe. The vendor’s typically sell the components as compiled MXPs, which is understandable. The packaging makes it easy to buy, download, install and use. Not so easy to modify, which if that’s what you want to do, you’re out of luck. Last week, a component we purchased forced me to program some hacky workarounds because of that fact. It’s a great component, really. It was just lacking a couple key events I wanted to use to trigger some interactivity and external asset loading. A quick visit to their forums showed me that a number of other users were looking for similar capabilities. I posted my current workaround and a couple other little functions that some of the users might find useful to learn more about the component. Here is what I’d love to see…

Sell the code, too! If your component is $50… why not sell the code with the MXP for $100, or $150, whatever you need to help protect your intellectual property from piracy or pilfering but offer your customers the flexibility they need. This will help cement your reputation with developers that need that power and stop the need to respond to support forum post after support forum post with the repetitive “We don’t currently offer that feature in the component at this time, we may add that in a future release”. That support forum post wouldn’t be necessary because if we needed a new listener, a new data type, a new UI widget or any other extended feature, we could have it.

Some of the absolutely most useful bits of Flash code I have used or reused didn’t come from closed components, they came from the Adobe open source stuff on Google Code, The Casa Framework, and Tweener. All open and all free. How about you? Do you know or use any commercial component vendors? Who are the easiest to work with, who has the most open licenses? Most editable code, best support? I’d love to learn how you are maximizing your time out there with 3rd party code, components and APIs.

No content here, really, just a big thank you to the team that has resurrected AXNA from the digital ashes.

Very cool… go check it out! http://feeds.adobe.com

I sometimes need big images out of my flash files. By big, I mean larger than the 2880×2880 maximum size allowed by the Flash player. It just so happens that Flex has a way around it, and so SWFShot was born. Read on to learn more and download it. (more…)

Followup to my post yesterday… I’m started wholeheartedly on my snapshot tool, tentatively called “SWFShot”. It’s to be an AIR app that allows the user to create high resolution output images of loaded Flash content from the users hard drive. I hope to have a functional prototype in the next few days. Time is tight these days, but I will continue to post my progress… It’s currently in a tab navigator and skinned with a slightly modified template from Scalenine. Here are some screenshots of the panel… Keep in mind the final app will be a full screen window less app, with the content loading in the background of the panel. Should be interesting anyway. If you have thoughts or suggestions… fire away, I’m all ears. Read on for screenshots and the app’s “read me” content.. (more…)

I don’t know if I really have a good post here, just want to know why a very useful, very powerful class that is in the Flex framework isn’t in Flash’s AS3 classes. For those of you who are Flash users but not Flex developers, you may not really know about this class (good explanation here, at Doug McCune’s blog.), but it acts as a shortcut/helper class to assist you when creating snapshots out of display objects or anything that implements IBitmapDrawable. It’s pretty nice.

One thing that this class does that is especially cool is let you get around the 2880×2880 pixel limit imposed on all Flash display objects, including our good friends Bitmap and BitmapData. I have been working around trying to get higher res images out of some of my comps lately and I have all but given up using Flash for it. Even when you run Flash through as an AIR app, and use sneaky tricks like employing AS3Corelib (which is a great selection of classes, I might add) to encode a container sprite as JPG or PNG and output them as files to your local machine you are still limited to the 2880 ceiling. Now, I have seen explanations on why the limit exists, and yes, it makes sense for web apps, but if you are already creating a signed or even an unsigned app for that matter that has to run as administrator on a machine, I see no reason why the 2880 ceiling exists. With monitors gaining pixels with every generation, I’m sure this will change someday, but hey… I’m impatient. No really, I am… ask my wife.

So then I was doing something like this linked example to get around it. You can use the numbers on your keyboard to move the canvas around. “C” toggles mouse visibility, “1″ moves the sprite back to it’s origin point, “2″ slides everything left by a bunch of pixels (I have a MacBook Pro, so it’s slightly less than 1440), “3″ moves everything to the right by the same amount, “4″ moves everything down by 600, “5″ moves up by 600… you see where I am going with this? I move the canvas, take the screenshot and then stitch them together in Photoshop. This allows me to get a pretty big canvas. But, it’s a pain. To get a 10k x 10k image (something that will give you a nice 2-3 foot size print) takes dozens of images. So I thought back to some stuff I have been playing with in Flex (more on that in an upcoming post) and want to do the same here. But that requires the ImageSnapshot class which is missing from Flash CS3… hmm. How vexing.

So, now, I’m currently planning on making a Flex developed app that will be deployed as AIR that will take an input SWF, allow you to set your dimensions and DPI and then use the imageSnapshot class to get a big fat uncompressed image out of it. ImageSnapshot supports up to 8192×8192 images of around 256meg. Has anyone seen an app like this around already? I certainly don’t like duplicating efforts as free time is at a premium. Thoughts?

Related to this post… I’m getting curiouser and curiouser as to why AIR doesn’t have a PDF encoder (especially since blazePDF is dead and is only AS2). I know I could find some uses for it. Postscript charts and elements from Flex or Flash anyone? Sounds nice. Especially with all the great work being done over at Degrafa, and the rumblings of the mx:Graphics stuff to come in Flex 4.

The ColourLovers API went public yesterday and the response has been phenomenal (The AIR app built with it is definitely worth a download). The API is super cool and very very easy to use. I built a port of my Dekaf app (built with Degrafa) in it and redubbed it dekafLovers. It has a few options that weren’t in the original Dekaf app.

All in all very very cool and the API was submitted to Digg with a pretty decent response, too. ColourLovers community is just fantastic and very supportive, offering lots of great suggestions to me, many of which I have been able to integrate into the app already, with hopes of adding more features soon.