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.

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 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.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at

comments powered by Disqus


  • Creating Reactive Applications in .NET

    In modern applications, data is being retrieved in asynchronous, real-time streams, as traditional pull requests where the clients asks for data from the server are becoming a thing of the past.

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

  • .NET 9 Preview 3: 'I've Been Waiting 9 Years for This API!'

    Microsoft's third preview of .NET 9 sees a lot of minor tweaks and fixes with no earth-shaking new functionality, but little things can be important to individual developers.

  • Data Anomaly Detection Using a Neural Autoencoder with C#

    Dr. James McCaffrey of Microsoft Research tackles the process of examining a set of source data to find data items that are different in some way from the majority of the source items.

Subscribe on YouTube