Response to Mosfet's response to Havoc's article on free software UIs

I just read Mosfet's reply to Pennington's article. I've got a few things to say, too. Click on the Read more... link to read the short piece.

Hi there, Mosfet:

Well,  I think you kinda missed the original point (or perhaps the unsaid but wanted-to-express point) in Havoc's article.  GNOME usability testing did uncover two things:

• bad organization and preference bloat hinders usability
• many preferences make the user feel "in control"

Why does it sound like am I contradicting myself?  Because "many preferences" is not the same as "preference bloat".  He's right regarding many free software applications having options to "unbreak my program, please".  I'm a software developer (I do Directory administrator) and you wouldn't believe the amount of preferences people request.  This is the REAL issue (kinda easy after you think), exemplified by a mocked up conversation with one of my users:

U> Hey, can you put a gizmo to find a specific user in your app?
Me> What is it you want exactly?  Why do you want the preference?
U> Finding a particular user is very hard.
Me> I'll think a solution to the problem.

two days later, I did keyboard navigation (a kludge that works around the shitty GnomeIconList control, now deprecated).

U> This is better than what I asked!  Thanks!

So, see, the conversation always begins with a request that SIDESTEPS the core issue (being that something is fundamentally broken in my app).  Finding out what really has to be fixed (the core issue) is my task as a responsible developer.  Yes, I have to listen to the user, but I have to *ask myself* "why does this guy ask for preference X? what could possibly be wrong" before I even begin to think how to implement that feature.  Then, the solutions I come up with have to pass the bar test of "does this make my app simpler or more complicated to use?".

The fact that many software developers can't or won't accept that their apps are wrong in a fundamentally wrong sense is why they cave in to "unbreak my app" preferences.

We are NOT advocating for less features.  We are advocating sound reasoning behind preferences (for example, NO preference should be provided when its value can be automatically determined by the computer, after all, that's why the damn computer has brains!) and a balance between features and performance.  It's, nevertheless, true that less preferences reduce support time (no matter what the lockdown framework can do) and QA testing (every time you add a preference you multiply your software's state machine by N, where N are the possible values for the preference).

Follow a rule of thumb: the less interaction your user needs to perform in order to complete a task, the better off he is.  That includes setting preferences.  I agree that more eye candy preferences are good, though.  I particularly enjoy and look forward for them.

Factual mistakes: regarding GUI autogeneration, KDE does not autogenerate GUIs.  It mostly picks them up from XMLGUI, which is a great thing and a timesaver, but not really autogenerated - they're developed with the same care regular GUI development with RAD tools is done.  But I guess you know that.  Don't mislead the non-programmer audiences into thinking what KDE does is autogenerating GUIs.

Good luck, Mosfet!  Keep up your efforts!