On Wednesday, October 9, 2002, at 07:08 AM, Jenda Krynicky wrote: > Yeah ... "Browser Client" applications tend to take longer to do > anything in.
Of course, this can be as much a fault of bad interface design as the medium. > The interface cannot contain all the features and rings > and bells a normal GUI can ... And on the flip side, some programs don't need that many bells to do their job. > Another thing ... browser > is a general ussage program, therefore it uses much more memory and > processor power than a small program that only does one thing. Which > on less equiped computers may mean that the user will spend more time > waiting. This too can be a plus, in a way. A browser is one of the most common "general usage" programs around. You can generally just count on the fact that a computer can display vanilla HTML no matter what it is or who made it. > ...read my emails in web based mail... I would say this example could be well suited to a web application. Granted I have yet to see an implementation as good as my favored client, but they are improving and they do have their advantages (again, available anywhere, just to name one). > If the application is something you use twice a week I'd say it would > be better if it was web based (so you did not have to install > upgrades almost as often as you use it), if you use it most of the > time you'd go crazy. (I'm going crazy from the ##%*%@^#%*&$^#$ PVCS > written in Java, even that is toooo slow and restricted.) My advice here would be to let the interface of the application be your guide. Is it well suited to an HTML interface? What would you gain that way, in addition to instant universal upgrades? What would you lose, in addition to the typical faults Jenda pointed out? Like most choices, there are plenty of tradeoffs here, I think. James -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
