Think First, Code Later

(Note: if you’ve just stumbled upon this post, please be sure to read the first three posts in the series here, here, and here to get an understanding of what we’re trying to achieve and where we’re at.)

In my last post I built out the shell we are going to need for our browser. After I did so I realized there was a key mistake. In that version of the code I had placed the menu and application path components within the navigation toolbar. The problem with this approach is that if I choose to configure the navigation toolbar either to always be hidden or only display when running out of the browser, I’ll lose the functionality of these components when running in the browser as they will be hidden. To correct this issue I moved the menu and application path components to the browser itself. I also added display properties to the browser to allow a more granular control of when these components should be displayed. Now that we’ve gotten this issue squared away let’s start moving forward.

Our next task is to built out the menu and application path components our browser will consume. My initial thought was to follow the pattern ASP.NET uses with it sitemap, sitemappath, and menu components. I went so far as to download the .NET Framework source code from here to take a look at how Microsoft does it. While I was fairly impressed with what I saw, I felt that it was just a bit too much for the task at hand, so I decided to only use the pieces that I thought were appropriate for our task.

After I had a general design direction I decided to get to work. The first think I did was to add a new project entitled Silverlight.Navigation.Mapping to our solution. Here’s what the current version of the solutions looks like:

In the Silverlight.Navigation.Mapping project it all starts with the MenuItem class. This is an abstract class that only contains a three properties the following three properties:

Description- a long description of the menu item (for tool-tips).
ImageUri - the uri of an image to use to represent the menu item (optional).
Title - the title of the menu item to use in visual display.

There are three classes that then inherit from the MenuItem class:

HomeMenuItem - this represents the “home page” of the application and simply contains a ContentUri property that points to the page.

MainMenuItem - this represents a top level menu item of the application. This class has one property SubMenus, which is a collection of SubMenuItems. A MainMenuItem itself doesn’t point to a page, it just serves as a way to logically group pages together.

SubMenuItem - this represents a page within the application. The ContentUri property points to the page, and the Parentproperty serves as a reference to the MainMenuItem containing the submenu.

You’ll note here that I’ve essentially limited the depth of the application to two nodes (Main Menu and Submenu). This was an intentional decision. Often times I come across apps with really deep menuing structures where it’s very easy to get lost and I’d like to avoid that, at least for the time being. I probably shouldn’t force this decision and allow implementers to make an app as confusing as they want, but this can be addressed at a later date.

Next up is the ApplicationMapclass. This is an abstract class that represents the map of an application. The properties and methods of the class are pretty self-explanatory. The key properties are the abstract HomeMenuItem and MainMenuItems properties. Inheritors of this class are responsibly for defining the implementation for this properties.

Lastly we have the XmlApplicationMapclass. This class inherits the ApplicationMap class and implements the HomeMenuItem and MainMenuItems properties by loading their values from an xml document. Pretty simple, and fairly consistent with the ASP.NET model

The UI implementation is pretty simple at this point. As you’ll see in the picture below, I’ve added several new controls to the project.

ApplicationMapPath- similar to ASP.NET’s SiteMapPath, this just keeps track of where the user is in the application.

MainMenu - this simply display the main menu items defined for the application.

SubMenu- this is used to display the submenu options for a given main menu.

The Browser control has an ApplicationMapPath control and a MainMenu control. When the user clicks a main menu item the SubMenu control is displayed for the main menu. When a submenu item is clicked the app navigates to the page defined by the submenu item and the ApplicationMapPath control is updated to show the path to the current page.

The actual implementation is a snap. If you look at the demo project you’ll see I created an ApplicationMap.xml file that contains the definition of our application. I also created some pages under the Views folder. These views aren’t much of anything to look at right now, but they help to illustrate the point.

If you look in Application_Startup method of App.xaml.cs you’ll see the following code:

Here’s what’s going on:

1. I create a new instance of the XmlApplicationMap class using the ApplicationMap.xml file I created in the project.

2. I create a new instance of the Browser control from Silverlight.Navigation.Controls, passing in the XmlApplicationMap class as the constructor’s parameter.

3. I set couple of UI preferences (DisplayNavigationToolbar and IsNavigationToolbarExpanded) on the browser.

4. Finally, I set the root visual of the app to the instance of the browser, and voila, my menus and application map are up and running. Both in and out of the browser!

In Browser:

Out of Browser:

I’ve issued a new release on the CodePlex site for this project that contains the functionality discussed above. You can download the release here.

I’ve also put this app up on my website here. Per Tim Heuer’s post on Silverlight 3 beta install guidance, I customized the install experience to let folks know if they need Silverlight 3 and what it means to install the beta version of Silverlight 3 at this point in time.

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

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