# \[OT\] Re: GUI's and the Rouge, Part III (yes, finally) 1/2 **URL:** \ **Category:** ruby-talk\ **Created:** [25 July 2002 12:53 UTC](https://rubytalk.org/t/ot-re-guis-and-the-rouge-part-iii-yes-finally-1-2/845 "2002-07-25T12:53:07Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Benjamin\_Peterson1](https://avatars.discourse-cdn.com/v4/letter/b/fbc32d/32.png) [@Benjamin\_Peterson1](https://rubytalk.org/u/Benjamin_Peterson1)\ **Post date:** [25 July 2002 12:53 UTC](https://rubytalk.org/t/ot-re-guis-and-the-rouge-part-iii-yes-finally-1-2/845/1 "2002-07-25T12:53:07Z")
> > 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 🙂 x ---
**Author:** ![clemens\_fischer1](https://avatars.discourse-cdn.com/v4/letter/c/9d8465/32.png) [@clemens\_fischer1](https://rubytalk.org/u/clemens_fischer1)\ **Post date:** [25 July 2002 21:57 UTC](https://rubytalk.org/t/ot-re-guis-and-the-rouge-part-iii-yes-finally-1-2/845/2 "2002-07-25T21:57:59Z")
> 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