Do we need a Silverlight Browser?
Stop. Don’t say it. I know what you’re thinking. Adam has been taking the crazy pills. Well, if I have, I’m not telling you, but that in no way relates to this topic.
As you’re hopefully aware there are countless cool and useful features in Silverlight 3. Just check out Tim Heuer’s post for a full run down of all the Silverlighty goodness that’s coming your way. Two of the features I’m most excited about are Silverlight Out of Browser experiences, or SLOOB, and the Navigation Framework.
(A quick sidenote to the SLOOB haters out there, and I know there are some, and I know some of them personally. Yes, I’m aware SLOOB is still operating in the browser sandbox, which means your app can’t access the file system directly. Yes, I’m aware that you can’t print in SLOOB. Yes, I’m aware you can’t style the chrome of a SLOOB app. And, yes, I’m aware Adobe AIR doesn’t have these limitations. The fact is it’s only a matter of time until Silverlight addresses these issues, so I’m not too worried about it. ‘Nuf said.)
So, when Silverlight 3 was announced I did what any self respecting developer would do, I downloaded the beta bits and started playing right away. During the first pass through of the features I was pretty impressed. I coded up some demos for work and for the local user group and that was that. Then while I was presenting the demos at an internal meeting I noticed something that I didn’t call out at the time because I didn’t know what to make of it.
My demo consisted of a four or five page Silverlight 3 Navigation Application that can run out of the browser. While running in the browser it was great. I had the Uri in the address bar, I had full history, I had easy navigation with the browser’s back and forward buttons, I could bookmark, etc., etc. However, when I ran the app out of the browser I realized all of this functionality was missing. Luckily no one caught it at the meeting and called me out on it because I had no answer for it.
My first thought was that maybe I didn’t enable something in app.xaml or maybe I missed some new control, but then Tim Heuer posted this entry about the navigation framework. Note he goes in and manually adds back and forward to his control, toggling visibility based upon whether or not the app is running in or out of the browser. From a UX perspective this is a bit problematic for me. If I create a SLOOB app that utilizes the navigation framework, my users are going to be in for a rude awakening when they take the app offline. They’ll have no way to navigate the app unless I take the time to to add the code just like Tim did. Granted, it’s easy enough to do, but to me it’s almost so easy that it shoud be part of the framework.
So, in my opinion, yes, we do need some type of browser control in the Silverlight 3 navigation framework to accomodate SLOOB scenarios. As I started thinking about a bit more, I also realized there’s also no way to really define the structure of your Navigation Application. It’d be nice if Silverlight 3 stole a page (no pun intended) from ASP.NET and provided features similar to Web.sitemap, Menu, and SiteMapPath. This would allow developers to define the structure of their apps, and then bind these navigation controls to the application map. These sure would be some nice features in my opinion.
I could just leave at that and say, “Hey Silverlight team, I’m not moving to Silverlight 3 unless these issues are addressed.” However, I’m not that kind of guy, and if you’re reading this you’re probably not either. I think Silverlight 3 is a great product, and I’m going to step up and see if I can’t make at least an attempt to address these missing features. In following posts I’ll start by laying out the basic requirements for each feature and then walk through the features as I start to build them out.
Stay tuned…
FYI - I originally hadn’t planned to have my first post be on this topic. I was planning to start a throwdown series between different presentationi patterns (i.e. MVC, MVP, MVVM, MVVMP, etc.) I still plan on doing the series over the next couple of weeks, but this topic was too compelling to stay at the bottom queue.
