web enabled performance

[Richard Choate]

I'm writing a piece about the push toward web enabled applications and
databases over the past couple of years and need your comments. My wife was
complaining that her company is using a new web enabled version of their
industry software and it is slower and less feature rich than the previous,
PC based version.

My theory is that web enabled or web based applications always depend on the
user's internet connection speed for performance and is therefore always
going to be much slower than a PC based application running on a fast
computer. Further, that the features are only imitations of the features
present on the original PC based programs.

I appreciate your relevant comments about this subject.

Richard Choate

[Ray at]

Remember years ago when you'd go to work and sit at a dumb-terminal
connected to an AS/400 or a mainframe that would provide you with only the
screens that you needed to do your job? That's what we're coming back to,
either with web-based applications or Citrix type solutions. I think that
we (the industry) have realized that desktop applications are a PITA. At
the same time, I'd kill myself if I had to use OWA instead of the full
client Outlook.

Ray at home

--
Will trade ASP help for SQL Server help


"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> I'm writing a piece about the push toward web enabled applications and
> databases over the past couple of years and need your comments. My wife

was

> complaining that her company is using a new web enabled version of their
> industry software and it is slower and less feature rich than the

previous,

> PC based version.
>
> My theory is that web enabled or web based applications always depend on

the

> user's internet connection speed for performance and is therefore always
> going to be much slower than a PC based application running on a fast
> computer. Further, that the features are only imitations of the features
> present on the original PC based programs.
>
> I appreciate your relevant comments about this subject.
>
> Richard Choate
>
>

[Tom B]

Regarding your wife's complaints
1) The speed of the application is partially dependent on the speed of the
connection, but also of the design elements. On an intranet application I'm
working on, I have to reign in the graphics guy constantly. He assumes that
since we have 100 Mb connections his graphics can be as huge as he wants.
Some of our users are in remote offices running over dial-up or dsl lines
and these graphics have slowed things to a crawl.
Another thing to bear in mind is that if you are going to use a thin client
with a server, you need to ensure that your server has enough power to
support the user load. Again, an application I was working on was running
on a decent server with Windows 2000 and 128 MB RAM. Guess what.....it was
slow. A simple look at the Task Manager showed that it was idling at about
130 MB, so speed was terrible.
2) Features can be limited, but it's usually a limitation of the developer
not the browser. A creative developer should be able to create an
application that is as feature rich as a thick application. Frequently,
I've noticed that to get a feature working in a browser, the feature needs
to be accessed differently which leads to user confusion. This user
confusion results in the user thinking the feature isn't there, or isn't
right. Proper user training will minimize this effect, but of course that
costs time and money.

One thing that is often overlooked is the power of the workstation. One
business I've been involved with has a Pentium 4 processor, 512MB RAM
etc.etc. running on each desktop. These workstations use only 4
applications, Word, Outlook, a DOS based application with data coming from a
database and an Intranet application. This is gross overkill. I recognize
the need to have good machines, I just see this as a huge waste of
processing power.

A strong argument for the thin client is the ease of deployment. In the
business I mentioned, a machine can be unpacked and configured in no time at
all.

Well, I think of ranted long enough

"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> I'm writing a piece about the push toward web enabled applications and
> databases over the past couple of years and need your comments. My wife

was

> complaining that her company is using a new web enabled version of their
> industry software and it is slower and less feature rich than the

previous,

> PC based version.
>
> My theory is that web enabled or web based applications always depend on

the

> user's internet connection speed for performance and is therefore always
> going to be much slower than a PC based application running on a fast
> computer. Further, that the features are only imitations of the features
> present on the original PC based programs.
>
> I appreciate your relevant comments about this subject.
>
> Richard Choate
>
>

[Richard Choate]

You seem to be supporting my general theory If I am reading you right. I was
not fully articulating my theory or using appropriate terminology, so I'll
try again.

My belief is that companies are, in many cases, desiring to go with newer
web-enabled applications, not knowing anything about what a thin client is,
because they believe that would be "better" or it would be the next step in
a logical progression. In fact, these companies are about to trade in what
you call "thick client" applications which are running on either full power
PCs or Macs, for thin client applications that will work from their
browsers. We're talking about business applications and databases and stuff
like that. Heavy lifters. For instance, I created an automated Excel based
application which generates Excel charts by the thousands utilizing data
that is mined from a filemaker database. Obviously, we're talking about some
heavy graphics and processing power. This app puts a strain on the normal
PC. Now, my client thinks it would be good to maybe have the whole thing run
from a web-enabled app. I'm saying that thin clients and web aps are great
for e-commerce and shopping carts, but not for generating 3,000 Excel charts
from 50,000 data records for one private client.

So, I ask you this: Doesn't the web-enabled app generally run slower for one
reason or another? Isn't the fact that graphics must be limited just proof
of this? Aren't the web-enabled apps really less feature rich because the
developer has to emulate the controls of a thick client app, and sometimes
you just can't reproduce the features you find in a client PC or server
based app? These are my basic questions and I can't imagine a web app that
will run as fast as one installed on my 2.4 Ghz PC with a hair over 1 Ghz of
RDRam.

thanks !

Richard

"Tom B" <shuckle@hotmail.com> wrote in message
news:OFNTZ7EUDHA.2008@TK2MSFTNGP11.phx.gbl...
Regarding your wife's complaints
1) The speed of the application is partially dependent on the speed of the
connection, but also of the design elements. On an intranet application I'm
working on, I have to reign in the graphics guy constantly. He assumes that
since we have 100 Mb connections his graphics can be as huge as he wants.
Some of our users are in remote offices running over dial-up or dsl lines
and these graphics have slowed things to a crawl.
Another thing to bear in mind is that if you are going to use a thin client
with a server, you need to ensure that your server has enough power to
support the user load. Again, an application I was working on was running
on a decent server with Windows 2000 and 128 MB RAM. Guess what.....it was
slow. A simple look at the Task Manager showed that it was idling at about
130 MB, so speed was terrible.
2) Features can be limited, but it's usually a limitation of the developer
not the browser. A creative developer should be able to create an
application that is as feature rich as a thick application. Frequently,
I've noticed that to get a feature working in a browser, the feature needs
to be accessed differently which leads to user confusion. This user
confusion results in the user thinking the feature isn't there, or isn't
right. Proper user training will minimize this effect, but of course that
costs time and money.

One thing that is often overlooked is the power of the workstation. One
business I've been involved with has a Pentium 4 processor, 512MB RAM
etc.etc. running on each desktop. These workstations use only 4
applications, Word, Outlook, a DOS based application with data coming from a
database and an Intranet application. This is gross overkill. I recognize
the need to have good machines, I just see this as a huge waste of
processing power.

A strong argument for the thin client is the ease of deployment. In the
business I mentioned, a machine can be unpacked and configured in no time at
all.

Well, I think of ranted long enough

"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> I'm writing a piece about the push toward web enabled applications and
> databases over the past couple of years and need your comments. My wife

was

> complaining that her company is using a new web enabled version of their
> industry software and it is slower and less feature rich than the

previous,

> PC based version.
>
> My theory is that web enabled or web based applications always depend on

the

> user's internet connection speed for performance and is therefore always
> going to be much slower than a PC based application running on a fast
> computer. Further, that the features are only imitations of the features
> present on the original PC based programs.
>
> I appreciate your relevant comments about this subject.
>
> Richard Choate
>
>

[Richard Choate]

I cross-posted this in the asp.general NG just a minute ago. I should have
put this over there in the first place but forgot to. Please don't be upset
my my double-post.
RC

"Tom B" <shuckle@hotmail.com> wrote in message
news:OFNTZ7EUDHA.2008@TK2MSFTNGP11.phx.gbl...
Regarding your wife's complaints
1) The speed of the application is partially dependent on the speed of the
connection, but also of the design elements. On an intranet application I'm
working on, I have to reign in the graphics guy constantly. He assumes that
since we have 100 Mb connections his graphics can be as huge as he wants.
Some of our users are in remote offices running over dial-up or dsl lines
and these graphics have slowed things to a crawl.
Another thing to bear in mind is that if you are going to use a thin client
with a server, you need to ensure that your server has enough power to
support the user load. Again, an application I was working on was running
on a decent server with Windows 2000 and 128 MB RAM. Guess what.....it was
slow. A simple look at the Task Manager showed that it was idling at about
130 MB, so speed was terrible.
2) Features can be limited, but it's usually a limitation of the developer
not the browser. A creative developer should be able to create an
application that is as feature rich as a thick application. Frequently,
I've noticed that to get a feature working in a browser, the feature needs
to be accessed differently which leads to user confusion. This user
confusion results in the user thinking the feature isn't there, or isn't
right. Proper user training will minimize this effect, but of course that
costs time and money.

One thing that is often overlooked is the power of the workstation. One
business I've been involved with has a Pentium 4 processor, 512MB RAM
etc.etc. running on each desktop. These workstations use only 4
applications, Word, Outlook, a DOS based application with data coming from a
database and an Intranet application. This is gross overkill. I recognize
the need to have good machines, I just see this as a huge waste of
processing power.

A strong argument for the thin client is the ease of deployment. In the
business I mentioned, a machine can be unpacked and configured in no time at
all.

Well, I think of ranted long enough

"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> I'm writing a piece about the push toward web enabled applications and
> databases over the past couple of years and need your comments. My wife

was

> complaining that her company is using a new web enabled version of their
> industry software and it is slower and less feature rich than the

previous,

> PC based version.
>
> My theory is that web enabled or web based applications always depend on

the

> user's internet connection speed for performance and is therefore always
> going to be much slower than a PC based application running on a fast
> computer. Further, that the features are only imitations of the features
> present on the original PC based programs.
>
> I appreciate your relevant comments about this subject.
>
> Richard Choate
>
>

[Tom B]

I agree that you can do more and it's generally faster to have a thick
client. It's important to remember that in large businesses, the cost of
rolling out thick applications can be very high.
In your example (the Excel charts) this is, in my opinion, a good example of
where a client/server application is better suited. If all of this data is
spread amongst a slew of workstations, creating accurate graphs would be
difficult. Having this data on a database server, and having a good server
create the charts is a better use of resources.
I am, of course, basing my thoughts on the assumption that the server(s)
would be more powerful than the workstations.
Your assumptions at the bottom of your statement, I would generally agree
with. You can usually do a lot more with a thick client. If you monitor
this newsgroup and particularly the inetserver.asp.general newsgroup you
might be surprised at what people are doing with web apps.

Some other things to think about,
1) I would expect most companies need to watch their resources, so if they
can put off purchasing new computers for a year or two, they would.
2) Along the same lines as #1, roll out costs, upgrade costs and maintenance
costs are higher with a thick client.
3) Centralized data, if your client creates data -- it should be stored and
backed up on a server. How many network administrators have client
workstations with Word, Excel and other files all over their hard drives?
4) Alternate operating systems, while I haven't seen much of this. Using a
web based application, reduces the problems of mixed hardware and operating
systems. As well as opening the door to using "free" software such as
linux.

However, to contradict everything I've said. There are huge advantages in
using a thick client.
1) Development time should be shorter. Although I'm sure many would
disagree with me.
2) Speed is always going to be faster locally.
3) Integrated help systems
4) Less need for graphical design.
I'm sure there are many more that I haven't thought of.

One interesting thing I'd heard of, was having idle workstations pick up
some of the load. Sort of like the SETI program, that runs as a screen
saver on home users computers, which analyzes data on thousands (millions?)
of computers when they are idle.
So, in the middle of the night, theoretically your charts could be produced
by the individual workstations, each doing a small part of the job. Not
really practical, but interesting.

Well, I think I'm done. I'm not sure which side of the fence I sit on this
one. As always it comes down to the individual situation. As you
mentioned, doing it just for the sake of doing it, isn't a good idea.


"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:%23HpheHMUDHA.304@tk2msftngp13.phx.gbl...

> You seem to be supporting my general theory If I am reading you right. I

was

> not fully articulating my theory or using appropriate terminology, so I'll
> try again.
>
> My belief is that companies are, in many cases, desiring to go with newer
> web-enabled applications, not knowing anything about what a thin client

is,

> because they believe that would be "better" or it would be the next step

in

> a logical progression. In fact, these companies are about to trade in what
> you call "thick client" applications which are running on either full

power

> PCs or Macs, for thin client applications that will work from their
> browsers. We're talking about business applications and databases and

stuff

> like that. Heavy lifters. For instance, I created an automated Excel based
> application which generates Excel charts by the thousands utilizing data
> that is mined from a filemaker database. Obviously, we're talking about

some

> heavy graphics and processing power. This app puts a strain on the normal
> PC. Now, my client thinks it would be good to maybe have the whole thing

run

> from a web-enabled app. I'm saying that thin clients and web aps are great
> for e-commerce and shopping carts, but not for generating 3,000 Excel

charts

> from 50,000 data records for one private client.
>
> So, I ask you this: Doesn't the web-enabled app generally run slower for

one

> reason or another? Isn't the fact that graphics must be limited just proof
> of this? Aren't the web-enabled apps really less feature rich because the
> developer has to emulate the controls of a thick client app, and sometimes
> you just can't reproduce the features you find in a client PC or server
> based app? These are my basic questions and I can't imagine a web app

that

> will run as fast as one installed on my 2.4 Ghz PC with a hair over 1 Ghz

of

> RDRam.
>
> thanks !
>
> Richard
>
> "Tom B" <shuckle@hotmail.com> wrote in message
> news:OFNTZ7EUDHA.2008@TK2MSFTNGP11.phx.gbl...
> Regarding your wife's complaints
> 1) The speed of the application is partially dependent on the speed of the
> connection, but also of the design elements. On an intranet application

I'm

> working on, I have to reign in the graphics guy constantly. He assumes

that

> since we have 100 Mb connections his graphics can be as huge as he wants.
> Some of our users are in remote offices running over dial-up or dsl lines
> and these graphics have slowed things to a crawl.
> Another thing to bear in mind is that if you are going to use a thin

client

> with a server, you need to ensure that your server has enough power to
> support the user load. Again, an application I was working on was running
> on a decent server with Windows 2000 and 128 MB RAM. Guess what.....it

was

> slow. A simple look at the Task Manager showed that it was idling at

about

> 130 MB, so speed was terrible.
> 2) Features can be limited, but it's usually a limitation of the developer
> not the browser. A creative developer should be able to create an
> application that is as feature rich as a thick application. Frequently,
> I've noticed that to get a feature working in a browser, the feature needs
> to be accessed differently which leads to user confusion. This user
> confusion results in the user thinking the feature isn't there, or isn't
> right. Proper user training will minimize this effect, but of course that
> costs time and money.
>
> One thing that is often overlooked is the power of the workstation. One
> business I've been involved with has a Pentium 4 processor, 512MB RAM
> etc.etc. running on each desktop. These workstations use only 4
> applications, Word, Outlook, a DOS based application with data coming from

a

> database and an Intranet application. This is gross overkill. I

recognize

> the need to have good machines, I just see this as a huge waste of
> processing power.
>
> A strong argument for the thin client is the ease of deployment. In the
> business I mentioned, a machine can be unpacked and configured in no time

at

> all.
>
> Well, I think of ranted long enough
>
> "Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
> news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> > I'm writing a piece about the push toward web enabled applications and
> > databases over the past couple of years and need your comments. My wife

> was

> > complaining that her company is using a new web enabled version of their
> > industry software and it is slower and less feature rich than the

> previous,

> > PC based version.
> >
> > My theory is that web enabled or web based applications always depend on

> the

> > user's internet connection speed for performance and is therefore always
> > going to be much slower than a PC based application running on a fast
> > computer. Further, that the features are only imitations of the features
> > present on the original PC based programs.
> >
> > I appreciate your relevant comments about this subject.
> >
> > Richard Choate
> >
> >

>
>
>

[Richard Choate]

Thank you so much for your amplified comments. While you do go back and
forth a bit, your analysys seems fair and balanced and will help me form my
comments.
Richard Choate

"Tom B" <shuckle@NOSPAMhotmail.com> wrote in message
news:uUO7LuMUDHA.1576@TK2MSFTNGP12.phx.gbl...
I agree that you can do more and it's generally faster to have a thick
client. It's important to remember that in large businesses, the cost of
rolling out thick applications can be very high.
In your example (the Excel charts) this is, in my opinion, a good example of
where a client/server application is better suited. If all of this data is
spread amongst a slew of workstations, creating accurate graphs would be
difficult. Having this data on a database server, and having a good server
create the charts is a better use of resources.
I am, of course, basing my thoughts on the assumption that the server(s)
would be more powerful than the workstations.
Your assumptions at the bottom of your statement, I would generally agree
with. You can usually do a lot more with a thick client. If you monitor
this newsgroup and particularly the inetserver.asp.general newsgroup you
might be surprised at what people are doing with web apps.

Some other things to think about,
1) I would expect most companies need to watch their resources, so if they
can put off purchasing new computers for a year or two, they would.
2) Along the same lines as #1, roll out costs, upgrade costs and maintenance
costs are higher with a thick client.
3) Centralized data, if your client creates data -- it should be stored and
backed up on a server. How many network administrators have client
workstations with Word, Excel and other files all over their hard drives?
4) Alternate operating systems, while I haven't seen much of this. Using a
web based application, reduces the problems of mixed hardware and operating
systems. As well as opening the door to using "free" software such as
linux.

However, to contradict everything I've said. There are huge advantages in
using a thick client.
1) Development time should be shorter. Although I'm sure many would
disagree with me.
2) Speed is always going to be faster locally.
3) Integrated help systems
4) Less need for graphical design.
I'm sure there are many more that I haven't thought of.

One interesting thing I'd heard of, was having idle workstations pick up
some of the load. Sort of like the SETI program, that runs as a screen
saver on home users computers, which analyzes data on thousands (millions?)
of computers when they are idle.
So, in the middle of the night, theoretically your charts could be produced
by the individual workstations, each doing a small part of the job. Not
really practical, but interesting.

Well, I think I'm done. I'm not sure which side of the fence I sit on this
one. As always it comes down to the individual situation. As you
mentioned, doing it just for the sake of doing it, isn't a good idea.


"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:%23HpheHMUDHA.304@tk2msftngp13.phx.gbl...

> You seem to be supporting my general theory If I am reading you right. I

was

> not fully articulating my theory or using appropriate terminology, so I'll
> try again.
>
> My belief is that companies are, in many cases, desiring to go with newer
> web-enabled applications, not knowing anything about what a thin client

is,

> because they believe that would be "better" or it would be the next step

in

> a logical progression. In fact, these companies are about to trade in what
> you call "thick client" applications which are running on either full

power

> PCs or Macs, for thin client applications that will work from their
> browsers. We're talking about business applications and databases and

stuff

> like that. Heavy lifters. For instance, I created an automated Excel based
> application which generates Excel charts by the thousands utilizing data
> that is mined from a filemaker database. Obviously, we're talking about

some

> heavy graphics and processing power. This app puts a strain on the normal
> PC. Now, my client thinks it would be good to maybe have the whole thing

run

> from a web-enabled app. I'm saying that thin clients and web aps are great
> for e-commerce and shopping carts, but not for generating 3,000 Excel

charts

> from 50,000 data records for one private client.
>
> So, I ask you this: Doesn't the web-enabled app generally run slower for

one

> reason or another? Isn't the fact that graphics must be limited just proof
> of this? Aren't the web-enabled apps really less feature rich because the
> developer has to emulate the controls of a thick client app, and sometimes
> you just can't reproduce the features you find in a client PC or server
> based app? These are my basic questions and I can't imagine a web app

that

> will run as fast as one installed on my 2.4 Ghz PC with a hair over 1 Ghz

of

> RDRam.
>
> thanks !
>
> Richard
>
> "Tom B" <shuckle@hotmail.com> wrote in message
> news:OFNTZ7EUDHA.2008@TK2MSFTNGP11.phx.gbl...
> Regarding your wife's complaints
> 1) The speed of the application is partially dependent on the speed of the
> connection, but also of the design elements. On an intranet application

I'm

> working on, I have to reign in the graphics guy constantly. He assumes

that

> since we have 100 Mb connections his graphics can be as huge as he wants.
> Some of our users are in remote offices running over dial-up or dsl lines
> and these graphics have slowed things to a crawl.
> Another thing to bear in mind is that if you are going to use a thin

client

> with a server, you need to ensure that your server has enough power to
> support the user load. Again, an application I was working on was running
> on a decent server with Windows 2000 and 128 MB RAM. Guess what.....it

was

> slow. A simple look at the Task Manager showed that it was idling at

about

> 130 MB, so speed was terrible.
> 2) Features can be limited, but it's usually a limitation of the developer
> not the browser. A creative developer should be able to create an
> application that is as feature rich as a thick application. Frequently,
> I've noticed that to get a feature working in a browser, the feature needs
> to be accessed differently which leads to user confusion. This user
> confusion results in the user thinking the feature isn't there, or isn't
> right. Proper user training will minimize this effect, but of course that
> costs time and money.
>
> One thing that is often overlooked is the power of the workstation. One
> business I've been involved with has a Pentium 4 processor, 512MB RAM
> etc.etc. running on each desktop. These workstations use only 4
> applications, Word, Outlook, a DOS based application with data coming from

a

> database and an Intranet application. This is gross overkill. I

recognize

> the need to have good machines, I just see this as a huge waste of
> processing power.
>
> A strong argument for the thin client is the ease of deployment. In the
> business I mentioned, a machine can be unpacked and configured in no time

at

> all.
>
> Well, I think of ranted long enough
>
> "Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
> news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> > I'm writing a piece about the push toward web enabled applications and
> > databases over the past couple of years and need your comments. My wife

> was

> > complaining that her company is using a new web enabled version of their
> > industry software and it is slower and less feature rich than the

> previous,

> > PC based version.
> >
> > My theory is that web enabled or web based applications always depend on

> the

> > user's internet connection speed for performance and is therefore always
> > going to be much slower than a PC based application running on a fast
> > computer. Further, that the features are only imitations of the features
> > present on the original PC based programs.
> >
> > I appreciate your relevant comments about this subject.
> >
> > Richard Choate
> >
> >

>
>
>

[Tom B]

Yeah, sorry I'm a rambler.
I do go back and forth, because I really can't decide which is "better"
It really does have to be decided on a case by case basis.

Will your article be published?


"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:uiN3JoTUDHA.2220@TK2MSFTNGP11.phx.gbl...

> Thank you so much for your amplified comments. While you do go back and
> forth a bit, your analysys seems fair and balanced and will help me form

my

> comments.
> Richard Choate
>
> "Tom B" <shuckle@NOSPAMhotmail.com> wrote in message
> news:uUO7LuMUDHA.1576@TK2MSFTNGP12.phx.gbl...
> I agree that you can do more and it's generally faster to have a thick
> client. It's important to remember that in large businesses, the cost of
> rolling out thick applications can be very high.
> In your example (the Excel charts) this is, in my opinion, a good example

of

> where a client/server application is better suited. If all of this data

is

> spread amongst a slew of workstations, creating accurate graphs would be
> difficult. Having this data on a database server, and having a good

server

> create the charts is a better use of resources.
> I am, of course, basing my thoughts on the assumption that the server(s)
> would be more powerful than the workstations.
> Your assumptions at the bottom of your statement, I would generally agree
> with. You can usually do a lot more with a thick client. If you monitor
> this newsgroup and particularly the inetserver.asp.general newsgroup you
> might be surprised at what people are doing with web apps.
>
> Some other things to think about,
> 1) I would expect most companies need to watch their resources, so if they
> can put off purchasing new computers for a year or two, they would.
> 2) Along the same lines as #1, roll out costs, upgrade costs and

maintenance

> costs are higher with a thick client.
> 3) Centralized data, if your client creates data -- it should be stored

and

> backed up on a server. How many network administrators have client
> workstations with Word, Excel and other files all over their hard drives?
> 4) Alternate operating systems, while I haven't seen much of this. Using

a

> web based application, reduces the problems of mixed hardware and

operating

> systems. As well as opening the door to using "free" software such as
> linux.
>
> However, to contradict everything I've said. There are huge advantages in
> using a thick client.
> 1) Development time should be shorter. Although I'm sure many would
> disagree with me.
> 2) Speed is always going to be faster locally.
> 3) Integrated help systems
> 4) Less need for graphical design.
> I'm sure there are many more that I haven't thought of.
>
> One interesting thing I'd heard of, was having idle workstations pick up
> some of the load. Sort of like the SETI program, that runs as a screen
> saver on home users computers, which analyzes data on thousands

(millions?)

> of computers when they are idle.
> So, in the middle of the night, theoretically your charts could be

produced

> by the individual workstations, each doing a small part of the job. Not
> really practical, but interesting.
>
> Well, I think I'm done. I'm not sure which side of the fence I sit on

this

> one. As always it comes down to the individual situation. As you
> mentioned, doing it just for the sake of doing it, isn't a good idea.
>
>
> "Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
> news:%23HpheHMUDHA.304@tk2msftngp13.phx.gbl...

> > You seem to be supporting my general theory If I am reading you right. I

> was

> > not fully articulating my theory or using appropriate terminology, so

I'll

> > try again.
> >
> > My belief is that companies are, in many cases, desiring to go with

newer

> > web-enabled applications, not knowing anything about what a thin client

> is,

> > because they believe that would be "better" or it would be the next step

> in

> > a logical progression. In fact, these companies are about to trade in

what

> > you call "thick client" applications which are running on either full

> power

> > PCs or Macs, for thin client applications that will work from their
> > browsers. We're talking about business applications and databases and

> stuff

> > like that. Heavy lifters. For instance, I created an automated Excel

based

> > application which generates Excel charts by the thousands utilizing data
> > that is mined from a filemaker database. Obviously, we're talking about

> some

> > heavy graphics and processing power. This app puts a strain on the

normal

> > PC. Now, my client thinks it would be good to maybe have the whole thing

> run

> > from a web-enabled app. I'm saying that thin clients and web aps are

great

> > for e-commerce and shopping carts, but not for generating 3,000 Excel

> charts

> > from 50,000 data records for one private client.
> >
> > So, I ask you this: Doesn't the web-enabled app generally run slower for

> one

> > reason or another? Isn't the fact that graphics must be limited just

proof

> > of this? Aren't the web-enabled apps really less feature rich because

the

> > developer has to emulate the controls of a thick client app, and

sometimes

> > you just can't reproduce the features you find in a client PC or server
> > based app? These are my basic questions and I can't imagine a web app

> that

> > will run as fast as one installed on my 2.4 Ghz PC with a hair over 1

Ghz

> of

> > RDRam.
> >
> > thanks !
> >
> > Richard
> >
> > "Tom B" <shuckle@hotmail.com> wrote in message
> > news:OFNTZ7EUDHA.2008@TK2MSFTNGP11.phx.gbl...
> > Regarding your wife's complaints
> > 1) The speed of the application is partially dependent on the speed of

the

> > connection, but also of the design elements. On an intranet application

> I'm

> > working on, I have to reign in the graphics guy constantly. He assumes

> that

> > since we have 100 Mb connections his graphics can be as huge as he

wants.

> > Some of our users are in remote offices running over dial-up or dsl

lines

> > and these graphics have slowed things to a crawl.
> > Another thing to bear in mind is that if you are going to use a thin

> client

> > with a server, you need to ensure that your server has enough power to
> > support the user load. Again, an application I was working on was

running

> > on a decent server with Windows 2000 and 128 MB RAM. Guess what.....it

> was

> > slow. A simple look at the Task Manager showed that it was idling at

> about

> > 130 MB, so speed was terrible.
> > 2) Features can be limited, but it's usually a limitation of the

developer

> > not the browser. A creative developer should be able to create an
> > application that is as feature rich as a thick application. Frequently,
> > I've noticed that to get a feature working in a browser, the feature

needs

> > to be accessed differently which leads to user confusion. This user
> > confusion results in the user thinking the feature isn't there, or isn't
> > right. Proper user training will minimize this effect, but of course

that

> > costs time and money.
> >
> > One thing that is often overlooked is the power of the workstation. One
> > business I've been involved with has a Pentium 4 processor, 512MB RAM
> > etc.etc. running on each desktop. These workstations use only 4
> > applications, Word, Outlook, a DOS based application with data coming

from

> a

> > database and an Intranet application. This is gross overkill. I

> recognize

> > the need to have good machines, I just see this as a huge waste of
> > processing power.
> >
> > A strong argument for the thin client is the ease of deployment. In the
> > business I mentioned, a machine can be unpacked and configured in no

time

> at

> > all.
> >
> > Well, I think of ranted long enough
> >
> > "Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
> > news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> > > I'm writing a piece about the push toward web enabled applications and
> > > databases over the past couple of years and need your comments. My

wife

> > was

> > > complaining that her company is using a new web enabled version of

their

> > > industry software and it is slower and less feature rich than the

> > previous,

> > > PC based version.
> > >
> > > My theory is that web enabled or web based applications always depend

on

> > the

> > > user's internet connection speed for performance and is therefore

always

> > > going to be much slower than a PC based application running on a fast
> > > computer. Further, that the features are only imitations of the

features

> > > present on the original PC based programs.
> > >
> > > I appreciate your relevant comments about this subject.
> > >
> > > Richard Choate
> > >
> > >

> >
> >
> >

>
>
>

[Richard Choate]

My article will only be published in my newsletter. I write a quarterly
newsletter on the subject of Excel and VBA macros (as they pertain to
Excel). Occasionally I write stuff that is on the perimiter of my actual
subject matter, such as this article. It is a free newsletter that I produce
mostly as a marketing tool, but it does contain some useful tips and
information for the advanced Excel user.
Thanks,
Richard

"Tom B" <shuckle@hotmail.com> wrote in message
news:#bTtc6dUDHA.1956@TK2MSFTNGP10.phx.gbl...
Yeah, sorry I'm a rambler.
I do go back and forth, because I really can't decide which is "better"
It really does have to be decided on a case by case basis.

Will your article be published?


"Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
news:uiN3JoTUDHA.2220@TK2MSFTNGP11.phx.gbl...

> Thank you so much for your amplified comments. While you do go back and
> forth a bit, your analysys seems fair and balanced and will help me form

my

> comments.
> Richard Choate
>
> "Tom B" <shuckle@NOSPAMhotmail.com> wrote in message
> news:uUO7LuMUDHA.1576@TK2MSFTNGP12.phx.gbl...
> I agree that you can do more and it's generally faster to have a thick
> client. It's important to remember that in large businesses, the cost of
> rolling out thick applications can be very high.
> In your example (the Excel charts) this is, in my opinion, a good example

of

> where a client/server application is better suited. If all of this data

is

> spread amongst a slew of workstations, creating accurate graphs would be
> difficult. Having this data on a database server, and having a good

server

> create the charts is a better use of resources.
> I am, of course, basing my thoughts on the assumption that the server(s)
> would be more powerful than the workstations.
> Your assumptions at the bottom of your statement, I would generally agree
> with. You can usually do a lot more with a thick client. If you monitor
> this newsgroup and particularly the inetserver.asp.general newsgroup you
> might be surprised at what people are doing with web apps.
>
> Some other things to think about,
> 1) I would expect most companies need to watch their resources, so if they
> can put off purchasing new computers for a year or two, they would.
> 2) Along the same lines as #1, roll out costs, upgrade costs and

maintenance

> costs are higher with a thick client.
> 3) Centralized data, if your client creates data -- it should be stored

and

> backed up on a server. How many network administrators have client
> workstations with Word, Excel and other files all over their hard drives?
> 4) Alternate operating systems, while I haven't seen much of this. Using

a

> web based application, reduces the problems of mixed hardware and

operating

> systems. As well as opening the door to using "free" software such as
> linux.
>
> However, to contradict everything I've said. There are huge advantages in
> using a thick client.
> 1) Development time should be shorter. Although I'm sure many would
> disagree with me.
> 2) Speed is always going to be faster locally.
> 3) Integrated help systems
> 4) Less need for graphical design.
> I'm sure there are many more that I haven't thought of.
>
> One interesting thing I'd heard of, was having idle workstations pick up
> some of the load. Sort of like the SETI program, that runs as a screen
> saver on home users computers, which analyzes data on thousands

(millions?)

> of computers when they are idle.
> So, in the middle of the night, theoretically your charts could be

produced

> by the individual workstations, each doing a small part of the job. Not
> really practical, but interesting.
>
> Well, I think I'm done. I'm not sure which side of the fence I sit on

this

> one. As always it comes down to the individual situation. As you
> mentioned, doing it just for the sake of doing it, isn't a good idea.
>
>
> "Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
> news:%23HpheHMUDHA.304@tk2msftngp13.phx.gbl...

> > You seem to be supporting my general theory If I am reading you right. I

> was

> > not fully articulating my theory or using appropriate terminology, so

I'll

> > try again.
> >
> > My belief is that companies are, in many cases, desiring to go with

newer

> > web-enabled applications, not knowing anything about what a thin client

> is,

> > because they believe that would be "better" or it would be the next step

> in

> > a logical progression. In fact, these companies are about to trade in

what

> > you call "thick client" applications which are running on either full

> power

> > PCs or Macs, for thin client applications that will work from their
> > browsers. We're talking about business applications and databases and

> stuff

> > like that. Heavy lifters. For instance, I created an automated Excel

based

> > application which generates Excel charts by the thousands utilizing data
> > that is mined from a filemaker database. Obviously, we're talking about

> some

> > heavy graphics and processing power. This app puts a strain on the

normal

> > PC. Now, my client thinks it would be good to maybe have the whole thing

> run

> > from a web-enabled app. I'm saying that thin clients and web aps are

great

> > for e-commerce and shopping carts, but not for generating 3,000 Excel

> charts

> > from 50,000 data records for one private client.
> >
> > So, I ask you this: Doesn't the web-enabled app generally run slower for

> one

> > reason or another? Isn't the fact that graphics must be limited just

proof

> > of this? Aren't the web-enabled apps really less feature rich because

the

> > developer has to emulate the controls of a thick client app, and

sometimes

> > you just can't reproduce the features you find in a client PC or server
> > based app? These are my basic questions and I can't imagine a web app

> that

> > will run as fast as one installed on my 2.4 Ghz PC with a hair over 1

Ghz

> of

> > RDRam.
> >
> > thanks !
> >
> > Richard
> >
> > "Tom B" <shuckle@hotmail.com> wrote in message
> > news:OFNTZ7EUDHA.2008@TK2MSFTNGP11.phx.gbl...
> > Regarding your wife's complaints
> > 1) The speed of the application is partially dependent on the speed of

the

> > connection, but also of the design elements. On an intranet application

> I'm

> > working on, I have to reign in the graphics guy constantly. He assumes

> that

> > since we have 100 Mb connections his graphics can be as huge as he

wants.

> > Some of our users are in remote offices running over dial-up or dsl

lines

> > and these graphics have slowed things to a crawl.
> > Another thing to bear in mind is that if you are going to use a thin

> client

> > with a server, you need to ensure that your server has enough power to
> > support the user load. Again, an application I was working on was

running

> > on a decent server with Windows 2000 and 128 MB RAM. Guess what.....it

> was

> > slow. A simple look at the Task Manager showed that it was idling at

> about

> > 130 MB, so speed was terrible.
> > 2) Features can be limited, but it's usually a limitation of the

developer

> > not the browser. A creative developer should be able to create an
> > application that is as feature rich as a thick application. Frequently,
> > I've noticed that to get a feature working in a browser, the feature

needs

> > to be accessed differently which leads to user confusion. This user
> > confusion results in the user thinking the feature isn't there, or isn't
> > right. Proper user training will minimize this effect, but of course

that

> > costs time and money.
> >
> > One thing that is often overlooked is the power of the workstation. One
> > business I've been involved with has a Pentium 4 processor, 512MB RAM
> > etc.etc. running on each desktop. These workstations use only 4
> > applications, Word, Outlook, a DOS based application with data coming

from

> a

> > database and an Intranet application. This is gross overkill. I

> recognize

> > the need to have good machines, I just see this as a huge waste of
> > processing power.
> >
> > A strong argument for the thin client is the ease of deployment. In the
> > business I mentioned, a machine can be unpacked and configured in no

time

> at

> > all.
> >
> > Well, I think of ranted long enough
> >
> > "Richard Choate" <rchoatecpa@NoSpam.com> wrote in message
> > news:e9AC4u8TDHA.3144@tk2msftngp13.phx.gbl...

> > > I'm writing a piece about the push toward web enabled applications and
> > > databases over the past couple of years and need your comments. My

wife

> > was

> > > complaining that her company is using a new web enabled version of

their

> > > industry software and it is slower and less feature rich than the

> > previous,

> > > PC based version.
> > >
> > > My theory is that web enabled or web based applications always depend

on

> > the

> > > user's internet connection speed for performance and is therefore

always

> > > going to be much slower than a PC based application running on a fast
> > > computer. Further, that the features are only imitations of the

features

> > > present on the original PC based programs.
> > >
> > > I appreciate your relevant comments about this subject.
> > >
> > > Richard Choate
> > >
> > >

> >
> >
> >

>
>
>