[Tutor] On GUI's

[Alan Gauld]

DT> I understand what you are saying but lets take a look at the
regular "user".

I know what you mean David, but strictly speaking the *regular* user
is the one who benefits from a command line interface, it is the
*irregular user* who benefits from a GUI! :-)

DT> If we had a program like the one below and (for conversation's
sake) only
DT> the payroll individual can work within the program, now the person
that is
DT> in charge of inputting the information has quit.  Now we have to
train some
DT> one else all over to do this same thing.

And the question you need to answer is:
Will the cost of training exceed the time saved in improved
productivity after training? In other words how often do you
need to train.?

DT> With a GUI it is much more time and cost efficient to train and
use.

NO, its more cost efficient to train but not to use.
A good CLI is faster than a GUI, but less friendly.

The book "The Pragmatic Programmer" has much to say on this.

ML>   - If you have made a program like the one I suggested, you can
always
ML>     wrap it in a GUI or a Web UI. If it's a well written python
program,

And this is an absolutely vital point. If you structure your
program well you can separate the interface from the working
code. This allows you to wrap it in a GUI as well as have a
CLI. The users get the best of both worlds.

ML>  - People who only use GUIs never learn how to actually empower
ML> themselves by making the computer work for them in an effective
ML> way. They use the computer as "power steering" to make their
ML> work a little simpler,

And of course there is nothing wrong with this either. Provided
we recognise the limitations of the approach. For example I used
command line email for years and it had a lot of power. But
nowadays I use a GUI client and am quite happy because I simply
don't need the power. And for the few things I do in mail the GUI
is more fun to use.

Alan G