Mitigate Mobile Cross-platform Headaches

Android is now the most widely used mobile operating system in both the Unites States  and the world , according to the research firms Canalys and Nielsen. But behind that news lurk a lot of headaches for enterprise developers.

For example, 36 percent of U.S. smartphones run Android. So unless an enterprise is comfortable alienating 2 out of every 3 employees or customers, its developers have to create apps for at least iOS, BlackBerry or Windows Mobile. If that enterprise is multinational, then its developers can add Symbian to their to-do list.

“We have European customers that say: ‘We know Symbian is going to die. It might take five years, but in the meantime, a large percentage of our workers have Symbian phones,’” says Adam Blum, CEO of Rhomobile, which provides development tools.

If that weren’t enough work for developers, there’s also fragmentation within some operating systems. For example, each Android smartphone vendor often has a unique implementation of the OS, while differences in screen size and resolution create additional variables that affect an app’s user experience.

Web or Native?

Some developers sidestep fragmentation by using “Web services” or “Web apps,” which consists of taking the phone’s browser and stripping off the user interface so it appears to be an app. One drawback is that the browser isn’t always able to access phone hardware, such as the GPS radio or accelerometer, thus limiting what this pseudo app can do.

“This is a very valid approach if you do not need to do anything fancy,” says Vince Chavy, product management director at RADVISION, a videoconferencing vendor whose portfolio includes endpoint apps that run on Android and iOS devices. “It is easy, and it is quite amazing what you can do with HTML5 and CSS nowadays.”

Some enterprises like Web apps because they leverage their developers’ existing skills. “What we always hear is, ‘Because my developers have Web skills, you get all that productivity and affordability across all phones,’” says Blum.

The alternative is a “native app,” whose benefits include better performance because the software doesn’t have to pull everything from the Web. If the target audience is made up of customers rather than employees, then another benefit is that native apps can be distributed through app stores.

“You will be closer to the look and feel of the device,” says Chavy. “You are only limited by your imagination and the OS SDK APIs.”

Write Once, Run Many

The big downside to native apps is that code for one OS version can’t be reused to create other OS versions. The corollary to that requirement is that if the enterprise doesn’t have developers versed in all of the major codes, it has to find them, which increases costs and lead time. “You need a different code base for iOS and Android,” says Chavy. “You need to find Objective C developers for your IOS client and Java/Android developers for the Android client. Those are tough to find!”

Hence the growing selection of tools that enable cross-platform app development, such as MoSynch , PhoneGap  and Rhodes .

“You develop in C/C++,” says Henrik von Schoultz, MoSync co-founder and vice president of marketing and sales. “We will later also use other languages, like Java Script and Lua. The developer uses MoSync APIs, and at build time we use an intermediate language and have profiles for your target devices. We compile native to the OS you want to target.

“If a feature does not exist on an OS, the system tries to handle that. For example, if the target device doesn’t have GPS, you may use positioning from the cell towers.”

So how much time could a developer reasonably expect to save by using MoSync versus developing from scratch for each OS? It depends, but in one case, a developer went from Symbian to Android in about four hours . “If you have an app with loads of logic and not so much UI, you can save up to 80 percent,” says von Schoultz. “But if it’s a very UI-intense app, you may save maybe 30 percent.”

PhoneGap, meanwhile, emphasizes the importance of having both apps and a mobile-friendly website.

“They can use largely the same code in their mobile website as their native app in PhoneGap because we’re just running HTML and Java Script right there,” says Andre Charland, president and co-founder of Nitobi, PhoneGap’s creator. “We’re compliant with W3C APIs. You’re also future-proofing your app because as the mobile browsers evolve, you can take your PhoneGap applications and push more of that into the browser, while still augmenting the native app experience with native code via plug-ins from PhoneGap.”

One Size Doesn’t Fit All

Tablets and smartphones come in an ever-increasing range of screen sizes and resolutions. As a result, developers also have to ensure that their app looks and works just as well on a 3.5-inch display as a 4.3-inch display, or on both an Android phone and an Android tablet.

“The first decision is if you want the same GUI on the phone and on the tablet,” says Chavy. “Some developers decide to have the same UX. In that case, they just make sure that when they design the GUI, it can resize nicely by deciding on which area resizes and by setting proper anchors on the objects.

The catch is that consumers and business users increasingly expect tablet apps to take advantage of the extra screen space.

“For example, in our SCOPIA Mobile application, on the phone, you can see the video or the presentation, and not both at the same time,” says Chavy. “On the tablet, since you have a bigger screen, we have layouts with both the video and the presentation.”

Need more details about mobile cross-platform development tools? Check out this article on Mashable.

Nice Gesture, But What Does It Mean?

One step forward, two steps back. That’s how Don Norman describes today’s gesture-based user interfaces (UIs) for smartphones, tablets and a growing assortment of other devices.

Named one of the world’s 27 most influential designers by Business Week, Norman laments the lack of standards, which have created a world where a finger-swipe on one device often doesn’t have the same effect on another. That inconsistency often makes using gesture-based UIs as much fun as folding a fitted sheet. Norman recently spoke to us about this and more from South Korea, where he’s distinguished visiting professor in the Korea Advanced Institute of Science and Technology’s Department of Industrial Design.

Q: Your colleagues from the Nielsen Norman Group recently did usability tests on Apple’s iPad: “The first crop of iPad apps revived memories of Web designs from 1993, when Mosaic first introduced the image map that made it possible for any part of any picture to become a UI element. As a result, graphic designers went wild -- anything they could draw could be a UI, whether it made sense or not. It’s the same with iPad apps -- anything you can show and touch can be a UI on this device. There are no standards and no expectations.” Yet tablet and smartphone sales remain brisk.

A: It’s confusing and difficult for people. On the other hand, it’s so engaging and so much fun, that it in many ways compensates for its difficulties.

I’m about to give a series of talks about the way the field has evolved. In the beginning, we were so delighted with the technology. With the passage of time, we’ve come to take understandability, usability and function for granted. What we want now is a good experience, some fun and delight.

That’s where Apple has transformed itself as a company. It really is about experience, fun, delight and entertainment. That’s what the iPhone did: By this whole new way of interacting with strokes and gestures, it was so delightful and different.

Q: In “Gestural Interfaces: A Step Backwards in Usability,” you and Jakob Nielsen identified two root causes for gesture UI inconsistencies: a lack of industry guidelines and “the misguided insistence by companies (e.g., Apple and Google) to ignore established conventions and establish ill-conceived new ones.” Will we ever have standards for gesture UIs?

A: There will be gestures that Apple will patent and refuse to let Microsoft and Google use. All of the companies will have competing methods that will just confuse the hell out of people. But we had that in the beginning of computers too.

When I was at Apple as vice president of the Advanced Technology Group in the ’90s, I was fighting hard for standards. We had this wonderful meeting, and we got all of the major companies together to argue for standards: Sun, IBM, Apple. Microsoft walks in and says, “This meeting is unnecessary. If you want standards, just use Microsoft’s.” That’s Apple’s attitude today.

Q: One downside of standards -- whether it’s a UI or a wireless technology -- is that they sometimes don’t leave companies with many opportunities for market differentiation, aside from price.

A: Every Android phone basically looks the same. So how do you compete in a world like that, where if you really follow Google’s guidelines, you can’t distinguish LG from Samsung from HTC from Motorola? Nobody wants to compete on price. That’s death.

With early technologies, as people are learning, it’s understandable that we don’t have standards and that sometimes different applications don’t follow the same rules. Jakob and I wrote our joint piece to be critical yet friendly, to say that we thought gestures and the new interfaces were exciting, powerful, adding a lot to our experience, and that this early confusion can be overcome. This confusion is compounded by the lack of differentiation among the vendors, who are desperate to do anything different, and the companies don’t wish to cooperate.

Q: For now, consumers and business users seem to be willing to put up with those inconsistencies, judging by how many iOS and Android apps and devices there are. How long before the gee-whiz wears off and they start to complain that app and device UIs aren’t as user-friendly as they could or should be?

A: It’s starting to wear off already. When the iPad came out, people just swooned over it. Now you’re starting to see articles, sometimes by the same journalists, saying, “You know, it’s got a lot of weaknesses. You can’t really type on it.” I think it’s becoming more realistic that the pad is not a substitute for a computer. It’s a wonderful device, but for its own purpose: You can read on the couch or answer a quick question. That’s a reality that wasn’t there at first.

Q: You and Jakob also bemoaned the lack of “Undo” in today’s gesture UIs. That absence is surprising, considering that PCs have conditioned us to expect it, and it’s useful.

A: I think because it comes a little out of the browser world, where the theory is that the “Back” button is the “Undo.” But it isn’t, not when you type something. On top of that, “Back” has always been very confusing. You’re never sure what’s going to happen when you hit “Back.”

I really hate this. There’s a stack of the previous locations, and “Back” takes you to the previous location. But I’m in some app, and I’m not sure where I am because it doesn’t tell me, and I want to get back to what I think is the home page. I hit “Back” and, whoops, I’m on the desktop.

It shouldn’t do that. You shouldn’t be able to back out of the application. In the browser, when you reach the end of its list, it doesn’t close the browser or take you to the desktop. It just dims the back button and doesn’t work anymore.

That’s what ought to happen when you hit “Back” in an application. I got really angry at one application developer. I kept saying, “Why are you doing this?” They explained that it wasn’t them, that the “Back” was programmed into the operating system.

Q: That means operating system companies have to provide a foundation that enables device vendors and app developers to make UIs more user-friendly.

A: Yes, it does. And they know that. That’s why Apple has usability guidelines. I’m not sure if Google does. There are people who have written them for Google.