[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Regarding your pennington reply
From:       "Manuel Amador (Rudd-O)" <amadorm () usm ! edu ! ec>
Date:       2003-02-26 13:09:05
[Download RAW message or body]

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!


         Rudd-O

(this is mirrored on my weblog:
http://www.usm.edu.ec/~amadorm/index.php?p=283&more=1&c=1
)

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]