There are few things more frustrating than filling out the last page of a four-page form on what purports to be a web application, pressing Submit and getting “Server failure — try again later”, a SQL error sloppily spewed out to my browser, or “You are not connected to the internet”.
That last one is a problem on my end, sure, but it’s the site owner’s responsibility to deal with any failure condition gracefully.
When I get the site back, my session has timed out for my protection, and I have to start over. That’s when I know that this would-be app was designed by someone who has never written a commercial client/server application, and that realisation causes me to lose all faith in whatever services this erstwhile app purports to provide.
That outfit lost my business for failing to understand the huge difference between a site and an application. I wish this was an isolated occurrence, but organisations are going ape over the promise of apps that deliver the desktop experience while running entirely on a server, zero client code, completely client-agnostic.
No one interviewing for a high-paying job as a web app developer is going to point out (if they know) that unless the original application was idiot simple, turning it into a website is harder than many other types of porting projects. If you’re hiring a developer to create a web app, the make-or-break interview question should be, “If I told you to turn this desktop app into a web app, what’s the first thing you’d do?”
I almost hate to give away the answer, but what the heck, developers willing to oversell their skills aren’t savvy enough to read InfoWorld.
Thought and debate must be invested in determining how things such as state information, field validation, and the storage of database query results should be split between the browser and the server.
The under-the-hood stuff can then proceed along a parallel path with the user-facing elements, but the presentation is subservient to the application, which is, as always, designed solely to make its users ecstatically happy to sit on their butts all day pulling the strings that make your solution work.
With web apps, as with all development projects, everybody needs to kneel down before quality assurance, but QA takes on special responsibilities with web applications.
It’s QA’s job to humble proud web developers by running the app on screens that are too small, text size dialed up to the browser’s largest setting, connections that are too slow or break in the middle of a transaction, bungled or bogus email addresses, server traffic and resource overloads, database changes after associated screens have already been displayed, forms filled in that can’t be posted before the browser or TCP/IP stack times out, Buy Now buttons that are clicked eight times, and sessions that are allowed to idle for six hours with no activity. In other words, scenarios that a local application would never face must be tested in realistic conditions.
Don’t pretend you’re hitting the site from a cellphone or over a dial-up session interrupted by call waiting; actually do it. Don’t warn a tester that you’re pulling the network cable from the wall; just do it. The response to every failure scenario has to meet not only desktop and n-tier application standards; it mustn’t fail server-hosted internet software standards either. What would Outlook and Exchange do? What would Amazon do? What would BlackBerry Enterprise Server do?
These may not reflect the scale or purpose of your web app, but you can’t put the web application ribbon on your software until it is as responsive, resilient and reliable as native software and the best examples of commercial web applications and sites. More often than buzzword fanatics would like to admit, all of this extra QA, which has to be revisited every time a browser changes, is more trouble than it’s worth. Terminal Server, application virtualisation, thin client computing, Flash and a host of other methods meet or approach the zero-client code requirement without imposing special conditions on architects, designers and developers.
If you finally decide to take the web app route, know that the only people qualified to create web applications are experienced n-tier application developers. Handling the project any other way will yield a website that drives like an application, but fails to meet expectations that an “application look and feel” creates in users.