Customization is a Liability

All too often, provisions for extensive UI customization by the end user amount to pushing the burden of UI design onto them. I'd like to avoid that if possible.

There are several reasons for this:

1. Customization is often enough to make deep UI problems bearable, but it's seldom enough to actually fix them. People can get more or less comfortable, but then nothing ever gets done about the underlying problem.
   
2. Such ad-hoc fixes aren't easily sharable, so every newbie has to discover how to make the application usable on their own. There's nothing to push upstream so everyone can benefit.
3. Everyone's own version is potentially radically different. This renders it hard to make general assumptions that would let us optimize workflow in the application. It also makes it harder for a user to move from their installation to another's.
   

I think back to the incident with the Gtk file chooser: some time ago, the filename entry was removed from the Gtk open dialog in the name of "usability". You could still get it in a pop-up dialog if you knew that Ctrl+L was the shortcut to do that, but it wasn't documented anywhere and there were no visual affordances. People were understandably really mad, but the Gtk maintainers refused to change it back. Suggestions for making it configurable were made: for instance, why not have Ctrl+L show the old entry, and it would stay shown in subsequent incidences of the dialog until the user turned it off again? How about an expander widget to show or hide it? The Gtk maintainers rejected those too. Eventually, however, the push-back over the next year or so was so intense that the maintainers finally relented and returned the fiename entry to the dialog where you can find it to this day.

What would have happened if the maintainers had thrown the users a bone by making it customizable, though? Probably most Gtk users would have toggled the filename entry on and left it that way. New users would still be confronted with no filename entry by default, but, hey, it's in the FAQ, right? I doubt there would have been enough demand to get it fixed the right and simple way, so we'd have been left with a needlessly complex file dialog.

Hopefully Mike or I or whoever ultimately ends up running the Moing project won't let something that dumb continue for that long, but if we did, I'd rather have people mad enough to get it fixed properly than have the problem papered over.