[plug] Good GUI Interface Design

[Craig Ringer]

Ben New wrote:
> First I'd just like to say that saying "GUI interface" is like saying 
> "ATM machine". That's just my pickiness for you ;-)

Conceded.

> I'd have to say there are a number of logistical problems with your 
> proposed ".guirc" method.
> 
> Firstly, not all software that is run on Linux is "Linux software" - 
> i.e. there are also Java apps, Windows apps under Wine (etc), and so on, 
> which would have no knowledge of the ".guirc" file.

Indeed. There's not much to be done about that, but that doesn't 
invalidate the need for a mechanism to control GUI behaviour in a global 
and consistent way.

> Neither are they all 
> developed using the same tools - there are programs written in C, C++, 
> Python, Tcl/Tk, and so on. It just seems impractical to have them all 
> tied down to the same interface constraints.

As Cameron said - most of what would be needed could be handled at a 
toolkit level, as it's the toolkits that are mostly at fault currently. 
Little things like the effect of hitting <tab> when a partial path is 
entered into a file select dialog, or hitting enter when a directory 
path is entered; single or double click to open, etc. Very simple stuff 
mostly, and much of it toolkit level. The toolkit could also inform the 
app of user prefs where the desired behaviour isn't toolkit controlled 
(single/double click), allowing the app to very simply handle the pref. 
Older apps (or apps that choose to ignore the facility) simply wouldn't 
know how to ask the toolkit about the interface behaviour prefs and 
wouldn't care.

I'm not saying that's the right way to go about achieving an interface 
that can be made to behave consistently. I do think it needs to be done, 
one way or another, and some kind of global configuration will no doubt 
be needed.

> Besides that - yes, there are certain behaviours that can be pretty much 
> consistent across the majority of software, but there is always the 
> exception, and there is always more than one way to skin a cat. By 
> forcing standard behaviours (even if they are configurable), aren't you 
> limiting the scope for application developer creativity?

No. The user can state a preference; if the app or toolkit chooses to 
ignore it then ... well, I guess it's the developer's choice. Mostly 
this turns out to be just irritating, but there are times when apps with 
unusual UIs work well.

A globally configurable set of UI prefs is, IMHO, the more flexible 
alternative to saying "it will be _this_ way" about a lot of issues.

Craig Ringer