[OT] Re: GUI's and the Rouge, Part III (yes, finally) 1/2

ruby-talk
1

I completely agree that the core functionality
should

not be dependant on the GUI. But since the GUI is
likely to be larger, more difficult, and much more
influenced by OS/toolkit/user considerations than
the

‘core’, it’s something to develop over the whole
life

of the project rather than add as an enhancement.

Do customers (of software) pay for core
functionality, or
the GUI?

Well, in the case of ‘Gui-focused’ software, which is
what I was discussing, and which is also the case in
which the GUI is likely to be more interesting, more
complex, and less easily developed with existing tools
available to Ruby, then the answer is, as far as I
know, ‘yes’.

This ‘yes’ may frequently be delivered at high volume,
although in some cases the message still doesn’t seem
to propagate as well as one would hope.

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.

I feel that the distinction you are making between
’real’ functionality and the GUI is very much a
product of one particular software environment.
Within that environment, perhaps it makes sense to
’extend’ an existing application with a GUI, and
perhaps you can expect the GUI to always take up much
less effort than the ‘real’ functionality. This is
not, however, a general truth.

If the GUI is “larger, more difficult, and much more
influenced by OS/toolkit/user considerations”, is
this
necessary or is it coincidental?

It is necessary, as far as I know. In an application
such as a real-time trading system, for instance, if I
found back-end code was bigger or more complex GUI
code I would know something was BADLY WRONG with the
back-end. Or that some silly person had placed what
is really business logic belonging on the server in
the back-end of the client. But enough about my
troubles…

do think it’s an easy trap to fall into to say that
"the UI is the closest layer to the user andtherefore
the layer the user will be most critical of, so it’s
the most important layer to do well"

How very true. I myself often find myself saying,
“The UI takes up 95% of the specification and 80% of
the code, is the only part that’s difficult, and is
the only part anyone outside this office cares about,
so it’s the most important layer to do well.” I must
remember to slap myself on the wrist when I catch
myself thinking that way :>

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 :slight_smile:

x

2

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 :slight_smile:

yes! :slight_smile:

clemens