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.

Flash Photo Viewer is exactly what it’s titled: an application built in Flash that loads on your photos on your home page, profile and canvas so you can view all your photos in a scrollable list, and see a larger version of a photo in the primary window. Click on that photo, and a new window displays the full version of the photo. While you view the profile or home page, the viewer goes into slideshow mode.

The application isn’t very complex, but it doesn’t have to be — it does exactly what it advertises.

The application design has a few issues though. It looks the the developer didn’t build separate Flash applications for the User Home Page, User Profile and Canvas, so the size of the slideshow controls is painfully small on the profile and home page. Additionally, the interface is clunky, not polished.

Application rating (1 to 5, 5 being highest):

• Usefulness: 4
• Usability: 3
• Fun Factor: 4
• Stability: 4
• Monetization Opportunities: 3

Use Rich Media With A Purpose

This is not a criticism — this is actually a compliment. Ted.com does an amazing job making Flash relevant with this page design, using large images are very prominent business and social leaders to create a very visual experience. Select an option on the left (say, technology), and the page reshuffles like a tag cloud to present new speakers. They could have built this using DHTML — the page still would have been fairly heavy — but it’s really aimed at an audience that already has a fat pipe to serve up this content.

Content can be ordered and sized by different faceted filters (woo hoo!), and if the visualization mode is too much for you, you can resort to a list view (how Web 1.0). You can even view the number of comments and times each was emailed to friends.

Another tip: it would be even cooler if the boxes could be dragged around and re-ordered to see certain topics large.

Be forewarned — the differences between Beta 1 and Beta 2 will be drastic, according to him.

I’m not saying it’s a me-too technology — there are some very obvious advantages to it, beginning with standardizing on a programming language people actually use instead of something specialized like ActionScript, but we’ve had the hardest time adjusting to the workflow, and a lot of designers are afraid of this much like they are afraid of Flash CS3 Professional because it is such an adjustment. It was hard enough just moving over to the whole motion graphics world, and now many designers and developers are expected to relearn the application to a certain extent.

To the person who applies for this job, please remember how your job is better adoption in following ways:

• It’s not enough just to have timelines — the application really should be easy to use for designers because they are not programmers
• Make some of the interactions easier to explain like, “how do you make a button so it has the multiple states”, maybe even adding wizards like, “create a new button”
• Produce a product that can actually align text better (text alignment should be one of those 1.0 items, not on the 3.0 product list)
• Cater to the designers that ditched Flash when it moved to Actionscript 2 to Actionscript 3
• Most of all, it’s about user adoption and talking to your audience — if you don’t do that, no one will use it