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

List:       kde-devel
Subject:    Re: Regarding your pennington reply
From:       Mosfet <dan.duley () verizon ! net>
Date:       2003-02-26 15:00:18
[Download RAW message or body]

I didn't say anything about XMLGUI. I said Qt Designer. It generates a GUI.

On Wednesday 26 February 2003 7:09 am, Manuel Amador (Rudd-O) wrote:
> 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]