thin-vs-thick-client1

Thin Apps Vs Thick – might just have become moot…

This was drafted as some disparate thoughts around the portability and the ‘comfort’ factor of having native features like formatting and notifications on mobile platforms

Backstory:

I had the illuminating experience the other day of unwrapping a new in box, HP Ipaq PDA, from (as best I could tell) 2007. We’re talking Windows Mobile v6 or so. Rather than dismissing this device out of hand, I began setting up for myself the challenge of finding for this device some context amongst the app and content hungry consumer of today. What I soon discovered was that the designers displayed an extraordinary amount of foresight – not the explicit, super-natural Nostradamus kind, but instead the kind where if you stay as true as possible to the (possibly only emerging) accepted standards of the time. This device had a 4in or so touch screen, Wifi (with WPA encryption support), SD (no HC but hey), internet browser, podcast, RSS (and other xml joys), word-excel-exchange support…

I’ve had consumer modem/routers from two years ago that didn’t support WPA2 without a firmware update. Within minutes I was able to connect to the internet, install a mobile version of the chrome browser, and run the new HTML5 version of the kindle cloud e-reader and bingo – accessing my eBook subscriptions over cloud. With a USB SD card reader or just using the included USB-B cable and connecting the device as a mass storage device, one could also locally access non DRM formats of eBooks or music. There are even apps out there that can be installed. It’s great to see almost all the components of a smart phone functionality set existing in a package that got there just on good old future proofing alone.

The model that I was working with did not come with mobile phone or internet connectivity but there were plenty of those out there too.

What that experience had originally made me want to write about:

I’ve already alluded to how design decision making can lead to both good and bad impacts on a products long-term viability. And not in the way that free-market pundits espouse sales levels of new product lines and consumer adoption rates. What I was going to write about was how we as consumers only seem to have two polarised alternatives when it comes to our content delivery method on mobile devices – HTML and other web technologies, and native app frameworks. HTML5 has gone a long way to making my app ‘look’ like an app but I’m still missing some important features – native access to local storage and devices, consistency with device formatting settings, notifications and so on. For RSS I prefer to use Google Reader rather than the available native iOS alternatives, since no matter what device I’m on, there won’t be any disparity between what is read and un-read. What I don’t get is the little number over the app icon on the menu on iOS to show me how many un-read items I have, and there is no local-side caching allowing content to be read when the train I’m on goes into a tunnel. I’m sure you can think of more examples when the ideal solution for content delivery sits somewhere between the online model and the local native app model. I won’t even get started on the holy grail ‘offline VDI’ or offline corporate productivity apps.

Where we could potentially progress and why vendors might be reluctant:

I’m thinking something like PhoneGap where developers can create a fully operational delivery content mechanism viewable entirely by a standards compliant browser, yet also build the platform specific ‘wrapper’ around it to deploy to the various app marketplaces. This already exists to some degree but imagine a fully independent web app, and a very thin native app that would just add the pleasantries of caching content and notifications etc. I imagine that this would make application market places very difficult to regulate in commercial and security terms, and result in a shift of responsibility of malware and exploit protection away from the control of the OS vendors, so I wouldn’t expect such a dilution of autonomy to occur without some resistance.

Taken one step further, a platform could include an abstraction of the ‘wrapper’ which would allow a web application to almost directly control the native features of a device by ‘offering’ various features to white-listed web services – making the creation of specific app wrappers for each web service unnecessary – complete functionality and OS agnosticism. We’re still a fair way off that yet, though.

Scroll to Top