Anyone who knows much about me knows that about year ago I participated on a team during Startup Weekend in the Twin Cities of Minnesota. Our team won the weekend competition by creating a company in 48 hours. Our company and our product is QONQR, the geosocial game of world domination.

You can visit the website to learn more about the game and the team.

Following Startup Weekend, we were honored to be selected as a Finalist in the SXSW Accelerator startup competition in Austin, Texas, sponsored by Microsoft BizSpark. It was at South by Southwest (SXSW) in March where we launched a public web beta of our application, a mobile optimized HTML5 application.

Today, as I write this, we prepare for the Minnesota Cup competition, where we have been selected as a finalist in the largest business plan competition of its kind around. As part of the competition, we have taken a look back at our player engagement. In five months, with absolutely no marketing initiatives, we have garnered players in over 2000 cities, towns, and villages in over 34 countries around the world. We decided to put together a small sampling of less than 10% of these locations in a Silverlight control, using Bing Maps.

[story continues below]

It strikes me today what a huge role Silverlight and Bing Maps have played in our success. While the web beta we launched in March was a pure HTML 5 application, our very first application from Startup Weekend incorporated a Silverlight map which allowed players to view the battle zones and watch them change hands in real time. It was this first Silverlight map that got all the “Oohs” and “Ahhs” at Startup Weekend. Silverlight was the “sexy” piece that grabbed the judges attention, and some questioned whether we cheated because they believed it was unlikely such a fancy UI could be built in a weekend. But it was…

It was our Silverlight application and the fact I migrated 26 hours of XAML and code behind to the Windows Phone in 1-2 hours that got me an invitation by Microsoft to keynote the Windows Phone 7 Developer Launch Conference in Minneapolis last fall. Once again, the speed of Silverlight development surprised even those that knew XAML with the ease of porting it to the phone. The QONQR web console was running on a real Windows Phone device weeks before any devices had even hit the market.

Once again today, Silverlight comes to the forefront. This map so clearly and powerfully shows the reach of QONQR, dare I say better than any HTML version of this map could. Furthermore, it was hours, not days, of effort to put this together in Silverlight. A small idea of how best to demonstrate the early success of QONQR was brought to life in very little time with minimal effort. We hope this little Silverlight app makes a big impact on the judges.

Who knows where QONQR would be today without Silverlight?

Stay tuned for more information on QONQR as our WP7, Android, and iPhone native applications near completion!

In the past few days I have been working to restructure the login and registration navigation for a Windows Phone 7 application I have been building. This project is for the startup I’m involved with called QONQR. QONQR is a complex interactive game with a backend service. Without going through the whole QONQR story, let me offer a quick summary: using GPS location to play, you must join a team with which you battle for world domination.

Why did I need to place structure on the way I had coded the login/registration process? It has everything to do with the WP7 Back Stack. WP7 remembers all the pages you have visited in your application and will send you back to each page in order when you hit the back button, without you the developer needing to keep track of the pages. Awesome, right? Not so much if the back button sends your users back through the registration process. You don’t ever want them to see those pages again once they have completed the registration. This is the problem we will explore below.

In the following section I outline the registration navigation for the QONQR application in detail. You can skip all that and go down to the solution below.

The needs of the game makes the signup process a long one. First we start with the welcome screen, which appears when the game loads. [See Welcome Screen]

When the user hits PLAY we show a pivot allowing the user to either LOGIN, or REGISTER. [See Login and Register Screens]

If the user is new to the game and must register, we collect the information you see on the screen shot and validate the necessary fields. The user must then learn all about QONQR by reading the back STORY. [See the Story Screen] Once they learn what they are fighting for, they must choose the FACTION (team) with which they want to fight for world domination. [See the Select Faction Screen]

At this point the user has registered and is logged into our application. For the sake of completeness, this is the place holder page I show once the user logs in. Let’s call this the HOME page. [See the Home Screen]

So let’s review. This is the navigation path of our application.


The top indicates normal navigation through the application for a variety of scenarios. You can get directly from the WELCOME screen to the HOME if you auto-login (saved credentials from a previous session). If you use the LOGIN page, you will jump to the HOME once login is complete. Finally there is the REGISTER path I outlined above. There is one additional step. Notice we need your birthday to make sure you are at least 13 years old. In WP7 this is done through a data picker control. When you display a date picker you actually trigger a navigation event, you leave the page that launched it and then navigate back to the source page. The date picker is not a popup. [See Select Birth Date Screen]

So the top arrows representing standard navigation forward through the application are pretty easy to follow, even if it looks less than simple at a high level. The back button navigation isn’t too difficult either. Notice that the pivots both go back to the previous page. The back button doesn’t go back to the previous pivot, but rather the previous page. This is standard back button behavior in WP7.

The whole problem is the lowest (red) arrow in the navigation diagram. The back button needs to go from the HOME screen to the WELCOME screen, regardless of how the user got there. If it wasn’t for this one red arrow, I would not have had to do anything to restructure my app, which was previously setup with distinct pages for each registration step.

The inspiration for the solution was found in this blog post by Peter Torr.

First, because the back button needed to go from the HOME screen to the WELCOME screen, all of the screens in blue (in the navigation diagram) must live on the same page. You cannot control the back stack, so the alternative is to manually manage the registration navigation forward and back in a single page, rather than using “Page Navigation”.

The Main Page has the WELCOME screen at its core. Then there is a pivot containing the LOGIN/REGISTER UI and another pivot that contains the STORY/FACTION UI. Both pivots start collapsed (hidden). I use behaviors to change the View State of the Main Page to show and hide the proper pivot, as the user moves through the navigation process. I also use Boolean properties on the view model to keep track of the current view state, and the currently selected tab in each pivot. These properties will become important when I discuss Tombstoning.

        private bool _showWelcome;
        public bool ShowWelcome
            get { return _showWelcome; }
            set { _showWelcome = value; RaisePropertyChanged("ShowWelcome"); }

        private bool _showLoginPivot;
        public bool ShowLoginPivot
            get { return _showLoginPivot; }
            set { _showLoginPivot = value; RaisePropertyChanged("ShowLoginPivot"); }

        private bool _showFactionPivot;
        public bool ShowFactionPivot
            get { return _showFactionPivot; }
            set { _showFactionPivot = value; RaisePropertyChanged("ShowFactionPivot"); }

        private int _loginPTabIndex;
        public int LoginTabIndex
            get { return _loginTabIndex; }
            set { _loginTabIndex = value; RaisePropertyChanged("LoginTabIndex"); }

        private int _factionTabIndex;
        public int FactionTabIndex
            get { return _factionTabIndex; }
            set { _factionTabIndex = value; RaisePropertyChanged("FactionTabIndex"); }

I use this code to catch the back button and correctly set the UI. This code is in the code behind of the main page. Notice the ViewModel decides if it should handle the back button, and thus cancel the back button event from using the built in back stack.

        protected override void OnBackKeyPress(System.ComponentModel.CancelEventArgs e)
            if (this.ViewModel != null)
                e.Cancel = this.ViewModel.GoBack();

This code is in the View Model

        public bool GoBack()
            if (this.ShowLoginPivot)
                return true;
            else if (this.ShowFactionPivot)
                GoToLoginView(this.LoginTabIndex, true);
                return true;
                return false;

I didn’t include the GoTo[X]View methods referenced in the sample, but they set the ViewState of the view (to transition the UI) and set the Boolean flags to keep track of the current state of the UI. The true parameters indicate that storyboard transitions should be used.

By managing the long list of UIs in blue (in the navigation diagram) in this way, I have manual control of the back button for all the registration UIs, and the backstack that WP7 maintains works properly once the user has logged in.

Finally, by tracking the state of the UI using the properties I’ve listed above, I can store these setting to Isolated Storage during tombstoning and rehydrate them during activation. The forward and back logic works perfectly after reactivation and there is no concern for restarting the application in the middle of a registration process. Oh… remember the date picker and how this triggers a navigation event? When you return from selecting a birthdate, the view model contains which pivot was visible and which tab of the pivot was the current tab when you left. The same logic runs to reactivate the Main Page on a navigation, in the same location and state as when you navigated away. No additional work needed, beyond what already was done to handle the reactivation from tombstoning.

Peter’s blog post I referenced earlier, suggests using a popup to handle multiple UIs in a single page, but I’ve read popups have some performance issues. Plus setting the visibility properties of the pivots (set to fill the entire screen) is simple and the storyboard animations can make slick transitions within the page. In the end, I wish I had considered the backstack issue identified by the red arrow in the navigation diagram before I started. This was clearly an instance where thinking ahead would have saved me significant rework. Hopefully this will help you avoid the same rework.

We hope to have QONQR in the WP7 marketplace by late summer or early fall.

Select Faction
Select Birth Date

Displaying a Silverlight control on one site when the XAP is hosted on another isn’t guaranteed to automatically work. In this case I wanted to show the WP Blog Menu on the CodePlex site, but needed to reference the XAP that is hosted on my blog site. My blog is a WordPress site, running on Apache. It turns out there is a simple fix to allow the hosting of a XAP on one site to be shown on another.

Tim Heuer is the hero who created the WordPress plug-in that allows me to host the Silverlight control on this blog. I also found that he has a comprehensive explanation of what it takes to solve the cross domain hosting problem. It my scenario, the fix was outlined in Tim’s blog post. I created a file called .htaccess and placed the file in the same directory where I had uploaded the XAP file to WordPress. This file contained only a single line.

AddType application/x-silverlight-app xap
Tim’s blog wasn’t clear that I could just put this single line in the file with no additional formatting, but that is in fact all it took—just this one-line file. Tim’s blog outlined several other things that can solve these issues, but the .htaccess file was all it took for hosting a Silverlight control on CodePlex when the XAP is hosted by Apache someplace else. Thanks Tim!

Last week I decided to get creative. I wanted to put a Silverlight control on my blog somewhere. I thought perhaps the best thing to do would be to create an animated live tile of my headshot to put in the blog header. For those that don’t have a Windows Phone 7, a live tile is my Facebook profile picture that slides up and down with “Me” on it. I thought the live tile would be a nice way to add a bit of WP7 to the header that is already Silverlight themed.

Then it occurred to me: why just build a single live tile, when I could make a full phone with 8 tiles? Each of the tiles could link off to the sites and organizations I’m involved with. Thus was born the control you see on the right sidebar of this blog.

It didn’t take long—less than a day I suppose. There was virtually no code, just a few lines to handle the click events on the tiles and a few more to kick off the storyboards that run the animations. All in all, a snazzy bit of XAML came together to make a cool navigation menu for my blog.

So a pretty neat menu, with a tiny bit of effort. Seems like a good thing to share, right? Introducing my first CodePlex project: WPBlogMenu. Go grab the bits and make your own WP7 themed menu.

I really dislike being involved in these kinds of debates.  I really don’t like to be portrayed as a one of those guys that has technology “religion,” but it seems that I am always on the side of defending Silverlight, which make me look like a fanatic.  All too often I find myself on the defense, even with my business partners.  It is true that I am a big Silverlight fanboy, but I try to always choose a technology based on the best fit for the business need it fills.  I run the Twin Cities Silverlight User Group, yet I built our website using ASP MVC2, and it is 100% HTML.  Why? Because it is just an informational website.  HTML is perfect for serving this purpose, and we need the information to be accessible from mobile phones.  It was the best technology fit for the business need.

It seems the issues that arrive today about Silverlight and HTML5 largely stem from fear and hope.  We as technologists are always trying to push the bleeding edge. We are always trying to make the right technology bets and predictions, and therefore argue vehemently for our choice to help validate it and promote the adoption we seek.  We all do it.  No one wants to make a mistake, and no self-respecting nerd wants to seem unsure about their craft.

There is doubt in both the HTML5 and Silverlight camps.  On the Silverlight side, adoption among the public is a bit lower than anticipated.  60-75% are the estimates I’ve seen so far.  On the business side, lack of Silverlight support on the iPhone, Android, and Blackberry have made Silverlight an impossible choice for current needs that involve these platforms—and a risky bet in the future if they will ever need to be supported.

On the HTML5 side of the fence, it isn’t about if HTML5 will happen, it is more about when and how standardized it will really be.  Those of us who lived through the pain of HTML4 and DHTML will forever remember the months of constantly finding things that didn’t work on this OS or in that browser version.  It seemed like projects never ended and support was perpetual, because it was impossible to test all the permutations of where the website would run.  Once again we are seeing this issue with HTML5, and it is uncertain if standardization will ever really happen.  We are several years away from an environment where more than 50% of the browsers on the Internet will be able to handle the majority of what is considered to be HTML5.  Companies must decide if they want to invest in technology now that the open Internet may not be able to leverage to its fullest for many years to come.

So, what do we do?  In my mind, neither solution is overly compelling.   Silverlight doesn’t really need any conditional code, and testing is straightforward. This gives you a high level of confidence that if it runs on your machine, it will run the same everywhere else…IF IT RUNS AT ALL.  Since it doesn’t run in the mobile browser platforms right now, the benefits of one-time-write and the lower development and testing costs that go with it are often a moot point.

On the HTML5 side, HTML is everywhere but it isn’t necessarily version 5 and probably can never be assumed to be version 5.  So many browsers in the world are over 10 years old, and web developers cringe when told they need to support these old browsers. HTML will always be available, but realistically, you may always need to build two “flavors” of your website/web application: one for new browsers and one for old.  Technology packages such as Modernizr will help to gracefully downgrade the site so it works with older browsers, which helps with development costs but not testing costs. Building applications today in HTML5 means making applications for a very small percentage of browsers that support HTML5.  For everything else, you are actually building web sites for the same set of browsers you have been targeting for years.  If you had to place a value of HTML5 for your development today, I think you would say the value really is marginal, and won’t be realized for years to come.  HTML is the right way to build applications that must cross all platforms, but how much of that is really HTML5?

To this point in this article, I hope I have been fairly neutral, expressing the strengths and weakness of both platforms, but let me now express some pro-Silverlight opinions as I am often impelled to do.  Silverlight went from Beta 2 (the first widely usable version) to Beta 5 in 3 years.  3 YEARS!  It is now a wonderfully complete platform that offers amazing power with beautiful user experiences.  It already far exceeds the functionality promised in the future for HTML5.  Have any other development platforms advanced so far, so quickly?  Do you really want to bet against a software platform like this?  Those that say HTML5 can do everything Silverlight can do really don’t know much about Silverlight.  HTML5 is full of promises that change monthly as the big players fight over its implementation, including Google’s new stance on H264 video support.

No one disputes that it will be a few years before the standard is truly standardized across each of the modern browsers…and probably at least 5 years after that before the majority of the public Internet users have HTML5 capabilities on their computers.  HTML 5 has a ton of optimism.  We are all very hopeful for the future of the technology, but no one has any illusion that the road to get there will be a long and likely painful path.  Optimism about HTML5 is clearly winning in the public mind.  On the other hand, there is much pessimism surrounding Silverlight.  In my opinion it is largely because Microsoft is not making promises about the future, like the HTML5 community is making.  But really, the promise of HTML5 is more than double the number of years away than Silverlight’s entire delivery to date.  Microsoft continues to invest heavily in Silverlight, blessing it as the preferred platform for distributed desktop-like applications.  It is impossible to say what Silverlight might be by the time HTML5 is “ready.”  I for one am not yet ready to proclaim HTML5 the “winner” based on promises and doubts.  Silverlight will never be the best solution for every web need, nor should it be.  But I believe there will always be a place on the Internet for Silverlight, and the places for its application will grow in the coming years, not shrink.