Back in 2006, I described the idea of the “webtop” via example in a number of posts. At that time, Web 2.0 and the browser as the center of the computing universe were the popular visions of the day. I personally wasn’t convinced that the browser would replace desktop software. Instead, the model I suggested was one where the advancements in the personal computer—especially operating systems and processors—would be fully leveraged by native applications that would pull data from the cloud.
Of course back then, my own computing world was significantly less complex, so this perspective did not stem from necessity. I mainly worked on a single PC-based laptop and a Nokia E61smartphone, where my killer app was still e-mail (or possibly SMS). There were no reading devices like the Nook or Kindle and consumer tablets were largely powered by Windows and not Apple’s iOS.
I decided to become ambidextrous in 2008 and shared my days between a PC and Mac. I was fully immersed in the world of the iPhone by then and even with one more device introduced into my workflow, the webtop needed to transform from a dream to reality. I no longer could tolerate having different documents, browser sessions, to-do lists, music, etc. on each of these three devices. I was determined to be able to move from one device to another without any impact on what I was doing.
My initial success only started between my PC and Mac by using tools like Sugar Sync and Mozilla Weave (now, Firefox Sync). These solutions were not elegant, however, and only were in the early stages of their existence. More significant though, was that it was difficult for these tools to access any data that was “locked” inside of apps. This situation typically occurred with the most custom, polished, and native of application, many of which were found on the Mac or iOS platform.
An example—and one app that still has this issue two years later—is Cultured Code’s Things. Unless on the same Wi-Fi network and a Mac and iOS device are paired, there’s no way to sync the data between these devices. This situation can lead to a loss of data (e.g., an item is only one device that becomes damaged) or out of sync data (e.g., an item is only on one device that has not been synced to the other); the former is disastrous while the latter is frustrating.
Unfortunately, this fairly basic scenario of a multi-device computing environment is still often unresolved. Consumers are mostly asked to find their own solutions to deal with having data distributed across 5-7 locations including traditional desktops, laptops, smartphones, digital cameras, tablets, and yes, even on the Web.
Remember that the Web itself is not a solution to multi-device computing because data can also become locked in it, similar to desktop apps. Other times, network connectivity is unavailable, which effectively is similar to data being lost or out of sync. When it came to web apps and the webtop, local storage of network data was one approach to this issue and making web apps better.
2010 is very different than 2006 and even 2008. The principles and architecture of the webtop are still applicable but mobile and more specifically, multi-device computing is at a tipping point with the proliferation of iOS, Android, netbooks, and ereaders. As I write in the afterword of my upcoming book, mobile will soon no longer be the exception, it will be the standard. To compensate for these advancements, the webtop must evolve. Joshua Topolsky’s describes this new paradigm as the “continuous client,” a model where, “when you leave one device, you pick up your session in exactly the same place on the next device you use.”
The continuous client builds on the idea of the webtop by more explicitly addressing the state of the application. Where my suggestion for the webtop was to keep the data between applications the same, the continuous client proposes that the exact task or operation being performed should also be maintained. For example, pick up a song from where it left off when going from a home stereo to the car or begin reading an article at the same line when moving from a tablet to a smartphone.
For the more basic criteria of creating a continuous client—data sync—Google is a leader in the older, browser-based model with its office suite (Gmail, Google Calendar, and Google Docs). Dropbox’s investment in its API is proving to be a smart one, as more and more native apps developers are realizing that the right approach is to integrate established providers who specialize in cloud-based storage and syncing rather than to develop this infrastructure themselves.
Mozilla (Firefox Sync) and Amazon (Kindle) offer two glimpses of the continuous client, where data is synced and states are (somewhat) maintained. In particular, Amazon shows how the continuous client must be considered both across devices and platforms. Beyond the physical Kindle reader, the Kindle software is available for all major devices and platforms including iOS, Blackberry, Android, PC, and Mac.
There are few companies that have the resources to invest in supporting continuous clients for so many devices and platforms at once. When it comes to mobile platforms, many organizations are choosing to invest first in iOS and then in Android. But even in those cases, their native client apps are usually not even first generation continuous clients that ensure data is kept in sync.
Some will again turn to web apps built using HTML 5 and CSS 3 but the browser still is not the definitive solution. While Dropbox’s API supports the data sync aspect of the continuous client, it is not built to address state maintenance. As Topolsky hints, there’s a huge opportunity to create a utility or service that facilitates the latter.