Better Silverlight Installer UX

Anybody keeping an eye on the prominent Silverlight blogs knows that Microsoft just published guidelines for good installation experience.  I took this as an invitation to update our Infragistics Silverlight prototype demo on Infragistics Labs.  Oddly enough, about the same time, it was brought to our attention that our demo was not working in Firefox, but it turns out that updating the demo to follow the new installer guidelines also occasioned fixing the FF problem.  What a happy coincidence!

Since probably most of those who read this have by now installed the latest Alpha refresh, here's what our demo looks like now (if you don't have SL 1.1 installed):

Yes, this preview image design is my own, so please don't blame VDG for it. :)  The key elements are:

1. Give them a preview.
2. Urge them to install to see it in action.
3. Provide any guidance around what needs to be done to complete installation.

I chose to snag a preview of Infragistics' Silverlight chart because I think it is the cat's pajamas (of course our Silverlight gauge is pretty nifty, too, if I do say so myself).  Then I used what little Fireworks mojo I have to fix it up as a proper background preview image and added it to my project.

Now to incorporate the new installer goodness, I added Microsoft's InstallCreateSilverlight.js file to my project as well, but to use it, I had to change our main Default.aspx page fairly significantly.  You see, with the last update I made to the demo, I updated to use the ASP.NET Futures Xaml control to emit the needed magic to display the Silverlight control.  What I found when I did that was that it didn't use the familiar JavaScript method for creating the Silverlight control but instead just emitted the HTML object tag with the parameters inline¹.  It seems also that this was causing the demo not to work in Firefox, so by updating to use JavaScript, I got to kill both of them birds with one stone.

To do this, I re-added the latest Silverlight.js file to the project, and then added a Default.aspx.js file to stick my JavaScript for that page into (trying to follow the relatively new approach for JavaScript-behind™ files²).  I modified the sample JS code given by Microsoft a bit in terms of the post-install guidance. 

First, because this is the 1.1 alpha version, Microsoft unfortunately does not allow in-place installation like they do for 1.0 RTM.  So I wanted to add an always-displayed message about the fact the user will have to leave our site to go to MS for the installation and return later.  I changed the styles to make the message more prominent, which you can see in the __setupSL() method in the Default.aspx.js file.  The other change was to use script constants for the messages rather than repeat them inline just for ease of maintenance; this was done within my __getPostInstallGuidance() method.

I'm also using ASP.NET AJAX Extensions, because the demo uses an early version of our Aikido WebDialogWindow control, so I used the MS AJAX auto-wired pageLoad(sender, args) event handler to do my page load script and also used the $get alias method to get elements rather than document.getElementById.  Other than that, I pretty much follow the Microsoft sample and guidance for the installer guidance update.

One other change I made with this latest update is to quit using a named window for our in-Silverlight "links"³.  Previously, I was using the Silverlight HtmlPage.Navigate(uri, windowName) overload, but I found that this must be using the JavaScript window.Open(url, windowName) method because the popup blockers would block it.  This is one of those unfortunate things about an alpha where you don't have native link controls that act like regular links (but who knows if they'll be able to do that in the final version anyway).  To work around this, I removed the window name, so it no longer tries to open a new window.

The end result is that we have a better non-installed experience.  Before this update, it'd just show the little Get MS Silverlight badge with nothing else, and as you can see in the image above, there's a big improvement.  We also no longer get the "click here to activate this control" message since we switched back from the Xaml Futures control to regular JS, it now works in Firefox, and the popup blocker is no longer being triggered now that we're using HtmlPage.Navigate(uri) without the window name.  It's all good.

Notes
1. I noted this in my chapter on ASP.NET & Silverlight (Ch5) for our Silverlight book and provided an alternate implementation with a custom Xaml control that uses the JS approach, but when I did the last update, I had not completed that.
2. I'm kidding about the TM.  It just sounded like one of those wacky terms that should be TM'd. 
3. I say "links" in quotes because as you probably know, there is no Link control in the box right now.  They're really just TextBlocks that handle the MouseLeftButtonUp event to masquerade as links.  In my implementation, I use the System.Windows.Browser.HtmlPage.Navigate method to navigate to the desired URL.