Farewell, Podcast Producer?

Yesterday, Apple released Mountain Lion, the latest version of Mac OS (or what they are now simply calling OS X). And while I wasn’t surprised, I am disappointed that Podcast Capture, Podcast Publisher and Podcast Producer have become legacy software.

To be sure, there were signs that this day would come. When Lion was released last year, Apple added the Podcast Publisher app to interact with the new Podcast Library service on Lion server. Upgrading to Lion client did not remove the Podcast Capture application from the Utilities folder, so you could still use it to upload to Podcast Producer servers. And even though it was not turned on by default, you could still run Podcast Producer on Lion server, albeit with a few headaches.

Now it seems Apple just wants to bring the Podcast Producer era to an end. Introduced with Leopard server, the first Podcast Producer was not fully baked. Still, many OS X server admins, including myself, successfully overcome many of Podcast Producer’s initial limitations. When Podcast Producer 2 came out with Snow Leopard server, it seemed like Apple was finally taking the podcasting service effort seriously. While it wasn’t perfect, Podcast Producer 2 was arguably Apple’s best effort to date at offering in OS X Server a useable solution for creating, hosting and managing podcasts.

Unfortunately, it appears that Podcast Producer 2 was the last genuine effort by Apple to offer a podcast service with their server product. While Lion server included the simplified Podcast Library service, it was clearly not a replacement for Podcast Producer 2. Nor was the Podcast Publisher app in Lion client much of an improvement over the Podcast Capture app. Indeed, Podcast Publisher seemed little more than a weak, dumbed-down, iWeb-like app for podcasts. The app offered some nice “eye candy” for podcast creators, but one didn’t have to dig very deep to see that its functionality was at least a full step backward from Podcast Capture. Even Apple seemed to tacitly admit that Podcast wasn’t all that strong by keeping Podcast Capture as an option in Lion client, and Podcast Producer 2 an option in Lion server.

But with Mountain Lion, Apple appears to just want the whole podcast era to die. When I upgraded a Lion client to Mountain Lion yesterday, both the Podcast Capture and Podcast Publisher applications went away. The installer wasn’t even polite about it. No notice to the effect that these apps would be removed from the computer. No moving of the apps to the trash. No moving the apps to some kind of “deprecated software” folder. Both Podcast Capture and Podcast Publisher just vanished. Permanently deleted. It was a bit of a shock when I saw the dreaded question marks in the dock where Podcast Capture and Podcast Publisher used to be.

For those of us who came to depend on Podcast Producer 2, it seems that running Snow Leopard Server is the most practical option for now. But how long that remains practical as Apple moves forward is an open question. Although I hate to admit it, eventually we may all have to forget the Podcast Producer era. It seems Apple already has.

Getting Flowplayer working on Lion Server

I’ve recently been working on upgrading Snow Leopard server to Lion server. While the new interface to Lion server looks good, it really lacks a lot of the options available in the Server Admin application of Snow Leopard. Lion also lacks MySQL, but that was fairly easy to install and configure.

What wasn’t so easy to figure out was why Flowplayer wasn’t working when I moved to Lion server. On some pages, the embedded Flowplayer swf file wasn’t even showing up. On other pages, the background image would appear, as well as the play button image overlay, but a black screen would appear as soon as one would try to play back a video.

After trying many things over the past week, I finally discovered that the issue was that Flowplayer wouldn’t work with Lion server’s Apache 2 configuration of gzip compression. These lines in an .htaccess file did the trick…

Options +FollowSymLinks
RewriteEngine on
RewriteRule \.swf$ – [E=no-gzip:1]

Actually, I only needed to add the last line, as I already had an .htaccess file that had the first two lines. I suppose I could have added these configuration directives in one of the httpd.conf files, but putting them in an .htaccess file ensures they won’t be overwritten by a software update.

I’m still struggling with other issues with Lion server, but hopefully I will be able to resolve them soon. I’ll try to document them here, not only in the hope that it might help others with similar issues, but also to remind me of what I might need to do in the event I need to reinstall. They may also be helpful should I eventually move to Mountain Lion server this summer.

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.

iHave iPad…and iLove it

Yesterday morning, at around 11:15 a.m., the doorbell rang. It was a friendly UPS delivery man, handing me a package from Apple. Inside, was my new iPad.

I was in the middle of a Skype conversation with some friends from Germany, so I took the opportunity to give them an exclusive look at me unboxing my new pride and joy. They were quite impressed, especially with how thin and sleek it looked. I promised to give them a better look when I’m in Germany this summer to attend a friend’s wedding.

I’ve had just over a day now with the iPad. I’ve already downloaded a couple of dozen apps, including a bunch of free ones and a few that I purchased. One of the apps that I’ve downloaded is the WordPress application, which is what I’m using now to create this post. (I’m also using a bluetooth keyboard, which I find a bit easier to use than the onscreen keyboard for longer typing sessions.)

So far, I must say that I’m very happy with my purchase. The iPad is really a remarkable device. I had written earlier about how much I wanted one, and why. But now that I actually have one, I can honestly say it’s even better than I had imagined. Really. It’s that good.

What makes it so good? Let me mention my top three reasons why the iPad is my new favorite device. First, the iPad is super fast. Tap an icon, and BAM, you’re online. Tap another, and you’re looking at your email in one of the best email interfaces I’ve ever used. Tap another, and you’re reading a book, or watching a video, or listening to a tune, or playing a game. This thing is already making my laptop seem slow (and it’s a pretty fast laptop).

Second, the iPad is gorgeous. It’s aesthetically very pleasing. Elegant lines, with tastefully understated controls. Beautifully intuitive interface. Brilliant bright screen that’s easy on the eyes. It’s the kind of cool look you just want to show off to others. And yet for all its good looks, the iPad doesn’t get in the way of the content it displays, whether it’s a web page, a movie or an email. It just makes all of that content look great.

And third, the iPad is versatile. It does so many different things right out of the box. But when you start adding apps, and experiencing what developers have been able to do with the iPhone operating system on a bigger screen, you begin to realize this is so much more than a big iPod Touch. I like the iPod Touch, and I’ve owned a couple of them. But the iPad is so much more. And with more apps being added every day, this thing really does fill the niche between a laptop and an iPhone. And it does so very well.

Some people have compared the iPad to netbooks and Amazon’s Kindle, but really, there is NO comparison. I’ve used netbooks, and they are mostly underpowered mini-laptops. I’ve used the Kindle, and while it’s a fine ebook reader, it’s a one-trick pony. And with the iBooks app, that pony is looking like an old mare.

It won’t take long for the iPad imitators to appear. After all, imitation is the sincerest form of flattery, and there is plenty to flatter about the iPad. There already is something called a “JooJoo”, which is probably the closest to an imitation iPad out there right now. We’ll probably see Google push out the Chrome OS to a slate. I could see Motorola releasing a king-sized Droid. And of course, Microsoft will undoubtedly copy Apple; they always have. But by then, we’ll be talking about iPad 2.0.

Once again, Apple has a hit on its hands. Once again, Apple has led the way toward a new paradigm in computing. And once again, I’m very glad I bought an Apple product.

NERCOMP 2010 Recap

The last couple of days I’ve been in Providence, Rhode Island attending the 2010 NERCOMP Conference. NERCOMP stands for “Northeast Regional Computing Platform,” and it’s essentially the Northeast regional affiliate of Educause. And Educause is, to quote their website, “a nonprofit association whose mission is to advance higher education by promoting the intelligent use of information technology.” I’ve been a fan of Educause for many years, and recently, of NERCOMP. I attended the NERCOMP Conference in 2008 and found it quite valuable. I also blogged the 2008 Conference rather extensively here on DrThompsen.com.

This year I decided to not blog in real time, as I did a couple of years ago. Instead, I tweeted real time, and took session notes in MacJournal to review and distill later. Here are three of the best ideas I gleaned from the conference…

Course trailers. I love this idea, something they started doing recently for undergraduate general education courses at Harvard. Essentially, these are two minute “movie trailer” plugs, highlighting what a class is about and why students might want to enroll. I wish all of the classes in our department had trailers. Then I could just point students to the trailer when they ask “what’s this class about?” Sure, we can put a syllabus online, but a little web video could really sell a class, and give students a better feel for what they’re getting into.

Facebook pages for historical figures. Another great idea: have students create, maintain and role play as important historical figures in your discipline. The session I attended described how this was done in an abnormal psychology course at Emerson College. Students created Facebook pages for Sigmund Freud, Anna Freud, Carl Jung, B.F. Skinner, Aaron Beck, Victor Frankl and other important historical figures in psychology. Students said they much preferred this kind of writing to a more traditional paper assignment. This would be a great activity for classes that cover a lot of history.

Tech Innovations TV show. Stony Brook produces a series of short web videos featuring faculty doing innovative stuff with technology. Post the videos on a web page and promote it to other faculty, as well as students, administrators and the community. The videos could be interviews done in a studio, but they could also be just simple videos recorded in a faculty office or classroom using a Flip camera.

Speaking of Flip cameras, I presented a “poster session” on how we’re using these little gems, along with Podcast Producer 2 and Flowplayer in support of our public speaking courses at West Chester University. If you would like to know, here’s a link to the screencast of my presentation. I enjoy the direct interaction enabled by poster sessions, but I wished I had time to visit some of the other poster sessions. I hear there were some good ones.

NERCOMP 2010 was a great conference. I got some good ideas, and hopefully shared a few. The “swag” on the exhibit floor was above average, and the food was good and plentiful. I definitely hope to attend another NERCOMP conference in the future.

Flowplayer and Podcast Producer 2: The Code

I’ve received quite a few comments about my previous post “Adding Flowplayer to Podcast Producer 2.” I’m pleasantly surprised by this feedback regarding my workaround to what is, in my opinion, a significant deficiency in Snow Leopard Server. I’ve responded to a couple of these commenters by direct e-mail, but perhaps it would be more efficient if I just shared the relevant code and provided some step-by-step directions.

Let me begin by speaking to this “significant deficiency in Snow Leopard Server.” As I said in my previous post: while there “might be valid reasons for Apple sticking with the Quicktime plugin rather than using a more modern-looking javascript player…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.” I am still hopeful that Apple will come to the realization that they should share with their Server customers the javascript player code they use on their own site to present videos. It would be in their best interests to do so, especially given the recent comments by Steve Jobs that Adobe Flash is a “CPU Hog” and the source of 90% of Safari crashes. Committing Apple to standards-compliant HTML 5 is noble, and I agree that Flash deserves to be criticized. Flash does hog CPU cycles, and I’m a believer in the future of HTML 5.

But as a practical matter, Apple’s SL Server customers need to be able to deploy videos on the web NOW, and to be able to have those videos viewed by ordinary people using ordinary web browsers on ordinary computers…including the vast numbers of ordinary Windows computers out there. And the Quicktime plugin doesn’t cut it as a Flash player replacement. Isn’t that why Apple’s own web site uses javascript extensively to present videos without using Flash players? Apple doesn’t rely on the Quicktime plugin to present videos on its web site, so why do they sell a server product that uses the Quicktime plugin to present videos on the web? It isn’t for lack of javascript in SL Server: there’s oodles of it all over the pages produced by Wiki Server. And I suppose Apple could say you could roll your own javascript player to mimic what Apple does on their own web site, but why should we have to reinvent the wheel?

I suspect one reason why we don’t see the slick javascript used by Apple on its website integrated into Wiki Server is because Apple’s own web developers don’t talk much with the developers of Apple’s Server software. And that’s a shame. Steve Jobs, if you’re listening…could you get these two groups together for an afternoon of sharing? If you really want to wean the world off of Flash, why don’t you start by giving your server customers a real alternative to Flash—a full-featured javascript player—rather than relying on the Quicktime plugin in your server product?

Until Apple delivers a real alternative to a Flash player in their server product, here is my detailed description of the workaround I’ve developed. In essence, I have modified the javascript in Wiki Server so that videos are presented using Flowplayer (a very nice Flash player) rather than the Quicktime plugin. Here’s how I did it:

Step 1: Download Flowplayer from http://flowplayer.org/, and upload it to a directory on your web site. As I write this, a basic download of Flowplayer will include the files flowplayer-3.1.5.swf (the core flash player) and flowplayer.controls-3.1.5.swf (the core flash controller bar). It will also include (inside the example folder) the flowplayer-3.1.4.min.js file, which is some basic javascript you need to load into the pages where you want to use Flowplayer. (Technically, Flowplayer will work without this bit of javascript, but in most cases you will want to have this javascript loaded onto your pages so that you can use Flowplayer’s javascript API.) So in order to add this javascript reliably, I add a SCRIPT tag that references this file in a custom theme, which is the next step…

Step 2: Create a Wiki theme that includes a reference to the Flowplayer javascript. The easiest way to do this is to copy an existing theme and make changes to the copy. You’ll find these themes in /Library/Application Support/Apple/WikiServer/Themes/. I used the Snowleoplard theme as the basis for my custom theme. I opened a terminal window, changed to the theme directory, and used the ditto command as root to make an exact copy like this…


cd /Library/Application\ Support/Apple/WikiServer/Themes/
sudo ditto snowleopard.wikitheme/ customthemename.wikitheme/

Replace “customthemename” with a descriptive name of your choice (no spaces). In my case, I called my new theme “snowleopard-wcu.” If you have the “Wiki Server Administration” manual handy, you might want to refer to chapter 3 for more information about creating a custom theme. There you’ll see that an important step is to edit the theme.plist file so that your new custom theme can be selected in the wiki settings. At the very least, you’ll want to change the “display name” and “name” values to match your new theme. Here’s what my custom theme’s plist file looks like…


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>displayName</key>
<string>WCU Theme</string>
<key>name</key>
<string>com.apple.snowleopard-wcu</string>
<!--
<key>mobileHeaderColor</key>
<string>#3772bc</string>
-->
<key>commentSortDirection</key>
<string>DESC</string>
<key>version</key>
<string>2</string>
</dict>
</plist>

Now I need to add a line to the theme’s default.xsl file that inserts the Flowplayer javascript file. Below is the relevant portion of my default.xsl file (with the vertical ellipses indicating there is code above and below this snippet):

.
.
.
<xsl:template match="page">
<html lang="{context/locale}">
<head>
<script src="http://communication.wcupa.edu/flowplayer/flowplayer-3.1.4.min.js" language="JavaScript" type="text/javascript"></script>
<!-- meta tags -->
.
.
.

Of course, you’ll want the URL in the src attribute to point to where you’ve saved your flowplayer-3.1.4.min.js file (please don’t point to mine!). Now save the default.xsl file, and reboot the wiki server by issuing this command in a terminal window…

sudo serveradmin stop teams; sudo serveradmin start teams;

Alternatively, just issue the stop command, wait for confirmation, then issue the start command. Once the wiki (teams) service has restarted, go into a wiki that you want to change to the new theme. Login, click on settings, and click the “choose themes” button (on the Blog tab). If all went well, your new custom theme should be available in the list. Select it and click OK.

Now you have a theme that will include this all important little bit of Flowplayer javascript on every page. Wherever you want Flowplayer, use this theme. If it’s important that you have Flowplayer in all of your themes, I suppose you could make the changes I describe above to all of your themes. But keep in mind that Apple could overwrite the stock themes that come with SL Server in a software update. If you want to insure Flowplayer works even after a software update, I recommend that you use a custom theme.

Step 3: Edit the wiki.js and compressed_wiki.js files to use Flowplayer instead of the Quicktime plugin. These two files are essentially the same, although the compressed file isn’t formatted with a lot of spaces and indents. It’s a lot easier to edit the wiki.js file, and then just use your favorite text editor to do a search and replace to make the exact same changes in the compressed file.

First, make a backup of these files, just in case. Both of these files are located in usr->share->collaboration->javascript. Make a backup of the files using your favorite method (using ditto in the terminal or just copy using the finder). Put the backups in a safe place. I can’t stress this enough: save a backup of the original files in case you need to revert to them.

Next, open wiki.js in your favorite text editor (I use TextMate). We’re going to change the value of the variable objectHTML. Here is what this variable looks like before our edit…


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>';
// Firefox wants only an embed tag, and it has to be written using innerHTML. Also, have to hide image *first*
if (MozillaFixes.isGecko) {
Element.hide(img);
embed.innerHTML = '<embed src="/collaboration/fake.qti" qtsrc="'+fullSrc+'?sessionID='+encodeURIComponent(server().sessionID)+'" type="video/quicktime" autoplay="true", controller="true" target="myself" bgcolor="'+backgroundColor+'" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" pluginspage="http://www.apple.com/quicktime/download/" scale="aspect" />';
}

…and here is what this variable looks like after my edit…

var objectHTML = '<object width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" data="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" type="application/x-shockwave-flash"><param name="movie" value="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" /><param name="allowfullscreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="flashvars" value=\'config={"plugins":{"controls":{"height":"16","backgroundColor":"#330033","timeColor":"#eeee99", "progressColor":"#cccc99","bufferColor":"#774477","sliderColor":"#777777","timeBgColor":"#222222"}},
"key":"#####","clip":{"url":"'+fullSrc+'?sessionID='+server().sessionID+'"}, "canvas":{"backgroundColor":"#550055"}}\' /></object>';
// Firefox wants only an embed tag, and it has to be written using innerHTML. Also, have to hide image *first*

if (MozillaFixes.isGecko) {
Element.hide(img);
embed.innerHTML = '<embed src="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" allowFullScreen="true" bgcolor="#333333" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" align="middle" type="application/x-shockwave-flash" pluginspage=http://www.macromedia.com/go/getflashplayer" flashvars=\'config={"plugins":{"controls":{"height":"16","backgroundColor":"#330033","timeColor":"#eeee99", "progressColor":"#cccc99","bufferColor":"#774477","sliderColor":"#777777","timeBgColor":"#222222"}},
"key":"#####","clip":{"url":"'+fullSrc+'?sessionID='+server().sessionID+'"}, "canvas":{"backgroundColor":"#550055"}}\' />';
}

Note that you’ll want to change the src values to point to the URL of the location of the Flowplayer swf file that you’re using on your site. I’m using the commercial version on my site, although I’ve changed the key value in this post to just #####. I don’t think the Flowplayer folks would like me sharing my key value, and besides, I don’t think it would work outside of my domain anyway. If you’re not using the commercial version of Flowplayer, take out this key value. I’m not sure if all of the “flashvar” options I’ve set here will work in the same way with the noncommercial version, but I think most will, as I don’t think I’m doing anything too exotic. You might want to change the color values of the player to match the look of your site, and fiddle with the flashvars to taste.

Once you’ve changed the value of the objectHTML variable in wiki.js (and in compressed_wiki.js), I would suggest backing up these modified files, and saving them in a safe place. That way, if a software update ever overwrites these javascript files, you can easily copy back your modified files. Of course, I’m hoping that one of these days, a software update to SL Server will modify this variable so that it doesn’t use the Quicktime plugin, but until that day comes, you can use the method I’ve described here to use Flowplayer instead.

You may need to restart your server after making these changes. And you may need to study my code and the example code on Flowplayer.org to get Flowplayer looking just right on your site. But with patience and determination, you should be able to get Flowplayer running on your site without too much trouble.

I hope this helps those of you who commented on my previous posts, and anyone else in a similar situation who stumbles across this post. And if you discover any additional tweaks or insights into this process, please consider sharing in a comment.