Sorry I haven't been responding.  I have been on vacation.  Not that I
needed it;-)

Brad, I agree to your logic to a certain extent.  We are remodeling our
software to have much of the business logic in modules so ANY interface can
get the information it needs and display it in whatever way it needs.  I
don't think the web is bad because of the complexity of showing a lot of
data from a lot of different files, I think it would rather be saving the
state and knowing what to do when the user clicks on different hyper links
and you no longer have the benefit of F3 control where you know when the
user is all done and can do final processing.  Of course all of these things
can be programmed into your programs, it will just take retraining your
users on how to run the different apps and commit data.

The best thing about a browser is that you don't need to deploy it to
anywhere except your webserver, period.  If I started doing thick client
applications then I would really have a deployment problem.  Of course I am
sure there are ways around this also if I built architecture to check to see
if they had the latest version before running the app.

There is one point that I didn't mention.  Our development group provides
software to some 20+ companies (almost all on different 400's).  Would I
want to support 20+ HTTP servers? YIKES!

Just some thoughts,
Aaron Bartell


-----Original Message-----
From: Brad Stone
To: web400@midrange.com
Sent: 8/12/02 3:46 PM
Subject: Re: [WEB400] Customer Service -- Online

Walden,

On Mon, 12 Aug 2002 14:26:57 -0400
 "Walden H. Leverich" <WaldenL@TechSoftInc.com> wrote:
> >From: Brad Stone [mailto:brad@bvstools.com]
> >IMHO, though, if this if for your in house CSRs, I'd
> steer clear of the
> web.
>
> Why? Expecially in-house he'd be free to control the
> browser used and could
> use browser-specific HTML. Even w/o browser-specific HTML
> you can get a
> rather powerful app, what are you afraid he'd miss?
>
> I think the ease of deployment would more that make up
> for the additional HP
> needed on the server side.
>
> -Walden

Because I know the people and business that he's building
this for very well.

Web apps are great, don't get me wrong.  But when you want
something that's going to be very complex, web isn't always
the best solution.

Yes, the web works great for simple order history, customer
service, and ordering.  But that's because these people are
outside of the business and don't need to know everything to
the last detail.  Just the basics.  Perfect fit for the web.
And the biggest reason, it needs to be an app that everone
can get to.  Web again is perfect for that because we can't
control what the customer is using to access the data.  We
can just make sure it's a web browser.

But in-house, when we'll be viewing items down to the lowest
level of customization, linking with AR, order history,
etc..  things get a little complex.  And just when you think
you have it, it gets more complex.  Not a great fit for web.
But possible.  There are better alternatives especially when
you can control the UI being used.

It could be done.  Im just saying web isn't the best fit for
everything.  And it's not just HP that's the problem.  It is
the UI.  If web was perfect for everything then we wouldn't
need VB, Java, VRPG, or other good GUI tools.  Fact is, we
do.

Brad
_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/web400
or email: WEB400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.