Re: GUI necessary? -- MIDRANGE-L

>Dont worry, I do not consider difference of opinion as personal attack. One
thing i find interesting in your explanation is that, if i follow you, you
dont require graphics in a graphical user interface. In fact, the more or
less dynamic positioning/usage of buttons is enought to qualify as GUI. So,
program like deskview (of the dos days) would qualify as GUI even if it did
not follow the MS standard for mouse and keys.
>
>Am i on the right track here?

I take exception with the guys here who say there is no relation between
multi-tasking and GUI. I agree that MT can existing without GUI (the 400
proves that!), but it was a combo of GUI and the multi-tasking model that
caused user interface innovations. The way-back-when PARC and SmallTalk type
innovations would not have excited Jobs so without multitasking. The two are
forever tightly coupled.

While it could be argued that it didn't GUI to make MT happen on the
desktop, that is what made it happen. There were many character-based
DeskView like wannabes at the time--remember TopView? Or Borland's Lightning
on-the-fly DOS-based MT spelling checker. However, it was the Mac and  Win
3.1 that brought MT to the masses. I remember using Win 3.1 almost
exclusively as a DOS multi-tasking environment for Clipper programming. Man,
I thought it was so cool!  Character-based, yes, but don't tell these
multiple DOS windows didn't forever change my programming interface (edit,
compile, debug and run were all one click away!).

GUI clearly needs a new name. It's not longer just graphical, with pixels
and pictures, but now represents a class of user interface innotvation that
presents something to the something that looks rational and more intutively
presents choices. Like clearly labeled buttons ("Checking" or "Saving").

Anyone pondering this graphical stuff should read Alan Cooper's book, About
Face. Cooper is the father of VB and presents some terrific ideas on UI. And
he does it from the users perspective. For example, arguing that the best
thing a program can do for a user is remember things: where the user left
off, how to finish input fields, etc.

The whole notion of absolutely positioning character-based version
pixel-based as green-screen versus graphical should probably be given some
thought. Back in the old FoxPro days, you could make pretty good
character-based UIs, that accomplished most of the same things a
pixel-driven UI could do.

So, for me, it's a matter of not being absolute and selecting what works
best given the situation and _always_ putting the users needs ahead of
needing to stop coding by 5.

rp







+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---