Think First, Code Later

So, in my first and second posts in this series I laid out the justification and high level requirements for a Silverlight browser. In this post I’ll walk through building the basic shell for our browser. This isn’t anything overly cool or sexy, but it has to be done as it’s the foundation for the rest of the project.

First a little housekeeping. I created a Visual Studio solution named Silverlight.Navigation to house the source code for this endeavor. The solution, as you can see below contains three projects.

Silverlight.Navigation.Controls - This is where most of the work will be taking place. This project will contain the necessary controls and infrastructure for the Silverlight browser.

Silverlight.Navigation.Demo - This is a small Silverlight demo application we will use to consume the controls created in Silverlight.Navigation.Controls.

Silverlight.Navigation.Demo.Web - This is the website used to host the Silverlight.Navigation.Demo application.

Also, the UI for this initial portion of the project is intended to look the way it does. This is just an experiment after all and I don’t want anything looking too finalized or polished as it might distract us from what we’re trying to accomplish.

Now that that’s out of the way let’s get to the task at hand. The first thing we need to do is define what exactly it is I’m building in this phase of the project.

1. A navigation container (or toolbar) that can be used to hold all the navigation features (i.e. menus, breadcrumbs, address bar, etc.) that we want to build into the browser. This container should be expandable and it should have some options around when it’s displayed.
2. The browser shell. This will contain our navigation (above) as well as a way to display navigated content.

Ok, easy enough, let’s move on to the implementation. Here’s the structure of the Silverlight.Navigation.Controls project

The first thing I did was to create the navigation toolbar (NavigationToolbar.xaml). The UI is simple enough at the moment. It’s nothing more than an Expander (new to Silverlight 3), with three TextBlock placeholders for where our future features will go. I added an IsExpanded property to the control to allow consumers to control the IsExpanded state of the control’s Expander control

Next up I wanted to create an enumeration that defined the values for when the navigation toolbar was to be displayed. I created an enumeration named DisplayNavigationToolbar (I know, really original) in the Enums.cs file. I gave the enumeration the following values: Always, InBrowser, None, OutOfBrowser.

The last step was to create the browser (Browser.xaml). This is nothing more than a StackPanel with our NavigationToolbar and a TextBlock placeholder for our navigable content. Since we don’t have any content yet, I choose to use the TextBlock placeholder here so you could see where the content will reside when running the app. Once we starting adding some content we’ll replace this TextBlock with a NavigationFrame.I added a couple of dependency properties to the browser. The DisplayNavigationToolbar property allows consumers of the browser to control when the toolbar is display by setting it to one of the values of the corresponding enumeration. The IsNavigationToolbarExpanded property allows consumers to control whether or not hte toolbar is expanded by default.When the browser loads we simply set the NavigationToolbar’s IsExpanded property to the value of the browser’s IsNavigationToolbarExpanded property. We then check whether or not the app is running offline (via App.Current.RunningOffline) and set the visiblity of the NavigationToolbar appropriately. No black magic, pretty straightforward.

That’s it. Seriously. Oh, wait you want to see it work? Ok, let’s wire it up in the demo project. Here’s the structure for the demo project:

Pretty basic at this point. It will start to grow as we add navigable content.

(While not shown here, I did modify the AppManifest.xml to suppor the out of browser experience.)

Main.xaml is the control that contains our browser. As you might expect, I had to add a namespace declaration for Silverlight.Navigation.Controls in the markup in order to get access to our newly created browser control. I thought that was all I would need to do, however, the browser would never render. This was because I also needed to add namespaces for the System.Windows.Controls in the System.windows and System.Windows.Controls.Navigation assemblies, as show below:

Once I did this the browser rendered no problem. As you can see above, I set the navigation toolbar to only display when running out of the browser and to expanded by default.

In Browser Experience:

Out of Browser Experience:

I’ve decided to house the source code for the project on codeplex. The code associated with this post is available here.

I’d say we’ve successfully delivered on phase 1. Next up creating the application map. This will allow us to define the structure of our applications and create controls (i.e. menus) that can consume the map. Stay tuned…

adam silverlight navigation framework, ria, silverlight, silverlight 3, silverlight browser, sloob

So before I just go off and starting coding this thing, I thought it’d be a good idea to flush some high level requirements. There are two main reasons I’m doing this:

1. To set expectations for anyone reading this post or interested in the code.
2. To define success for myself. It’s very easy when start endeavors such as this to get so lost in the details that you lose site of what you were trying to accomplish. Eventually you just give up.

These aren’t going to be anything formal, just some notes about what to expect, and to get this thing rolling.

Here we go…

The first thing I though I’d do is come up with a really rough wireframe of what the heck I’m talking about. So, here it is:

silverlight browser wireframe

 Let’s run through the features at a high level:

• Navigation Manager -This will be the hub of navigation. Think [insert your favorite browser here]’s nav bar. This will enable users to navigate back and forth in the app, see their current location in the app, type in uri within the app for navigation, view history, set favorites, etc.
• Application Path - Think breadcrumbs. This will show the user the path that was taken to get to the current location within the app.
• Menu - Just like it sounds.
• Navigation Container - The thought here is that while these navigation controls are nice to have, and required in SLOOB scenarios, you probably don’t want to have them visible all the time. We may want to hide it altogether when running in the browser and then display it in a SLOOB situation. Furthermore, when it is visible you may want it to be collapsible in some sense, allowing the user to easily get to it and even pin it without taking up real estate your application could be using.
• Navigation Frame - This is the Silverlight 3 control, no need to elaborate.

Obviously these are some pretty high level descriptions. Before diving into each feature we’ll need to examine them in more detail to flush out the exact functionality we’re looking for. But, hey, at least this gets us going.

Where to go from here? I’m all about low hanging fruit and quick iterations, so I think the best place to start will be to frame out the browser and build out the Navigation Container. In my next post I’ll lay out the requirements for the container and either build it as a part of that post or the following post, we’ll see what happens.

adam silverlight navigation framework, ria, silverlight, silverlight 3, silverlight browser, sloob

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.

adam silverlight navigation framework, ria, silverlight, silverlight 3, silverlight browser, sloob