Making Mobile Applications Alternate-Device Aware

It’s not just a desktop world any more. Now your application may have to run on notebooks, tablets, and smartphones. While mobile targets may not be in the original requirements specification, you’ll save yourself time and trouble when you have that software run on, or work with, alternate devices. At the very least, you can avoid erecting brick walls to keep such devices from working. Here’s some design issues you can incorporate now, even if the mobile app is slated for a later iteration.

If mobile isn’t part of the written specification for your project, it probably will be in the next iteration. How much trouble you have in that later iteration depends on large part on what you do in the software design now.

The trick is to design and develop your software so you don’t dig yourself into a hole when the time comes to turn the application into a mobile one. And, unfortunately, that hole can be an elephant trap.

It’s a truism that mobile devices are different. However, most developers who haven’t ventured into the Mobile Morass don’t understand just how different. And even a lot of those who have gone into mobile territory haven’t really figured it out yet. They’re too busy digging themselves out of elephant traps.

Take the most obvious difference between mobile and desktop applications. Of course you can see that screen resolutions are vastly different just by looking at the device. What is less obvious is that there isn’t just adifferent resolution for smart phones; there are dozens of them.

According to Mike Donahue, a Web/UX Designer for Jarden Consumer Solutions, based in Boca Raton, Florida, there are something like 4,000 different screen resolutions in use on devices today.

What is worse, he says, is that none of those screen resolutions are dominant, either in terms of categories, or in terms of devices within categories. “There is no major player,” he says. “The biggest market share is something like 11% or 12%. It’s not like the old days when Internet Explorer in various versions had 60% to 80% of the market share.”

And of course, the tide of innovation in mobile devices still sweeps forward, bringing new devices with new screen resolutions to the market.

This isn’t just a matter of screen size. There are many other different issues with designing for mobile devices, from processors to operating systems to the way the devices are used.

Plus, people use mobile applications in different environments. A mobile user may be less involved with the application and may well be multitasking in a distraction-rich environment such as outdoors or three stories up on a steel beam.

Finally, data entry is different. Typically a mobile user needs one hand to hold the device and (in the case of a smartphone) enters the data with one thumb.

Separation Is Vital

This leaves developers with three options. They can:

A) Design their application for only a small fraction of the devices on the marketB) Go crazy trying to design for everything, orC) Rigidly separate the data and business logic from the presentation layer, and include at least one more layer to mediate between the two.

Since A is not going to win favor with the marketing department (except on custom applications), and most developers want to hang on to what shreds of sanity they have left, that leaves C.

“You’re going to have to separate your concerns,” says Chris Maunder, co-founder of CodeProject, an open source development community. “If you’re writing business code you have to separate it so your presentation layer and business layer are completely separate,” he says. “Otherwise that’s a big hole.” In addition, Maunder says, you need an interface layer between the two to take care of selecting the appropriate presentation layer.

“If you have combined the logic (of presentation) then you’ve put yourself in a major predicament,” says Alex Moazed, president of Applicor, a New York City company that specializes in mobile applications. “You can’t scale up and you can’t scale down because all the parts are independent of each other.”

How big a hole this can be was something CodeProject discovered when they tried to adapt older code to the mobile world.

“CodeProject has some code written 10 years ago that’s running as an underlayer under our applications,” Maunder says. They’d like to have offline caching to speed up presentation to the device. But, the team found, “Unfortunately the data layer feeds directly into the web page.”

“So this creates a nice big hole,” Maunder says. “The request goes to the webpage and the flow is really tailored toward that specific application. We’re kind of screwed because one piece of code doesn’t control how the view is presented.”

One method that has been developed to deal with this sort of situation is Responsive Design: that is, designing the user interface with a multitude of resolutions and other characteristics in mind from the ground up and letting the middle layer choose which version to present to the display.

An extreme version is “Mobile-First Design.” The user interface (UI) design starts with the smallest screen and works upward. “That forces you to consider everything you’re putting on there,” Donahue says. “It helps you prioritize your planning. As you get more screen size, you add more elements. You’re delivering based on the capacity of the screen size.”

Donahue hastens to add that this doesn’t mean designing bare-bones layouts to all screens. “You can build up and rely on elements to make a beautiful user experience.”

The trick here, Donahue says, is to design the user interface so only the content that will actually be displayed is downloaded. Some designers download everything and then decide what to display, which slows down performance to no purpose.

A closely related technique is adaptive design, where the layouts are broken into chunks and only the parts appropriate for the device in use are downloaded. Those don’t have to be the same chunks, particularly in the case of images. Smaller, simpler elements can be used on smaller screens.

Moazed cites an application that displays a list of locations and a map. On a netbook both the map and the list fit on the same screen. “What you can now do is not put the same graphic on the screen,” he says. On a smartphone you just display the map view on the screen. “It’s like pieces of a pie; you can mix and match them,” Moazed says. “You break down the user interfaces into different sections of functionality.” This makes it easy to shrink or expand the application’s display to fit the screen size you’re working with.

“What we can do is display three different blurbs on a desktop home page, on a tablet two, and on a phone one. We want the code base to work across all these different form factors,” Moazed says.

To deal with the problem of the huge number of different screen formats, Donahue advises grouping screen sizes by families. Write the user displays in terms of families rather than trying to match each individual device’s screen.

Do You Really Want To Do This?

Sometimes you don’t want to retrofit a desktop or Web application to a mobile platform. There are so many differences that some experts recommend not trying to convert non-consumer apps at all. Instead, they say, you should just start over. This is especially true with custom-written business applications which only need to support one, or a small number of, mobile devices.

“I believe strongly that apps for people who use mobile apps for their daily work, where the app is used constantly, need apps that are written to reflect their work flow,” says Mary Brittain-White, CEO of Retriver Communications, a mobile application developer headquartered in Australia. “You can’t just pick up something that’s used in the office.”

Even if it is technically possible to translate the application, Brittain-White says, “The (applications) don’t suit the that people [who] work with mobile applications.”

“In mobile it’s all about the end user,” Brittain-White says. “IT forgets that and has done so for some time.” Mobile software only gets used if people find it easy, she asserts.

Still, recreating an application from the ground up for mobile devices is a lot of work and money. Most companies prefer to adapt what they have – as much as they can.