iphone – Factory Joe

Obama Phone!

Obama Phone If you haven’t heard about this yet, the Obama campaign today released an iPhone app that, among other features, enables you to call your friends prioritized by their location in battleground states.

This is critical.

There’s nothing more important, or more influential, than friends encouraging friends to vote, and when it comes to getting informed on the issues and what’s at stake, nothing is more effective than getting an impassioned plea from a personal contact or relative.

Providing a tool that allows people to get in touch with people who they personally know is so much better than cold-calling phone banking (the importance of that tactic notwithstanding given the need to reach out beyond the friends of iPhone owners).

You can get the app in the iTunes App Store.

The Obama ’08 app development was spearheaded by personal friends of mine — co-organizers of the popular iPhoneDevCamps that we held the past two years at Adobe’s offices in San Francisco (which are now spreading, like all good *camp events should!). Specifically, props go to Dom Sagolla and Raven Zachary, without whom this application might never have happened. But credit is also due to the entire top-tier team that spent countless hours over the past month putting this app together (*iPhoneDevCamp alumni):

Raven Zachary (Project Director) *
Jason Grigsby (Project Manager)
John Keith (Server Development)
Lyza Gardner (Server Development, Design)
Aileen Jeffries (Design)
Jonathan Wight (Lead iPhone Development) *
Dom Sagolla (QA, Community Development) *
Mike Lee (iPhone Development, UI) *
Louie Mantia (Design) *
Tristan O’Tierney (iPhone Development) *

What’s significant is not only the application, but what this move represents for those of us who live and breathe the web and open source: this app is born of both, reusing a number of open source components and, from the outset, leverages the web with presence on social networks like Facebook. This is the Obama campaign reaching out to the open source and iPhone development communities and working with us to do what we know how to do best, and giving us a space in which we can make a difference for the campaign.

We’re nearly a month a way from the election, and that means that if you want to participate, you’re going to need be registered to vote beforehand. It also means that if you’ve been waiting, or holding out, and looking for an opening to get involved, now’s your chance. As Raven says, making a few simple calls with this app enables even ‘The Two Minute Volunteer’ to make a substantial difference by personally involving friends and family in the election.

Seeing this work inspires and gives me hope; if we can keep up this kind of innovative thinking for the next 30 days, I think it’s clear that the best candidate is going to come out on top and get the country back on its proper footing.

OAuth for the iPhone: Pownce.app

If you’re one of the lucky folks that’s been able to upgrade your iPhone (and activate it) to the 2.0 firmware, I encourage you to give the Pownce application a try, if only to see a real world example of OAuth in action (that link will open in iTunes).

Here’s how it goes in pictures:

And the actual flow:

Launch the Pownce app. You’ll be prompted to login in at Pownce.com
Pownce.app launches Pownce.com via an initial OAuth request; here you signin to your Pownce account using your username or password (if Pownce supported OpenID, you could signin with OpenID as well).
Once successfully signed in to your account, you can grant the Pownce iPhone app permission to access your account.
Once you click Okay, which is basically a pownce:// protocol link that will fire up Pownce.app to complete the transaction.

There are three important aspects of this:

First, you’re not entering your username and password into the Pownce application — you’re only entering it into the website. This might not seem like a great distinction, but if a non-Pownce developed iPhone application wanted to access or post to your Pownce account, this flow could be reused, and you’d never need to expose your credentials to that third party app;
Second, it creates room for the adoption of OpenID — or something other single sign-on solution — to be implemented at Pownce later on, since OAuth doesn’t specify how you do authentication.
Third, if the iPhone is lost or stolen, the owner of the phone could visit Pownce.com and disable access to their account via the Pownce iPhone app — and not need to change their password and disrupt all the other services or applications that might already have been granted access.

Personally, as I’ve fired up an increasing number of native apps on the iPhone 2.0 software, I’ve been increasingly frustrated and annoyed at how many of them want my username and password, and how few of them support this kind of delegated authorization flow.

If you consider that there are already a few Twitter-based applications available, and none of them support OAuth (Twitter still has yet to implement OAuth), in order to even test these apps out, you have to give away your credentials over and over again. Worse, you can guarantee that a third-party will destroy your credentials once you’ve handed them over, even if you uninstall the application.

These are a few reasons to consider OAuth for iPhone application development and authorization. Better yet, Jon Crosby’s Objective-C library can even give you a head start!

Hat tip to Colin Devroe for the suggestion. Cross-posted to the OAuth blog.

Apple Tablet Concept: the iPad Touch

I don’t really do much industrial design (there’s probably a good reason for that) but I couldn’t get over a niggling (though probably baseless) inkling that Apple will be coming out with a tablet this spring. I mean, if anyone can ship a tablet that’s not lame, it’ll be Apple. Besides that, there’s just too much evidence out there that suggests rather convincingly that Apple intends to put one out sooner or later (not that they haven’t tried before), so rather than sit around and wait, I thought I’d mockup what one of these devices might look like:

Here it is with the touch keyboard:

With a wireless keyboard:

And with CoverFlow™:

So, there were some other ideas I had about this too that venture into the realm of pure conjecture. I mean, I could have just blogged these ideas without pictures, but I think it’s certainly more compelling with them. Anyway:

The OS will actually use the same OS as the iPhone. I mean why else would they invest so much in a paired down OS if they’re only going to use it on one platform? Ludicrous! Instead, this device will basically be a glorified iPhone, just 2.5x the size. Here’s the kicker <wild conjecture>: the iPhone SDK was delayed in order for 1) Leopard to come out (so you wouldn’t write Tiger-apps for the iPhone) and 2) because this device will launch at MacWorld, and the iPhone SDK will work for the Apple iPad Touch as well.</wild conjecture> Pretty clever eh?
Just like the name implies, and just like its cousin the iPod Touch, this device is all about tactile user interface. There’s no solid state keyboard on this bad boy. Instead, it’s a pure software keyboard, able to be gloriously adapted and regiggered to fit the task at hand, or able to have key identifiers in any language imaginable. Heck, you could even have a Halo-specific keyboard with specific buttons for each type of grenade.
To add an additional Minority Report-quality to this device, Apple will probably introduce their own software-driven version of the clickwheel, and it’ll probably look something like the QuickSilver constellation menus or the new Sapiens app. This interface will be necessarily for navigating around without a Dock and without having to return to the home screen. And, don’t forget how good CoverFlow looks at larger sizes.
Although this device wouldn’t have a CD or DVD slot, it would still be an excellent device for movie playback (for all the movies you buy from the iTunes store, of course!). Imagine being cramped in an airplane seat — no more dinky iPod Video… and no more awkward 15″ laptop. You get a perfectly mobile, conveniently flat device for even the seats with the least legroom.
Speaking of the lack of optical drive (well, the bottom-loader theory is interesting)… this device is all about wireless, just like the iPod Touch. Fortunately it has all the same ports as the MacBook Pro, but is only as thick as the lower part of that system, given that the screen is just a thin layer above the inner workings.
There’s no mouse or touch pad on this device (though you can add a mouse via Bluetooth or USB). As with the Touch series, you interact with everything directly, rather than having the traditional out-of-body pointer experience.
Dashboard Widgets really get their due here with a souped up WebKit rendering engine — supporting CSS animation and transforms, downloadable fonts, offline storage (for those airplane rides, again) and SVG, not to mention a lot of Core Animation goodness. And yes, with the SDK, native apps will of course be possible.
Losing the optical drive helped another area that rocks with this device: battery life. It’d say 12 hours without too much trouble, thanks too to converting to flash drives.

So that’s about it. Part of this exercise was just to come up with a bunch of random ideas and see what other people think or what they want from an Apple tablet. If you ask me, less is more here; I don’t want just another Windows-style tablet with all the bells and whistles. I actually like my iPhone better without third-party apps. If Apple’s going to build the Apple iPad Touch (or whatever better name they come up with), I expect nothing less than a slick, streamlined experience that feels less like a computer and more like a lifestyle object.

Oh, and one more thing. 😉

This baby will retail at $699 for 32GB and $899 for 64GB (remember, flash drives are still pricey) available immediately (well, if I were speaking at MacWorld 2008 it would be…).

Did the web fail the iPhone?

Ian might be right, but not because of Steve’s announcement today about opening up the iPhone.

Indeed, my reaction so far has been one of quasi-resignation and disappointment.

A voice inside me whimpers, “Don’t give up on the web, Steve! Not yet!”

You have to understand that when I got involved in helping to plan iPhoneDevCamp, we didn’t call it iPhoneWebDevCamp for a reason. As far as we knew, and as far as we could see into the immediate future, the web was the platform of the iPhone (Steve Jobs even famously called Safari the iPhone’s SDK).

The hope that we were turning the corner on desktop-based applications was palpable. By keeping the platform officially closed, Apple brought about a collective channeling of energy towards the development of efficient and elegant web interfaces for Safari, epitomized by Joe Hewitt’s iPhone Facebook App (started as a project around iPhoneDevCamp and now continued on as iUI by Christopher Allen, founder of the iPhoneWebDev group).

And we were just getting started.

…So the questions on my mind today are: was this the plan all along? Or, was Steve forced into action by outside factors?

If this were the case all along, I’d be getting pretty fed up with these kind of costly and duplicitous shenanigans. For godsake, Steve could at least afford to stop being so contradictory! First he lowers the price of the iPhone months after releasing it, then drops the price of DRM-free tracks (after charging people to “upgrade their music”), and now he’s promising a software SDK in February, pledging that an “open” platform “is a step in the right direction” (after bricking people’s phones and launching an iPhone WebApps directory, seemingly in faux support of iPhone Web App developers).

Now, if this weren’t in the plan all along, then Apple looks like a victim of the promise — and hype — of the web as platform. (I’ll entertain this notion, while keeping in mind that Apple rarely changes direction due to outside influence, especially on product strategy.)

Say that everything Steve said during his keynote were true and he (and folks at Apple) really did believe that the web was the platform of the future — most importantly, the platform of Apple’s future — this kind of reversal would have to be pretty disappointing inside Apple as well. Especially considering their cushy arrangement with Google and the unlikelihood that Mac hardware will ever outsell PCs (so long as Apple has the exclusive right to produce Mac hardware), it makes sense that Apple sees its future in a virtualized, connected world, where its apps, its content and its business is made online and in selling thin clients, rather than in the kind of business where Microsoft made its billions, selling dumb boxes and expiring licenses to the software that ran on them.

If you actually read Apple’s guide for iPhone content and application development, you’d have to believe that they get the web when they call for:

Understanding User-iPhone Interaction
Using Standards and Tried-and-True Design Practices
Integrating with Phone, Mail, and Maps
Optimizing for Page Readability
Ensuring a Great Audio and Video Experience (while Flash is not supported)

These aren’t the marks of a company that is trying to embrace and extend the web into its own proprietary nutshell. Heck, they even support microformats in their product reviews. It seems so badly that they want the web — the open web — to succeed given all the rhetoric so far. Why backslide now?

Well, to get back to the title of this post, I can’t but help feel like the web failed the iPhone.

For one thing, native apps are a known quantity for developers. There are plenty of tools for developing native applications and interfaces that don’t require you to learn some arcane layout language that doesn’t even have the concept of “columns”. You don’t need to worry about setting up servers and hosting and availability and all the headaches of running web apps. And without offering “services in the cloud” to make web application hosting and serving a piece of cake, Apple kind of shot itself in the foot with its developers who again, aren’t so keen on the ways of the web.

Flipped around, as a proponent of the web, even I can admit how unexciting standard interfaces on the web are. And how much work and knowledge it requires to compete with the likes of Adobe’s AIR and Microsoft’s SilverLight. I mean, us non-proprietary web-types rejoice when Safari gets support for CSS-based rounded corners and the ability to use non-standard typefaces. SRSLY? The latter feature was specified in 1998! What took so long?!

No wonder native app developers aren’t crazy about web development for the iPhone. Why should they be? At least considering where we’re at today, there’s a lot to despise about modern web design and to despair about how little things have improved in the last 10 years.

And yet, there’s a lot to love too, but not the kind of stuff that makes iPhone developers want to abandon what’s familiar, comfortable, safe, accessible and hell, sexy.

It’s true, for example, that with the web you get massive distribution. It means you don’t need a framework like Sparkle to keep your apps up-to-date. You can localize your app in as many languages as you like, and based on your web stats, can get a sense for which languages you should prioritize. With protocols like OpenID and OAuth, you get access to all kind of data that won’t be available solely on a user’s system (especially when it comes to the iPhone which dispenses with “Save” functionality) as well a way to uniquely identify your customers across applications. And you get the heightened probability that someone might come along and look to integrate with or add value to your service via some kind of API, without requiring any additional download to the user’s system. And the benefits go on. But you get the point.

Even still, these benefits weren’t enough to sway iPhone developers, nor, apparently, Steve Jobs. And to the degree to which the web is lacking in features and functionality that would have allowed to Steve to hold off a little longer, there is opportunity to improve and expand upon what I call the collection of “web primitives” that compose the complete palette of interaction options for developers who call the web their native platform. The simple form controls, the lightboxes, the static embedded video and audio, the moo tools and scriptaculouses… they still don’t stack up against native (read: proprietary) interface controls. And we can do better.

We must to do better! We need to improve what’s going inside the browser frame, not just around it. It’s not enough to make a JavaScript compiler faster or even to add support for SVG (though it helps). We need to define, design and construct new primitives for the web, that make it super simple, straight-forward and extremely satisfying to develop for the web. I don’t know how it is that web developers have for so long put up with the frustrations and idiosyncrasies of web application development. And I guess, as far as the iPhone goes, they won’t have to anymore.

It’s a shame really. We could have done so much together. The web and the iPhone, that is. We could have made such sweet music. Especially when folks realize that Steve was right and developing for Safari is the future of application development, they’ll have wished that they had invested in and lobbied for richer and better tools and interfaces for what will inevitably become the future of rich internet application development and, no surprise, the future of the iPhone and all its kin.

OpenID on the iPhone

I helped lead a session on Saturday at iPhoneDevCamp on the topic of OpenID and Oauth (a new protocol a group of us have been developing) to a packed room of developers, designers and interested parties.

My basic premise was that if you’re going to be developing an application for the iPhone that has any kind of account or social functionality that you should dispense with creating yet another identity silo and instead make use of OpenID. Among the reasons I cited:

Safari on the iPhone doesn’t have a password manager like 1Passwd and won’t be able to import all the Firefox passwords you’ve been recording for years. And, as mobile web browsers become more powerful, remembering web service account credentials will become more important (and more of a burden). Better to make it easy on your customers — one OpenID url, one username and password.
if you’ve logged in with OpenID on a web service on your desktop or laptop and have set your provider to always allow you to login in automatically, logging in on the iPhone will require you to only login to your OpenID provider and then enter your URL once for every web service that you want to login to. This means that you avoid the challenge of invisibly typing in your password over and over on the error prone touchscreen keyboard.
The ability to cross-polinate authenticated data using a combination of OpenID and Oauth while remote will be increasingly valuable, especially if the expectation is that applications are going to be entirely web-driven. When you’re dealing with desktop apps, you’re operating off a harddrive with known permissions; when you’re passing between web apps, the permission model is radically different and, just as when you go to check out from Amazon you always have to authenticate, developing patterns for this experience between web apps needs refinement. OpenID can help smooth out that interaction.

Lastly, there is work going on (okay, I’m doing it so far) to make the OpenID login experience on the iPhone (and elsewhere) trump any kind of old school login system available. This obviously needs a lot of work and new thinking (maybe instead of authenticating by typing a password you have to SMS a unique shortcode, etc) but I think your money should be on OpenID if you’re going to be developing account-based web applications on the iPhone — or — generally.