How to build a quality GUI!
dingo at coco2.arach.net.au
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:
>> http://toastytech.com/guis/uirant.html -- 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
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
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