It’s probably one of the most interesting moments to do a post mortem for a Silverlight project. The entire Microsoft ecosystem is boiling around the Silverlight OR HTML 5 debate fueled by the recent PDC and some statements from Microsoft officials. The interesting part about it is that it is a false debate, and like most false debates it will probably lead to nowhere. The simple truth is that Microsoft’s commitment to Silverlight has not changed a bit, and Silverlight is more healthy and strong than ever. And the fact that the same Microsoft places an important bet on HTML 5 too can only make me happy as an architect and a developer. Mostly because it assures me I’ll have my fair share of choices in the future without having to leave the development platform I like. The reality is that neither Silverlight/RIA nor HTML 5 will turn out to be the magic to fly us to the land of perfect web apps and, at least for the foreseeable future, there will always be a need for alternatives. That’s why I think the debate on Silverlight or HTML 5 is nonsense in the Microsoft ecosystem. But I digress… Let me tell you about the latest software project I participated in.
Project Overview
One of our large customers (a regional player in Eastern Europe) is going through the process of consolidating its Line-Of-Business (LOB) applications. As with any successful company that grows rapidly, LOB applications have a tendency of becoming both scattered and heterogeneous (in terms of technologies used to implement them). At some point, the IT Manager found himself in a position where he had to handle about two dozens of such LOB applications (some smaller ones as well as a few large ones). One key decision he made was to unify these applications from two points of view:
- The technological one - one platform, one framework, one approach.
- The user experience one - eliminating the need to constantly re-train end users for every single application.
Eventually, the consensus was reached that the backend platform will be based on SQL Server (for data) and Windows Communication Foundation/Workflow Foundation (for business logic and service façade). This was pretty much in line with company’s strategy to expose as much functionality as possible via services. On the user experience side of the world, choices were rather limited because of the existing SharePoint intranet implementation which basically meant that the decision for the user experience delivery vehicle was a done deal. What we needed to decide was the actual technology for implementing the user experience. After a detailed analysis of the UX requirements we decided to go the RIA way instead of the HTML way. At this date, I am 100% convinced that RIA (read Silverlight) is the safe bet for the user experience in LOB applications when web technologies like SharePoint are involved. Consequently, our technology platform for the user experience was to be built around SharePoint 2007 and Silverlight 3.
What we had in front of us was the monumental task of re-engineering some of the existing applications while also implementing some new ones. Due to obvious space restrictions, I’m not going into details about the whole saga. Instead I will focus on one of the earliest projects because that was the point where blog posts, web casts, conference sessions and demos turned into real-life, field experience for us. Furthermore, I’m going to focus my discussion on the user experience part of the project which was the most interesting one for us.
What Went Right
Using Silverlight for User Experience in Line-of-Business Applications
The basic idea of the entire application was to provide support for budgeting different types of activities, like sales, merchandising, site visits, orders, and so on. Due to the hierarchical nature of the organization, the main staring point of the user experience had to be centered on the tree view control showing the organizational sub-tree of the current user. This had to be synchronized with several controls placed on the same level as well with controls that were initially hidden from view. The entire idea of supporting different types of activates in a dynamic way lead to the necessity of having a model where one can dynamically add controls in a configurable manner without impacting existing ones. On top of that, most of the controls were quite heavyweight so it was perfectly clear for us that the default Silverlight toolbox will not do the trick. Finally, the deadline was a killer. Basically, we had to deliver the first iteration of this particular application in a period that was just a bit over three months.
Given these circumstances our bet on Silverlight itself turned to be a very good idea. Having a strong background in .NET and WPF, our team of developers was able to tackle all the user experience requirements of the customer in a very efficient way. From minor to quite major changes, we were able to deliver at a constant pace. And the beauty of it was that in one particular case, when the controls we had at our disposal weren’t able to provide the functionality, we were able to extend them using their source code without a problem. We’ve even had two or three cases where we were able to fix bugs in the controls without having to rely on complicated workarounds. (Remember the good old days of native Windows user experience development?) All in all, the actual user experience functionality turned out to be pretty compact and clear code.
Using Windows Communication Foundation for Exposing Middleware Functionality
Since we were dealing with not one but several integrated LOBs, exposing application business functionality via service facades was a natural thing for us. Especially because the customer has several other apps that need to be integrated with the ones we were consolidating at the level of their business functionalities. Using Windows Communication Foundation endpoints proved to be the right decision. Because we had prior knowledge and experience with WCF, we were right on the spot with almost all the issues. Supporting additional bindings and specialized security features like packet-level encryption was a walk in the park with WCF.
Supporting a New Version of Silverlight
Another interesting thing we experienced with this project was upgrading the user experience technology (from Silverlight 3 to Silverlight 4). Despite the fact that we had a rather large number of lines of code, upgrading to the next version went very smooth. Right after the delivery of the first iteration we decided to deliver the next one on Silverlight 4. It was a matter of days to absorb the various differences (mostly in XAML syntax) and then a couple of weeks of regression testing and we were basically done. We learned this way that going from version-current to version-next is a good experience with Silverlight.
Out-of-browser Experience
Using Silverlight on a massive scale also led to an unexpected result (a good one). Although initially SharePoint integration was a kind of alpha and omega issue (pushed by the technical personnel), it eventually turned out that the Silverlight out-of-browser experience was quite pleasant for many end-users. Now, after delivering the latest production version I can say at least one third of these end-users rely almost exclusively on the out-of-browser experience. It’s actually not a technical issue but one related to perception. But it did us a lot of good in winning the end-users to our side.
Short Release Cycles
The sustained pace at which Microsoft releases Silverlight versions worked in our favor and even helped us sell to the customer the idea of upgrading to new versions. As I mentioned above, at some point we decided to move up from Silverlight 3 to Silverlight 4. Clipboard access and full-screen support (the ability of a Silverlight application to remain in full-screen mode when another application is active) were some of the important advantages we used to convince the customer to move up one version. This also helped us create a very dynamic image of the application in front of the customer and more importantly, helped deliver the message that we can constantly improve (at a fast pace) the functionalities and still deliver stable iterations.
What Went Wrong
Asynchronous Calls in Silverlight
There was a glitch in using Silverlight on a massive scale though. It was an issue that we were aware about, but underestimated its effect on a large user experience project. I’m talking about the fact that Silverlight permits only asynchronous calls to services. Since our entire middleware was exposed via WCF services, there was no way out of this. Of course we knew the reasons why Silverlight does this (in fact we totally agree with the approach) and we thought we were prepared for the consequences. Turns out we were not quite as prepared as we thought we were. Since some of the service interfaces were designed in a pre-Silverlight era, they had a tendency of being rather chatty. This led to some interesting developments in the user experience source code, as you can imagine.
At some point, it became so cluttered that the asynchronous calls logic was dominating over the actual user experience logic. Our user experience developers were quite unhappy with this. What we’ve learned from this is that you really have to factor in the “chattiness” of your service interface when you’re planning to call it from Silverlight.
Silverlight Support for WCF Bindings
What turned to be the downside of using WCF with Silverlight was Silverlight’s support for WCF bindings. We were basically stuck with the HTTP bindings which did not make us very happy. We did know about this up front, but as you all know, life does like to play tricks on us. At some point, the customer requested a change in the authentication mechanism of the WCF services which in turn lead to the necessity of implementing a custom authentication provider for WCF (due to the fact that we were stuck with a restricted choice of bindings courtesy of Silverlight). What we’ve learned from this is that you need to be much more careful when analyzing the impact of potential major security changes (like changing the authentication mechanism) in the grand scheme of things.
Reporting Services Integration
Another area where things were not so bright was integration with SQL Server Reporting Services. By the time we were ready to deliver the second iteration (about 5 months into the project) the customer started to favor the idea of integrating SSRS reports directly into the user interface. Initially, we used SharePoint as the host for accessing and exporting reports related to the application. It turned out end-users were not that happy switching back and forth between pages in SharePoint (especially the ones I told you above who were running the application in out-of-browser mode). So we were under real pressure to provide report viewing inside Silverlight. Much to our surprise there is a very weak offering of Report Viewer controls for Silverlight (at least it was at that point in time). Eventually, we settled with the one vendor that seemed to have it right but we were not very comfortable with that decision. We’re learned that integrating SQL Server reports in Silverlight is not quite an easy ride.
Visualizing Workflow State in a Graphical Way
Speaking about integrating functionality, we’ve also learned that integrating visual workflows into a Silverlight application is not an easy ride either. Turns out that the Windows Workflow designer is a pretty good WPF control but it lacks a Silverlight counterpart. We did have to turn down one change request from the customer that asked to have a visual representation of the different workflows running in the application at some point in time due to the lack of a hostable Silverlight control that has the capability of rendering visual representations of WF workflows.
Support for Mobile Devices
Lack of Silverlight support in mobile devices was (and still is) something that gives us a bit of a headache. Coming in as a change request (rather than part of the initial specification), the client’s desire to make available some of the functionality of the integrated apps for mobile devices forced us to use ASP.NET to solve that issue. Fortunately, developments in the Windows Phone 7 sector combined with the client’s willingness to consider upgrading the old Windows Mobile devices makes room for the promise of user experience convergence.
Conclusion
All in all, I think the best thing that we got from this early Silverlight project was that we proved you can use this relatively new user experience technology in projects where you’re under pressure to deliver functionality, where changes do happen, and where IT has to deliver real and fluid value to the business. Remember, we’re talking here about a fast growing, regional player, whose business needs do change often. Looking back, I can say that all the negative things were eventually helpers rather than show-stoppers. As you can see from my story, it’s not all milk and honey with Silverlight but it can be a smooth ride once you’re well prepared and equipped for some of the issues that come with the package. And what’s most important, if we get in a position to reconsider our choice for the user experience technology we’d most definitely make the same choice.
