Booth!

I see you have attended my GUI Tips session..

Yes, there is much more to GUI - it really is all about the USER part of the
interface, not so much as the Graphical part. The User Interface is
definitely something that we programmers have not been trained to
understand. We do it by rote, and by the way people have done it before. We
pack as much on the screen, and abbreviate because we can. We use colors
that don't work together, and colors whose low contrasting values mean
colorblind people cannot see them. I constantly see red backgrounds with
aqua text - something that burns your retina - because a programmer thought
it looked cool.

There is MUCH more to the user interface, though, than a browser. Part of
the interface is removing the ENTRY part, and replacing it with technology
that can do it for you. RFID, eye scanners, fingerprint readers, bar code
readers, wireless, bluetooth, speech-to-text.. to name a few. The discussion
that Paul started was that green is better for data entry than GUI. I
disagree, because I use a GUI tool that does data entry well, but for the
most part, GUI slows down a data entry function due to poor design or a poor
tool.

My conjecture is that we remove data entry, then we don't argue any more
about which is faster - since 'pure' data entry is gone. Of course, this is
mostly around batch forms of data entry, not the one-at-a-time entry that is
now in most web apps. Moving data entry from a telephone operator to the web
user is also one way to remove the heads-down data entry function.

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

Trevor




On 9/13/07 2:45 PM, "Booth Martin" <booth@xxxxxxxxxxxx> wrote:

Several years ago I decided that VARPG would survive and Java would not,
so I learned VARPG. Oh well. :)

In the process I realized that there are huge design differences between
event driven and cycle driven design. Applying cycle solutions to an
event driven method is just a horrible choice. Paul is absolutely
right with what he says, in my opinion. I believe that where we have
failed our masters is that we have not understood the difference in
designs well enough for us to show off the possibilities well. Being
able to transfer green screen thinking to a web browser will look like
lipstick on a pig.

Again, my opinion, but I believe we need to learn a lot more about the
design issues if we want to truly use GUI interfaces. I do not mean the
graphics, but the way we present and retrieve information and how we
communicate to the user. Drill downs, use of colors, mouse-overs, and
the order of processing data. We need to understand type-ahead fields,
radio buttons, icon use instead of menus, drag & drop, and updating one
window from another window. These are the things that work and provide
huge training benefits and gains. Productivity can move up, too, if
we do it right.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.