iPad: Yet Another Opinion

Here are my initial, general thoughts about the much-hyped iPad. Clearly the world doesn’t need another blog post about this, but it sets the stage for something coming next.

  • As many have observed, iPad is most easily summarized as a larger iPod Touch, plus some of the mobile data capability of an iPhone. Although this has been expressed widely as a criticism, I note that a very large number of people have bought an iPod Touch or iPhone.
  • By making the iPad fit the above description so well, I fear that there is a tinge of Apple playing it safe for Wall Street. Playing it safe, has not been the strategy that invigorated Apple (and its financial performance) over the last decade.
  • This iPad “1.0” is somewhat short on hardware features. I suspect a second generation device will arrive in 2011 with a few more ports, more storage, more wireless, etc. 1.0 only has to be good enough to prime the market for 2.0.
  • The screen needs more pixels; the resolution / DPI is unimpressive. Also, OLED would have been nice; but Apple had to trade off some things to get to a price point, and the screen technology was obviously one of them.
  • The battery life Apple claims, even if it is vaguely close to reality, is fantastic.
  • I am surprised at the lack of a video camera.
  • I expect to see some kind of trivial tethering interoperation between iPad and iPhone over Bluetooth, sometime in the next couple of revisions of both products. I suspect that loyal Apple fans carrying an iPhone 3GS will end up able to use their iPhone mobile voice/data service for both devices… possibly with some extra monthly service charge.
  • iPad 1.0 will not replace Kindle or other eBook readers, though it might slow their sales growth a bit. But what about iPad 2.0, 3.0, with a better screen and even longer battery life? Once a beautiful color LCD device is good enough, monochrome eInk will be a very tough sell.
  • I will quite likely buy an iPad shortly after it ships; but I’ll be buying perhaps 25% to enjoy it as a consumer, and 75% as a means of more fully understanding the industry importance of the tablet form factor.
  • As a user of a “real” Apple computer (a MacBook Pro running OSX 10.6), I find the closed App Store software distribution model something of a disappointment, compared to a tablet form factor Mac OSX PC I could easily imagine; but I have another blog post coming about that in a few days, after I get some real (non-punditry) work out the door.

I have seen the future, and it runs OSX

iPhone: Wow

It’s a phone. It’s a PDA. It’s an iPod. It’s a widescreen video iPod. It has zero physical buttons, rather the whole front is a multi-touch-screen. I’ll leave the rest of the raving to the many other sites doing a great job of that.

The real innovation of this new device is the OS. Apple has an answer to PalmOS and Windows Mobile (CE): run their real desktop/server OSX, with Unix inside, on the phone. Today’s handhelds have much more computing power and storage than desktop PCs of a decade ago, and there are enormous benefits to running a real, common OS on such a device. I’d been saying since I bought my first Palm (a Handspring, actually) than within a decade the handheld OS’s would go away.

Apple has gone first. How soon will Microsoft follow? Will Palm and RIM make to the new era at all?

(Update: Yes, the title of this post is slightly in jest. I’m serious about real OSs in handheld devices, and the iPhone looks fantastic, but Apple is very unlikely to dominate the phone market in the way the iPod dominates the tiny-media-player market.)

Why I will also never deploy with Java Web Start again

Keith Lea pointed out that he will never deploy with Java Web Start again.

With Web Start in its current form, he’s be deploying with it long before I will use it again.  “Never” is much too soon.. here is why, echoing and expanding on Keith’s experiences. Some of these things are not Web Start’s fault per se. But they are unavoidable with Web Start.

A key piece of background: the most important point of Web Start for us is the notion of auto-update. We periodically put a application Jar up, update the JNLP to point to it, and our users get the new version running on their PC without a re-install process.

Java Web Start doesn’t work for a large number of users

We have the same trouble here. With a large number of users, inevitably Web Start does not work for all of them. For a few percent of users, it simply does not work. We don’t know why. Yes, we upgrade them all to the current Java, the current browser version, etc. Most of the time we get around this with a cycle or two of completely removing then reinstalling Java. In a few cases, the solution was to repave the machine entirely. Both of these are a considerable burden on our customers.

Users don’t like the experience

The part they hate most is this: the auto-update to the current application version is not optional. We upload a new version, and the next time a user runs the application (if Web Start’s update works… see below), they get the new version… even if the new version is a couple of megabytes of bloat… even if the user is on a slow, wireless link… even if the user only wanted to use the application for a minute or two.

Java/JWS detection in the browser is necessary, and unreliable

Mercifully, we have been able to avoid the problem by other means; our customers install Java on a machine right before they launch our application with Web Start.

Users don’t know what JNLP files are

… and they unwittingly misuse them

There is only one right way to use a JNLP file with Web Start, if you want Web Start’s auto update capability to work: pass around / link to / email the URL that points it it. But in the Real World, user misuse JNLP file in many ways:

  • Email the JNLP to a group of users. The users then click on it in the email… so they get the old JNLP each time they click on it. From there the auto-update (based on the URL in side the JNLP) might or might not work.
  • Copy the JNLP file on to the desktop. They do this because the “feature” in web start to create desktop icons, appears to semi-randomly work or not work.
  • Put the JNLP file on a machine, then disable web browsing on that machine… thus disabling Web Start’s auto-update… invisibly.

You cannot make the user experience much better

Most of the unpleasantness happens outside of the application’s control.

Random Caching

Web Start has a cache. The browser has a cache. Between the two of these, sometimes it is not possible to persuade Web Start to update an application to the current code (in the current JNLP file on the server). There is no visibility in to where/when/how-long the old JNLP data is cached. Sometimes clearing the browser cache fixes this, sometimes it is necessary to remove and reinstall the Web Started application. This is enormously frustrating when a field user needs the current application version Right Now, which you deployed to your Web Start web server some weeks ago.

Wireless Hostillity

Wireless network connections are sometimes slow and unreliable. Web Start always downloads a whole file or fails, as far as we can tell; thus a user on a weak connection might repeatedly wait several minutes for a Web Start update, have it fail, then start again at the beginning. Of course they can’t cancel the update as noted above.

If Not Web Start, What?

Like Keith, I have concluded that a native, non-Web Start solution is the way to do. We’ve built this sort of this for several past applications, and while it takes some coding and testing to get it right (work we planned to avoid by using th off the shelf Web Start approach), it tends to work very well. Here are some key design points for auto-updating applications:

  • The user is in control. Tell the user you have a new version to offer. Perhaps start downloading it in the background. But don’t try to force them to update now.
  • Tell the user about the new version in the application, perhaps in the status bar; not only at application startup.
  • Keep the old version, and expose it to the user. The new version might not work, so if they user can click a button to run the old version instead, you have transformed an emergency in to an inconvenience. (It has been suggested that we should not update our JNLP files, rather put up a new JNLP and pass out its URL. This is totally unfeasible for our, since most users would update rarely or never.)
  • Download in the background. The user can keep getting their work done with version N while version N+1 is downloading.
  • No silent failures. If the application can’t access its update information, expose this fact clearly to users and support staff.
  • Dodge the browser cache. Do whatever you must do, to have as few layers of caching as possible; ideally just one layer, in the application auto update mechanism itself. One way to avoid the browser cache is to use a “raw” HTTP-over-TCP library in the application.
  • Incremental Download – if a new version download retrieves 1.9 megabytes of a 2.0 megabyte file, keep the 1.9 and start there next time.

Design Considerations in a Mobile/ Wireless Application

Mobile / Wireless applications must let the user get work done even with a network connection is not available. That and other consideration were covered in this talk to the St. Louis Wireless SIG meeting.

On April 23, 2002, I gave a talk at the St. Louis Web-developers Wireless SIG (what a mouthful!) on design considerations in a mobile/wireless application. The slides from that are available at:


Of course, there was much more in the talk (a very full 90 minutes) than is shown in the slides; hopefully they are useful nonetheless.