Douglas Purdy

Dewitt Clinton (who I am running into more these days) posted an article (“People love Apps”) asserting that Web apps will be the dominant application model in the mobile space (as they have in the PC market).

There’s still a functionality gap right now, but there is no technical reason that mobile web apps won’t catch up. And when they do, all the advantages of being able to target multiple platforms with one codebase, all the advantages of sharing a single stack between desktop web and the mobile web, and all the advantages of HTML5 itself, will push the balance back in favor of the web.

Incidentally, the browser is already my most-used app on my Android device, but I may be an early adopter / leading indicator rather than the norm.)

Native mobile apps may be bigger and better than mobile web apps today, but they won’t be tomorrow.

Mark my words.

We’ve seen this all before.

I mostly agree with DeWitt; it is very difficult for native platforms to stay ahead of the “Web platform” (such as it is) over the long term.

But the operative phase in the above is “long term”…

One of the key factors at play between native and Web platforms is access to new hardware capabilities.

The Web platform catches up eventually (note all the mobile hardware device support in “HTML5″), but the native platform will always have “first mover advantage” to give developers access to these capabilities.

In short, the most innovative apps leveraging new hardware will be written to the native platform.

Of course, a device vendor could adopt the Web platform as their native platform (read WebOS), but apps written to this platform are not really a Web app as defined by Dewitt or as I would define it (Web app ~= works on > 1 OS && > 1 browser).

Also note, that you even see Palm creating a native platform layer for developers (mainly for games).

When Apple releases the iPhone 5 with the iNeuron connector kit, I envision the following sequence playing out:

1. Apple releases the “Cocoa Thought” framework that you can program in Objective-C
2. In 6-12 months, Apple will have Javascript/HTML extensions that work in Safari only
3. In N months, some of the other mobile browser vendors support a variant of #2
4. In N+24 months, the W3C, IETF or some other standards body agree on some variant of #3
5. The neuron interface is now part of the “Web platform”

Net:  Hardware matters.  Native apps will support new hardware sooner.  Ergo, native apps will continue to be important.

I do think that the most apps will be Web apps, but native apps are like waves cresting over that vast ocean.

Broadly, I don’t like to make negative statements about organizations or people.  In my experience, most organizations and people are well-intentioned, but simply prone to mistakes and errors in judgement.  Further, I may be the one making the mistake or error.  That said, if I have a particular bad experience, it is often good for me to write about it to get the foul taste out of my mouth and _hopefully_ someone responsible can read about it and fix it.

Once upon a time a developer went to a conference called Google I/O.

The first day was great, lots for conversations with smart folks.

On the second day, the developer realized that they forgot their badge at home during the 40 minute drive to the conference.

Not to worry or turn around, the developer thought. Just like all the conferences the developer had attended before, with proper ID they will surely let him in.

Arriving at the event, the developer walked to the help desk.

Developer: “Please help. I left my badge at home and I need a new one.”

Google: “Sorry, we cannot help you, our systems do not support printing two badges.”

The developer asked for someone else, and then someone else and then someone else.  Finally, the developer got to someone that seemed like they could make something happen.

Developer: “Who do you need to hear from in order to let me in the conference? If you got an email from [unnamed Google executive] would that do it?”

Google: “You can do whatever you like, we won’t help you.”

The developer was somewhat upset at this point. Not only did the “system limitation” make no technical sense, but Google seemed to forget that the developer spent money to attend the conference, that the developer likely talked to lots of other developers; they seemed to forget that customers, particularly developers matter.

The developer knew some Google folks at the I/O, so he sent some email and made a call.

The developer got a response quickly. This Google employee was helpful (you know who you are) and told the developer what might work to get him in the conference without driving for another 80 minutes.

The developer went back in the conference with this new information. The developer talked to one person and then another and then another — finally to reach someone that really worked for Google and had the authority to make something happen.

Developer: “I talked to [unnamed, but helpful Google employee].  They told me if I showed you my confirmation letter, you may be able to let me in the conference.”

Google: “Nope. He should know better. I am going to call him.”

Google goes off to call unnamed (but helpful) Google employee.  Google can’t get in touch with unnamed (but helpful) employee, comes back and says “Left him a voice mail, but I can’t print you a badge.”

Developer: “Why not?”

Google: “Our systems cannot print out two badges.”

Developer: “Ok. Write my name on a piece of paper and put it in the holder.”

Google: “No.”

Developer: “So, I need to drive back to Silicon Valley? Really?”

Google: “I have sent people back to Holland for forgetting their badges.”

The above line was said with pride. Really. Now, the developer suspected that it was said with the sort of pride one feels when they are trying to show their power in a conversation, not with the pride of being malicious toward someone intentionally, but that is a nuance thing.

Developer: “What if [unnamed Google executive] forgot their badge?”

Google: “[unnamed Google executive] would not forget their badge.”

The developer loved this response. Google was basically calling him an idiot, which clearly he was for forgetting his badge, but more so because the developer believed that a company like Google that wanted to attract developers to their platform (or to work at their company) would never treat attendees this way.

Developer: “Ok, I see how it is going to be, but I don’t understand. What are you trying to prevent?”

Google: “It is against our policy.”

Developer: “But why?”

Google: “I can’t have our conference staff printing out badges all the time for people that forget.”

Developer (motioning to all the conference staff just sitting around): “There are lot of folks doing nothing, can’t one of them do it?”

Google: “No.”

Developer: “Is there anything we can do?”

Google: “You can call one of your friends at Google and use their badge. Or you can get someone else you know to give you their badge.”

Developer: “Really? Doesn’t that defeat the whole point of badges?”

Google: “No.”

The developer was very confused at this stage, but he was an idiot, so you would suspect that.

Developer: “Ok, I have a workaround, but it doesn’t make any sense, I really want to confirm that I can get anyone’s badge and just walk in.”

Google: “Yes, everyone is doing it.”

The developer keep wondering if this violated the policy too. That logical flaw didn’t seem to trouble Google. The developer wondered what would happen if every attendee gave their badge to a homeless person on the street during lunch time. Would Google think that was ok?

The developer shook the hand of Google. Thanked them. Walked away.

You can draw your own conclusions from this story. It is only one-side. I am sure Google would have a different take, but the developer will not be attending I/O again (save perhaps to organize that badge swap with the needy of San Francisco).

Update:

The above was a summary.  For example, I saw Scoble during these events and actually used him as an example to ensure that I understood the badge swaping process.  In addition, I accepted my defeat (although I had several offers to use others badges), went home and back (80 minutes exactly), so I could get my hands on the HTC phone.  It is a fairly interesting device.

Thanks to the Google folks that have reached out to me as a result of this post.  Reaffirms my respect for most Google employees (I have many friends that work at Google).

I fully understand why they have this policy; to ensure that I didn’t give my badge to someone else.  There are lots of ways to check for that.  Further and most importantly, you need to start from a position of trust, particularly with a paying customer, especially in the tightly nit developer community.

Prereading: Google Reader to Twitter (rdr2twt)

In the interest of doing a simple comp for some other work I am doing, I decided to move this mere trifle to Google App Engine.

It took around 100 LOCs of Python code.

Observations:

1. The local SDK environment (dev fabric in Azure-speak) is straightforward, did what is was supposed to do, and mostly stayed out of the way.
2. Using whatever Python libraries I wanted was reasonable, although I had some issues with paths around the GData client (which I wanted to use for the Reader feed).  I ended up using ElementTree and urlfetch directly, not a big deal.
3. I didn’t like the fact the the SDK environment didn’t run cron jobs, but I did like two things.  First, it told me that the configuration was right and when the job would have right.  Second, cron just does supports HTTP GET, so it makes trivial to test.
4. The online management environment is quite nice.  I like the analytics a great deal for example.
5. TextMate is hands down the best text editor on the Mac.  This is not a GAE observation, but I want to the Intellipad team to read this and get motivated by the fact that I am using a different text editor.

I am thinking about adding more to see how this scales with application complexity. Two ideas are to make rdr2twt a public service (needs UI, etc.) or to use this as a prototype of some Infobus ideas that I have.  Still thinking on it.

That said, this has to compete with the siren call of the iPhone.  I am getting a lot of pressure to use the basis of LocoFoto as launching point for a couple of different apps.