Here’s Maxine’s original inquiry:

Hey Jonathan,

I know this might sound like a strange question, but, in your opinion, what are the names of a few mobile web apps worth talking about? ie, that are getting a bit of traction or press, or that are just plain good? Also – are there any sites that aggregate or review these? ie, iPhone apps people find out about via the app store, where would you find out about a mobile web app?

–
Maxine

And here’s my reply:

Hi Maxine -

All the mobile web apps that come to mind as the highest quality and most useful are from big name web players like Google, YouTube, Facebook, Twitter, Wikipedia, Flickr, and the like.

In terms of sites that aggregate web app listings, Apple’s directory is probably the best place:

http://www.apple.com/webapps/

But when I think about it, web app discovery seems somehow fundamentally different than native app discovery.

Personally, I tend to discover web apps as a side effect of using some other product or service. For example, at some point I visited the online banking site for Bank of America on my mobile phone and was delighted to discover that they had a mobile version available.

So the use case here is, “I’m trying to get something very specific accomplished.”

Conversely, the native app/app store model reminds me of the bad old days of VHS video tape rental. It was not uncommon for me to wander around a bricks and mortar video store for an hour on a Friday night looking for something I thought might strike my fancy.

Use case here is, “I’m bored and I want to watch a video, but I don’t know which one.”

What’s interesting to me about these two cases is that the first usually leaves me with a positive experience, and the second is very hit or miss; the need is vague (even I’m not sure what’s going to satisfy me) and I have to make a purchasing decision based on limited data (essentially, judging a book by its cover). The potential for “app buyer remorse” is particularly high in the iOS world because Apple doesn’t really allow returns.

Of course, this is just based on my personal behavior, which I know is not representative of the general public.

Best,
j

I’d be super interested to get your input on this because I know I’m not a typical case. If you have a sec, please leave a comment.

Long time fans of jQTouch will be happy to know that:

A) jQTouch will remain MIT licensed.

The gang at Sencha and I are in full agreement on this point – so much so that we wrote it into our contract.

B) jQTouch development is going to ramp back up.

It’s now literally my job to address bug reports, consider feature requests, and generally refactor code for jQTouch (this is my job? Somebody pinch me!).

Big thanks to Sencha for giving back to the mobile web community by supporting jQTouch development!

I have an unlocked Nexus One with an AT&T SIM card in it (the one from my iPhone). I followed these instructions to download and install an early version of Android 2.2 (Froyo).

There are a number of great improvements in 2.2, but the one that I’m most interested in is the portable Wi-Fi hotspot functionality that allows your other devices to access the internet by connecting to the Nexus One as a wireless router (like my Verizon MiFi, for which I’m paying $60 USD per month).

Some things I’ve noticed so far that seem to be true:

- Even though the AT&T card I’m using is supposedly only 2G when installed in a Nexus One, the performance is pretty good. Not as good as 3G Verizon Mifi, but acceptable for email, Twitter, web browsing, etc…

- I was able to connect five devices to the Nexus One simultaneously (MacBook Pro, Mac Mini, iPod Touch, iPhone, and iPad). I don’t know if there is a limit.

- The range is more than adequate. The signal from the Nexus One registers as full strength everywhere in my house (basement and two floors above ground). I had to leave the house and go halfway down the block (past all of my immediate neighbors houses) before my iPod Touch lost the signal from the Nexus One.

- You can’t have the Android phone connected to a wireless hotspot AND have wireless tethering enabled. IOW – the Android phone *has* to be connected to the internet over the cellular network for portable Wi-Fi hotspot functionality.

- There is no way on the Android phone to tell what devices are connected to it.

I began testing with the phone fully charged and unplugged. I’m going to continue testing unplugged to see if I can determine the effect on battery life.

Stay tuned!

P.S. If you have links to other test results, please post in the comments here.

NOTE: If you don’t yet have the Android SDK installed, follow the instructions in the video here:

http://jonathanstark.com/blog/2010/05/20/how-to-install-the-android-sdk/

NOTE: Once you’ve watched this video, you might want to watch “How To Create An Android Virtual Device”:

http://jonathanstark.com/blog/2010/05/21/how-to-create-an-android-virtual-device/

Is there an Android simulator that I can use to test my app pages?

There is. It’s included in the Android SDK.

You can download the SDK here:

http://developer.android.com/sdk/index.html

And the emulator instructions are here:

http://developer.android.com/guide/developing/tools/emulator.html

It’s actually somewhat complicated to set up because you have to first create one or more “Android Virtual Devices” that will emulate the hardware and software that you want to test against.

I’ll be doing some screencasts on this very topic this week, so subscribe to my feed or follow me on twitter if you want to be alerted.

Right now nobody’s interested in a mobile solution that does not contain the words “iPhone” and “app” and that is not submitted to a closed environment where it competes with approximately 2,437 similar mobile solutions.

His post goes on to assert that in many (most?) cases, the business needs of the customer would be better met with a web app than a native iPhone app:

I am convinced that the HTML5 app route is the best one for a fat slice of the non-game iPhone apps currently out there, especially those that are simple and face stiff competition. Increased interoperability will help them more than a relative lack of eye candy will hinder them.

I totally agree with this. Like PPK, I have observed in my clients a blind exuberance for iPhone apps and the iTunes App Store. In my experience, this desire for a native iPhone app is sometimes warranted because it would be infeasible to build the app using HTML, CSS, and JavaScript. However, in the vast majority of cases the apps that my clients want can be built better, faster, and cheaper using standard web technologies.

PPK – for whom I have a deep and abiding respect, btw – suggests that the solution to this issue is to popularize the phrase “HTML5 Apps” as a buzzword. I suspect his post is a bit tongue-in-cheek, but taken at face value this approach seems decidedly cynical to me because it’s predicated on the notion that clients are easily manipulated. In a word, simpletons.

I admit that my clients are typically not very knowledgeable when it comes to software development, mobile or otherwise. However, this does not make them simpletons, any more than my lack of knowledge about the inner workings of the FedEx delivery chain makes me a simpleton.

Clients are experts about their business, their customers, and their budget. They don’t know much about the inner workings of mobile apps, and they don’t need to – that’s why they hire people like me (thankfully!).

When a client comes to me wanting an “iPhone app,” my first step is to determine whether they are using the term “iPhone app” literally, or as a synonym for “mobile app.” It’s as simple as asking:

“Do you want your app to run just on iPhone, or other phones too?”

They almost always respond by saying that iPhone is important, but that it would be great if it ran on other phones as well.

NOTE: I have a bit of a bias here because I consult with large companies that have a very broad user base. As such, they always want the app to run on iPhone, Android, and Blackberry at a minimum.

Throughout the course of my initial discussions with a propective client, my primary goal is to learn why they want the app built, as opposed to what they want the app to do. Once I know why they want the app (i.e. their goal) I can make a judgement as to whether I can acheive that goal for them. If I believe that I can do it, I’ll write up a quote and we’re off to the races.

Here’s the thing – at no point do I feel compelled to discuss *how* I’m going to acheive the goal. Whether I build the app with HTML, CSS, and JavaScript, or Objective-C is irrelevent to the client. All they care about is that their goal is reached.

And yes, there are some exceptions. Sometimes I have a client who does understand the inner workings of mobile apps. In this case, I’m more than happy to invite them into the decision about what technologies should be used to build the app. We can get into the pros and cons of native apps, versus web apps, versus native web apps built with PhoneGap, etc… But again, clients don’t usually care about that sort of thing. They just want it to work.

Ultimately, I think that the distinction between web apps and native apps exists mostly in the minds of developers. To clients, they are all just mobile apps. My suggestion to mobile developers is to sidestep the issue completely by achieving your client’s goals using whatever tools you feel are right for the job.