Convenience, low or no cost bundling and the thrill of "the new" draw users and subscribers into clouds and to other varieties of online applications (Web 2.0, RIA, mobile) and services. By the same token, a shot at recurring subscription revenue, brand/platform stickiness, elimination of piracy, or a non-paying user base primed for targeted marketing is carrying businesses into the online space. It's unstoppable. Today, all Mac desktops and all popular varieties of professional mobile devices ship with online apps and associated services so deeply wired that they're part of the platform. Over the next couple of years, commercial client software will take on split duties as self-contained applications and "cloud terminals", with appealing functionality set aside for users who subscribe as well as buy. There's little downside to using online apps as long as you apply sensible standards. Make sure your cloud storage is locally backed up, don't ship anything to the cloud that you wouldn't want shared with the whole world (unless your service guarantees security), guard your online identity, and don't create tacit trust relationships between your LAN and a cloud by, for example, folding your company's shared calendar and contacts into local copies that are synced to Yahoo, Google or MobileMe.
The IBM 3270 display terminal seemed backward even among green screens, yet its approach to issues of distance, latency and link and service reliability contributed greatly to the perception of mainframes as fast, bulletproof commercial systems. The 3270 was more like a browser than a serial terminal in the way that it dealt with data: not one character, but an entire screen at a time. IBM 3270 applications assembled visible content into editable and non-editable fields, and tacked on non-visible instructions to the terminal to create a payload that was streamed to the 3270's controller. After sending the stream, the app sat idle until it received a notice from the terminal that the user had submitted data. A primitive indicator on the display let you know when you had changed data, keeping you mindful of the need to submit the changes to maintain them, and another lit up when you had submitted the screen. Submitting a screen made the 3270 go into a busy state in which the keyboard (literally) locked. You could unlock the keyboard to make a change if you caught an error before the server picked up the screen. Yet, there was never a question about what was being sent and since submitting the screen locked the keyboard, it was impossible to submit anything twice. You also knew that once you saw the next screen, the previous screen had been handled successfully. There are several 3270 qualities that I think belong in online apps. Screen-based, rather than character-based interaction makes more sense for online apps. A server round trip for every keystroke may make for a more convincing emulation of a desktop app, but it presumes an unfailingly reliable link, and a low-latency one at that. The 3270 and the browser were designed to permit local viewing and full-speed data entry, even if a link goes down after the page is rendered. Both also store form data locally so that it is safe until the server receives it. I also appreciated the simple style forced by the 3270's technology. The 3270 didn't do Windows and it could not smooth scroll the whole screen, so you had to make everything fit. Full-screen scroll bars should never appear in online apps, because no matter what device you're using scrolling is an awkward, disruptive gesture.
Lastly, 3270 apps felt faster than those that ran on serial terminals. Each screen full of data was rendered instantly with a satisfying "ping" from the CRT. A serial terminal offered less delay to first response — the period from submitting a form to seeing the first character of the new page — and might even render it faster overall. If you make a user wait until a complex screen is loaded before making it visible, perceived performance is enhanced. I'm enthusiastic about the future of all types of online applications. Interactive apps need to be written with the limitations and frustrations of variable connectivity in mind. If I could make a rule about online apps now, I'd mandate they all be written in HTML5, with data persisted locally before being shipped to the server or run on top of a locally hosted server (like Google Gears), which lets the app work off-line as well as online. In three years that will be the way it's done. In the meantime, just stay mindful that online apps aren't always online. That reality must be managed with preservation of the user's data and productivity foremost in mind.