> Benjamin Peterson:

> > I think that applications that get driven by their UI rather than the
> > functionality the software is supposed
> > to deliver are doomed to fail (at least, relative to any competing
> > application which isn't UI-bound).
> 
> Hmm...  I can think of many real-life examples of successful UI-focused
> applications, but I don't think the distinction you are making between
> 'driven by UI' and 'driven by functionality' is valid for applications
> whose UI is the majority of their functionality.

you may be thinking of window$, where marketing suggests a GUI will make a
computer do things unthinkable of in earlier times, but this is a bad
example.

think of a simple grapher application used to draw polynomial curves for
teaching, or think of the remarkable idea of using markov trees to have the
unix command-line "learn" which character is the most propable the user
will type next depending on the history.  some of you may remember the
little program circulating the USENET decades ago, but i tried it and it
really, really works.  if only it had ...  but that's another story.

what i do currently is validating DNS domain requests.  for this i have to
check several items on a checklist that each can take between a few seconds
and a few weeks.  furthermore, it is not neccessary that i do this all by
myself for a given domain:  we have a system where several admins take on
requests from a list, so it could be possible /with an UI enabling this/,
that other admins pick up where i left off, with new incoming results. 
without this UI, however, even with a lot of helpful scripting, this is a
tedious task.

note that for our purposes it would not have to be a graphical UI, but it
is the flaws in current GUIs that make them unattractive.

> The next thing I think is usually "I wish I could do it in Ruby!" -- but
> I can't, because everyone who makes Ruby GUI tools is busy making stuff
> for bolting on X dialogs to existing programs :)

yes!  :)

clemens