• Article

April 2015

Volume 30 Number 4

Modern Apps - A Mobile-First Approach to Modern App Development

By Rachel Appel | April 2015

Rachel AppelAt this very moment, millions of mobile devices are accessing millions of Web sites and mobile apps. According to Pew Research and other statisticians, more than 55 percent of Americans use a smartphone to access the Internet, and 30 percent of Americans use only a phone to access the Internet. These numbers are growing, as phones become cheaper and easier to use. If you can read the writing on the wall, you know you should be going with a mobile-first design.

Users can have the best experience on all devices—from desktops to phones—when a Web site or app is designed with mobility first. It’s difficult to scale down from a large screen to a tiny one. The UI just doesn’t work. Look no further than the Microsoft Windows Mobile 6.5 OS (not to be confused with Windows Phone) as a primary example of a shrunken and barely usable desktop UI.

However, you can scale up from a phone to a desktop without tossing usability out the window. You can add features to the experience as you scale up, making the UI transitions smooth. This technique is called progressive enhancement. Both Web sites and apps benefit from this type of mobile-first development strategy.

Mobile-First Means Responsive Design

Adjusting content to fit various screen sizes is the primary requirement for multi-device modern apps. You have to take one of two approaches. You could design two versions of software; one for desktop and larger computers and one for smaller form factors. Your other option is to design the software to adjust the UI in response to the device upon which it’s being used.

You’ll be dealing with many different types of devices. Some you may be wearing and some may be at your side. You may soon end up considering Internet of Things (IoT) devices as part of the design requirements for app development. IoT devices like the Fitbit or Microsoft Band are both wearable devices that track the user’s activities.

Other examples of IoT devices include the smart thermostat (such as the Nest), a smart door lock or the software in a new vehicle. Many IoT devices work in tandem with a mobile-first Web site or app, such as a smart coffee maker. As computers become smaller and cheaper, more IoT devices will flood the market with more ways to use them.

Going mobile-first also means considering the implications of the platform. Native apps have different development, architecture and sometimes business requirements than Web applications. Here are some design considerations for a mobile-first app:

  • Responsive UI
  • Navigation
  • Lists and grids of items, and content formatting
  • Storage, including offline storage
  • Supporting touch, pen or alternative input
  • Managing resources and performance

I’ll consider these in more detail. Web sites, hybrid and single-page architecture (SPA) apps use CSS to implement responsive design. XAML apps and apps on Android or iOS platforms have different, proprietary ways to create a responsive UI. For example, XAML uses an object called Resources that contains style information. You can apply resources to XAML controls to automatically render in a favorable and responsive way according to the device screen size.

In HTML apps (either Web or native such as Windows Library for JavaScript [WinJS]), you can use CSS to define styles and aesthetics. CSS uses the notion of a media query to create a responsive UI. Media queries are CSS rules that respond to different media types. These media types represent differing screen sizes, print or TV, braille, screen orientation and other features. When you create a media query, you specify the CSS rules for that device’s supported features, as shown in the following code:

@media only screen and (min-device-width : 320px) and (max-device-width : 480px) {
/* style rules */
}
@media only screen and (min-width : 321px) {
/* style rules */
}
@media only screen and (max-width : 320px) {
/* style rules */
}
@media only screen and (min-device-width : 768px) and (max-device-width : 1024px) {
/* style rules */
}
@media only screen  and (min-width : 1224px) {
/* style rules */
}

The CSS here works for smartphones in both portrait and landscape modes, and iPads in both portrait and landscape modes, and, finally, larger devices such as laptops or desktops. To read more about using CSS for native Windows apps, see “Build a Responsive and Modern UI with CSS for WinJS Apps” at msdn.microsoft.com/magazine/dn451447.

For good, responsive, mobile-first design, don’t target specific device types in your code. You’ll never be able to keep up with the dozens available. Always target a range of screen sizes. For example, you might wish to target 3- to 4-inch devices, 5- to 8-inch devices, 10- to 13-inch tablets, and greater-than-13-inches laptops and desktops. This way you can create a UI that works for the widest possible audience. Focus on just a few common phone sizes. This code will continue to be maintainable as time progresses and new devices come to market, because you’re already targeting them by size range.

An easy way to do this and design a project that scales from smartphone to desktop is to choose a Universal App project type in Visual Studio for Windows Store and Windows Phone. Universal Apps have all the code and structure in place to react to the different clients. You can use either XAML or HTML to build a Universal App. These apps share a significant portion of their code, so you get to reuse a lot of code. If you need a refresher on Universal Apps, check out “Build Universal Apps for the Windows Platform” (msdn.microsoft.com/magazine/dn781364).

Developers usually display data in tabular or list formats in Web sites and apps. Small lists on phones will work fine on larger screens, although there will be wasted space. A progressively enhanced UI will add and format more content as the screen size increases. It will do the reverse, as well—removing and reformatting the screen to display less content on smaller devices.

As you might expect, phone apps tend to show only the most important content, as smartphones are small and space is limited. Phone apps usually cut through the chaff. While there are ads, they’re small and normally located in the same places. Because there’s so much space on even the smallest of desktops, you’ll see ads and content that isn’t always relevant to the Web page topic. So when you add content, make it relevant and meaningful so it doesn’t get in the user’s way. The content you add could be sidebars about the content itself, relevant ads or even some quick links.

Mobile-First Navigation

Having an easy-to-use and straightforward navigation scheme is important. Navigation is one way to interact with the app itself. It’s also a way to access the desired content. Every app has navigation; unfortunately, a number of apps have poor navigation.

Native desktop software, such as Windows Forms, tends to use traditional cascading menus as navigation. Web sites often do the same. In fact, Web sites often use awful JavaScript dropdown menus that require the precision of a surgeon. Fortunately, this practice is quickly fading. It’s obvious these types of menus simply don’t work on smartphones. What does work on smartphones are several specific navigation techniques:

  • Large tiles: Square or rectangle, much like Windows 8.
  • Touch-friendly lists: Rectangles that are both wide and tall enough for all finger and thumb sizes.
  • Swipeable tabs: These let users swipe in short horizontal motions, a great way to present a menu of options for a particular category or feature.
  • Docked App Bars: Options reside in a strip across the top or bottom of the screen. You can hide the app bar and show it when the user swipes to request it.

You can also use a combination of navigation techniques, such as swipeable tabs with a nice touch-friendly list of options. Often, these types of navigation menus are part of the content itself, such as a news app that lets you tap on the textual headline to read the article. Whichever you choose, make sure users can navigate backward, as well. A prominent back button works fine.

In Windows Store apps, the navigation paradigm uses the Windows grid system to display data, and lets the user click or tap to navigate to details about the current grid item. There’s also a prominent Back button, so the user can always back out of a series of navigation steps. Alternatively, apps can present an app bar full of navigational choices.

Data Storage and Offline Capabilities

It’s rare to find an app that wouldn’t benefit from some offline support. Even airline boarding passes airlines send as a hyperlink via text are simply Web pages that won’t display if you have no connectivity. A quality app must support offline capabilities.

Many apps don’t store content locally. They call a Web service, or make a remote call to retrieve data, and save the data remotely. Of course, there’s always a tiny bit of data you need to store locally, anyway, such as app or user settings and preferences. Store things that only make sense to store locally, such as the current location in an eReader or a game, or the app’s theme color.

Here’s where storage requirements differ depending on the platform you’re targeting. In HTML client apps, you can use Domain Object Model (DOM) Storage or IndexedDB. In native XAML apps, you can use local app settings or a StorageFile object.

  • DOM Storage (HTML5 local storage): This is a lightweight container for local data in HTML apps.
  • IndexedDB: This stores significant amounts of data locally. Use IndexedDB in HTML apps and store relational or BLOB data in key value pairs.
  • App Settings: Both XAML and HTML Windows Store and Windows Phone apps can access app settings data structures. The app can store data in these small objects. They usually contain settings such as log-in name, theme color or other settings.
  • Storage Files: These are good, old-fashioned files, but with an API for Windows Store and Windows Phone XAML or HTML apps.

You can save app settings in the read-only ApplicationDataContainer object. You would access this with the applicationData localSettings property. The following code retrieves the local and roaming app settings and their folders:

var localSettings = applicationData.localSettings;
var roamingFolder = applicationData.roamingFolder;
var roamingSettings = applicationData.roamingSettings;

Local settings, of course, are only locally available on the associ­ated device, whereas roaming settings can be accessed from multiple devices or locations. For more information on data storage in Windows Store apps, see “Data Access and Storage Options in Windows Store Apps” (msdn.microsoft.com/magazine/jj991982).

Mobile-First Architecture and Development

The important thing about going mobile-first is you actually ensure the software you’re creating works on mobile devices first. It’s easier to scale bigger than smaller when it comes to screens and UX. You can always add information as screen sizes increase.

Performance is extremely important to mobile users. People pay for expensive but often limited data plans. They don’t want to wait around, paying to download a Web page or app. If you thought the days are long gone where you have to manage and hoard every bit and byte, you are premature in your thinking. Managing memory and resources is a big deal in mobile development.

Today’s phones and IoT devices are at comparable levels of technological proficiency to their larger desktop counterparts of the past. Many IoT devices still have less than 1GB of RAM, even as storage capacities grow to astronomical levels. Let’s not forget about the battery life, either. Users will dump your app fast if it drains the battery. And you want to use as much of the same code base as possible across platforms. Mobile-first approaches work for both Web sites and apps. Remember, it’s not just about screen size.

As part of a mobile-first architecture, first determine what kind of mobile app you’ll be producing. Is it a mobile Web site? Perhaps it’s a native app. How many platforms must you support? If you have an existing mobilized Web site and want to get into an app store quickly, maybe hybrid is the way to go.

If you need help deciding which to choose, read “Mobile Web Sites vs. Native Apps vs. Hybrid Apps” at msdn.microsoft.com/magazine/dn818502. Once you have a clear vision of what to build, the next step is to illustrate the architecture of the app. For more details about how to plan for your mobile Web site or app, check out my column, “Design a Cross-Platform Modern App Architecture,” at msdn.microsoft.com/magazine/dn683800.

Independent developers who target app stores think in terms of mobile-first. Their deployment targets are most often one or more app stores. Enterprise developers tend to deploy to a location on their internal network or perhaps in their private cloud.

In enterprise development, JavaScript has gained a lot of traction. Developers are even running it on the server. Right now, it’s quite possibly the most popular in the world. Like it or not, developers use JavaScript as the easiest way to deliver cross-platform software in the form of a Web app. Even enterprise developers are using more JavaScript to enhance business app UIs. This is especially true with the advent of the Bring Your Own Device (BYOD) movement in the enterprise, as workers cart their iPads, Surfaces and smartphones into workplaces everywhere.

If you’re writing enterprise JavaScript or SPA apps, you might consider using TypeScript. TypeScript has implemented all the ECMAScript 6 requirements for which developers are patiently waiting, such as inheritance, as well as a set of types, object orientation and other features that help you generate better code, file and project organization. It’s a good idea to familiarize yourself with both UI design patterns and development patterns. They both aid in a more organized project structure. Before using TypeScript in your enterprise JavaScript projects, see “Use TypeScript in Modern Apps” at msdn.microsoft.com/magazine/dn201754.

Wrapping Up

The most important takeaway here is building software with mobile-first in mind will make it easier to scale bigger. Progressively designed UIs often mean a more modular architecture. This inherently makes code easier to maintain and add new features. Also, users certainly appreciate a sleek and well-designed UI. A mobile-­first strategy forces you to focus on the most important data and features. These same features are what make for high ratings and add more sales in app stores.

Rachel Appel is a consultant, author, mentor and former Microsoft employee with more than 20 years of experience in the IT industry. She speaks at top industry conferences such as Visual Studio Live!, DevConnections, Mix and more. Her expertise lies within developing solutions that align business and technology focusing on the Microsoft dev stack and open Web. For more about Appel, visit her Web site at rachelappel.com.

Thanks to the following Microsoft technical expert for reviewing this article: Frank La Vigne