Shortly before the World Wide Partner Conference in July 2009 - where Microsoft announced that Office 2010 had reached the technical preview engineering milestone -Intergen got a call. Microsoft wanted us to spruce up and extend the existing Office 2010 promotional Silverlight application. Microsoft’s call prompted the start of an intense two-week project (that’s right, we implemented the entire solution in 10 working days!) that showcased not only the power of Silverlight but what it takes to deliver a great result in an extremely aggressive timeframe.

Project Overview

The goal of the project was to provide a Silverlight application to deliver high quality, Silverlight smooth streaming (http://www.iis.net/expand/SmoothStreaming), videos that showcase some of the cool new features of Office 2010. New videos would be added over the months following the initial release. You can see the result in Figure 1.

Figure 1: Full page Silverlight application.

As you can see in Figure 2, users can comment on and rate videos and suggest topics they would like to know more about.

Figure 2: Comment and rating system via WCF.

We were also required to support mobile users, on platforms like Windows mobile and the iPhone, who wanted to access the videos without having Silverlight. Finally, we thought it’d be great to have an RSS feed to allow people to subscribe to the videos and integration with all the popular social media sites such as Facebook, Digg and Twitter. You can see the mobile optimized version in the iPhone simulator in Figure 3.

Figure 3: iPhone Emulator showing mobile optimized version.

What Went Right

A number of the things that worked well were related to the processes we followed and the way the team worked together and leveraged each other’s strengths.

  • Clear Delineation of Responsibilities On a project like this it’s important that every member of the team knows what they are responsible for. Of course, there is always some overlap and people help out where they can, but it’s also important to “own” features. Apart from the integration and deployment item where two people shared the work, each of the feature sets below was owned by a separate person.
  • Mobile Web Site - Mobile detection, simple HTML equivalent of Silverlight application.
  • Backend Services - Web services, business rules, validation, database.
  • Designs - Designs, usability, graphical elements.
  • Designs Implementation - XAML integration based on designs.
  • Smooth Streaming
  • Core Front-End Functionality - Comments/suggest topics.
  • Integration and Deployment

For larger, longer term projects, specialization isn’t always a good idea - people get bored, you encourage silos of information, you depend on individuals too much and don’t share knowledge. But for short sprint projects like this, it worked really well.

For larger, longer term projects, specialization isn’t always a good idea - people get bored, you encourage silos of information, you depend on individuals too much and don’t share knowledge.
  • Releasing Often and Early - From the first day we started to plan how we were going to release the software into production and User Acceptance Testing (UAT). We scheduled releases often and early and, regardless of whether we had achieved all the functionality we were aiming for, always released an update for the client to provide feedback. In the first week we had no production environment to deploy to and had to deploy to our own servers - as soon as we could deploy to the production environment, we did, so that we could ensure we eliminated many platform-specific issues. During the 10 or so days of development we had about five official releases for the client to review and about 20 internal releases for our own testing.
  • Core Functionality Comes First - This is especially important for applications built in Silverlight. Silverlight has so many cool UI features that it’s very tempting to get stuck in its goodness at the expense of actually implementing all of the mandatory functionality first. Our first few releases were entirely unbranded but by the third release we had implemented all the essential functionality - by this time, Dave (the designer) was ready with the UI designs and the guys could start to integrate these into the final product. At the end of the day, if we couldn’t play videos or record comments, it wouldn’t matter how amazing the site looked - we would have failed.
  • Daily Meetings - We sometimes even called these meetings “stand ups” but to be honest we rarely achieved the well-behaved, time constrained, three-question focus of the Scrum doctrine. However, the end result was the same - we discovered progress, identified road blocks and set the priorities for the next 24 hours. These meetings were critical to make sure we were all on the same page. At almost every meeting we made small corrections to the path we were travelling to reach the end goal.
“Stand ups” were critical to make sure we were all on the same page. At almost every meeting we made small corrections to the path we were travelling to reach the end goal.

The more technical aspects that we were pleased with included:

  • MVVM - Using this presentation pattern had several advantages. Naturally, this level of abstraction meant our Silverlight developers weren’t dependent on the back-end services to be able to implement the front-end functionality. It was a trivial task to mock out the View Models to provide realistic data. Additionally, we could take full advantage of the databinding features of Silverlight and bind our controls directly to the View Model, reducing the amount of code we needed to write in the Views themselves.
  • Smooth Streaming - The ability to implement adaptive streaming (i.e., automatically adapt the streaming to match the client’s bandwidth) in such a simple way was incredibly powerful. The Silverlight MediaElement natively supports playing videos source from a smooth stream. Chris Klug wrote a nice post on how to consume smooth streaming video in Silverlight (http://chris.59north.com/post/Playing-Smooth-Streaming-videos-in-Silverlight.aspx).

Challenges

  • Designer/Developer Interaction - I wasn’t sure whether to put this under “Challenges” but it is a point worth noting and something that I know a lot of teams are trying to address. You only have to look at the result to realize we had a great designer on board (thanks Dave) but XAML is a new beast to most designers and we had to rely on one of our developers (http://tech-and-arts.blogspot.com/) to translate XAML that was imported into Expression Blend from the designs done in Photoshop. This took additional time but meant that the developers could control exactly how the XAML was structured, reused and applied. Even for traditional HTML development, lots of teams still anticipate a design/developer integration effort. It’s true that Dave could have worked directly on Expression Blend but he, like many other designers, is still more comfortable in Photoshop. Expression Blend now has source control support and allows designers and developers to work on the same solutions - this is a great step forward. I can see a future where more designers get familiar with it and the transition from designs (and more importantly re-designs) to implementation improves.
  • Not Using Silverlight 3.0 - Unfortunately we implemented the solution just before the official release of Silverlight 3.0- We made the call to not take a dependency on Silverlight 3.0 mainly because we expected a big influx of users in the first few days of operation and we did not expect a broad deployment of Silverlight 3.0 within that time period. Some things would have been a lot easier in Silverlight 3.0. A few examples include:
  • Element Data Binding - Would have simplified some aspects of our View Model.
  • Style Enhancements - In particular being able to manage styles in separate files and merging them using MergedDictionaries.
  • Mouse Scroll Wheel Detection - When you browse to the site and hover over, say, a comments list, you’ll notice that the list scrolls as you turn your mouse scroll wheel. You’ll see similar functionality when you hover over the main page. This is natural behavior and what users expect but it isn’t natively supported in either Silverlight 2 or 3. Silverlight 3.0 does have a new MouseWheel event to make things easier but it still requires coding. While it’s not too difficult to implement, hopefully this will become native behavior in future versions.
  • Multiple Host Headers and WCF - A last minute challenge was uncovered as the site was going live. When we switched over the domain name and setup the new host headers, WCF started to throw errors. It turns out that WCF doesn’t play well by default when setup with multiple host headers (both office2010themovie.com and www.office2010themovie.com map to the site). This was the first time any of us had ever run into this issue; we have always hosted services on a dedicated site but for this project we chose to deploy the web application and services in the same site to minimize deployment overhead. With a broken site and time against us (a speaker was preparing to announce the site to the world live on stage within minutes) we scrambled to get things up and running again and chose the simplest fix we knew would work; create a separate site in IIS for the non-www host header and have it redirect to the real website. Instantly the site was back up and running, just in time for the thousands of visitors the site would get over the next few hours. While this 2:00 am fix worked, fortunately, .NET 3.5 has real support for WCF and multiple host headers (http://blogs.msdn.com/rampo/archive/2008/02/11/how-can-wcf-support-multiple-iis-binding-specified-per-site.aspx).

Conclusion

All in all this was an extremely successful project. The end result is a very slick looking site that leverages the media and user interface power of Silverlight. We met our deadline (with minutes to spare!) and didn’t have to sacrifice the quality of the solution. I’m pretty confident that to be able to create a similar site using HTML/CSS/JavaScript would have taken a lot longer and certainly wouldn’t be nearly so cool.