DesignBais - Impressive

#41

murthi wrote:

Quote:

Disagree with shamda. One problem with fat clients is the deployment on
individual PCs. And with a thin client, anyone anywhere can access the
application. Comments intrinsically noted:

Chandru Murthi
"sh" <shamada (AT) prupipe (DOT) com> wrote in message
news:tIbog.3196$ii.2399 (AT) newsread3 (DOT) news.pas.earthlink.net...

Kevin Powick wrote:

Any nTier configuration, fat or thin, will be subject to network
latency.

Fat client latency is far shorter than thin client latency. Less for the
server to do. Less for the client to render.

True, but it's what you're used to. At first I could not believe users could
accept the browser latency, but after a few years it's not an issue (unless
Verizon does its frequent work-to-rule) . I think-ahead instead of
type-ahead. The latency issue seems much more important to the developer
than to the end-user. The latter pretty much gets used to it, having been
beaten into submission by the web, and doesn't even notice it anymore.

My users are smarter than that.

Quote:

2) limited data-validation capabilities on the browser

Many tools are making this less so.

True, but it's always a catchup game.

You can do pretty much anything you want on the browser itself since
javascript functions are so easy to write. If you build a tool to build the
forms instead of discrete forms, you only have to do it once. For example,
we have the I/Oconv of date, time, pattern matches, range checks, numerics,
money, etc. It's all about a couple hundred lines of javascript. What's not
to like?

"You can do pretty much anything you want" with anything. The question
is which is a better solution to do so - choosing your tool either from
the developers standpoint or from the end-users standpoint.

Quote:

3) Keeping numerous forms open on the
screen at the same time (MDI). Can you keep 2 customer records and 4
order records open at the same time in a browser?

Certainly. Multiple browser windows have never beena problem.

Not the same as an MDI, where you can maneuver them around on your screen
any which way

Don't understand this. What's the problem with multiple browser windows?

It seems to me that MDI is much cleaner from the end-users standpoint.
I'd much rather have 2 documents open in one session of Word than having
them open in 2 sessions of Word. But then, maybe that's my personal
preference.

Quote:

Yes, that's true. I guess what I meant was that things like AJAX are new
technologies bolted onto the browser. In fat clients they have been made
more an intrinsic part of the development environment. It feels more like
one integrated technology.

AJAX is the overblown acronym that means you write javascript embedded in
the html. What's not "intrinsic" about that?

HTML <> JavaScript. (Or in PickBasic "HTML # JavaScript"). Two different
languages.

Quote:

But you get what you pay for. You have to invest time and money to get a
smooth, feature-rich app.

And you don't say, in VB? To any mv programmer, javascript is the most
pleasant seque into mainstream. I cannot not abide Java, VB, php et al, and
doubt I could have been a tenth as productive as in js.

But don't you have to spend just as much time in your "think-ahead"
developemnt mode in order to give that smooth-browser feel to the
end-user? I'm spending my time on one aspect of the development, and
your spending a similar amount of time on another aspect of development.
Not much difference, and I produce a more feature rich app.

And why wouldn't you be just as productive in C# or VB.NET? Plus you
must now be knowledgable about both html as well as JavaScript. Seems
easier to be just knowledgable in either C# or VB.NET.

Quote:

The deployment is not the time-consuming part. It's the development and
testing that is. I wouldn't deploy a fix in 5 minutes on a thin client
either, unless it was purely cosmetic. (And in that case, I would do it on
a fat client as well in 5 minutes.)

How about 120 obese clients?

"ClickOnce reduces the time and effort required to deploy Windows
applications across a network. Rather than distribute a separate
executable to each individual hard drive, ClickOnce places the
executable on a common Web page, from which all users can launch it."

"Updates to the Windows application can be re-published to the Web
server, and the newer application files are then available to clients.
If an older version of the Windows application opens locally on a client
machine, an update dialog box gives the option to check for updates from
the Web server."

Definitely not as easy as a browser update, but you clearly don't have
to run around to those 120 fat clients to install the update.

Quote:

I don't think anyone is pushing the browser as the be all and
end all fat client replacement.

Why not? For one thing, it's universal. If you accept its limitations, it
works well.

I don't accept it's limitations.

#42

just thought i would say that deployment is a big big issue with fat
clients, especially if you have several thousand desktops in 28
countries (one scenario i have been involved in recently). yes there
are tools out there for this, including citrix, but non of them are
trivial.

#43

comments embedded. Chandru Murthi

"sh" <shamada (AT) prupipe (DOT) com> wrote

Quote:

murthi wrote:
Disagree with shamda. One problem with fat clients is the deployment on
individual PCs. And with a thin client, anyone anywhere can access the
application. Comments intrinsically noted:

Chandru Murthi
"sh" <shamada (AT) prupipe (DOT) com> wrote in message
news:tIbog.3196$ii.2399 (AT) newsread3 (DOT) news.pas.earthlink.net...

Kevin Powick wrote:

Any nTier configuration, fat or thin, will be subject to network
latency.

Fat client latency is far shorter than thin client latency. Less for the
server to do. Less for the client to render.

True, but it's what you're used to. At first I could not believe users
could accept the browser latency, but after a few years it's not an issue
(unless Verizon does its frequent work-to-rule) . I think-ahead instead
of type-ahead. The latency issue seems much more important to the
developer than to the end-user. The latter pretty much gets used to it,
having been beaten into submission by the web, and doesn't even notice it
anymore.

My users are smarter than that.
I wouldn't say our benighted users are not smart. I think they accept

certain limitations (as they used to on green screen) in return for
increased functionality and ease of use. Besides, with event driven actions,
the latency is masked. Maybe it's a matter of training 'em properly.

Quote:

2) limited data-validation capabilities on the browser

Many tools are making this less so.

True, but it's always a catchup game.

You can do pretty much anything you want on the browser itself since
javascript functions are so easy to write. If you build a tool to build
the forms instead of discrete forms, you only have to do it once. For
example, we have the I/Oconv of date, time, pattern matches, range
checks, numerics, money, etc. It's all about a couple hundred lines of
javascript. What's not to like?

"You can do pretty much anything you want" with anything. The question is
which is a better solution to do so - choosing your tool either from the
developers standpoint or from the end-users standpoint.

We have a well proven browser based interface to uv that's quite productive.
No one is straining to fit a round peg in a square hole here. It just works,
and works well. So far neither of us have proved a thing except to show our
biases. If your bias is towards thick client so be it, but you have shown
nothing that proves that's a superior way to go.

Quote:

3) Keeping numerous forms open on the
screen at the same time (MDI). Can you keep 2 customer records and 4
order records open at the same time in a browser?

Certainly. Multiple browser windows have never beena problem.

Not the same as an MDI, where you can maneuver them around on your screen
any which way

Don't understand this. What's the problem with multiple browser windows?

It seems to me that MDI is much cleaner from the end-users standpoint. I'd
much rather have 2 documents open in one session of Word than having them
open in 2 sessions of Word. But then, maybe that's my personal preference.
And, from a user viewpoint, what is the difference? Why would they care if

there's "one version.." or "two"? Unless you're suggesting that the 2
sessions open use more client resources?

Quote:

Yes, that's true. I guess what I meant was that things like AJAX are new
technologies bolted onto the browser. In fat clients they have been made
more an intrinsic part of the development environment. It feels more like
one integrated technology.

AJAX is the overblown acronym that means you write javascript embedded
in the html. What's not "intrinsic" about that?

HTML <> JavaScript. (Or in PickBasic "HTML # JavaScript"). Two different
languages.

Well, that's obvious. What about CSS embedded in html? Another language?
What about the glue code probably written in C to get to the database? Or
Pick BASIC itself on the server? What exactly is the issue here? From the
application developer's viewpoint, he codes Pick Basic on the server and
creates browser forms via the development environment. It all would look
quite integrated to him. I guess you're really saying that the tool
developer has a harder time of it via this approach vs using an integrated
environment?

Quote:

But you get what you pay for. You have to invest time and money to get a
smooth, feature-rich app.

And you don't say, in VB? To any mv programmer, javascript is the most
pleasant seque into mainstream. I cannot not abide Java, VB, php et al,
and doubt I could have been a tenth as productive as in js.

But don't you have to spend just as much time in your "think-ahead"
development mode in order to give that smooth-browser feel to the
end-user? I'm spending my time on one aspect of the development, and your
spending a similar amount of time on another aspect of development. Not
much difference, and I produce a more feature rich app.

Not clear on the first sentence. I was making a joke referencing green
screens when I said think-ahead.
What's a substantive feature or two which you think is not available on the
browser?

Quote:

And why wouldn't you be just as productive in C# or VB.NET? Plus you must
now be knowledgable about both html as well as JavaScript. Seems easier to
be just knowledgable in either C# or VB.NET.

Well, firstly because of the sheer simplicity of javascript vs those others.
Same as for Pick Basic vs other languages.
Being "knowledgable about both html as well as JavaScript" is hardly onerous
and in any event, most application programming is done via the tool and
nobody looks at html except the tool developers.

Quote:

The deployment is not the time-consuming part. It's the development and
testing that is. I wouldn't deploy a fix in 5 minutes on a thin client
either, unless it was purely cosmetic. (And in that case, I would do it
on a fat client as well in 5 minutes.)

How about 120 obese clients?

"ClickOnce reduces the time and effort required to deploy Windows
applications across a network. Rather than distribute a separate
executable to each individual hard drive, ClickOnce places the executable
on a common Web page, from which all users can launch it."

"Updates to the Windows application can be re-published to the Web server,
and the newer application files are then available to clients. If an older
version of the Windows application opens locally on a client machine, an
update dialog box gives the option to check for updates from the Web
server."

Which would be unacceptable to our users, and freak 'em out.

Quote:

Definitely not as easy as a browser update, but you clearly don't have to
run around to those 120 fat clients to install the update.

I don't think anyone is pushing the browser as the be all and
end all fat client replacement.

Why not? For one thing, it's universal. If you accept its limitations, it
works well.

I don't accept it's limitations.

I was somewhat softpedalling my opinion. Comparing any two UIs will always
show up "limitations". But I don't see any true limitations in the browser
(except security issues).

#44

Hi Frosty
Try bringing up a message to reply without double clicking on it.
Regards
Peter McMurray
"frosty" <frostyj (AT) bogus (DOT) tld> wrote

Quote:

Excalibur wrote:
Hi All
Sorry about the empty reply again. I will strangle the moron that set
"reply group" as a single click when everything else is double.
[snip]

You are using Outlook Express as a UseNet client, right?

Which are these "everything else" that require a double click?

Not "Send/Recv," not "New Post," not "Reply," Not "Forward;"
in fact, I can't find an icon that _does_ require double click.

--
frosty

#45

Excalibur wrote:

Quote:

Hi Frosty
Try bringing up a message to reply without double clicking on it.
Regards

Sure, easy... found four ways to do just that.

--
frosty

#46

Quote:

Excalibur wrote:
Hi Frosty
Try bringing up a message to reply without double clicking on it.
Regards

frosty wrote:
Sure, easy... found four ways to do just that.

Sorry, did I say, "Four?" I meant "Seven."

--
frosty

#47

dawn wrote:

[snip]

Quote:

AJAX also holds the promise of letting us write UI's that give the user
the benefits of our character interfaces with its responsiveness plus
the ease of use, no training necessary, of the 90's GUI's because of
the asynch services architecture. It isn't yet _easy_ to write
really-satisfying applications that run in a browser, but the
popularity is going to explode, not go away any time soon.

Of course I could be wrong. But you wouldn't believe how much effort
it was to convince my colleagues that the internet was going to be huge
after I saw Cello, followed by lynx and Mosaic. I did a talk in 1993
about database-backed web sites (using Mosaic, predating both Netscape
and IE). I'm doing AJAX talks now. My track record might have a
little dent in it by picking Java, which might be hugely successful but
is still not easy for software development IMO. So, time will tell.

I think that the biggest obstacle to the success of the "browser as
platform" model is Microsoft Impotent Exploder. It takes simply forever
for new features to be adopted, and many highly useful features just
never make it in there at all. Hence the endless, tortured stylesheets,
made more and more complex just to support simple features in a
cross-browser way. Like tying to place a <div> at the bottom of the
screen - dead easy using standard CSS, but insanely difficult (and
incompatible) in IE. Phooey!

It's this sort of obstructionism and foot-dragging that is going to kill
off the BAP model, IMO.

Luke

#48

sh wrote:

Quote:

"ClickOnce reduces the time and effort required to deploy Windows
applications across a network. Rather than distribute a separate
executable to each individual hard drive, ClickOnce places the
executable on a common Web page, from which all users can launch it."

"Updates to the Windows application can be re-published to the Web
server, and the newer application files are then available to clients.
If an older version of the Windows application opens locally on a client
machine, an update dialog box gives the option to check for updates from
the Web server."

Definitely not as easy as a browser update, but you clearly don't have
to run around to those 120 fat clients to install the update.

Sun also has Java Webstart, which offers the same flexibility.
Deployment is no big deal.

Luke

#49

Kevin Powick wrote:
[snip]

Quote:

Yes, there is nothing more feature rich than a fat GUI client, but
there is also nothing more time-consuming and resource intensive to
develop, deploy, and maintain.

Where I contend that web-based apps are far harder to develop and
(especially) to debug. And they also introduce far more complexity in
areas such as concurrency handling. Moreover, even with Javascript,
sometimes, there simply aren't enough hooks to hang your Javascript from.

Quote:

There are no 5 minute fixes when it involves a fat client. From the
time a change/fix is requested until it is fully implemented, tested,
and deployed in the field is rarely less than an hour -- If not
entirely held off until the next "upgrade" which could be days, weeks,
or months.

I'm not a big fan of five-minute fixes on live systems. Certainly if you
uncover a disastrous bug, you should (and can) make quick fixes, in both
models, but in general, I'd discourage that approach.

[snip]

Quote:

I agree. I don't think anyone is pushing the browser as the be all and
end all fat client replacement.

You don't? Dawn seems to see it that way - even to word processors and
spreadsheets. And she's not the only one.

Quote:

As usual, one needs to use the appropriate tools for the project at
hand.

Sensible. I see the browser as the appropriate tool for occasional use
apps and/or for extranet access. For everything else, I like the fat
client. Of course, when it comes to Multivalue access, there are plenty
of complications, but I'm speaking more in general terms than just MV.

Luke

#50

Kevin Powick wrote:

Quote:

I don't disagree. I just think it depends on the application and I'm
not willing to dismiss the thin-client approach out of hand, as Luke
and you intitially did, in favour of fat clients.

"Out of hand" makes it sound like I haven't bothered to study and use
the technology, which is a base canard. I've been using the crud for
years, and I've seen its underwear. "The Emperor has no clothes!" <g>

Quote:

Btw, are you still developing fat clients with the same technology as
you did 5 or 10 years ago? Will you be using today's technology in 5
or 10 years?

How long is the release cycle on IE? You might be using "the same
technology" in twenty years after IE7 finally leaks out. ;^)

Quote:

Things change, and though I don't think we should jump on every new
technology trend that comes along, I think we need to remain open
minded and sensitive to the desires and requirements of our customers

You bet. And I can and do recommend and develop browser-based apps
wherever they seem appropriate. But for the really meaty,
mission-critical apps? Never.

Luke