|
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 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.