How to build a quality GUI!

John dingo at
Wed Aug 17 05:38:37 CDT 2005

Scott James Remnant wrote:
> On Tue, 2005-08-16 at 19:41 +0200, Emil Oppeln-Bronikowski wrote:
>> -- follow this steps. :-)
> Though this is largely a joke, there's a few points on here I'd actually
> like to reply to:
>  * Always use obscure or poorly drawn graphics for your tool bar
>    buttons, and never put text on them.
> Actually I tend to find that a toolbar button that requires text is a
> perfect example of one with obscure or poorly drawn graphics.  Improve
> the graphic so it's obvious, and get rid of the text.  Or if you have
> too many similar buttons, get rid of some!

What you think is an obvious icon is obscure to me/ Text bridges that gap.

> A good toolbar has a small number of obvious buttons.
> The addition of text is generally useful for Fitt's law, ie. making the
> button bigger and easier to hit with the mouse; so should be limited to
> the first button or two.
>  * Avoid including a preferences or options dialog. Instead, let the
>    user use the standard OS provided text editor or an editor of their
>    choosing to edit text configuration files. .
> Avoid including a preferences or options dialog.  Instead make your
> software just work!  Preferences are often a sign of poorly designed UI;
> though not always.

My eyes are not as good as yours, I need bigger text. In fact, they've 
deteriorated significantly in the past eight months.

I like courier. Do you?

Do you like the way I lay out my Thunderbird window?

Do you like Evolution? I think it's a heap of rubbish.

Which do you prefer, Gnome or KDE? I prefer KDE and that is why I don't 
use Ubuntu on most of my computer.

How do you configure your email settings? I rarly use mutt because 
configuring it is too hard and the UI is doo different. I prefer PINE.

>  * Begin coding the guts of the program immediately. Designing the UI
>    can come later in the development process.
> Personally this is exactly how I design software, because the UI is the
> hard bit.  The guts should be modular and flexible enough to fit around
> any UI (because after all, one writes them as a library for all types of
> UI).

Both are important. There is a good argument for something that works 
without a GUI but can work with one: this allows for development of 
multiple GUIs.

OTOH a program that doesn't have a UI at all can mostly not be said to 
work at all: Imagine a file-copying program with no UI?

More information about the sounder mailing list