Practical .NET

Redefining Mobile UIs with ASP.NET

Because the mobile platform has come later in the history of computing, developers have gotten in the habit of redesigning desktop applications for the handheld device. Peter Vogel thinks developers have that backward, and that the UI design process shows the way out.

• By Peter Vogel
• 03/14/2013

In an earlier column, I discussed how important personas are as the first step in the UI design process. Once you've defined your personas, the next step in the UI design process is to define how those personas will use your application's UI. That step is based on developing what are called "user stories" -- descriptions of how specific personas interact with your application's UI.

But, in addition to talking about how user stories work, I also want to show how user stories provide a way to design Web sites so that they'll work for both the big screen (desktop computers and tablets) and the small screen (smartphones and tablets). Bad news: It's going to take me two columns to do this, and there's some homework involved. This problem is usually associated with the question, "How do I port my existing `big screen' Web site to the `small screen?'" I think that question is the wrong way around, and user stories will demonstrate that.

Rethinking the Problem
ASP.NET MVC has a solution for moving big-screen sites to the small screen. In ASP.NET MVC you can make a copy of your views and incorporate the string ".mobile." into the new view's name (for example, Customers.cshtml becomes Customers.mobile.cshtml). When an ASP.NET MVC site is accessed from a mobile device, the version of the view marked as "mobile" is sent.

For this solution to make sense, there are two related assumptions required. The first assumption is that addressing the mobile experience consists of changes to the view only (for instance, removing some content, moving to a vertical rather than horizontal layout, and rewriting the JavaScript in the view to use jQuery Mobile). We're assuming that the controller used by the big-screen version can work with the small-screen version of the view with a few modifications. The related assumption is that the workflows of small-screen users are the same as those of big-screen users.

I think those might actually be reasonable assumptions -- but only for applications with the simplest of UIs (and by "simple" I'm thinking of the Google textbox). But if you come at the problem as "repurposing the small screen for the big screen," I think this strategy could work. You don't have to build two completely different Web sites or even two completely different sets of views. User stories demonstrate that.

This solution, of course, isn't useful for existing sites, but it can provide a way forward for new sites. This strategy should work in both ASP.NET and ASP.NET MVC (in fact, I suspect it would be easier with ASP.NET user controls than with ASP.NET MVC partial views).

To demonstrate that, next month, I'll look at the big-screen and small-screen UI user stories for a mapping application. I know: I should pick an application that you'll actually build at work rather than pick some exotic commercial application. I'm going to use this example because it allows me to talk about an application that we're all familiar with -- using a real business application would involve too many organization-dependent variables when generating user stories.

The first step, before talking about any user stories, is to define the persona for this UI case study: Pat, a 30-ish mother of two primary school children, living in a major urban center, married, and part of a family with a joint income of $75,000 to $100,000 (a real persona would fill in more details).

And here's your homework: Look at how you use mapping packages on your big and small screens. Based on what you learn, think about how Pat would use a mapping application. (Would she use it just like you? Differently?) In my next column, I'll give you my answers and talk about how this might provide a way to build big-screen sites from small-screen sites.