| Comments

If you are like any other developer, including me, you probably disregard most warnings and are usually the same type that keeps clicking next when installing things without paying attention to detail.  That’s okay I do it too.

In the release of Silverlight 3 Beta, we noted that this is a developer release and that no “Go Live” licensing was going to be available for this release.  What this means is that we don’t recommend putting things in production as we’ve not exposed or wired up the end-user runtime for Silverlight 3.  The only way people can view Silverlight 3 content during this Beta phase is by having one of the versions of the developer runtime for either Windows or Mac installed.  We’ve not integrated the end-user upgrade/install into the template for now.  So what does this mean to you when you put a sample out for people to see in your organization or perhaps if you have a preview of a product or something and users visit this application.  Here’s a few scenarios for you – keeping in mind the information below is related to the application being build in Silverlight 3: No Silverlight installed, Silverlight 3 installed, Silverlight 1/2 installed and a note about the plugin MIME type.

Scenario: No Silverlight Installed

If the user has no previous version of Silverlight installed at all, they’ll be presented with whatever your default “not installed” experience is.  If you’ve don nothing to customize this, shame on you :-).  The default Visual Studio templates will simply provide you with a static image.  That link in the templates links to a “coming soon” page which describes the situation.  You can view that page here: Silverlight 3 coming soon page.  If the user installs one of the developer runtimes then they’d be able to review your application.

NOTE: People with Silverlight 3 Developer runtimes cannot “upgrade” to an end-user runtime.  This means that if an end-user (non-developer) installs the developer runtime, then when Silvelright 3 releases they will have to manually uninstall the developer runtime to get the update of the released runtime.  If you’re a developer, you probably don’t care and future developer runtimes can install on top of other developer runtimes.  This is one of the driving reasons for no Go Live support at this time.

You should inform your viewers of your beta sample of the scenario and what they may have to do in the future.

Scenario: Silverlight 3 developer runtime installed

If the user has the correct version of the Silverlight 3 runtime as defined by your application, then they will be able to view your application.  You define the minimum version of the runtime required when you instantiate the plugin using the minRuntimeVersion parameter.  This might look like:

   1: <object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
   2:     <param name="minRuntimeVersion" value="3.0.40307.0" />
   3:     ...
   4: </object>

If the user has the minimum you specified, all should be well.

Scenario: Silverlight installed (any released version)

Ah, this is the tricky one.  If the user has any released version of Silverlight (1.0 or 2), the experience they see at your beta sample will be driven off of two properties as you instantiate the plugin: minRuntimeVersion and autoUpgrade.  Let’s look at what will happen and assume that the user has Silverlight 2 installed.

minRuntimeVersion=”3.0.40307.0” and autoUpgrade=”true” – if you do nothing else, the user will see this:

Silverlight default auto upgrade

This is bad on a few levels.  First because it isn’t a customized experience, it is the default.  Second because the “install” link will take them to the latest released runtime – which they already have most likely.  What happens?  The user feels like they are in and endless loop of Visit Site –> prompted to upgrade –> seemingly install –> visit site –> prompted to upgrade –> repeat.  This will frustrate your beta visitor and confuse you :-). 

You should always customize the user experience for the end user.  For beta, here’s what I recommend doing to ensure they aren’t confused with the goals being the following:

  • Detect if the user needs to upgrade to see your beta sample
  • Inform them of the situation and that your sample is beta
  • Direct them to the coming soon information page for Silverlight 3

Here’s what you need to do.  Ensure that your application (object tag) is within some type of HTML container, like a div and give that an appropriate ID.  In your plugin instantiation you’ll want to add 3 parameters like this:

   1: <div id="silverlightControlHost">
   2:     <object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
   3:         <param name="minRuntimeVersion" value="3.0.40307.0" />
   4:         <param name="autoUpgrade" value="false" />
   5:         <param name="onerror" value="pluginError" />
   6:         ... other param values as required ...
   7:     </object>
   8: </div>

The minRuntimeVersion specifies the version required for your application, which for Silverlight 3 beta is 3.0.40307.0.  The second is to turn autoUpgrade to false.  This prevents the default experience.  The third is to add an error handler as since autoUpgrade is now false it will throw an error saying that the required version isn’t installed.  In your error function you would want to do something like this:

   1: function pluginError(sender, args) {
   2:     if (args.ErrorCode == 8001) {
   3:         var msg = "This sample application was built with Silverlight 3 Beta.\n";
   4:         msg += "You currently have Silverlight installed, but not the version required to view this sample.\n\n";
   5:         msg += "For more information about Silverlight 3, please visit: \n";
   6:         msg += "<a href=\"http://go.microsoft.com/fwlink/?LinkID=141205\">Silverlight 3 Coming Soon</a>.";
   7:  
   8:         var hostContainer = document.getElementById("silverlightControlHost");
   9:         hostContainer.innerHTML = msg;
  10:     }
  11:     else {
  12:         // handle other plugin errors here
  13:     }
  14: }

The error code of 8001 means that an upgrade is required.  Since we know we have a beta app and we know that the user has some version of Silverlight installed, but not the beta version.  Replace the container inner content with some HTML explaining that your application is a sample application and direct them to the coming soon page for more information.  This way your users aren’t sent in an endless loop, get confused, and hate you.

Why isn’t the <object> type attribute “application/x-silverlight-3”?

A common misconception is that the data and type attributes on the plugin object directly correlate to the runtime version of the plugin you are using.  This is not true.  Just because you have a Silverlight 3 application does not mean you need to change it to type=”application/x-silverlight-3” and in fact you’ll have problems if you do!  These attributes refer to the plugin MIME type and not the runtime version.  You would still use application/x-silverlight-2 for a Silverlight application (in fact you could use x-silverlight if you wanted to handle edge cases of Silverlight 1.0).

Summary

Beta software is fun and confusing.  It’s fun for us developers because we’re technically astute, understand what beta means, and are probably accustomed to working with others’ beta software all the time.  For end users, it can be confusing because they see things/links/articles and want to check it out, but may not have the required software.  As developers we can do things to help our beta visitors understand the scenario much clearer and do our job to inform.

So if you are showing Silverlight 3 beta samples, please take an extra moment to follow this guidance and trap the upgrade error code and handle it with information to inform the user.

Hope this helps!

| Comments

One of the great things I like about some of our platform products is that they are building in extensibility more and more.  Take Windows Live Writer as an example.  It’s no secret on this blog that I’ve got a geek affair with that tool.  I use it daily and have customized it (via plugins) and my blogging platform (Subtext) to make it even more of a best experience for me for web authoring.

Writing plugins for Writer has been a lot of fun and a great way to get the functionality I want/need into a workflow without having a different utility to work in.  Another one of these tools has been Expression Encoder 2 which I’ve been using a bit more lately.  Expression Encoder is a tool that enables the encoding of audio/video assets into VC-1 formats and H.264/AAC formats.  It’s a really simple tool to use and also comes with several Silverlight player templates that you can choose as a part of your output.  In one click you can have your HD home movie encoded and a rich playback experience developed for you as well.  I’ve wrote several times about Encoder, templates, etc. before and you can see some of them here:

With no shortage of information on how to do it, I got home last night and began cranking one out.  I’ve been using Amazon’s S3 web services for a while and have really grown to like it a lot.  One of the Live Writer extensions I spoke of earlier is a plugin for S3 for Live Writer that Aaron Lerch helped out with as well!  I though I should extend Encoder so that I’d have a one click publishing point to my S3 account instead of having to use S3Fox all the time (which is an awesome tool btw).

So after getting home from a user group I started cranking one out, figuring out the nuances and just coding something together.  A few hours later I came up with what I’m calling 1.0 beta of my plugin.

It’s not a fancy UI, but it doesn’t need to be, it serves a purpose: enable publishing of Encoder output directly to an Amazon S3 bucket in one click.  That’s it.  Encoding just media?  No problem.  Adding a template?  Not a problem either.  You simply need to enter your Amazon S3 account information and enter a bucket.  If the bucket isn’t there, it will attempt to create it.  You can also list your current buckets if you forgot them.

There are likely indeed a few problems and some fit-n-finish needed.  I am positive the error handling needs to be refined as well as it could probably benefit from some more efficient threading handling.  The cool think about the Encoder publishing plugins is that they are WPF user controls, so it gave me a chance to work with more XAML.

At any rate, even in the current form (which isn’t perfect but seems to be working for the specific need I built it for -- “works on my machine” warranty applies here) I wanted to share it out for any others to use and hopefully give feedback and contribute.  It’s available as a Ms-PL licensed project with source code and you can get it on CodePlex: Amazon S3 Encoder Publishing Plugin.  I hope you like it and can give feedback.  Please if you find issues log them in the Issue Tracker for the project so they are trackable.

| Comments

Well today (17 JUN 2008) will be the release of Firefox 3, a seemingly much anticipated browser update.  I checked out an earlier build (I think beta 2) and it was a nice browser.  I’m not a browser zealot, I use what works for me and IE works for me, has some tools that I like, etc.  Firefox is a fine browser as well and I do use some plugins from time to time in my Firefox install.

Today, I assume a lot of people will be downloading FF3 whether by explicit choice or by a prompt from their FF2 browser installs.  In fact, it appears that FF is going for a world record of software downloads.  Um, cool?  At any rate, the downloads will start soon (FF3 is already on public FTP servers now).

UPDATE (02 JUL 2008): See updated information here on specific silverlight.js update instructions.

So what does this mean for Silverlight?  Well, there has been an issue with Silverlight and FF3 getting along since the first public builds of FF3 started trickling out.  There has been a couple of issues, but two main nagging ones.  I’m not going to go into detail here, but there is certainly an interesting read in the bugzilla comments and a commentary here from Jon.  My personal opinion is that there was some disagreement in the Mozilla core team about if indeed it was a bug or not…the comments are an interesting read and I think the MSFT team made valid arguments (the other issue is here).  The nutshell version is that there was an apparent change in how NPAPI model was implemented in FF3.  Despite the back and forth in the bug report, Microsoft has made some servicing updates as well as SDK updates that make FF3 and Silverlight play nice together.  There still seems to be some broader concern over the FF3 implementation (as there were a number of plugins that stopped working as well), but at least a level of work around has been established for Silverlight.

The main concern really has to do with some install experience and initiation of the Silverlight plugin.  The latest SDK includes an updated Silverlight.js file with the necessary fixes in script detection that works with FF3.  You can get the SDK as a part of the Silverlight 2 SDK downloads.  This doesn’t mean that you have to immediately upgrade Silverlight 1.0 applications to v2, but just that the update is in the Silverlight 2 SDK.

Another item that was fixed (added) was removing the step to restart the browser in these instances as well – these are the same techniques as demonstrated in one of my latest videos on optimizing the install experience.

So if you are a Silverlight site author and anticipating a lot of FF3 usage on your site, you should indeed get the latest SDK for Silverlight and update the detection script and do some testing.

| Comments

If you are doing Silverlight development, you are no doubt slapping in the <object> tag or using the <asp:silverlight> control (if in ASP.NET) to host your Silverlight content/application.  This is all great, but don't forget about deployment!

When I talk about Silverlight I like to relay a story I heard from one of the Silverlight program managers (PM) a while back.  The PM was pretty excited about a feature just completed in Silverlight and one of the samples that had been created.  He went home to show his wife and told her to 'go to 'dub-dub-dub-dot-something-dot-com' (yelling from the other room of course) and to tell him what she thought.  After a long pause of a few minutes he shouted back 'what do you think?'  Her response: 'It's lame.'  He was no doubt offended until he walked up to her machine and on the screen saw this:

Silverlight Install Image

The Problem

You see, 'Get Silverlight' means nothing to your mother-in-law (or wife in this matter).  Technology means nothing to non-geek users.  Content is king.  And to your non-savvy users (and even your savvy ones), leaving this default experience isn't a wise one.  It doesn't convey that there is anything of value by installing something they might not have.  It doesn't even convey what the action is going to be when they 'Get Microsoft Silverlight.'  Leaving this experience unchecked leaves your users in the dark as well as a reputation rank downward in my opinion.

NOTE: This site is likely riddled with these badges as seen above.  I'm claiming exempt status because they are samples :-).

While in Silverlight 1.0 creating a great install experience was possible, Silverlight 2 makes that process so much easier.  In Silverlight 1.0, the use of the silverlight.js file could aid in detection and direction to an alternate experience.  This method is still possible in Silverlight 2, and in fact might be a best practice still.  Most interactive developers using Flash use some method of script creation in instantiating the Flash host.  This is mostly due to the IE EOLAS "click to activate" issue that has been resolved and will remedy in an upcoming IE update.

Some Solutions

So that brings a few methods for instantiating the Silverlight control host.  You can still use a script method to do the check for you and provide alternate content or redirect to something.  You can also still simply include the <object> tag itself.  My favorite is using the simple <object> tag and tricking the HTML.  You see an object tag might look like this:

<object type="application/x-silverlight-2-b1">
    <param name="source" value="ClientBin/CallingServices.xap"/>
    <param name="onerror" value="onSilverlightError" />
    <param name="background" value="white" />
    <div id="no-sl" class="install-badge">Some descriptive information</div>
</object>

Notice the random HTML after all the params?  Browsers will read the HTML like a book (US-English) from top to bottom.  They get to the object tag and can't understand it, so will look at the next part of the DOM.  Param tags...nope don't get it.  Next part.  Oh, a <div> element...yep I understand...begin render.

Within here you can put an image or some element with a CSS class that is absolutely positioned, etc.  Bottom line is you own that experience.  It is now on you, the developer, to ensure that your users aren't just seeing 'Get Silverlight' but are being provided at least some explanation of what they are about to see, why they should install this plugin, etc.

Some Examples

Perhaps you need some inspiration?  Here's some examples from some recent sites...


Silverlight.net Gallery


Zombomatic Game on Miniclip.com


WWE Insider Video


Hard Rock Memorabilia Site


65th Annual Golden Globes


Major League Baseball Video

As you can see, the options are endless from very simple, to heavily branded. 

Testing your deployment experience

So now that you've decided you are going to optimized that "no Silverlight" experience, how do you go about testing it?  Well, here's a simple trick that I employ to do this.  There is no need to uninstall/re-install the runtime on your machine.  In fact, this will likely give you headaches in doing so and waste endless minutes :-).  Here's a simpler way.

In Internet Explorer you have the ability to manage your add-on experience.  To test your "no Silverlight" experience, simply do the following.

To make it easier go to a page with Silverlight content.  You can do this without this step, but it will cost you 2 extra clicks and I'm trying to save you time.

Next, go to Tools...Manage Add-ons...Enable or Disable Add-ons:

Now, find Microsoft Silverlight in the Enabled section and change the radio button to 'Disable' and click OK. 

You will be prompted with a message which you can just click OK through.  The page will be refreshed and the Silverlight plug-in no longer enabled.  Now any site you visit will give you the "no Silverlight" experience for you to test your deployment experience.  When you want to re-enable, simply repeat the process and choose 'Enable' and you are back in business.  No messy control panel uninstall/re-install mess.

I'm not a Firefox power user and couldn't find an easy way to do this rapidly without installing another plugin, so if anyone knows the similar method in Firefox, please enlighten me (or Safari for that matter).  I tried searching and found solutions of moving the plugin out of the /plugins folder in Firefox so I'd imagine you could batch script this out.  I really like the ease that Internet Explorer provides in managing my own preferences for each add-in running.  Looks like this gets even better in IE8.  I'm actually surprised it isn't a part of Firefox.

Summary

The bottom line is: don't ignore this experience.  This is your chance to explain that the user is about to see premium content, a better user experience, a fun game, whatever it is you are trying to convey.  I hope this has helped at least some be enlightened on ensuring you make that a work item in your task list and the tip of disabling the add-in is helpful to some. 

| Comments

Phoenix Silverlight User Group logoi was able to make it to the phoenix silverlight user group last night (2 separate trips downtown, yikes) and had a good time chatting with everyone there.  i understand that there will NOT be a separate march meeting because it essentially falls very close to when scott guthrie and others will be coming to town.  the group is recommending that people attend that to learn the latest and greatest about silverlight 2 right out of MIX!  we had a good discussion about various things.  mike palermo showed a couple of things he'd been working on including a simple game and a magnifier for photos (similar to the one michael has for video).  the concept was that you have a high resolution image on the page and then he had a magnification bubble that would react to the mouse wheel event on a mouse to zoom in/out of a selected area.  it looked in concept a lot of what like the Live Labs 'Seadragon' project describes as far as smooth zooming, etc.

one of the things mike did in this image magnifier is use a high-res image and basically clip it to the area being zoomed on for the mouse using transforms, etc.  i asked mike if he was using another image element or using an imagebrush.  i noted that i felt he should use an image brush rather than to use an existing image so that the image wasn't requested twice.  this is the efficient way of doing it when working with MediaElements and VideoBrushes so that the video in the brush is in sync as well as efficiently processed.  we worked up some pseudo code on the board real quick to describe what i was talking about.

well, i was slightly wrong.  the imagebrush element doesn't use 'sourcename' like a videobrush.  in videobrush you use the x:Name value of your mediaelement.  in the imagebrush you specify the actual image location (ImageSource).  i guess this somewhat surprised me so i started sniffing (thinking i made a mistake in my 'efficiency' statement.  when looking at the result of something like this:

<Image Width="240" Height="121" Source="silverlightUGwithText_6.jpg" 
         Stretch="Fill" x:Name="PhxUgLogo" 
         Canvas.Top="102" Canvas.Left="132"/>
  <Ellipse Width="107" Height="107"
           Stroke="#FFEC1818" Canvas.Left="224" Canvas.Top="250"
           StrokeThickness="5">
    <Ellipse.Fill>
      <ImageBrush ImageSource="silverlightUGwithText_6.jpg" 
                  Stretch="None">
        <ImageBrush.RelativeTransform>
          <TransformGroup>
            <ScaleTransform ScaleX="1.4" ScaleY="1.4"/>
          </TransformGroup>
        </ImageBrush.RelativeTransform>
      </ImageBrush>
    </Ellipse.Fill>
  </Ellipse>

there are actually 2 HTTP requests to the image source.  you can see them being requested.  what i've learned is that silverlight maintains an internal image cache anyway so the second request (although there and happening), would see the cached image instead.  so it looks like the method of using two Image elements would have the same effect...so given that i'm not sure either is 'better' than the other for doing this type of sample...what do you think?  regardless it was a cool demo.  thanks mike.

we talked a lot about why people are waiting for silverlight 2 and if that made sense.  we also had a good discussion of 'what if i just have casual media on my home page, why silverlight instead of flash' which is a question i hear a lot.  this discussion never revolves around technical issues (noted i said 'casual media' instead of high fidelity streaming, etc.) but rather around penetration of the plugin.  a lot of sites don't want to bear the load of plugin download/installation.  it's an interesting challenge when any new technology comes out and no different a discussion than when the .net framework first came out -- which 'app' was going to bear the installation tax in their app?  good discussion.