Once upon a time, I worked for an internet postage company. Seems like decades ago, but it’s core product was a Windows application that allowed the user to print postage (think of it, the equivalent of actual money!) from your computer. Due to the USPS’ requirements, the security for the client was off the charts — even higher than 128-bit encryption.
We actually tried to do the impossible, which was print from a web-based client, and we got it to work. It’s wasn’t production level code, but with a few tweeks here or there, we could have hit that mark. There was no indication if we were going to be allowed to release that client, but the usability wasn’t too bad, especially for skunkworks project.
Soon after that experiment, the company purchased another company that developed a shipping client for shipping centers. It was pretty advanced for it’s time: it did all the AJAX stuff before Jesse James Garrett got rich off of coining the term AJAX. Other than a few glitches, it seemed to work pretty well.
Except it didn’t.
When you visited the clients that used the application, they hated it, and here’s why:
- It was slow
- Performed poorly over DSL
- Was a bloated mess and a fragile application.
- The web client worked only on Internet Explorer 5.0, and as soon as 5.5 was installed, the application broke.
So what are the lessons? I always thought the internet postage client should have been a web application, and conversely the shipping application should have been native to Windows, because almost every one of these locations had a Windows system. As much as I keep repeating that the web is a fad, I think it depends on the following on what you select to be the platform to develop on:
Who’s the audience?
The needs of a bunch of workers telemarketing day in and day out are much different than a sales guy that’s going to make 10 sales calls a day. The telemarketers are going to want hot keys, they definitely don’t want to use a mouse, the latency means less phone calls, which means less money in their pocket.
That’s usability that costs the company in revenue, so they’re going to want a rich or native application. The sales guy making those 10 calls doesn’t mind taking a minute or two longer to futz over a dial up connection or a slow DSL connection, so a web application is just fine. It’s the difference between a casual vs. an expert user.
What’s their platform?
Take a good look at the audience’s technology before you select the platform. Is the audience has a bunch of different platforms and technologies they are working with, that’s an easy answer — go with a web application. If they are on fast connections, look at Flash. If they are on a single platform (Windows, for instance), a native application isn’t a bad idea.
How fast is their connection?
Native applications, once installed, don’t have to be downloaded again. Rich media applications have to be downloaded through a web browser, usually in one chunk. Web applications have latency depending on the connection. Which would you rather be using while working in Alaska, depending on how much data you have to push around?
How often does this need to be updated?
There are advantages, of course, to a web-based application, because you don’t have to worry about backwards compatibility, a code base that’s branched all to hell, and 18 different flavors of windows. If you are going to update the application every day, a native or even a rich media application might not be the way to go. However, if there are long cycles between updates, and there’s a way to push the updates cleanly, then a native application is okay.
All of the above should be considered even before selecting a development platform, because each affects usuability. It’s about the appropriate technology for the appropriate audience, something developers forget.
Comments |
Comment
