RE: GUI development language

Hi Joe

I won't argue the additional complexity (I couldn't if I wanted to) but the
issue of multiple Operating Systems is fairly solvable by using a virtual
machine. It comes down to whether the extra layer(s) of software is
justified by a productivity gain.

Delivery of updates to a fat or rich client is also reasonably easily
achieved; there are plenty of approaches and products to make this work if
the justification exists.

Since browsers are based on the OS they are just as subject to the vagaries
of modern day OS issues as application software. I've seen and had plenty of
experiences of browsers doing weird things or needing re-installation. With
multiple browsers as potential clients I think it would often be a case of
"it depends" as to whether supporting a browser app is more work than a
rich/fat client, depending on how well the client is written - and that's
definitely an important point, if not the most important.

I'm still not convinced a browser interface can match the Windows interface
- it is a hugely rich and productive environment when it works, just light
years ahead of the browser interface, at least in my opinion. Every complex
browser GUI I have seen just sucks compared to a decent Windows counterpart;
Outlook Web Access was mentioned earlier and it's a great example of how
clunky the web interface can be. The Google Spreadsheet is another. Using
either of these works but is something of an exercise in frustration.

On the other hand, despite the OWA interface, I use it regularly because it
is so readily accessible no matter where I happen to be working. That's a
pretty useful property to have, but I'm not sure I would ditch the full
application.

I think it would be hard to argue the point that a Windows interface is much
more productive than a Browser interface. It's true that for data entry 5250
is probably even more productive than Windows but 2 factors work against
this: the windows interface is well understood by most if not all users and
does not require the training that a 5250 interface requires; secondly, much
more of the work people do now compared to the past is devoted to
information access rather than data entry, so the advantages of the 5250
interface are diminished. It is a poor presentation medium compared to
modern alternatives.

On this last point, I'd have to agree that a browser app can make some
claims as being a better delivery medium than a windows based client in
terms of presentation and access to data, particularly given the fact that
access is no longer tied to the desktop. If lots of interaction with the
data is required then the browser starts to struggle.

Regards
Evan Harris

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx

[mailto:midrange-l-bounces@xxxxxxxxxxxx]

On Behalf Of Joe Pluta
Sent: Wednesday, 5 September 2007 2:38 p.m.
To: 'Midrange Systems Technical Discussion'
Subject: RE: GUI development language

From: albartell

I also have to say, "Duh." <grin>

Of all people I wouldn't have expected you to consider something "good
enough" :-)

Hmm. Then you haven't been reading what I write. What I say is "it's a
business decision" and in a business decision, if it's good enough for the
user, it's good enough. Which begs the question: if speed is really the
issue, why aren't you pushing 5250 applications? There's hardly a person

on

this list who wouldn't agree that 5250 is the fastest interface out there.

I would take that more like "the customer isn't complaining so
neither am I". Or "...they are used to slow web applications; why

can't

mine be too?"

No, I would take it as "How much more productive is the user with a

browser

vs. a thick client." And "How much longer does it take to make a thick
client, and how much more does it cost to support it?" Balancing those
questions is what an IT manager does. Architects and academics think up

cool

ways to do things; managers figure out how to pay for them.

What is the issue? There is no "back button" in a thick client

application, so it seems to me the only problem is disabling it. I do
that in PSC/400 quite effectively.

Re-POST's. It more might be the framework/technology I am using (i.e.
JSF)
than anything. There was a good podcast by somebody well respected
titled "JSF, the 7 layer burrito". This was one of the issues they

brought

up.

Far be it from to suggest that you might be displaying a little bit of a
tendency to repeat other people's complaints without really understanding

the

underlying issues, Aaron, but it seems to me that you might be displaying

a

little bit of a tendency to repeat other people's complaints without

really

understanding the underlying issues. :)

I think a lot of what we would both agree on is that the browser can
implement MANY *cool* features that we haven't seen much before, but
they are still second place to a well designed "rich client".

I almost never see a situation where one technology is inherently "second"
to another. I think that's a classic trap technologists fall into; they
become enamored with some technology and then insist it's better than

anything

out there. Each technological decision is a business decision: how much

does

it cost, and much does the company profit by this choice. And once those

are

answered, then you can afford the luxury of worrying about strategic

direction

and platform independence and technological elegance.

But instead you're going to write a fat client and have to worry
about

the
OS wars!

Writing for the OS has potentially less work involved than writing for
x times the number of browsers on each OS. I am not saying developing
a Java "smart client" for 4 or 5 OSes would be easy, I am simply
saying that the environments to write for are less in number vs.
having to retest your web app with each browser on each OS. I still
remember my first RPG CGI app about seven years ago. It worked fine
with IE on Windows and did work fine with IE on the Mac.

This is hogwash and poppycock, Aaron. The differences in graphic APIs far
outweigh the differences in browsers. By orders of magnitude. What's the
analog of an HWnd in GTK? How do you write to a printer in Windows?

I'm guessing here, but I don't think you've ever tried to deploy a multi-
platform thick client application. Remember, even if you go the route of

a

renderer (e.g. a rich client), the renderer itself is a full-blown thick
client, subject to all the vagaries of thick client distribution).
It's hard enough to deploy a single-platform thick client. Good luck
deploying it across 10 operating systems.

Piece of cake with a chromeless browser.

<cough> Hack. :-) I had a PHP app that did this. Most annoying app
I ever wrote because it always had two browser windows open. It was a
customer mandate. Two years later they paid me to take it out because
they thought it was too annoying also :-)

It's not a hack. It's an easily implemented feature. The biggest problem

is

going from an normal browser session to a chromeless one, because the

system

thinks it's a popup. But if you're going to write your own thick client,

it's

almost inconsequential to write your own chromeless browser.

Another one I forgot in my initial post:
7) Type ahead. I am not even a fast order entry type person, but when
I know an app well I REALLY enjoy the benefit of type ahead.
Inherently that means the app is going slower than me, so yes there
are many a thick/fat/rich client apps that still aren't as fast as I
like - but I don't have type ahead capabilities in a browser
(potential ignorance again - but I am guessing I am right).

You can implement type ahead with Ajax.

But for those applications that absolutely require type ahead, I again

assume

you're planning to use a 5250 interface, because that is by far the

fastest

interface available.

Joe


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list To

post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,

or

change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a

moment

to review the archives at http://archive.midrange.com/midrange-l.