iPhone and Widgets, Part 2
By now, everyone who’s interested has probably watched Apple’s 25 minute video on the features of the iPhone. I did, and it was the clincher to convince me to find a line at an AT&T store somewhere near my house on Friday (I suspect the lines at the Apple Store at West County Mall in St. Louis will be far too long for my taste).
I previously had posted some thoughts on Apple’s announcement that applications for the iPhone can be written using Web 2.0 technologies (except Flash, for now). Patty Seybold contributed to the conversation with some comments and on her blog. After watching the video, I wanted to continue the conversation.
Besides games, which really are using the device for an entirely new purpose, the only area where I see a need for third party applications is in the “Internet Communicator” domain. Clearly, no one needs to write anything to help it play music, watch videos, or make telephone calls, Apple’s taken care of that. For me, Internet communication comes down to four things: a web browser, an email client, an RSS reader, and Instant Messaging. Apple’s taken care of two of them, or possibly three, presuming Safari on the iPhone has the same RSS capabilities as the desktop version. They don’t have Instant Messaging, which is a glaring flaw as far as I’m concerned. While your average teenager may be more concerned about SMS, I tend to rely on IM systems. Many enterprises don’t allow outside IM communication from corporate machines, so that means using a phone for it. I can’t find any good reason why Apple’s wouldn’t have included it. If they felt the primary use was phone-to-phone communication, then why did they not include MMS and instead make you email pictures? Anyway, I digress.
Let’s look at the RSS space. Clearly, there are web-based RSS readers. Safari itself is one. Google Reader is extremely popular. I prefer a standalone reader and use NetNewsWire, but even it syncs with NewsGator to allow for web based access if I so desire. So, Apple’s strategy seems to make sense at this point. The biggest challenge, however, is going to be the diminutive screen. There’s a whole crop of web applications beginning to appear (you can keep up with them via the iPhone Application List) which are effectively web sites that are designed to fit within the iPhone screen. While this can all be managed through bookmarks, I’d much rather have them have an icon on the home page of the device. After all, it’s the strategy Apple itself has chosen.
The YouTube, Google Maps, and Weather applications are clearly examples of web-based applications that were tailored for the diminutive screen, simply because the existing web-based interface was probably designed with at least a 640×400 screen in mind, if not more. This is an implicit recognition that zooming and dragging within full size web sites simply won’t cut it from a usability standpoint. It would be interesting to find out just how much of those applications are web-based, and how much of the presentation is actually generated on the phone, versus on some server.
I would fully expect Apple to issue an update to the iPhone to allow it to have a Home Screen Manager, just like the Dashboard Manager in OS X. While the Dashboard provides APIs for saving preferences locally, I don’t even think this is an absolute requirement for the iPhone, which should eliminate any security concerns. The only thing stored is a bookmark. As long as all of these applications rely on centralized cookie management, there’s no reason why all preferences can’t be stored on the server side. The real question is whether developers will produce the iPhone specific interfaces. I think they will, and I think it’s great that Apple isn’t requiring them to use anything proprietary in doing so. As other smartphones add full web browsers to their mix, these sites that were designed for iPhone will probably be usable, albeit not perfect given subtle differences in screen size, without modification.
Many IT departments see the lack of tangible enterprise value the iPhone can ultimately contribute. Security and compatibility, the two biggest strikes against the iPhone, are what keep popping up for reasons IT professionals stray away from the idea of an enterprising iPhone. In addition to headaches for personnel, the increased cost of employing a secure means of using the device for businesses internally is another mark against it. http://www.iphailure.com
While your comment doesn’t really discuss the subject of the post, it’s certainly true that the iPhone, in its present state, is more of a consumer device. I have no data on what percentage of the smart phone market is taken up by corporate customers versus the consumer market, but it’s pretty clear that Apple isn’t targeting it, so I don’t see that there’s any argument here. As for security, I’d actually argue that the iPhone is less of a problem than the iPod, because as far as I know, it doesn’t have a hard disk mode. Compatibility (and I presume you mean with email servers) may not be an issue if the rumors regarding Apple licensing Active Sync from Microsoft is true. Anyway, thanks for the comments, now let’s back on to the subject of the development model.