Silverlight Problems: Yet Another Plug In

Tags: Knockout, pubsub, observer, MVC, jQuery, Ajax, EF, Validation, FluentValidation, Visual Studio 2010, ASP.NET, JSON, FullCalendar, Silverlight, Architecture, Vista, IIS, Generics, NHibernate, WCF, RIA Services, Visual Studio 2008, SQL, STORM!, Nullable, ChannelFactory, netTCPBinding, VSPAT, responsive, design, HTML5, CSS3, MVC WebAPI, MVC 4, WebAPI, JQuery Mobile, ScheduleWidget, recurring events, Ninject, Pluggable, CQRS DDD, Windows

So I labored mightily last December on Wanting to be hip and happening I implemented it in Silverlight 4 and RIA Services. It worked out well. I was pumped. So post-launch I asked a few non-technical friends to take it out for a spin. And then the problems started. They told me it didn't work. I quickly discovered most didn't know that they needed to install the Silverlight runtime. I was counting on the blue box of joy to do the work for me but it wasn't explicit enough and many didn't even look at it very closely. So following Tim Heuer's lead I dove into a custom installation experience. But the detection script reports Chrome as an unsupported browser. I could hack the script of course. But the problem is much deeper: my friends didn't want to install yet another plug in. They didn't understand why they needed to do it, had questions about it, and finally hesitated to take the simple 30 seconds to do it. I realized that if this is how my friends reacted what would complete strangers do? In the end I decided I needed to port the app over to a web application. MVC 3 to be specific and it's going great. More on that later. My takeaway from this experience is if you cannot control the end user's browser then stick with tried and true web applications. If it's an intranet app where you know your end user's environment and they need a rich-client experience then consider Silverlight 4.