Tag Archives: apple

Adventures with PhoneGap

Posted by on 21 May 2010 16:15 9 comments

Palm Pre, Motorola DROID, iPod TouchI’ve been working with PhoneGap this week to create a simple geolocation app. It’s a framework for creating mobile applications in HTML, JavaScript, and CSS that will run on all the major platforms. You write your application and reference the APIs that PhoneGap provides. Then you simply drop your HTML and JavaScript into the various platform-specific template projects they provide and compile it with the platform’s native compiler. Simple as that.

But the devil is in the details. Every platform and device has subtle differences that make cross-platform development painful. There are even differences between how an emulator and a device run the application.

I’ve been testing on three platforms: webOS (Palm Pre Plus), Android (Motorola DROID with Android 2.1), and iPhone OS 3 (iPod Touch).

Here are a few of my frustrating findings:

Notification: alert, beep, vibrate

First off, webOS doesn’t support the alert() command at all. Android and iPhone do, in the typical fashion.

Beeping is fine on the devices themselves (the Motorola DROID even says “Droid” when you call that function). But the Android SDK emulator kills my app when I call it.

Vibration works on Android. I assume it also works on the iPhone, but I only have an iPod Touch at the moment, and it doesn’t have a vibrator in the first place. The Palm Pre won’t vibrate unless the package name begins with com.palm. Obviously for testing purposes it would be fine to label your app as coming from Palm, Inc. itself, but that won’t fly if you want to distribute the app. So no vibration on webOS. And can you guess what the iPhone simulator does with the vibrate() command? It makes the app hang. Go figure.

Moral of the story: Alert, beep, and vibrate won’t work reliably if you need to support every platform and don’t want your code to break in an emulator.

Location services

The webOS and iPhone simulators both show their location as the headquarters of their respective companies (Sunnyvale or Cupertino). The Android simulator doesn’t even provide location data, so it’s utterly useless for testing in that regard.

My Palm Pre Plus (running on Verizon) can get its location relatively accurately when I’m running it on 3G (even inside my office). Not so if I’m on the WiFi. If I get a fix at all, it’ll take a long time and may be quite inaccurate. (Note that this is the behavior I get everywhere in webOS, not just with PhoneGap.)

The iPod inexplicably thinks it’s in Lilburn, Georgia. For comparison, I’m in Provo, Utah. Only 1,927 miles off. Google Maps on the iPod gets the correct location, but not PhoneGap.

The worst of my problems, though, is the Motorola DROID. More than half the time, my app can’t find its location. It doesn’t matter whether I’m on 3G or WiFi, inside the office or out on ground level. When I compile and run the app immediately after I’ve changed something, it usually seems to get a location fix. But when I subsequently run the app (whether connected to the debugger or not), it fails to get the location. I’ve tried it on two different DROIDs and they both exhibit the same behavior. Google Maps and turn-by-turn navigation work perfectly–they find the location and track it reliably. But something between the phone’s GPS and the PhoneGap library is getting screwed up.

Device UUID

webOS and iPhone OS both return a useful UUID on the device.uuid property. However, Android (both on the emulator and on the DROID) returns simply the unhelpful “undefined.” My app needs to be able to identify users by the UUID of their device, which simply doesn’t work on the Android.

UPDATE: Android 2.2 (Froyo) returns a UUID as you would expect. Only problem is that hardly anyone has it as of now (July 2010), and a lot of older mainstream handsets won’t be getting it at all.

HTML Select boxes

This one really ought not to be a problem. But webOS won’t let you tap on an HTML select box inside a PhoneGap application. It’ll display just fine, but you can’t make a selection. Select boxes work fine on normal web pages. iPhone and Android both support the select box perfectly, including the native OS skins. No dice with PhoneGap on the Palm Pre.

EDIT: Ryan from Nitobi is working on a solution for this on webOS. You can read about it on his blog.

UPDATE: Ryan has fixed this now. See his comment below for the updated files for your project.

Conclusion

So. After wrestling with all of these issues, what have I determined?

PhoneGap is a really slick framework, and it makes it very easy to create a mobile app that is “write once, run anywhere.” But the actual implementation details get hairy, and even fundamental operations like geolocation services and vibration are not implemented uniformly across all these devices.

Caveat emptor.

For those interested, I’ve posted a few questions about these issues on Stack Overflow:

Eliminating the hierarchy: GNOME Do and Google

Posted by on 7 September 2009 22:51 4 comments

This week I became acquainted with two applications: GNOME Do and Google Chrome.

GNOME Do is a program similar in concept to the Mac Spotlight. Although not quite as simple as Spotlight, it still allows you to find files, launch programs, and even search Gmail contacts.

GNOME Do and Spotlight both illustrate a concept Alan Cooper addresses in The Inmates Are Running the Asylum. (See my recent post on this book.) Cooper suggests how incredibly confusing hierarchial filesystems can be to users (see, e.g., pp. 9-11). Humans don’t think of file storage in a hierarchial way. When you’re writing something on a pad of paper, you might tear the sheet off and leave it on your desk. Or you might put it in your file drawer. That physical drawer has an advantage over a computer’s filesystem–it is much easier to see and comprehend the whole thing at once. You open the drawer and see all the folders inside it all together.

Now imagine your computer’s filesystem. You just wrote something on your virtual pad of paper. You “tear off” the page and want to put it somewhere. You click Save As…, and it opens to your usual My Documents folder. You put the file there and forget about it.

That isn’t so hard to deal with until you have to dig into the hierarchy of your hard drive. Imagine that you want to locate a file you worked on six months ago. It was a poster for the company barbeque you had in the spring, and you need it again. But where in the world did you put it? How are you going to find it now?

You could start clicking through all the folders on the hard drive until you find it. Or you could use a tool that eliminates the need to comprehend the hierarchial file structure in the first place, such as GNOME Do or Spotlight. Or the Windows search, if that’s the best you’ve got….

Those programs will let you search the file name or (more understandable for a human user) the full text of the file. Once it finds possibilities, you’ll still probably have to wade through a disorganized list to find the actual file. But at least you didn’t have to click through a hundred folders to get to it.

Google does a good job of implementing non-hierarchial file systems in their web apps, such as Gmail and Docs. You simply have lists of things, which you can further organize them with labels (and even use the labels as a sort of file-folder system if you really want to). And full-text searching is a standard, simple necessity.

Google Chrome also does an excellent job eliminating the hierarchy from the web browser: it has very few menus; your address bar, history, and web searching are all in the same box; you open a new tab and see a list of your most frequently-visited sites. No searching through menus of bookmarks or a confusing history pane. Just type in a keyword and it finds it for you.

After all, the computer knows where everything is anyway. Why not make it find things for you?

Inmates

Posted by on 4 September 2009 20:45 No comments

I’m in the process of reading Alan Cooper’s delightful book The Inmates Are Running the Asylum. Cooper discusses the reason computer software is often so difficult to use. His main thesis: when programmers design software, they do it in a way that fits how the computer operates, not necessarily how a human being operates. It makes sense to them, but not to the average end user. This makes clear the need for so-called interaction design, as opposed to interface design. In order to be truly effective, this must be done by dedicated interaction designers, not by the programmers. The reason for this lies in the simple difference of how programmers think about problems and how normal people think about things. (Being a programmer myself, I can tell you that programmers really do have a different way of seeing the world. That view often doesn’t mesh with how normal people see the world.)

Cooper’s book dates from 1999. Things have changed in the realm of software interaction design since then. But he notes trends of the day that are still obvious in current software development. In chapter 5, for example, he discusses the concept of customer loyalty. He argues that Microsoft’s Bill Gates had tremendous business prowess and, as such, was able to get his company’s products to sell, imperfect or unpleasant to use as they may have been. People bought his things because they provided solutions for the problems they faced. They were driven by “economic necessity,” as Cooper puts it (p. 75). But as soon as something better comes along, the customers’ disloyalty will become apparent. They will be willing to switch to those better products without suffering withdrawl from their emotional attachment to Microsoft. Apple, on the other hand, has always had an eye for design. Their products were and still are attractive, and Apple has an incredibly loyal consumer base. Just think: how many people do you know who sport an article of clothing, bumper sticker, mug, or other object advertising Apple to the world? And how many people have you seen with similar products from Microsoft?

I believe that companies like Apple and Google have done much to drive innovation in the field of interaction design. Just think of the iPhone. How many smart phones have been developed in the last two years that look or act like the iPhone? A staggering number. But who thought of having such an intuitive, tactile touch screen before Apple did? And what mainstream email program is there that groups communications into threads besides Gmail? (If there really is one, please correct me.)

It’s issues like these that Cooper addresses in his book. I would highly recommend it to anyone desiring to improve the usability of their software. His current consulting company also has a blog discussing these topics.

Usability, the iPhone, and Fitt’s law

Posted by on 5 July 2007 16:25 Comments Off

I just read a great iPhone usability review on the Humanized Weblog. Interface design interests me, and Humanized has a ton of really cool ideas for creating humane, usable, intuitive interfaces.

Also on the post was a discussion on Fitt’s law and the way Apple designed multi-level lists on the system. I found a link on the Wikipedia article to a Microsoft blog discussing the implications of Fitt’s law in interface design for Windows and Microsoft Office.

Very interesting reads.