End-user platforms for the next while

Sometimes I read a statement by a supposed expert that I think indicates a ridiculous level of misunderstanding. This post is prompted by one of those (I won’t identify its author, and it was a few weeks ago).

There’s apparently confusion out there about what platforms we use that run on specific end-user devices and for which applications can be written by any third party. Operating systems are such platforms – but they’re not the only ones. Web browsers are too. A Java Virtual Machine is as well, and Adobe’s AIR.

Here are what I think are the near future’s most common platforms for end-user devices (not in any particular order):

• Windows 7 and earlier
• Windows 8/RT Metro (this is a new platform since applications will need to be rewritten for it)
• Mac OS
• Browser with medium-size screen – i.e. on a laptop/desktop/tablet (I’m reserving “large” for TVs)
• Browser with small screen – i.e. on a phone (note that if you have to create two versions of your website it’s because there are two platforms to be addressed; there are also differences among browsers but those are generally handled within a single version of the site) UPDATE: There is a trend toward using Responsive Web Design so that a site can handle a range of screen sizes with just one version.
• iOS with small screen – i.e. on iPhone and iPod Touch
• iOS with medium screen – i.e. on iPad
• Android with small screen (Android with medium screen isn’t on this list because not only have Android tablets not caught on but not many apps are being written for them, with users relying on a browser and on apps written for phones)

People writing apps for laptops/desktops often write them for the “Browser with medium-size screen” platform, because (among other things) a single version of the app (which in this case is a website) will cover both Windows and Mac users (and desktop Linux too), and (moving forward to modern times) may even be somewhat usable on a phone (and is likely quite usable on a tablet, unless it contains Flash and the tablet is an iPad). But those who try to use it on a phone will likely be disappointed, i.e. more and more people all the time, and a second version is a good idea. This puts website developers in much the same position as those who in earlier days wrote for only Windows or Mac and who put off as long as possible creating a second version for the other platform. More and more sites now also have a mobile version, though many of them are quite pitiful (like Facebook’s at present, which doesn’t even provide a “Use full site” option to get past its severe limitations).

The iPhone initially didn’t permit third-party apps to run “native”, i.e. directly on iOS; instead developers had to write their apps as websites. But this was before HTML5 came along and allowed websites to do things that had previously required a native app, so a developer revolt forced Apple to change its mind and permit native apps – though only through an app store that required approval by Apple in order to guard against malware. (What Apple did reluctantly has turned out wonderfully for them.)

Particularly on phones, native apps have provided a much better user experience than browsers. But this was once the case on Windows and Macintosh machines too, and then both the browsers and the web apps that ran on them got much better, to the point that (for instance) doing email could be done just as well through a website instead of a native app, thanks to the creation at Google (a web-centric company) of Gmail. I don’t think it’s happenstance that the popular browser that’s been lagging its peers of late has been Apple’s Safari: Apple wants apps that are usable on its hardware to be usable nowhere else, so it encourages native apps for iOS and Mac OS and is not inclined to encourage web apps.

So if you’re writing an app and you want people on the above popular platforms to be able to use it, how should you write it?

The very best user experiences are those designed specifically for the device or at least tailored to it, and where the app’s response to a user action is, when possible, generated locally without requiring server involvement that might take a while – depending on the user action, even a tenth of a second might be an irritating lag.

In native apps that’s the norm. In web apps, local actions often require more work, particularly in apps built on application frameworks. I think it’s time for the general standard of web apps to be raised: the norm should become a single-page application, where the app consists of a single page which is mostly JavaScript that runs entirely locally except when it needs something from the server. Then the web app is a client to the server in much the same way as a native app would be.

I don’t really have a conclusion to this post, except to say that I hope it gives even one person a better understanding of the end-user device platform situation.