[sword-devel] Re: GUI interfaces

[Jerry Kreps]

On Wednesday 19 December 2001 15:24, Stuart D. Gathman wrote:
[snip]
>
> GUIs are nice.  Their benefit lies in making the abstract appear
> concrete - visible and audible in todays technology, more in
> tomorrows technology.
>
> However, GUIs have a serious drawback.  They require a warm body to
> operate them.  All too often, I struggle with anger because some
> utility is available in a GUI interface only.  This means some poor
> soul has to sit in front of a screen somewhere and click a mouse
> and/or keyboard until the task is done, when they could be home
> with their family. Countless hours are wasted with GUI chores that
> could be automated if only a command line or other programmatic
> interface was provided.

More than likely you encountered a GUI app written by a command line 
coder.  Not too intutive and not mindful of standard mouseing rules.

BTW, doesn't your 'warm body' operate the keyboard on the command 
line as you type in the utility name and parameters?  :)    

I understand what you are saying, though.... gui-less utilities allow 
unattended batch processing, for example.  I use that approach all 
the time.  But, to my users, it is just another app activated by 
clicking a mouse.  They don't write the scripts nor do they care 
about the utility.    The job is what counts.    For example, to 
replace Win98E running the Wildcat BBS,  I wrote one bash script, one 
page long, and two python scripts, also one page each.   The bash 
script is what is executed when the user logs into their account. and 
it restricts their activity to three tasks, or logging out.  The two 
python scripts automate two repetative manual processes that the BBS 
admin does.  Both python scripts are accessed via desktop icons that 
the BBS admin clicks on.   Both scripts could have been coded as 
exposed methods of some resident object supplyling services and also 
triggered by a desktop gui, but the required processing and data 
movement was cut and dried.  Sound familiar?  

I've been using commandline utilities since 1978.  The biggest 
objection is that there are so many, they are obscure, and each have 
their own set of switches (parameters), and none are standardized as 
to what switches do what, except that either -h, --h, -help or --help 
calls up some form of help.  Frankly, as I got older, I got tired of 
trying to remember parameters, switches, etc..., and inevitably one 
loses the manual, if there ever was one, that explains them all.   

When I got into Linux four years ago the most popular coding tool was 
emacs, or xemacs.  I got O'Rilley's book and after a couple of 
chapters grasped the number of pluggins and switches that are 
associated with each one.   I realized that, having only 5 to 10 
activing coding years remaining ahead of me, there isn't enough time 
in life to endure such nonsense.  GUI apps are standardized far 
better than commandline apps are,  and the well designed ones  are 
intuitive.  The general user can move from app to app and never have 
to consult a manual on mouse clicks.  Coders writing GUI apps who 
short-circuit this design principal are shooting their apps and 
themselves in the foot.  A commandline app  is never intuttive, 
unless you were the coder that wrote it.

>
> Microsoft's solution to this problem is a programmatic interface. 
> Good Windows programs include a DDE or COM interface which is
> automatically available to Windows aware scripting languages. 
> (This is where the Windows term "automation" came from as in "OLE
> automation".)  The common unix solution to this problem is to
> provide a command line interface to the program.

The command line is not like Dynamic Data Exchange or Object Linking 
and Embedding, later expanded to become ActiveX, etc....  A script 
composing a shell program, ... maybe.  Scripts are not event driven 
like GUI interfaces are.   Part of the 'dynamic' is the user, for 
example, seeing clues in the data returned from, say, a remote 
server,  that causes him to mouse a  particular GUI control that 
triggers a particular event, out of many, causing the data to be 
moved, processed, returned, destroyed or what ever.  Such dynamic 
interaction is not possible with commandline utilities unless the 
'warm body' types commands that pipe data to files or does a screen 
capture, etc...  Object linking was created to allow an object to 
reuse code present in exposed methods of other objects.
GUI interfaces, of course, are not procedural, because the coder 
usually doesn't know in advance in what order events will be 
triggered, except in certain limited ways.  

>
> Command line utilities are not valuable because they are "friendly"
> to the casual user (they aren't).  They are valuable because they
> are easily integrated with other programs in a way that does not
> require user intervention.

That they are not 'friendly' is why they are dying, no matter how 
useful they've been in the past.   When it was only academics and 
geeks using them, and they were the only game in town, there was no 
other choice.    The number of people who are impressed by geek 
knowledge of utility apps and their parameters is rapidly dwindling.  

>
> How does this relate to Sword?  Well, Sword is currently available
> to C++ programs.  There should be alternate interfaces for other
> tools.  A simple command line tool to quote a verse by reference or
> output a concordance like list of references given a search key
> would be handy for a scripted web page or editor macros.  A C
> interface would be more easily wrapped for script languages like
> Python or Perl.  A command line tool would also let you search the
> Scriptures on a 4Mb 386 in console mode (although an ncurses
> frontend would be nicer for that).

Diatheke does that.  A curses version by Richard Holcombe also 
exists, but it has had less than 100 downloads in the last 9 months, 
which probably explains why Richard isn't too active right now.  The 
last work was on 0.16 on 2-17-2001.     I've noticed a lot of older 
geeks talk about the 4MB 386 as if there were a huge, unexploited  
market for software that would run on them.  There isn't.  If those 
boxes haven't been run the dialectrics in their capacitors have begun 
to or have dried out.  If they are being run then their component 
MTBF limits have been passed and they are in need of constant repair 
from a  pool of parts that are drying up.  No one makes 386 stuff 
anymore.  Few people write for it.  Even third world countries won't 
settle for them.  Would you be happy with a model T when everyone 
else is driving a 2001 Saturn?  Even my brother, Dennis Malepi, in 
Botswanna is using Pentiums and acquiring them for the Christian 
school he is building there.   

That BBS box I told you about is a P200 with 64MB of RAM and two 1GB 
HDs, running SuSE 6.4.  It replaced a P450 with 128MB running Wildcat 
because the higher ups didn't think Linux could do the job and they 
didn't want to waste a 'good' box on what they considered an 
experiment.  That was 16 monhts and ZERO crashes ago.  The WinXX 
'solution' averaged a couple of crashes a day and couldn't be left on 
overnight to allow after hours downloads from electronic taxpayers.  
The clerk that runs it says it is easier to use than the WinXX setup 
and KDE1 is just as easy to use as WinXX.  She says the P200 solution 
runs about twice as fast as the WinXX solution.

Finally, if folks had to install Linux distros the way they did when 
Slackware first came out......   Only the GUI install programs are 
giving Linux a fighting chance in the desktop arena.  GUI apps are 
rapidly taking over sever control too.  With will designed GUI apps 
users do not have to give up power, either.

The reign of the command line has come to an end.