SEARCH

We recently launched a cool adaptation of RPS-101 on Facebook.  It's built in Silverlight and it's loads of fun turning up some pretty funny results.  Of course when you get an app out into the wild it's nice to know what's going on with it.

Our custom tracking tool was integrated into the app with our new feature set.  The new features include graphs, user-agent details, and a custom gameplay stats module.  But we decided to go one-up on those features and build a custom Silverlight suite to track penetration and new installs.

There's some contention about Scott Guthrie's "one in four" so the first number we're after is penetration before they come to our app.  The second number is "what happens next" - when presented with the prompt to install Silverlight are users likely to take action and install it?

Tim Sneath detailed the Silverlight install experience guidelines in his blog.  It outlines the best-practices around the install experience.  It appears from the documentation that it's possible for a seamless installation experience inside of Internet Explorer but most browsers require a restart after the plug-in is installed.

Unfortunately it's a little outdated (Oct 2007) and fails to detect Silverlight correctly in non-IE browsers breaking the code around their seamless experience for everyone else.  The premise is simple, though, prompt the user for a download and then set a timeout to repeatedly check for plug-in availability.  When it comes online replace the <div> contents with the Silverlight object tag.

So we did some research around the install experience and used a simplified check to see if the browser has Silverlight 2.0 available:

function isSilverlightInstalled()
{
   var isSilverlightInstalled = false;

   try {
      try {
         var slControl = new ActiveXObject('AgControl.AgControl');
         isSilverlightInstalled = true;
      }
      catch (e) {
         if ( navigator.plugins["Silverlight Plug-In"] ) {
            isSilverlightInstalled = true;
         }
      }
   }
   catch (e) { }

   return isSilverlightInstalled;
};

This simple function (from the JavaScript files in the experience guidelines) worked for us.  Whenever the client hits the Silverlight page the JavaScript simply posts back the availability of the Silverlight client.  Because our Dormouse platform seamlessly handles stateful users we're able to keep track of install statistics and adoption across sessions.

$(document).ready(function () {
   if ( !isSilverlightInstalled() ) {
      postBackSilverlight(0);
   } else {
      postBackSilverlight(1);
   }
});

function postBackSilverlight(installed_val) {
   var restURL = getRootIFrame() + "/postBackSilverlight";

   $.get(
           restURL,
         {
            installed: installed_val,
            nt: theTime.getTime()
         },
         function(data){}
      );
}

The stateful user on the Dormouse platform keeps track of Silverlight installation status.  If it's the first time Silverlight status has even been posted back then we post a message to our Zabra REST service indicating pre-install conditions and save the information on the User objects.  When these are summed up we get "Pre-App Silverlight Penetration" statistics.

If a user has doesn't have Silverlight they'll take one of two actions - install Silverlight and come back or bounce from the app and not return.  Whenever a user comes back to the app with the plug-in newly installed we post a new message to Zabra "SilverlightInstalledAfterApp" which tells us that someone installed Silverlight and came back.  The difference between the total Users who are "Not Installed" and "Installed After App" users will leave us with our bounce number.

This works great on our Zabra system and seamlessly integrates into our Dormouse platform. Want to implement it yourself?  All you need is a way to track user data across a few sessions.  You might store their Silverlight status in a cookie, SharedObject, PHP session, or CMS system.  Here's some pseudocode to keep track of Silverlight installs:

postBackSilverlight(user, silverlightinstalled) {
   if(user.silverlightinstalled has been set) {
      if(user.silverlightinstalled equals false) {
         if(silverlightinstalled equals true) {
            statistics.post("new silverlight install");
         }
      }
   } else {
      if(silverlightinstalled) {
         statistics.post("silverlight installed before app");
      } else {
         statistics.post("silverlight not installed before app");
      }
   }
}

We've passed these into some nice charts that let our clients keep tabs on user adoption both before their app and after hitting the installation user experience.  Hopefully Silverlight will hit a critical mass where adoption is no longer a concern.  For now we're all keeping our eyes on the future of a really promising technology.

In our efforts to find a more comfortable collaboration and streamlined flow from Design to Development while working on Silverlight projects, we started brainstorming ideas to keep our chops up to date. We decided we wanted to create a Silverlight 2.0 game that could be deployed on Facebook, as that would allow us to explore new territory (being there aren’t a ton of Silverlight Facebook apps available) as well as contribute to the cause of evangelizing its adoption.

Of course internal projects are great vehicles for advancement, but we also wanted to get this out fast! So, we decided to leverage concept and art from existing resources in order to put it in 5^th gear. Being avid readers of The Stranger | SLOG we had previously been amused and impressed with an article on a 101-hand gesture game based on Rock Paper Scissors. But, imagining the complexity involved in remembering all those hand gestures and what beats what or the awkward inaction of trying to play it on the computer together with someone, made it a picture perfect candidate for a Facebook game! The asynchronicity allows for breathing room in computer game play and makes receiving the results that more fun!

We worked together with the creator of the game to bring his concept to life using our design and development talents and released RoshamBOOM! within just a few weeks — the speed of which could not have been possible without the versatility of our Social Networking Platform, Dormouse. I would say this was the most fun I’ve had developing a game, and undoubtedly one darn fun game to play! Check it out: http://apps.facebook.com/roshamboom

Currently, only the Challenge and Outcome pages are in Silverlight, but we plan to integrate all pages in subsequent releases. Last but not least, we can’t forget props to the originator, David C. Lovelace.

 

We had the pleasure of working on some significant Silverlight projects over the last year, one of which included building a plug-in to Microsoft Expression Encoder.

 

The project in a nutshell was creating a Silverlight 2.0 video/audio player that synced with PowerPoint slides and visual chapter points.  Imagine a live presentation in which a speaker is showing PowerPoint slides and the cue cards they hold in hand are the chapter points to be discussed.  Now imagine an online version of this presentation in which the speaker was pre-recorded and their cue cards exposed alongside the PowerPoint slides they are referencing – this is what we built.

A list of chapter points as well as thumbnails of PowerPoint slides and other supporting media are available for the viewer to navigate forward and backward in the presentation, in addition to the normal player controls on the video/audio itself.  Any of the three navigation areas selected will sync the others to the correct point in the presentation.  Pretty cool!

 

Another cool part of this project was making it so the presentation could be assembled and output from Expression Encoder.  We built a plug-in that enabled the user to associate chapter point text and other visual media with markers in the video/audio and then export it to the Silverlight Presentation template we created, which could either be hosted online or run locally via an EXE.

 

It was a fun and invaluable experience, but still a rough ride.  The project spanned 3 iterations of Silverlight releases (Alpha 1.1, Beta 1, and Beta 2), which continually required updates to the code and the use of preview versions of both Expression Blend and Encoder.  And unfortunately there was not much in the way of support in the skinning department for Expression Blend just yet.

 

Luckily with the release of Silverlight 2, came many improvements to Expression Blend, adding support for the new Visual State Manager which allows designers to create interactive mouse states (without needing to know any code!), by way of editing the default templates for existing controls.  This, paired with the ability to access static resources through the VSM, paved way for our next project in creating skins for the Silverlight 2 .NET control set.  For this project we were tasked with building specific UI themes for the Silverlight toolkit, which released on CodePlex in December (see Whistler Blue, Bureau Blue & Black). 

 

Having a more stable version of Blend to work with - thanks to SP1, helped immensely but there was still the hurdle of getting designers used to the VSM interface and template structures.  Other internal struggles consisted of:

 

·         Maximizing the use of shared static resources without compromising the design or simplifying it to the point of banality.

·         Walking the line of VSM animations versus layered assets and how to structure the control templates using the least amount of XAML.

·         Cleanup of code added by Blend (collapsing lines where possible and removing unnecessary default properties).

·         Managing workflow from design to development for cleanup and consolidation into ISM framework, while maintaining continual design updates.

 

This was the biggest learning experience of all, because it involved a steady flow from design to development, and there didn’t seem to be an efficient way to handle recurring updates without continually redoing dev work.  The most plausible solution would have been for everyone to work from one XAML file containing all controls, merging updates in source control, but having all controls laid out in one file caused a HUGE update lag within Expression Blend’s interface.  Even editing XAML directly was experiencing lag, making it impossible to work that way.  Instead we had to separate each control to a different project and continually clean and consolidate them with each update for delivery.

 

Maybe in the near future this problem will have surfaced enough to find a fix, we can only hope!  There is definitely one thing we’re looking forward to in 2009 with the release of Silverlight 3 – 3D support and GPU hardware acceleration! Let the games begin! 

 

Shortly after Silverlight 1.1 released we were approached to design and develop an interactive application that would pull in and display RSS content in addition to creating an animated web banner.

However, due to the request for Silverlight 1.0, it turned out we needed to create two applications in a very short time. To meet this demand we began with a local pre-formatted XML reader in Javascript, and then shortly after, delivered the RSS functionality of the product. Due to reduced capabilities in Silverlight 1.0 versus 1.1 (which includes .NET support), we created an external script in C# to parse and streamline data from several RSS feeds—stripping out undesirable data and excess formatting before consumption by the Javascript frontend. The result: an interactive RSS blog aggregator that offered automatic progression through feeds, as well as a way to browse them manually, all inside a Silverlight frame.

Being our first Silverlight project, the rewards didn’t come without obstacle. Adventures in setup and installation were some of the biggest hurdles. There were updates to the Silverlight 1.1 runtime which changed the GUID (globally unique identifier) for one of the DLLs (dynamically linked libraries) without keeping the registry key, causing build errors when trying to publish. Correcting the issue was a confounding problem, but luckily a temporary fix was had and in the end all was well. Getting the correct ASP.NET extensions registered and folder permissions in IIS was also fun!

The next challenge was internal as our designers learned how to work with XAML and Expression Blend. Their frustration in not being able to easily create mouse events without code (the Silverlight template doesn’t create the code for simple buttons automatically) collided with development’s frustration in trying to maintain structure in the XAML file. The solution was process. Strict adherence to naming schemes, particularly in how the designers named their layers in the design (which were reflected as the xName), allowed smooth cooperation between the designers and the developers who needed to code events.

Finally, an observation: We found that while Silverlight supports gorgeous animations it can also demand an unexpected high amount of CPU usage. We optimized our animations through compression to JPG where possible, but if you need to maintain transparency in images, you must use PNGs because GIFs aren’t supported!

We'll share more solutions to Silverlight challenges in the future!