The application was meant to make it so that you could have cust support agents working from *wherever* - all they would need is a phone and a browser.

When you call into the system, the agents phone rings and his browser refreshes w/your account data.

On the web console part, but that's not useful.

Applets never did have it too easy. The way Java is set up, they only have (had) limited capabilities in the earlier JREs. Today you can sign applets and let them play merry havoc over the entire system if you choose to. They've gotten the 'security insecurity' hoodoo hanging over them. People didn't trust downloaded code at first, even though the early applets only ran in their own sandbox environment and had pretty extensive security restrictions. No one adequately or repetitively made this point to the masses enough to get the idea that downloaded code was not such a bad thing, before the stigma stuck.

That, and the general uselessness of them at first (hence the nickname 'craplets'). Everyone was making applets with little useless graphics thingies that took 10 minutes to download (at 28.8k remember) and then ended up being nothing more than time-consuming eye candy. There wasn't a lot of emphasis on them since you could do 95%+ of the work with HTML/JSP/Servlets and control all that from the server side.

They could be useful now, but the 'critical mass' of developers is gone. Most Java developers do more with Server side stuff than anything else. Applets are kind of a lost art type of thing today.

It's also a catch-22. Managers 'know' that applets aren't great, so they don't authorize developers to make applets, so the ones that do make applets don't have an awful lot of experience and tend to make horrible first-run applets. Thus proving the managers correct, and many times squashing a second possibly better project.