Apple, Flash, and The Truth

I'm sure by now you've read "Steve Jobs"'s Thoughts on Flash. Did it convince you? Do you think it was truthful? Not me. Sure it has some valid points, especially about Flash being buggy on OSX. As someone who has developed Flash applications using a Mac, I am especially aware of this bugginess, and part of me can't help but get a perverse sense of satisfaction that this bugginess is now coming back to haunt Adobe. However, this doesn't change the fact that Jobs's epistle is far from the truth. It is corporate slander, designed to make Adobe look as bad as possible. Why? So that when devices from competitor's ship with full support for Flash, this technological advantage can be discredited in the eyes of consumers. In other words, this well thought out post by Apple is not some intellectual/technical analysis, it is just marketing designed to boost Apple's profits.

The most dishonest thing about the post is what Apple says is "the most important reason" to ban Flash from their devices: that it will result in sub-standard apps and hurt their iPhone/iPad OS platform. This is complete bullshit. It's not like developers would suddenly only be able to create iPhone apps using Flash. It's not like they could no longer use all of the tools they use today. The difference is that they would have a choice. They could choose to use Flash. Or they could choose to use Objective-C/Cocoa/XCode.

But don't forget, that not only would developers have a choice, but so would consumers. If for some strange reason, some developers started choosing to use Flash,  it's not like consumers would be forced to buy those Flash-authored apps. No, they could still choose other, traditional apps. In fact, if, as Apple claims, Flash-authored apps would be of such low quality, then one would expect that few consumers would choose to purchase those apps.

So if Apple allowed developers to use whatever tools and technology they wanted to use, to create apps for the iPhone and iPad, what might happen? Well if Apple's claims are right, then there would be bad apps that nobody would buy (aren't there already a lot of such apps on the App Store?). Consumers aren't idiots, and they won't buy crappy apps when there will be better alternatives. So those Flash-authored apps will lose money. Developers aren't idiots, and they won't keep using technology that produces software that nobody wants. So they would abandon Flash and go back to Cocoa. So Apple's "concerns" would be unwarranted.

Or perhaps what would happen is that some developers would produce good apps using Flash that consumers bought for their iPhones. Certainly developers would continue to use Flash. However, in this scenario, Apple's "concerns" are proven to be false -- Flash produces some good apps. But wait, what about Flash holding back innovation on the platform? Apple would still be free to add new features to their OS, and make them available to developers through new APIs in the iPhone SDK. Who knows how long it would take Adobe to expose those features through the Flash authoring tools, but who cares? If those features greatly improve apps, and they aren't available in Flash authoring, then what happens? The power of choice wins again. Developers can still choose to use Cocoa, tap into these innovations, and user's can choose to purchase the apps that take advantage of these innovations. If these features are so great, one might expect that Adobe would try to bring them to Flash authoring as quickly as possible. Either way, the notion that the Flash platform would be held back makes no sense.

So Apple's self-described most important point is so false that it is laughable. Some of their other parts are equally false. For example, the notion of touch and Flash. Yes, many things in Flash are designed for users interacting with a mouse, not a finger. Such things don't work well on touch devices. However, this is not just true for Flash. It is equally true for HTML and JavaScript. If you've done a lot of surfing on your iPhone or iPad, you have surely experienced the "rollover" issues described in Apple's post. Want more examples? Check out this clever little video on HTML 5 and the iPad:


So why all the bullshit? As I said earlier, the reason for the post is to discredit any competitor that provides Flash support on their devices. First and foremost on that list is Android, which will support Flash in Android OS 2.2. That doesn't explain why Apple doesn't want to allow developers to use Flash to develop for the iPhone? The answer to that is simple. They want complete control of their platform. If you want to make money off of the iPhone, you have to be in bed with Apple. They saw how the web has hurt Microsoft, and they will not let this happen on the iPhone or iPad.

Now wait a minute, isn't Apple investing heavily in the web, namely HTML 5? Doesn't that demonstrate that they are willing to give up control of their platform? Yes, and no. Yes, Apple has invested into WebKit, a technology that in various forms implements a decent chunk of the HTML 5 standard. But you see, the key word here is "standard." This is how Apple fools you into thinking that they are providing an "open" alternative to their proprietary system.

It's easy to get fooled into thinking that any company that implements and open standard is innovative, but just the opposite is true. We think standards=innovation for browsers because of Microsoft IE 6. That browser dominated the world for a long while being completely stagnant. It was both non-standard and non-innovative, but this is an exceptional. It is rare that such technology can flourish. It took the unique nature of Windows, IE, and Microsoft's legal troubles to produce this situation.

Adopting a standard just means that you either change an existing feature of your technology to comply with the standard, or you copy a feature from others in the space. It is anti-innovation. When it comes to web standards, they are introduced post-hoc. XMLHttpRequest, the key technology behind Ajax, was proprietary Microsoft technology for many years before it became a standard. Many of the features of HTML 5 were introduced by various plugin technologies like Flash or Google Gears before they became part of the HTML 5 spec. You cannot innovate while waiting for some super slow moving corporate committee to vote on a new standard.

Going back to the iPhone/iPad, Apple is saying: pick either Cocoa and go through the App Store, or stick to the web, but only the "open standards" part of the web. They have given you a choice, but only the weakest, most impotent choice possible. You see this is where the other part of their Flash ban comes into affect. Not only have they recently banned compiling a Flash authored application into a native iPhone application, they have always banned Flash running in the browser. Why? Because with browser plugin technologies like Flash, Silverlight, and yes even Java, you can create user experience's on par with desktop applications. If they allowed Flash in the browser on the iPhone, then developers could create web applications that might rival the native iPhone applications. And we wouldn't want that, now would we? So Apple give you a single alternative to using Cocoa/XCode/AppStore, and then they horribly cripple it, by removing the most innovative parts and tying a design-by-committee-technology weight around its neck. Apple's endorsement of HTML 5 is one of the greatest marketing ruses ever. They stifle innovation, limit choice, and line their own pockets while getting everyone to believe they are being developer friendly and innovative.

After all of the above, you might think that I am very anti-Apple, anti-iPhone, anti-iPad. I'm not at all. I am anti-bullshit though. I don't like being lied to and treated like a lemming. Apple has every right to keep Flash off of their devices. It's their OS after all. They have very right to ban apps that were authored with Flash from their AppStore. It's their AppStore after all. Just don't lie to me about this stuff. Don't say it's better for developers or better for consumers, when it's actually worse for both. Just tell the truth: it's just better for Apple.

JsonViewer Updated

Some folks pointed out that the JsonViewer installer was complaining about being on the wrong version of AIR. That was because I wrote it before AIR went 1.0. So I thought "no problem, just re-compile it." Well sort of.

I updated Flex Builder 3 to the GA version and updated AIR to 1.0. I imported the old project. It picked up my Subversion settings and what not, very nice. I did a new "export release version" and it worked just fine. I tried to execute the .air file and it bombed. It told me that my AIR file was damaged.

WTF!? I tried to run the app directly from Flex Builder. It did nothing. No errors, just nothing. So I tried debugging. Then I finally got an error message about using the wrong version of AIR. I opened up the JsonView-app.xml. There was no "setting" in here for AIR version, but then I saw this

<application xmlns="http://ns.adobe.com/air/application/1.0.M6">

Yep the .M6 was killing me. I removed it from the XML namespace declaration, and voila! Everything worked perfectly. Show your appreciation for my pain by downloading JsonViewer.

Silverlight Slim and Fat Flex

A couple of days ago, I talked about Silverlight 2.0. One of the interesting things to me was that it was how Silverlight RIA-style apps could be a lot smaller than Flex apps. I posted a comment to Scott Guthrie and he was kind enough to post a reply to my question. His reply indicates that for Beta 1, a relatively complex application will be slightly smaller than the same thing in Flex. However, much more of the framework is going to be included with the initial Silverlight download starting in Beta 2, thus giving Siliverlight a huge advantage in terms of app size.

When Adobe announced that the Flex framework could be cached on the Flash player across domains, I wondered why the didn't just included it with the Flash player. I have even bugged Flex evangelist Ted Patrick with this question. His response to me was that they would open themselves up to "DLL hell." In other words, there could be problems with people building their app against Flex framework version X, but a user has an older version installed.

As if this doesn't already happen! Let's not forget that Adobe jumped ActionScript from version 2.0 to 3.0 and thus required Flash player 9 or higher for anything authored using 3.0. This was not just some update in framework, it was the entire programming language being overhauled. It is common to use JavaScript to detect Flash player version and require people to upgrade. It is so common and so part of Flash development, that Adobe distributes the ExpressInstall SWF for doing this as easily as possible. Heck, I usually require users to be on 9.0.28 or higher, since that is the version that fixed some bugs with ExternalInterface.

So back to the Flex framework/DLL hell issue. It would simply require people to check for a certain minimum version of the Flash player (since that would correspond to a version of the Flex framework) and prompt for an upgrade if needed. In other words, it would require something that most folks already do today.

To me the real reason is that it is more economical for Adobe to not include the Flex framework. Ted has a widget he wrote showing over 3.9 billion downloads of Flash player 9. Add an extra 200K to that and you get over 726 TB. That's a lot of bandwidth to pay for. That's a price Microsoft wants to pay, because it would indicate lots of folks with Silverlight installed. Perhaps once that happens, Adobe will reconsider.

Flash CS3 and SWCs

A co-worker called me up recently to ask me how to use a SWC with Flash CS3... A SWC is a collection of compiled ActionScript classes, similar to a DLL or JAR. They are very easy to use with Flex Builder and the Flex compilers. In this case, there was a SWC that I had created that my co-worker wanted to use in his Flash project. I knew that this was a pain. 

Flash CS3 thinks that SWCs are for UI components. You can create a SWC with a manifest.xml (in Flex Builder), drop it into your components directory, and use it. That's great for UI components, but not for class libraries.

On an older project, the developers using my library just linked to the source code directly to compile. I told the new developer to do that, but he quickly pointed out that the new version of my library used Adobe's corelib library... which is also a SWC. 

So the first thing I did was take the source of corelib and zip it together with the source code of my library to give to the developer. Now he could work while I solved this SWC problem. I saw a post on the corelib group site, but it did not quite solve my problem. So I emailed one of the corelib developers from Adobe.

He thought I should be able to add any SWC to the CS3 project's classpath (file->publish settings -> flash.) That did not work. I was able to compile against classes in the SWC, but got runtime errors equivalent to a Java NoClassDefError. 

About the same time, I was reading some documentation on PureMVC, an AS framework that looks promising to me. I noticed that it was supposed to be able to work with Flash CS3 and it was distributed as a SWC. I read the install directions for CS3 ... they indicated that you needed to use the source code, not the SWC.

So now I'm thinking that there may not be a solution to this problem. Maybe this is a bug in Flash CS3?

New IBM Tutorial on XUL

I wrote a tutorial on XUL for IBM. It's a very introductory look at XUL. You can do some seriously crazy programming in XUL. The focus of the tutorial is on how web skills can be leveraged in XUL. Adobe AIR is getting a lot of press right now (and deservedly so) for letting web developers bust out some desktop apps. XUL lets you do the same thing. It's definitely a little more complicated than AIR, but also much more powerful. XUL gives you access to a lot more desktop resources than AIR does. Plus, if there's something that it doesn't already give you, then you can just write some native code and expose it via XPCOM. I think a lot of AIR developers are already begging for this kind of extensibility.

FlexCamp

I went to FlexCamp last night at Adobe's office in San Francisco. It was awesome. Adobe really knows how to host an event and how to treat developers. I was impressed. It was really cool seeing new Flex Builder 3 features presented by developers (and QA!) One of the sweetest moments was one of the developers showing how you can preview variable expressions during debug sessions just by mousing over the expressions. That may sound like a small thing if you haven't debugged code, but it's really useful. It elicited huge, spontaneous applause from the crowd of developers.

The demos by MixBook and SlideRocket were also really impressive. I was particularly blown away by SlideRocket. I was talking to one of the Adobe guys during a break and he told me that SlideRocket was completely coded by one guy, which just blew me away.

I was also really impressed with the Fireworks integration with Flex. I loved the idea of a designer using Fireworks to create a visual prototype using actual Flex UI components. Designer-developer workflow is still a holy grail of application programming IMO, and this was a small, but significant step in the right direction.

I did a presentation on using Flex to build a Facebook app. It was late at night. I was pretty tired and tried to keep it to 15 minutes, but I think it went over pretty well. I had lots of people asking me for the slides afterwards, so here are the slides in PDF. Also, here's the code for YouTubeFaves.

Google Gears

This is actually the second time I've written about Gears. The other time, Flock ate my post. I wasn't too upset, since I was using a daily build of "Sulfur". It's much better (in terms of feature set) than the current 0.7 version of Flock, at least when it comes to blogging on Blogger because it supports Blogger labels. Anyways, back to Google Gears.

I gave it a try (via Google Reader of course), and was not too impressed for one simple reason. I have to tell it to "go offline." So I guess the idea is that I know I'll be offline later, so I will "go offline" now, thus downloading content to read later. Ok, that's fine, but not very useful. It requires too much planning, in my opinion.

It's really not that big of a deal for Google Reader. But clearly Gears has the most potential for other Google Apps that have more direct "offline" analogies: GMail and Google Docs. The choosing to go offline thing would be silly for either of these.

With a Gears enhanced GMail, I would expect to always have a copy of (at least) my most recent email. I'd expect to be able to search it, too, but that's another story for another day. For Google Docs, I would at least expect to have an offline version of all my "active" docs. For both of these apps, I would expect to have these things all the time, seamlessly. Anything else is of very limited value in my opinion.

So I am left to assume that Google will enable this kind of seamless enhancement via Gears, but they just haven't figured it out, yet. I think that makes the most sense. If they had figured it out, I'm sure they would have enabled it with Reader, even though it's not quite as essential for Reader. In fact I'll wager the reason they launched with Reader was exactly because they didn't have the above use cases solved, yet.

One other Gear related thing. I was fascinated that Adobe seemed to be hanging around for the launch of Gears. It's interesting in a lot of ways. First, Adobe already has something similar, but far less powerful than Gears: Flash Shared Objects. Gears and its database make SO's look silly. Second, doesn't a Gears enabled Flex application provide everything that an Apollo application could promise? Sure, an Apollo app could be "heavier", have a fancier UI maybe, do more with local files, etc. Finally, I got the feeling that there was a Adobe+Gears announcement that didn't happen. That something that was supposed to be ready for Google Developer Day, wasn't ready. That's why Adobe was there.

Flex Stocks Updated

I tweaked the Flex version of the Stocks app. I cleaned up the UI to make it just plain ol' white. I also integrated the HTML "host" page for the SWF file with the WAR and the source. So here it all is:

• Deployable WAR -- Drop it into to your web container and go to http://localhost:8080/Stocks
• WAR Source Code -- Unzip it and import into Eclipse
• Flex Source Code -- Unzip it and (hopefully) import into Flex Builder.

Enjoy!

I'm thinking of refactoring the original GWT app to use the exact same code as the code used here. More on that later.

Flex Stocks

As planned, I re-implemented the Stocks application from the first GWT tutorial using Adobe Flex. Here is a link to a short document I put together outlining the code and the interesting parts. It also has links for downloading the code I wrote.

It was really pretty easy to do this. Of course this was a pretty simple application. I might try to re-implement the advanced version of the Stocks application from part of the GWT tutorial. First, I'll do the easy one in Silverlight.

Silverlight

Microsoft's announcement of Silverlight seems to have really caught a lot of attention. I'm having a hard time understanding this. What did they really announce that we didn't already know?

• Free storage for streaming video using Silverlight: That's nice I guess. In typical Microsoft fashion, they are subsidizing the switch from an existing technology (Flash) to their own version of the same thing. Don't get me wrong, there's nothing wrong with that.
• .NET CLR included with Silverlight: This is the big news, I guess. Well not really. Using the CLR as a runtime for rich content over the web is not new. It was always one of the ideas behind .NET. It's a replacement for ActiveX, which even Microsoft seems to hate now (well at least IE7 complains and warns a lot about it.) MS obviously had to include some kind of runtime with Silverlight. Adobe has its supercharged version of JavaScript, ActionScript (Microsoft has this too, it's called JScript.) The CLR that will be included will be a subset of the "full" CLR. So it just means that Silverlight devs can use a stripped down version of C# that will (just guessing here) will perform JavaScript like duties. That's nice. I guess. I'm going to conjecture that for most things you will do in Silverlight, it will be a lot easier to use a dynamic language like JScript (or Python or Ruby, as .NET versions of those were mentioned) instead of C#. Adobe experimented with making ActionScript more Java-like with ActionScript 2.0, and re-thought the decision with ActionScript 3.0.
  
• Silverlight CLR open sourced and ported to Firefox and Macs: Oh wait, this is the big news. Actually I guess it is, but not for the reasons most people think. This is Microsoft's white flag. They are admitting that a lot of people use Firefox now and there's even a reasonable number of people using Macs. So for them to compete with Flash, they need to support Firefox and Safari.
• Silverlight CLR on Windows Mobile: This is actually the most interesting thing to me, though I am somewhat skeptical. The idea of being able to write an application that works on the web, on the desktop, and on a mobile device is very appealing to me. Heck, I basically spent a year of my life writing a language to do exactly that at Ludi Labs (RIP.) I went to one of those grandiose Microsoft launch parties earlier this year just to see what progress they had made on this front with Windows Presentation Foundation err I mean .NET 3.0 err I mean Silverlight. The stuff I saw from Mix only seemed to indicate things like video streaming (more on that soon) than real application development. That's why I'm still skeptical. I've written Windows Mobile apps and it is definitely a differentiated development experience vs. writing a Windows application. Sure a lot of things are similar and you can use some of the same languages (or a subset, does this sound familiar?)

Now part of why I'm not so impressed with Silverlight is that I mostly care about application development. It seems to me that Silverlight will basically enable developers to build Flex-like applications. I see its support for CLR languages as a minor advantage. It will be interesting to see if they give away a Visual Studio Express edition for doing Silverlight development. That would be an advantage over Flex. Otherwise, I see this playing out similar to how the introductoin of C# and .NET played out. Microsoft shops may switch to it, but it's hard to imagine Flex developers switching to it.

There's big wrinkles I've left out. The biggest is streaming video. It may very well be that Silverlight provides superior streaming video capability. If that is the case, then a Silverlight based YouTube would seem to have potential. It would be a real boon to pirated video, like HD episodes of TV shows. That would be huge. If works great on phones, even better.

The last piece of the puzzle is the desktop. Is Microsoft going to push Silverlight as a desktop application development? I did not get this impression. It seems possible, but why would they do this? Adobe is certainly going this route with Apollo, but Adobe doesn't have any presence on the desktop. Microsoft already owns it. So it seems like Silverlight would only be used as a counter, if needed. I'm not really sure it will be needed though.

Opening Up Flex

Interesting news on Adobe open sourcing some of the Flex platform. Here is a cool video from the Scoble Show on the architecture.

For the past couple of years I've thought Flex had some clever concepts behind it, but it was going to be collateral damage in the ascension of AJAX. Why? It was too closed on multiple levels. First, to take advantages of its greatest strengths (continuous, bidirectional communication between client and server) required a proprietary Adobe server. Second, the development tools were also proprietary. It's hard to quickly prototype something in Flex, unless you've already made an investment in it. That is poison for innovation. That's also why so much more innovation occurs in Java and PHP rather than .NET, but I digress.

I don't think the above equation has changed with Adobe's new open source initiatives. However, it seems like maybe they are more concerned with competing with .NET/XAML/SilverLight as browser/desktop hybrid technologies. There might be some potential in that, but I still don't think they have the right strategy for it.

Imagine if you were at a mall and you were hungry. There were several hamburger stands in the mall. The hamburgers were pretty cheap and pretty good, and there was a lot of variety. There was one place (Microsoft) that sold hamburgers and fries, but it was very expensive. Now let's say you wanted to sell hamburgers and fries as well. You could make a hamburger and fries that were in similar quality to the sole hamburger+fries vendor, and maybe charge a little less. Or you could make a hamburger that could stand on its merits to the many hamburger-only places, and charge a price similar to those guys. It's riskier, because there's so much competition, but you could still charge a nice premium for the fries. If people start buying your hamburgers, there's a good chance some will splurge on the fries too.

Adobe has chosen to charge a lot for both the hamburger and the fries, just like Microsoft. It's a safer strategy, but with a lot less upside in my opinion. They have to hope that Apollo will lead them to success, because otherwise my original thought will still hold. Flex will be a casualty of Web 2.0.

Adobe Apollo and Flex

With all of the recent hoopla around Adobe's Apollo, I decided to give it a try. From what I've read, you should be able to develop a web application and Apollo will give it an "offline" mode. So you could just build a typical web application or even an AJAXy one. I figured for the full Adobe effect, maybe I should finally dip my toe into the Flash waters.

So I downloaded a trial version of Adobe Flex Builder, plus the Apollo SDK and extensions for Flex Builder. It turns out that Flex Builder is built on Eclipse. That made me optimistic. Not only do I think Eclipse is a very smart platform to build on top of, but I know Eclipse really well. One would think that my familiarity with Eclipse would help me to be productive with Flex Builder.

A direct consequence of the Eclipse heritage is that there are two installations options for Flex Builder. You can install it "standalone" or as an Eclipse plugin. I have a lot of Eclipse plugins, but I've had some bad experiences with "bigger" plugins in the past. For example, when I was at Vitria, I was using Xml Spy for debugging complex XQuery expressions. I had the professional version of it, and it gave you the option of installing an Xml Spy-Eclipse plugin. I thought "cool, I can do my XQuery debugging inside Eclipse!" That may have been true, but I'll never know because it really hosed my Eclipse installation. I had to wipe it out and rebuild it. Rebuilding an Eclipse installation that involves lots of plugins is a real pain.

So needless to say that when confronted with a commercial application wanting to install itself inside Eclipse, I always decline. So I went with the standalone installation of Flex Builder. It was pretty quick and clean. One thing I noticed was that installed a JRE. Thankfully it only installed it inside its installation directory and it did not mess with any environment variables. I've been burned by Oracle installing its own JRE and then putting it on the path or even redefining $JAVA_HOME...

Still you would think that the Adobe installer would be a little smarter. It would be easy to detect if Java is present on the path. If it is, then don't bother installing a JRE and just use the system's JRE. Also, digging around I quickly found that the JRE they included was the HotSpot 1.4.2. Talk about old! Hopefully they'll skip 1.5 and move straight to 1.6. They may not get much advantage out of 1.5, but the speed improvement on 1.6 (particularly for a long-running process like an IDE) is definitely worth while.

Enough complaining about the installation... Here's what it looks like fresh out of the box on Windows.


Pretty similar to Eclipse. It seems like the big difference is the squarish windows. Of course the options in the menus are a lot different. They are very simplified with just options for creating Flex projects and objects. They did leave in the Software Updates, so you can easily install Eclipse plugins. That is very nice. All in all I am looking forward to building something Flashy.

Slideshow Software

This past weekend was Raymond's first birthday party. One of the things I did for Michael's first party was make a slideshow video of the best of the many, many pictures we had taken of Michael. Of course a lot of the pictures were really cute, and it's also interesting to see him grow up in the pictures. I thought I would do the same thing for Raymond.

When I did Michael's slideshow, I used my G5 with the iPhoto/iDVD integration. It's been almost two years since then, and I am no longer a Mac user. I didn't think something as simple as making a slideshow would be require very sophisticated software. I decided to try Windows Photo Story. This was a disaster.

It was easy enough to add photos, edit photos, etc. It was the music that became the first problem. First, you have to place the music in the slideshow manually, i.e. pick which picture to start each song on. There is no fit to music. It default to 5s durations per slide. So you basically have to either pick enough music to take 5s * number of pictures or edit the duration of each slide. If you go the second route, it gets worse. There is no way to change the duration for all the slides or even two slides at a time. That's right. If you wanted to make it 6s per slide and had 200 slides, then you have to change this one at a time on all 200.

But wait, it gets worse. Photo Story incorrectly calculates the length of variable bit rate mp3s. If you're like me and use LAME to rip most of you music, then most of your mp3s are variable bit rate mp3s. So for example, I wanted to include the song "Close to Me" by The Cure. If I look at this song in iTunes, it correctly shows it as being 3:40 long. In Photo Story, it was convinced the song was over 6 minutes long. So in my editing of the slideshow, it showed what slide the song would end on. Of course I picked the next slide to begin the next song, and what did I get? Three minutes of slides with no music behind them.

I thought about trying Windows Movie Maker instead, but then I figured that a more general purpose program for Microsoft would probably not be any better at a specialized task. So at the advice of my wife, I tried using Adobe Photoshop Elements.

We use Picasa for organizing our pictures, but before we switched to using Picasa, we used Adobe Photoshop Album which then became Adobe Photoshop Elements. This was a much better experience. First off, it had the coveted "fit to music" feature. However, it still had issues with vbr mp3s. All was not lost. It allowed me to simply edit how long each song was to play. So I could look at iTunes and see how long each song really was, edit it to play for that much time, hit the fit to music button and I easily had seamless music for my slideshow.

There were some things that were nice about Photo Story. It automatically did the Ken Burns effect, something I liked from using iPhoto. I'm not sure if there was an option for this in APE. I liked Photo Story's UI a little better too.

Now it was time to burn my little slideshow so I could play it at the party. Here is where things were not so good again. APE did not have any kind of DVD burning option. It did have a VCD option, so I thought I would give that a try. First it converted the slideshow to Windows Media Video file (why oh why this option) and then it tried to burn it to a CD. It took forever for it to make the WMV file and then it had an error burning the CD. I couldn't just put in a new CD for it to try again, it had start over. This was really annoying.

So instead of doing the burn VCD option, I decided to just export to WMV so that at least the fruits of the labor would be persistent. Again this took a long time. I had done this on Photo Story and it was much faster (and gave a lot more options on the quality, and it was encoding a slideshow with the aforementioned Ken Burns effect enabled, which would seem like a more complex encoding task.) The encoding did seem to make use of both cores on my computer, keeping one core maxed out and the other at around 70%, but it still took close to an hour to encode a 20 minute video.

Once I had the video, I decided to use Nero to burn it. My only option with a WMV on Nero was a Super VCD, so I went with that. Again, Nero had to decompress the video before burning it, which took awhile. Once it did that, it burned rapidly. The quality was really not that great. The WMV movie looked very good, but the burned result was so-so. I made the WMV at 800x600, the highest quality offered by APE and a much higher resolution than Super VCD supports. Still the encoding-decoding-encoding process is going to be lossy, no way around that.

So all this made me really miss my Mac! It was so nice being able to create the slideshow in iPhoto, then just export it to iDVD. The DVD it would burn was really nice, and of course I could do other fun things like create menus, etc. for my DVD. The WMV creation with Photo Story was definitely a lot faster than the similar step on the Mac, but was painfully slow from the Adobe program. I'm not sure if it was slower than the same thing on the Mac. The other steps were a lot faster than they were on the Mac, but again I'm comparing a first generation G5 Power Mac to a year old, custom built Athlon 64X2. Still, I would have gladly traded a slower encode/burn process for an easier creative process.

Now there are other software packages out there. I used Roxio Easy Media Creator at the recommendation of my brother-in-law. It was an incredibly slow program to use, and seemed very unstable. Perhaps it is better now. Still, it's really disappointing that there's not an easy way to do something like this on Windows.