Re: IBM HATS vs. ?

Buck,

We often hear bits and pieces of Webfacing woes. But you've shared quite a bit of anecdotal background, which is more candid and helpful than most.

My focus right now is on the development of a new financial accounting database & package, but if we were drawn into a modernization project, my approach would be to let DDS screens go by the wayside, and use relatively little existing RPG code in the final product. I'd generate new applications based on new Web 2.0 UI templates and RPG models, but may cut and paste data validation and business rules from existing source, where applicable.

It seems that we're nearing the phase where screen-scrapping won't cut it.

-Nathan.



----- Original Message ----
From: Buck <kc2hiz@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Tuesday, October 6, 2009 10:26:47 AM
Subject: Re: IBM HATS vs. ?

Frank wrote:

Hi Folks, I've heard that we've selected HATS for webfacing.? I'm not sure this is the right forum but...is that what you folk would choose for webfacing?? I see it has been recommed by 400stuff.?

I think that WebFacing is now rolled into HATS as far as sales,
marketing and support are concerned. Back when electrons were
individually carved out of grains of beach sand I spent a lot of time
WebFacing a large home grown ERP application. We had CUA standard
screens, standard function keys, standard header/footers for subfiles.
It was pretty sweet on the green screen side.

It converted the DSS and ran with very few technical issues; what issues
there were, were related to us using an incredibly undersized machine
(before POWER hardware) to run WebSphere Application Server.

In the end, we discovered the hard way that there are two types of
people in the user community. Green screen and Web. The Green Screen
people wanted... no, insisted on being able to use their familiar F keys
to navigate. They thought the resulting GUI was... queasy.

The Web people thought it was insane to have so many buttons (one per F
key) to click to move through an application. Web apps are supposed to
be stateless - how many F keys do you use when you surf Amazon, Yahoo or
Google? They thought the resulting GUI was... queasy.

The overall impression of the auto-converted DDS was that it looked like
someone changed the colours on the monitor from green to grey. The
Green Screen people thought the result was ugly and slow, the Web people
thought the result was ugly, slow and revoltingly counter-intuitive.

You (like me) can then spend lots of time tweaking the conversion,
adding widgets and the like but the end result is going to be the same
sequence of displays, stepped through in the same order as their green
screen precursors. If you (unlike me) have an unlimited time budget,
you can probably make your screens look pretty nice. They will never be
as good as a GUI created by a web person; how good is 'good enough?'
Only you can answer that one.

I'm probably going to go through this at my new place, and I'm going to
give my new boss the same advice I gave my earlier boss: We CAN deploy
our app on the browser. It will be slow, ugly and counter-intuitive to
web users but it will be a zero footprint deployment. We can spend time
to beautify the GUI, but every hour spent doing that will be an hour
taken away from the core re-write that will ultimately occur. If the
business insists that browser based is an imperative, then I'll do the
very best screen scraping possible, but it is impossible to make the
screen scraped / WebFaced / converted DDS look as good as the output
from a web programmer.

An app designed for the web starts off with a completely different set
of guidelines than a 5250 app does, and that's the bottom line. Good
luck to us both.
--buck
--
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.



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