[plug] Good GUI Interface Design

[Ben New]

Craig Ringer wrote:

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

OK, I think I understand more of what you are saying now.  Consistency 
at the toolkit level (i.e. across different toolkits) does make a lot of 
sense.  Although it would certainly not be easy, as every developer has 
their own idea of what should be "standard", "default" and "optional".  
It would also be quite easy to over-standardise the behaviour - which I 
guess was the point of my original post.  Sure, it can be overridden, 
but usually that means a lot more work, so more developers will leave it 
as it is, thus creating a reduction in overall creativity.

Personally I like the Gimp, now that I'm used to it's quirkiness ;-)

-- 
Ben New
ben at leftclick.com.au

Leftclick Software Development
http://www.leftclick.com.au/