Rich online apps can learn from old IBM 3270

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.

Pitfalls will emerge as online replacements for local, interactive applications start to gain traction. Clicking an application icon in a Start menu, a dock or a home screen may load and launch a traditional self-contained local client application, but it could also start up a native front end to an online service or a browser session with embedded controls serving that purpose. There's a drive to blur that line as rapidly as possible; to make online apps look and feel like local ones, to make the cloud productivity suite (an accessible example) feel like Office. However, there is a problem with that. As a professional, I bring expectations to Office. I expect it to auto-save as I type. I edit multiple documents at once. I leave Office running when I close my MacBook Pro's lid, and I exit rather than log out of Terminal Services sessions so that I don't have to start Office and re-load my documents. Microsoft invested a lot of effort making sure that even when I'm running remotely, my expectations don't bite me in the end. All of the drawbacks and risks of online applications are related to distance: User productivity can become dependent on bandwidth and remote server load, data can be lost if a link goes down mid-session, and if a network link is unreliable, as with cellular data, a user can be left wondering whether changes made to a document or form have been accepted. For example, if a browser is used as a front end, a temporary loss of link to the server — or a site, browser, or JavaScript timeout — can wipe out several minutes' worth of a user's data entry, with the Back button popping up a maddeningly blank form or a redirect to an authentication page. Online software and solution designers look to desktop applications (such as Office, iPhoto) for behavioural models, figuring that what users find most familiar is what they're most likely to take up. That works for consumers, but the first time a browser-based spitting image of Word gives me a 504 and trashes my 2,500-word document, I'm an instant non-subscriber. When I look to a potential online replacement for a local app, I am a lot less concerned about look and feel than I am about losing my work. A desktop GUI experience is nice, but I want online apps built with some old school timesharing (Cloud I) lessons in mind. As a smart front end for online applications, the IBM 3270 display terminal had a lot in common with browsers.

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.