|
High quality car makers care about how their cars look.
From: kurt.anderson@xxxxxxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Date: Tue, 12 May 2009 17:12:47 -0500
Subject: RE: GUI vs Green Screen was open source IBM i. was Re: From RGP to ¿Java ?
I'm sorry Vern, but your argument doesn't make sense. You're making the assumption that green screen doesn't require the user to... see? I've experienced life with users who don't look at their green screen while entering data - the pain of fixing their flubs hurt a lot. Or are you making the assumption that GUI must be point-and-click?
I really don't get this anti-GUI when it comes to data entry. At the very least, a GUI screen can be developed to look exactly like green screen. I don't know who'd want to do that, but it negates the idea that GUI is inherently bad in comparison to green screen. The important thing, when creating a GUI screen for data entry is to insure the user has the means of navigating the screen via keystrokes alone. The bonus is you get a nice look and feel. The bonus is (as someone previously mentioned) most of the computer literate workforce will have a basic idea of how to work a program. The bonus is screen real estate (I can't express this one enough). The bonus is having additional functionality for those that do want to make use of the GUI-ness.
I'm pretty proud to say that at my previous job, our team developed a GUI order processing system that the users loved. The only real hurdle we faced was introducing change. But once they tasted the apple... The key was listening to the users.
Remember, Green Screen apps can be poorly designed for data entry as well. This hard-nosed opposition to a different form of delivery seems to me to only be resistance to change.
Back in school, given the choice of RPG, COBOL, C++ or VB (those were my choices)... I never had to even compare, RPG & COBOL had ugly development tools (here's hoping schools aren't teaching with SEU these days...) - and bland output. How I ended up in RPG was due to an internship. A blessing in disguise.
High quality car makers care about how their cars look. They don't walk around trying to sell high quality metal boxes that look like crap and say, "Well it's more reliable." There's a bigger picture here. To not understand that how a product looks impacts a person's acceptance of it... well, I'm sorry but marketing shows us that's how it is. Even the value of a soothing skin on a program interface can impact enjoyability of working with the program. A happy employee is better for a company than an unhappy employee. (Given, I'm not saying go make everything pretty and the ROI is a smile on someone's face.)
Whoah... sorry, I should have warned you, I was standing on a soapbox.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Tuesday, May 12, 2009 10:30 AM
To: Midrange Systems Technical Discussion
Subject: Re: open source IBM i. was Re: From RGP to ¿Java ?
Au contraire, Pierre! Or Jean!!
Any interface where you have to use your eye to locate where you are
entering text is inherently slow. It IS possible, probably, to write a
GUI app that uses tabs and some kind of newline key for navigation, but
it's not simple to do. Heads down data entry people really fly on green
screens.
Users that do occasional entry can use a well-designed GUI just fine, I
suppose.
JMHO
Vern
Josh Diggs wrote:
I don't really buy this argument. Of course people who already know the current process don't want it to change. In my opinion that has very little to do with green screen versus GUI. Instead, I think that is indicative of user's resistance to change. The other side of that coin is that any new users are almost certainly going to be GUI literate. As such you only have to train functionality, and not interface for new users.--
I do agree that green screen data entry is faster bar none.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Wintermute, Sharon
Sent: Tuesday, May 12, 2009 6:35 AM
To: Midrange Systems Technical Discussion
Subject: RE: open source IBM i. was Re: From RGP to ¿Java ?
One point I would like to make is that not every one WANTS a GUI.
For straight data entry purposes, its much faster to use a "green screen" style of entry. The end user that actually "uses" the system is not the one pushing for a gui - management is.
One client offered the users a choice, 8 out of 10 wanted the green screen. Speed of data entry was the reason. Point and click just does not give that to you. Most of the users used the type-ahead feature. At that point they didn't want the PC but it was forced on them for email purposes. Now, they see the benefit of point and click for some things, but straight data entry? - No.
Now granted the other 2 were casual users that really didn't enter any data, they simply "managed". They were the ones that wanted the same GUI type applications they had on their desktops.
Sharon Wintermute
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, May 12, 2009 8:20 AM
To: Midrange Systems Technical Discussion
Subject: Re: open source IBM i. was Re: From RGP to ¿Java ?
From: M. Lazarus
Have you gone on a sales call where your competition has the GUI and
you don't? I have and it's not pretty.
Your competition provides a GUI, and you don't? It was about 1993 when we began feeling pressure from prospects and competitors to provide a GUI - which begs the question, what have you been doing for the past 16 years, or so?
Waiting for IBM to fix the problem?
Nathan.
--
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.
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.
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.
midrange.com
