Tag: Apple

App Store First Impressions

Today Apple launched the App Store for Mac. The App Store on the Mac is a lot like the App store for the iPhone/iPad/iPod that is part of the iTunes Store. I’ve been spending some time today trying out the App Store, have downloaded a few of the free applications, and have made a few modest purchases. Here are some of my initial impressions.

The App Store is installed when you update your Mac operating software to 10.6.6 (by selecting “Software Update…” from the Apple Menu). It is not available to those running older versions of the Mac OS, like Leopard and Tiger. This is not much of a problem for me, as I almost always run the latest version of the operating system. But I do know people who are still running older versions of the Mac OS who won’t be able to attend the App Store party, at least not until they upgrade (assuming they have an Intel Mac and can upgrade to Snow Leopard).

Once installed, the App Store icon appears in the dock, by default right next to the Finder icon. A link to the App Store also appears in the first section of the Apple Menu, right below Software Update. And of course, the App Store application can be found in the Application folder. The App Store for Mac is not hard to miss, but It’s not built into iTunes, where I suppose it could be confused with the App Store for iOS.

Although the App Store is a separate application from iTunes, it borrows heavily from the App Store on iTunes in form and function. You use your Apple ID to login, and iTunes Store account information is used for any purchases. So if you got an iTunes Gift Card like I did over the holidays, you can now use it to pay for Apps from the App Store. This makes those iTunes Gift Cards quite versatile: I can use them in iTunes to purchase music and music videos, rent and/or purchase movies and TV shows, buy audiobooks and apps for my iOS devices, plus I can use them in iBooks to purchase books. And now I can use them to buy software for my Mac. Sweet.

One of the first things I noticed after I launched the App Store was that it recognized quite a few programs already installed on my Mac. For example, instead of a “Buy” button next to the description for iMovie, there was an “Installed” button. This was true for all of the programs in the iLife and iWork suites, as well as some third-party programs that I had on my computer, like MacFamily Tree from Synium Software and Transmit from Panic Software.

But interestingly, not all programs that are on my computer show up as installed in the App Store. For example, I own iStopMotion Home from Boinx Software, yet the App Store does not seem to recognize it. At first I thought this might be due to having a different version installed, but no, the version on my computer is the same version that is available from the App Store. This behavior is not unique to Boinx products, as I noticed the same thing with Compartments from LittleFin Software and TapeDeck from SuperMegaUltraGoovy (yes that really is the name of the developer of this fine audio recording app). I suspect that programmers need to include something in a a program’s code in order for the App Store to recognize it as installed, so perhaps these programs just need to include this code in future versions.

The first program I purchased on the App Store today was a game called Chopper 2 from Majic Jungle Software. I own the first version of Chopper, and thought this would be a good time to upgrade to Chopper 2. The price was certainly right: Chopper 2 is just 99 cents (for a “limited time” according to the App Store). Purchasing was easy, and proceeded much like a purchase in iTunes. Once I clicked the Buy button, I saw a cute animation of the Chopper 2 icon flying from the App Store to land in the dock, along with a download progress indicator below it. Once installed, the Buy button became an Installed button in the App Store. Unlike my other apps that the App Store recognizes as installed, Chopper 2 was listed in the App Store under the purchases tab. It seems that only apps purchased through the App Store show up on this list.

One of the most interesting things I noticed about the App Store was the dramatic reduction in prices on some of Apple’s products. Aperture, for example, retails in a physical box for $199, but costs just $79.99 as a download through the App Store. This is less than the price of the Academic version of Aperture, which unfortunately is not available for upgrade pricing. (I wonder if the App Store version of Aperture will be eligible for upgrade pricing when a new version comes out.) Even more dramatic is the cost reduction of Apple Remote Desktop. Yesterday this product cost $299 for the ten seat version and $499 for the unlimited seat version. But today it can be downloaded from the App Store for just $79.99. And since the App Store description doesn’t mention a seat limitation, this might be the unlimited version, which could make this a very tempting purchase. What is not clear to me, however, is whether the terms of the license for this product would allow me to use it to manage a small group of computers where I work. The license reads that I can install the software on computers that I “own or control,” so perhaps this might be permissible. In any case, it’s interesting that the version of ARD on the App Store makes no mention of a limit on how many clients one can control; I’m still not clear on why Apple decided to sell two different versions of ARD based on the number of clients anyway.

There are plenty of good apps available at good prices in the App Store. There are also quite a few not-so-good apps available, but I suspect the overall quality level of the software available will improve with time. Noticeably absent from the App Store are the big third-party software companies, like Adobe and Microsoft, which is perhaps not surprising. Staples like Roxio’s Toast and Parallels Desktop are also absent. Given the time of the year, I was really surprised not to find any of the major tax preparation programs available on the App Store. Neither Intuit’s TurboTax nor H&R Block at Home (formerly known as TaxCut) are currently available.

Another surprise was the absence of iBooks from the launch of the Mac App Store. Amazon’s Kindle app is on the App Store, so I suspect it won’t be long until we see iBooks released for Mac. But this raises an interesting possibility of having three programs on my Mac where I could spend my iTunes gift cards: iTunes, the App Store, and iBooks. Perhaps this is the start of a trend, and someday Apple will enable the use of iTunes cards in iPhoto for paying for cards and calendars.

In general, I think the App Store is off to a strong start. There are some inconsistencies in how it recognizes installed apps, and I hope Apple improves on this feature in a future update. I think the App Store could eventually move closer to the functionality of the MacUpdate Desktop App, recognizing all of the software on your computer and alerting you to any available updates. The current number of apps for sale in the Mac App Store is modest; at the moment, there are only 7 programs available in the news category, 8 programs in the Weather category, and 9 in the Medical category. But I suspect the number of available apps will grow quickly as developers recognize the potential of this new marketplace for Mac software.

Podcast Producer 2 and the iPad

Shortly after I got my iPad, I discovered something interesting. Whenever I visited one of the many web pages on my Snow Leopard Server with embedded videos created by Podcast Producer 2, the videos wouldn’t play. When I clicked the thumbnail, the image would just turn to a black square.

Some of you who read my blog know that I’ve written many posts about Podcast Producer 2, a key component of Snow Leopard Server. I’ve described various techniques for getting Podcast Producer 2 (PP2) to “play nice” with Windows Internet Explorer, and how I substituted the Quicktime plugin for the open source Flash player Flowplayer. Of course, Flash doesn’t work on the iPhone, but that wasn’t a major issue since Snow Leopard Server dishes up a different version of a PP2 page for iPhones. I had hacked together a solution that would serve PP2 videos inside Flowplayer when viewed on a computer browser, but serve PP2 videos inside the native H.264 player on the iPhone.

But my little cludge didn’t work on Mobile Safari on the iPad. That’s because Snow Leopard Server doesn’t serve up a different page for iPads like it does for iPhones. Perhaps this is deliberate, since the bigger screen real estate on the iPad doesn’t necessitate the compact presentation of an iPhone-optimized page. Or perhaps Apple didn’t include in the latest update to Snow Leopard Server specific user agent detection code to serve iPad-optimized pages.

Whatever the case may be, I reported this situation as a bug to Apple a few days ago. I had hoped that the most recent Snow Leopard Server update would include code that would produce PP2 pages that could be viewed on the iPad, but no such luck. Hopefully, this will come in an update down the road. But until then, I’ve developed a workaround.

Here’s how I got PP2 to play nice with the iPad…

First, I downloaded the open source javascript library Modernizr from http://www.modernizr.com. This little gem allows one to detect whether a client’s web browser can handle HTML 5. Mobile Safari on the iPad can display HTML 5 video, and in fact, Apple explicitly recommends using the HTML 5 VIDEO tag to display video on an iPad optimized page in this technote.

I put the Modernizr javascript file in my web directory (I just put it at the root level). Then I added a line in the custom wiki theme that I use for PP2 pages. The line I added is just a simple SCRIPT tag that references the Modernizr javascript file. Essentially, every page the PP2/Wiki Server produces that uses this custom wiki theme will include a call to the Modernizr javascript library. This wasn’t hard to do; in fact, the process was very similar to what I did to add a call to the Flowplayer javascript library that I described in great detail in a previous post.

Next, I added the following bit of code in the expandMedia function found in wiki.js (and compressed_wiki.js)…


else if (Modernizr.video) {
var objectHTML = '<video autoplay width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" src="'+fullSrc+'?sessionID='+server().sessionID+'" controls></video>';
embed.innerHTML = objectHTML;
Element.hide(img);
}

Essentially what this code does is call on Modernizr to test whether a browser supports HTML 5, and if so, uses HTML 5 to display the PP2 video instead of presenting it with the Quicktime plugin. I use the autoplay attribute to cause the video to click when a user clicks on the thumbnail. And the controls attribute causes the video to be displayed with whatever playback control bar is provided by the browser.

Again, I describe in great detail in this previous post the process for editing the wiki.js and compressed_wiki.js files, since I used a similar technique for swapping out the Quicktime plugin for Flowplayer. I would certainly recommend making backups of the original wiki.js and compressed_wiki.js files, as well as any modifications, since these files will likely be overwritten by future Snow Leopard Server updates.

With these changes, the Podcast Producer 2 videos on my website can now be played on an iPad. Indeed, as an added bonus, these videos are now displayed using HTML 5 on any web browser that supports HTML 5, like Safari and Chrome. The Modernizr script detects whether the page is being viewed in an HTML 5 capable browser, and if so, my code swaps in the appropriate HTML 5 code.

My iPad is happy now. Here’s hoping that the folks at Apple who maintain the Snow Leopard Server code will produce an update that will work with an iPad someday. Until then, my little hack seems to do the trick.

Why iWant iPad

Apple has officially announced the iPad. And iWant one.

The iPad hasn’t even been officially released, and it’s already being panned by critics who just don’t get it. Moments after the iPad announcement, Fake Steve Jobs (Dan Lyons) called it “underwhelming.” Many see it as just a big iPod Touch or an “iPhone on steroids.” Others compare it to Tablet PCs, which have been largely unsuccessful. Some wonder if the iPad will be just a newer Newton, one of Apple’s biggest flops. There are those who are disappointed by the lack of a camera. Or the apparent inability to support Flash content. Or the big bezel around the 4:3 ratio display. Or the onscreen keyboard. Or a host of other nitpicking criticisms that, in my mind, miss the whole point of iPad.

And that point is best summed up by Jonathan Ive in the opening lines of the promotional video: “When something exceeds your ability to understand how it works, it sorta becomes magical. And that’s exactly what the iPad is.”

Yes, the whole point of the iPad is to be magical. Sure, one can already do much of what the iPad can do on a laptop or an iPhone or an iPod Touch. And many of the initial criticisms of the iPad have come from comparisons to other things that can do what the iPad can do.

But I don’t want an iPad because of what it can do. I want an iPad because of how it will do it. And from what I’ve seen, it does indeed look like magic. Understated elegance. Intuitive interface. Brilliant display. Screaming fast. Amazing price. Serious magic.

And iWant that magic.

I don’t want the iPad to replace my MacBook. Nor do I want it to replace my iPhone or iPod. And I don’t expect it to. Yes, I will probably use the iPad to read my email, keep my calendar, show off my photos, listen to my tunes, watch some videos, and surf the web. But I don’t want an iPad just to do those things. I want an iPad because I want to do those things (and more) in a new way, a fun way, even a magical way.

And iWant what could be the iPad’s killer app: iBooks and the iBooks Store. I’ve been holding off on getting a Kindle. I was really tempted to buy a Nook. But I’ll put down my money for an iPad, so I can read books in full color, on a bright, backlit screen. I know there are those who say it will be hard on the eyes, that monochrome e-ink displays are better. I don’t think so. I’ve spent some time with a friend’s Kindle, and I didn’t find it particularly easy on the eyes. If anything, I found it harder to adjust to an e-ink display after spending most of the day looking at a computer screen. Maybe my eyes are different. Or maybe I just don’t buy the argument that a black-and-white display is somehow better than one in full, glorious color. Go figure.

And even if my eyes do tire after an hour or two of reading iBooks on an iPad, at least I can do something else with it besides read books. A whole lot more than I could do with a Kindle, or a Nook. And for not a lot more money.

It would be nice if Apple gave an educational discount on the iPad. Apple typically does give a small price break to educators and students. It wouldn’t surprise me if they didn’t give one on the iPad, at least not at first. But I would be very surprised if Apple didn’t eventually have some kind of promotion to make the iPad even more affordable for the education market. Perhaps in their next “back to school” promotion, in time to get iPads in the hands of college students everywhere. Who knows? Maybe the iPad will even make reading textbooks fun again. OK, maybe reading textbooks was never fun. But I’ll take anything I can get that would help my students get more out of reading them.

So let the naysayers and critics write all the negative reviews they want. I’ve heard this kind of reaction to Apple products before. Some people have been calling the Mac a “toy” since the day it came out in 1984. Some people predicted the iPod would never catch on, and that the iTunes store would never be successful. Some people even thought the iPhone would be a flop. And some people today think the iPad will be a failure.

Some people never learn. If there’s one thing Apple can do, and do well, it’s create products that people want. And I firmly believe that people are going to want the iPad. Lots of people.

I know iWant one.

Adding Flowplayer to Podcast Producer 2

Today I had another breakthrough in my implementation of Podcast Producer 2, a core part of Snow Leopard Server. As noted in my previous posts, PP2 is “still a work in progress,” but it is also a vast improvement in many ways over my previous video transcoding system based on ffmpeg and Drupal. I’ve been consistently impressed with the quality of the videos produced by PP2, although the file sizes are a bit larger than what I squeezed out of ffmpeg. But one thing that hasn’t impressed me is the “plain vanilla” look and minimal functionality of videos presented using the Quicktime plugin.

I realize there might be valid reasons for Apple sticking with the Quicktime plugin rather than using a more modern-looking javascript player. But for the life of me, I can’t think of any reasons that would excuse Apple from not providing its Snow Leopard Server customers with the option to make videos look as good as on Apple’s site. Almost everywhere you look on Apple’s website, you see snazzy-looking Quicktime presented in cross-platform stable players, typically built in javascript. Even the new Quicktime player that is included with Snow Leopard client gives you a javascript option when exporting a video for the web. So why didn’t Apple provide a javascript player option with Podcast Producer 2? At the very least, Apple could have provided some configuration hooks to make it easier to do something other than present videos using the Quicktime plugin.

But where there’s a will…there’s got to be a way. And my “breakthrough” today was in finally finding that way. It isn’t using one of the various javascript players you can find on Apple’s site. Those aren’t at all well-documented, and trying to piece together something workable from the clues found in page sources is not my idea of a fun afternoon. No, the player I’m using to present the Quicktime videos produced by Podcast Producer 2 is Flowplayer, a really great little Flash-based player.

With my previous ffmpeg/Drupal system, I had been using a Flash-based player to present the videos: the venerable JW Player (now a product of Long Tail Video). But for a variety of reasons, I couldn’t get this player to work right with the m4v Quicktime files produced by the PP2 system. And the look of JW Player is getting a bit dated, although not nearly as dated as the look of the Quicktime plugin. Flowplayer, on the other hand, is modern-looking, clean and well-documented. The key to getting Flowplayer to work with PP2/Wiki server was finding just where to put the code…something that I mentioned at the end of my last post.

So today, after editing some code in the wiki.js and compressed_wiki.js files (both located in usr->share->collaboration->javascript), I now have Flowplayer injected instead of the Quicktime plugin whenever a user clicks on a thumbnail. The main edit was to the objectHTML variable (quoted in my previous post). In essence, instead of referencing the Quicktime plugin, I referenced the SWF player file included in Flowplayer, and passed to it the same parameters that had been going to the plugin. To keep things in line with the way the Quicktime plugin had been injected, I used the OBJECT method of inserting Flowplayer. To keep Firefox happy, I echoed this change using the EMBED method found in the embed.innerHTML variable in the code right below the objectHTML variable. I also tweaked the height adjustment, adding 24 pixels to video files and 8 pixels to audio files (using extendHeight?24:8) to accommodate the slightly higher control bar of Flowplayer. And to get the Flowplayer javascript file loaded, I added a call to this file in the head of the default.xsl file in the Wiki theme folder (and in the enclosed compressed folder). And that’s pretty much it.

Now videos on my site look so much better, with a decent looking control bar that I can customize to my heart’s content. Time indicators? Check. Slick color instead of boring monochrome? Check. Volume slider you actually notice? Check. Seek bar with time points? Check. Big bold play and replay buttons? Check. Options galore for tweaking things just right? Check.

It did take some effort to get my head around the code I needed to adjust in Apple’s javascript files. And yes, my changes will most likely be overwritten by a software update, so I’m being careful to backup my edits. But now that I understand where to make the changes, and how, I think I will continue to use Flowplayer instead of relying on the stock Quicktime plugin to present PP2-produced videos.

At least until Apple does the right thing and finally brings to their Server product a decent javascript player…like the ones that have been used for a long time on Apple’s own web sites.

Getting Podcast Producer 2 to Play Nice With Windows

In my last post, I wrote about my experiences with Podcast Producer 2: the good, the bad and the downright ugly. Well, I had a bit of a breakthrough today in getting Podcast Producer 2 to “play nice with Windows,” so I’m posting my “new and improved” workaround.

As I described earlier, the main problem is the way PP2 posts videos to user blogs maintained by Wiki Server (which is a core part of Snow Leopard server). The primary culprits are the width and height tags that are included in the IMG tag that is written to the blog entry. If the video files were of a small resolution, PP2 would typically write out height tags that were empty, which breaks Internet Explorer on Windows, since IE assumes an empty height tag means a height of zero. But even if the video files were at a larger resolution, PP2 would write out width tags that were narrower than the actual width of the video file, presumably to make the thumbnail smaller than the video. That breaks any browser on Windows, since the Quicktime plugin for Windows doesn’t seem to be able to scale videos to fit within the dimensions defined by smaller-than-actual width and height tags. It works fine on a Mac, since it appears that the Quicktime plugin for Mac can shrink videos to fit into whatever dimensions are defined in a web browser.

My workaround was to manually edit these entries, removing the width and height tags. This would make the thumbnails full size, the same size as the associated video files denoted in the ALT attribute of the IMG file (a rather non-standard use of the ALT attribute, but that’s another issue). This workaround was a lot of work: manually editing the HTML of each and every video file produced by my server had become a daily chore. In the last month, I had edited over 1,000 blog entries. But at least the videos would play on Windows.

I had originally thought I should be able to fix this by changing the code found in the “_podcast.html” file found in the WikiTemplates folder in Library->Application Support->Apple->WikiServer. After all, this file looks like the exact template used by PP2 when it posts to WikiServer. But even though I removed the width and height attributes from this template file, it had no effect on the blog entries posted by PP2. I have since found that these templates are not used by PP2; they are used by WikiServer itself. That is, when you go to a user blog, click the plus sign to manually add a blog entry, and select the option to add podcast content, the resulting code is drawn from the _podcast.html file in the WikiTemplates folder. So PP2 must be getting the code from somewhere else.

Today I found out where: in a line of code in /usr/lib/podcastproducer/actions/wikiserver.rb. Near the top of this file is the following line…

MOVIE_ERB_TEMPLATE = "<%= h($properties[\"Description\"]) %> <br> <br> <img src=\"<%= poster_image_url %>\" alt=\"<%= published_url %>\" width=\"<%= width %>\" height=\"<%= height %>\" class=\"aligncenter posterimg\" />"

Bingo. I just took out the width and height tags from this line and restarted the server. Now PP2 doesn’t write out the width and height tags when it posts video podcasts. And I no longer have to manually edit the posts produced by PP2 to enable them to work on Windows. Hallelujah.

While studying this file, I think I discovered what may be the reason why PP2 is mucking up the dimension attributes. Further in this file are these lines of code…

if width > 480
height = PcastQT.info(input_published_path, "height").to_i * 480 / width
width = 480.0
end

So if I understand this correctly, what this does is check if a video is wider than 480, and if so, force it to stay at a width of 480 and adjust the height downward proportionally. That is, if a video has standard “VGA” dimension of 640 wide by 480 high, this bit of code forces it to be 480 wide by 360 high (the original height 480 multiplied by 0.75, or 480/640). And again, this scaling of the thumbnail downward is what seems to be breaking the Quicktime plugin on Windows.

I’m still not sure why videos that are smaller that 480 wide are being posted by PP2 with an empty height attribute, but I have a theory. I notice that in this section of code that the width is explicitly defined by this line of code:

width = PcastQT.info(input_published_path, "width").to_i

But height is not explicitly defined UNLESS the “if width > 480″ is evaluated true. This could be why I’ve discovered that for smaller submitted videos (say at a resolution of 320 by 240) the code being posted by PP2 has an empty height attribute (specifically, height=””). But whether or not this theory is correct, I’m happy that I’ve discovered a fix. By removing the width and height attributes completely from the MOVIE_ERB_TEMPLATE line of code, I’ve effectively addressed both the empty height attribute problem and the scaled-down width attribute problem.

Of course, Apple is likely to rewrite this file with a software update. Here’s hoping they correct this problem, so that I don’t have to hack the same file in the future. But just in case, I’ve documented my fix here for my reference, and potentially for the benefit of others frustrated trying to get Podcast Producer 2 to play nice with Windows.

UPDATE: I think I’ve discovered where the code lives that swaps out the video file for the thumbnail when you click on it. It appears to be in the javascript file wiki.js at /usr/share/collaboration/javascript/wiki.js. Near the bottom of this file is an “expandMedia” function that’s part of the QTMediaExpander class. The “objectHTML” variable appears to contain the code that embeds the Quicktime object…

var objectHTML = '<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" codebase="http://www.apple.com/qtactivex/qtplugin.cab"><param name="SRC" value="/collaboration/fake.qti"><param name="QTSRC" value="'+fullSrc+'?sessionID='+server().sessionID+'"><param name="TYPE" value="video/quicktime"><param name="SCALE" value="aspect"><param name="AUTOPLAY" value="true"><param name="CONTROLLER" value="true"><param name="TARGET" value="myself"><param name="BGCOLOR" value="'+backgroundColor+'"></object>'

I don’t think I should try to hack something here now, not with a PP2 server filled with 1200 videos and counting. But perhaps between semesters or over the summer break I’ll poke around here to see if I can’t get a prettier javascript Quicktime player instead of the plain vanilla Quicktime interface provided by the Quicktime plugin. Many people have requested a player that displays the elapsed time of the video, something I know is possible since Apple has such players on their own website (including here, for example).

Podcast Producer 2: Still a work in progress

I was eager to install Snow Leopard (SL) Server on the Mac OS X server I manage at work, primarily because of Podcast Producer 2 (PP2). This component of SL Server represents a major advance in functionality over the first version of Podcast Producer, which was introduced in Leopard Server. Unfortunately, after creating over 500 podcast episodes with PP2 so far, I’m convinced it’s still a work in progress. I’ve uncovered numerous little bugs that should have been caught in beta. I’ve reported these using Apple’s bug reporter (bugreport.apple.com), and so far I’ve heard back on exactly one of my bug reports with a terse message that it was a “known issue.”

Don’t get me wrong, I still think this is a great program. It’s much easier to configure and tweak than the first Podcast Producer, which was essentially unusable for my purposes. One great feature is the new Podcast Composer application, which makes it a breeze to create new workflows. The quality of the finished video podcasts is significantly better than what I was able to do previously with a combination of Drupal modules and the open source “Swiss Army Knife” of web video applications, ffmpeg. So all things considered, I think Podcast Producer 2 is worth the upgrade to Snow Leopard Server.

But I’ve discovered the hard way that it isn’t perfect, and some of the deficiencies are serious. I’m hopeful that Apple will soon release an update that addresses at least some of the issues I’ve identified. Until then, let me share a few of the annoying bugs I’ve found, and some of the workarounds I’ve discovered. I know from experience that when things go south, a webmaster’s best friend is Google, so perhaps some kindred webmaster will come across this blog entry and appreciate my documentation.

Earlier this month I documented three of these bugs with short videos that I posted to my MobileMe Gallery . If a picture is worth a thousand words, a video must be worth at least a few thousand more, so if you’re interested, I’d encourage you to check out these clips.

One of the biggest problems: PP2 doesn’t create episodes that reliably play back on Windows computers. This probably doesn’t come as a surprise; after all, this is a Mac program. But it’s a Mac Server program, and Mac Servers need to service Windows clients, so I would have hoped that this would have been better tested in beta.

Essentially, if you create a podcast from a video file using PP2, using a workflow that posts the podcast to the submitting user’s blog, the result is a blog entry that looks and works great on a Mac, but not on Windows computers with the latest Quicktime plugin installed. At first I thought this was an issue with Internet Explorer, and to some extent, the issues are greater with IE. But I believe the primary culprit is the Quicktime plugin, since I’m able to reproduce this bug with IE, Firefox and Safari for Windows. Yes, this bug even affects Apple’s own browser.

Thankfully, I’ve discovered a fix. The root of the problem seems to be the way that the podcasts are posted to the user’s blog. Rather than using an EMBED or OBJECT method, PP2 (and the SL Wiki Server that manages the blog service) links to the podcast via an ALT attribute to the IMG tag of the thumbnail, with a ROLE attribute added so that the thumbnail acts as a button for the video file. This is pretty slick coding, except for the fact that it doesn’t quite work right on Windows IF the HEIGHT or WIDTH attributes don’t match the dimensions of the video. And PP2 doesn’t insert the full HEIGHT or WIDTH attributes, presumably because the goal was to provide a thumbnail, not a full-size image. On a Mac, this is not a problem, as Quicktime on a Mac can play back fine within the scaled-down dimensions. But it’s a deal-breaker with the Quicktime plugin for Windows. If you click on one of these thumbnails on a Windows machine, the file loads, but you only hear the audio; no video appears. As best as I can tell, this is because the video doesn’t scale down to the dimensions provided in the IMG tag. Audio doesn’t have to scale so it comes through, but what’s the point of a video podcast if you can’t see the video?

The workaround is to delete the width and height attributes. While the result are full-size thumbnails, at least they work on Windows. Since I’m only deploying the iPod/iPhone resolution files (640 x 480), the thumbnails aren’t that huge. But it is a rather huge task to manually have to delete these width and height attributes. I would like to just delete this in the templates so that I didn’t have to do this every time a podcast is posted. And I can see where the templates are on the server. Unfortunately, editing the templates available in the Wiki Templates folder does not have an effect on the resulting code. Apparently, PP2 (or perhaps Wiki server) doesn’t read the contents of this templates folder when creating the pages. Perhaps there is some way to synchronize changes in the templates with the actual code produced (one would think there would be) but I’ve yet to discover it. If I find out, I’ll be sure to post an update. Until then, I’m manually editing the code of each podcast so that the majority of users who use Windows can actually see the videos.

It also would have been nice if the developers had included (or at least made available as an option) a Javascript player for the Quicktime videos posted to the user blogs by PP2. I find it interesting that nearly everywhere you see a Quicktime video on Apple’s own website, it’s presented in a Javascript player. Note only do such players look a heck of lot more “Web 2.0-like” than the standard OS 9 look of the Quicktime plugin, a more modern player might have alleviated the big problem of cross-platform playback. Indeed, one of my early efforts to develop a workaround for this problem was to present the videos using a Flash-based player (Dash Player by TMT Media). The Quicktime videos produced by PP2 will indeed playback quite nicely in an embedded Flash player (at least one that can handle MP4 files). But because making such a change would require extensively rewriting the code produced by PP2/Wiki Server, I eventually settled on the much easier (although still time-consuming) method of deleting the width and height attributes. I can understand why Apple wouldn’t include a Flash player with SL Server, but they could have at least put in a Javascript player.

Another small annoyance (and an almost humorous faux pas) is the fact that the “Subscribe in iTunes” link that is posted prominently on a podcast-enabled blog page doesn’t actually work. The workaround I’m using for that is to simply delete the button in the Theme files (which are honored by Wiki Server, at least if you’re careful to follow the rules carefully). For those users who want to subscribe to a podcast using iTunes, I send or post a link that does work, using an appropriate RSS feed from the Podcast Library (another nice addition to PP2).

One very serious bug I discovered has to do with overwriting files. I’ve always felt that one of the cardinal sins of programming is to create something that destroys data. But if you’re not careful, PP2/Wiki Server can do just that. It probably won’t happen very often, but given the volume on my server (between 500 and 1000 videos a month), it didn’t take long for me to find this bug. If a user submits a video with the same name as a video submitted earlier in the day, the older video is overwritten by the newer one. Actually, the older video still exists in the Podcast Library, just not in the podcast directory that is referenced in the code posted to the user blog. The workaround here is to manually edit the entry to point to the correct video in the Podcast Library. I’ve also taken some steps to try to enforce some naming conventions on PP2 users to help prevent this, although really, I shouldn’t have to do this. PP2/Wiki Server should be smart enough to not overwrite files, and I would hope Apple would squash this bug quickly, as it is genuinely serious.

Again, all things considered, I’m quite pleased with the advancements made with Podcast Producer 2. To be fair, most of the bugs I’ve found aren’t necessarily with PP2 per se, but rather reflect deficiencies in how PP2 works with Wiki server when writing podcasts to user blogs. My guess is that PP2 and Wiki Server (two very important components of SL Server) had largely separate developer teams working on them in Cupertino (or wherever the developers are located). Even so, one would hope the quality control teams at Apple would have tested this better before releasing it to the world. It would have been nice if “real world” users such as myself could have participated in the beta testing. As it is, I guess I am helping to beta test this product, since in some key areas, Podcast Producer 2 is still a work in progress.