Re: Accounting Vendors

This discussion of accounting software has been interesting on several  levels. 
 My minor was in accounting.  Most of my experience  as a developer has been 
with accounting solutions.
  
  Perhaps 95% of the applications I've developed in the past five (5)  years 
produce HTML output, but in many ways I yearn for the simplicity  and economy 
of green-screen programming.  In developing  green-screen applications, most of 
my time would be focused on business  requirements.  Now, much more time is 
spent on UI requirements.
  
  As far as economy is concerned, I once asked a colleague to measure CPU  
utilization of a green-screen application that had been "refaced" using  IBM's 
Webfacing tool.  The result was that the Webfaced version  consumed about 35 
times more CPU, and decreased end-user productivity.
  
  I doubt that iSeries accounting software vendors are getting the  mileage 
they need out of interim "refacing" solutions, which from an  end-user 
perspective provide little more than a tax on an otherwise  5250 interface.  On 
the other hand, there's an interesting  psychological element that makes GUI 
more appealing to most people,  like adding color to old movies.
  
  This weekend my wife and I placed an order for a new sewing machine and  
accessories.  Our sales lady entered the order using a Windows  thick-GUI 
client, which required her to alternate between keyboard and  mouse several 
time to complete the order.  A UI with either strait  keyboard, or strait mouse 
clicking would have made the job easier.
  
  For those suggesting AJAX, consider that AJAX is not the same as so  called 
"rich-thin" user interfaces, which in most cases are neither  rich nor thin.  
They're not rich because they're hard to  develop.  They're not thin because 
they require extensive runtime  engines, built with JavaScript, to be 
downloaded to the browser, such  as the email client from www.zimbra.com.
  
  These user interfaces seem to be byproducts of server lag times that  occur 
in request-response cycles, due to poorly performing server  technologies, such 
as J2EE, .Net, script based interpretive  environments, and bulky documents 
that traverse limited bandwidths.  It's much easier for developers to implement 
and maintain server based  UI control logic than develop extensive runtime 
engines with  JavaScript, but people need server interfaces that are more 
responsive.
  
  Ultimately, iSeries ISVs will need to provide value in the form of  database 
designs that are more point and click oriented, UI design  patterns that 
streamline end-user I/O, and server interfaces that are  EFFICIENT!
  
  Nathan Andelin
  
  
                
---------------------------------
 Yahoo! Personals
 Skip the bars and set-ups and start using Yahoo! Personals for free