× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Booth,

There are two problems with many of the old green screen designs. First is
that the paradigm has changed. When most of the 5250 applications were
written, communications time and CPU time were an issue. We designed the
screens to complete a single transaction at the press of the enter screen,
because it might take almost 5 seconds to send the screen from the remote
site to the CPU, process the transaction, and return the response to the
terminal.

The second thing that has happened is that over the 20-30 years the
application has been in use, there have been a number "just add one more
field to the screen, move this line down, eliminate that blank line"
fixes. What began as a readable screen is now unreadable. It no longer
tabs in the proper order, and the blank space that separated the different
areas have been eliminated. No one wanted to/was allowed to break the
screen apart into more readable, easier to use separate screens, because
that would take too long. In the current environment, dividing the over
crowded green screen into several subparts of the transaction would make
the screens much easier to use.

Along the way, most people have become used to the browser interface, with
radio buttons, and drop down boxes. But the browser interface is not
always easy. I get frustrated at poorly designed browser interfaces. I
don't like entering a dates like my birthdate/credit card expiration dates
from drop down boxes. I find it much easier to key that directly, rather
than scrolling through a drop down to choose my birth year. Certainly
there are times that choosing dates from a list makes sense, such as when
entering hotel/flight reservations from a calendar are sensible and easy.


Steven Morrison
Fidelity Express




Booth Martin <booth@xxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
09/13/2007 03:54 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Thin Clients






You demonstrate the point I believe. The issue isn't one of
"prettiness" as much as it is an issue of work flow and user
interaction. As Trevor said earlier, we were taught that the screen is
24 x 80: Use it! However that is not the case with gui design. Instead
of cramming everything on one screen and then processing it once its all
filled in, we can better do it a bit at a time. For instance, get the
name: OK, what addresses does that name have? Pick one. Ship to
different? Does the name & address need repair/maintenance? If so, do
it (whatever "it" is). Credit OK? Contact names? OK, move on. what to
order? (Side window showing related items to uptick the sale), side
window showing previous orders, all with drill down. Order complete?
Shipping suggestions, choices, and costs. Ok to ship? Thank you.
etc. Same ideas, applied to green screen design, would move green
screens to the unproductive side of the ledger, in my opinion.




Wilt, Charles wrote:
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Trevor Perry
Sent: Thursday, September 13, 2007 3:33 PM
To: Midrange Systems Technical Discussion
Subject: Re: Thin Clients


<snip>

And yes, we need to learn more about GUI, UI, Human
Interaction Guidelines, graphic design, and so on. This is
not the world of the usual programmer.
And not the world of most people selling green to GUI tools.
The GUI produced by some just makes people want to go back to
ugly green. Therein lies the problem...



I'm not so sure WE need to or even should learn all that.

While I can put together a functional web site, it won't be really
"pretty". I'm a Software Engineer
not a Graphics Designer or Graphics Artist.

IMHO, one of the biggest problems with GUI applications, is that you
have one (or more) software guys
trying to do all that you mention above. Granted in small shops, you
might not have much choice. But
for critical projects, you really need a team. There is after all a
reason there's a separate degree
for each of the disciplines you mention above.

Sure, there needs to be some cross over. The software guy should know a
little about UI design and
Human Factors Engineering. Depending on the project, he may know
enough.

When you've got a software guy doing everything, you'll (probably :-)
end up with a 100% functional
app. But I bet you'll be able to tell it's not a usable or a visually
impressive as it could have
been.

One of the best experiences I had was with a Extranet web site.
Consulting for a small prior
employer, I worked with outside web consulting firm on the site. I
handled writing the stored
procedures on the iSeries that handled the data being passed in and
return the data required. Worked
with the web guy to determine just what was needed where, which he then
put together using Coldfusion
and his graphics designer handled the actual look.

It was a very successful project which was well received by the
customers using it.

Just my .02

Charles


This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not a
named addressee you are hereby notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so is prohibited and may be unlawful.
Please reply to the message immediately by informing the sender that the
message was misdirected. After replying, please delete and otherwise
erase it and any attachments from your computer system. Your assistance
in correcting this error is appreciated.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.