Re: GUI v Script

From: Guy (
Date: 11/08/03

Date: Sat, 08 Nov 2003 22:27:36 GMT

"Richard Dell" <> wrote in message
> Not strictly an OO question, but I could not find a more appropriate NG
for this
> issue, as I know serious professionals use it.
> I maintain an old system which has a locally developed script interface.
It is,
> in fact, a superset of Fortran, and quite an elegant one at that. I have
> unable to persuade my colleagues of the virtues of providing a script
> as compared with a new GUI interface. My own view is that:
> 1 GUIs cannot ever match the flexibility of scripts. If the designer of a
> has anticipated a need, then the app will do it well and efficiently, if
> then the app cannot do it at all. Perhaps this is best illustrated by a
> comparison of Windows with VMS DCL.
> 2 Once you have the vocabulary of a script interface, most users will
> faster with a CLI than a GUI, particularly if the GUI is like Windows,
where the
> design changes such that a particular function has moved to another
> 3 A script interface with a parser may well be harder to design, because
> requires more thought to work at all, whereas a GUI can be knocked
> without much thought. It often shows.
> 4 Scripts impose discipline on users. For a complex and powerful
> planning what you intend to do is much easier with a script, because you
> develop what you intend to do in advance, and see errors in your logic
> you submit it. With a GUI, you may have scraps of paper with a rough route
> but get lost in the middle of your session.
> 5 Scripts give an audit trail. The results can be compared with the
input, and
> errors spotted fairly quickly. For production work, errors or
> should be obvious to your customers.
> It comes down to horses for courses. The more powerful and complex the
> requirement, the design of a GUI increases exponentially in complexity,
> the development of a script interface has an linear characteristic. Maybe
> are not that many requirements that merit the design of a script
interface, such
> that their merits are seldom appreciated.
> Comments?

The first GUI system I worked on was to replace a data tabulation system
which had a custom specification language with a GUI specification system.
The client was dissatisfied with the old system because it required staff
with both programming skills and subject matter knowledge. At that time,
programmers were scarce, so it was becoming very difficult to find and
retain programmers willing to spend 6-12 months to learn a programming
language and complex subject matter which was only useful in one place.

The GUI specification system now allows non-programming subject matter
experts to produce custom tables, and this cut down the turn-around for
these from months (waiting for a programmer to become available) to hours.

As other posters point out, a well designed GUI program must allow new
features to be added to accommodate new requirements. But this is also true
of scripting languages which aren't totally general purpose.

For our project, we built the GUI around a central theme which was familiar
to the users. We also provided feedback in the form of displaying a
prototype of the final product, minus the actual data, so they could verify
their spec before submitting it for processing.