Re: Green-screen versus browser -- MIDRANGE-L

Hi Scott- 

I agree with you completely: I spend a lot of time dealing with DSPF
design (mixed case labels, consistent field attributes, consistent
label terminology, fields lined up to promote easier reading).  My
(mostly) DDS dabatase has mixed-case column headings (right-justified
for numerics, of course), mixed-case text, and edit codes.  Command
keys are highly standardized; every application panel has a custom F1
(help) panel.  And of course there are strong, enforced naming
standards and conventions application-wide.  I don't call any of this
"cosmetic"; it's mission-critical function, usability, and
documentation.

Having readable TEXT() allows me to program-generate help panel groups
and insert the help keywords into DSPF's automatically; I just extract
it from the database.  It's another example of why doing the right
thing pays off later.

One problem is knowing I can make a browser application look and work
much better by adjusting font size, color, and type; by using varying
colors to indicate degree of a given status; and by using a few little
icons to denote status.  But you can't beat green screen for
time-to-deliver or response.

Except for 5250 and CGIDEV2, I don't have any useful knowledge of
other UI's.  I need to commit to investigating all major approaches
(in my spare time).

Unfortunately, many senior executives associate green-screen
applications with old, tired products.  How many CxO's know that
iSeries won the 2001 Linux World award for best Linux integration? 
Not many, probably, because IBM's done a crummy job of beating that
drum.  The drum and bugle corps is out for WebSphere every day.

-reeve

On 4/25/05, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx> wrote:
> Hi Reeve,
> 
> >
> > Am I missing any points meaningful to senior management?
> 
> I think one of the major issues that you're missing is the idea of
> "presentation" vs "utility".  How something is presented to the user makes
> a big difference, even if it doesn't seem practical.
> 
> For example, When you walk down the aisle of a grocery store, studies have
> shown that the packages that are most pleasing to the eye are the ones
> that sell. Not necessarily the food that tastes the best, or has the
> lowest price (Though those factors do help!) but the most important thing
> for attracting customers is how the package looks.
> 
> The same is true of your screens. How they look to the user is a BIG DEAL
> as to how satisfied your users will be. This is the face of your
> application to them, this is all they see.
> 
> Sure, green screens are practical.
> 
> Let me use another analogy... clothing.  What's needed for clothes to be
> practical?  They don't have to match. They don't have to look good at all,
> in fact. They just have to protect you from the weather, that's all. Yet,
> it's very important to all of us to look good. We want nice looking, new
> clothes. We want to coordinate them so the colors look good together, they
> fit us well (well, some better than others!) and that they're appropriate
> for different events. How they look to others is paramount.
> 
> The same is true for your comptuer programs.  How the screens look is
> absolutely vital. You should be putting as much effort into how they look
> as you do into how they work -- both are important!
> 
> And that's a HUGE reason why green screen fails.  In fact, the green
> screen paradigm is a big part of the decline of the iSeries.  Nobody wants
> a system where all/most of the programs are green screen.  It's ABSOLUTELY
> KILLING US.  And IBM has given us not one, but SEVERAL ways to make them
> GUI and for some reason we're not doing it.
> 
> There's more to marketing than paying for advertisements!  You have to
> make your applications look good, and when everyone does that, it'll make
> the iSeries look good.  Until then, it's a "legacy machine."
> 
> ---
> Scott Klement  http://www.scottklement.com
> --
> 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.
> 
>