Re: Question for Printer Gurus

I've helped quite a few customer "modernize" their applications by putting
them on the web (both intranet and internet). If done right, they love it
and ask for more.

It normally starts small. Maybe an open orders list. Then it grows when
they see what can be done.

The biggest issue I have is that the web technology changes so fast that
every 2-3 years you wish you could go back and implement the new
technologies (jQuery comes to mind... 5 years from now, it will be
something else that may replace that).

There are even instances I can think of 10+ years ago where a kit like
CGIDEV2 or eRPG SDK was not used.. just API wrappers! Yes, still in
production and working fine. But man, it would be so nice to convert them
over.

The second biggest issue is I'm a programmer, not a page designer. :) I
can make it functional as heck, but making it look super pretty should be
left to those that can do that. Most of those that can make them look nice
can't handle the functionality part. So if you find the right designer,
you can make a great team and provide an excellent product.

The third issue is browser compatibility. I've run into a lot of shops
where they have Javascript turned off, are using IE 7 or lower, and can't
or won't change that.

Brad
www.bvstools.com


On Thu, Sep 4, 2014 at 11:28 AM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

It's funny. In the shops I worked in everyone wanted their reports in GUI
and everything had to be converted to Excel. Nobody wanted printed reports.

Everyone wanted GUI front ends. "Why can't I have GUI screens like I get on
my PC applications.". Now making that happen was damn near impossible but
that was always the request and I don't know how many AS/400 that ceased
being because the management wanted GUI applications and the AS/400 people
told them they couldn't do that.


On Thu, Sep 4, 2014 at 8:59 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 9/4/2014 9:56 AM, John Yeung wrote:

Re: Partial laundry list of user rationale for printed output

Was this just an illustration of how difficult it is to get some folks
away from printed output, or does it also imply that your users have
been less resistant to migration away from green screens? And if the
latter, how successful have you been at migrating away from green
screens?

We are 100% green screen by the very vocal choice of our end users and
their managers.

The reason I ask is that the technical issue still remains:

Finally, regardless of how easy or hard it is to learn other UI
technologies and paradigms, in large existing systems, it's easier to
replace printer files one by one in organic fashion than it is to
replace a display file here and a display file there.

Granted, different shops are very different. Maybe in some places, it
is indeed easier to replace display files organically. I struggle to
see how that would be the case, though.

Display files tend to come in clusters, given the modal nature of our
applications which use them. There's a panel to enter the customer
number, a panel to verify the sold to / ship to information, a panel to
handle purchase order number and other ancillary information, a panel to
enter items, a panel to verify the order and a panel to ask 'are you
sure?' In this sort of environment, it's really difficult to extract
just one of those panels and make it a web page.

Printed reports tend to be less like that, but still the tendency is
there. No one wants to get their weekly aged trial balance on the web,
the delinquent customer list in Excel, the customer list in PDF and the
top ten dollar amount delinquents on their dashboard. All of those
reports are related, at least in the mind of the person tasked with
dealing with them.

The technical problem is less, but the procedural problem still exists.

:-(

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