Direction of Pidgin development

[Andrew Roeder]

>From: Ethan Blanton <elb at pidgin.im>
>To: devel at pidgin.im
>Subject: Re: Direction of Pidgin development
>Date: Thu, 3 May 2007 23:44:38 -0400

>Part of the problem here, is that often times users become emotional
>about not just features, but the particular way in which features are
>implemented, and become unable to see the forest past all of the
>trees.  The protocol icons are a prime example of this; we removed
>user interface clutter which had very real detriments (making the
>buddy list more difficult to scan; placing emphasis on unimportant
>information, inadvertently magnifying its perceived importance; and,
>of course, ugliness), replacing their *functionality* with a user
>interface paradigm which obviates their existence.  They remain
>visible where they are needed, but are hidden where they are not.
>Everyone wins.  However, some users keep coming up with the same lame
>arguments over and over to justify the visibility of protocol icons,
>regardless of the fact that those individual uses have been rebutted
>specifically in numerous ways and on multiple occasions.  For example,
>"not all protocols support offline messaging!" keeps coming up,
>despite the fact that we have stated that the new paradigm would hide
>these consequences from you, *automatically* selecting buddies from
>within a contact which support offline messaging over buddies which do
>not, when necessary.  The proponents of reversing this change continue
>to forward this argument, despite that it has been addressed; until
>said proponents start actually *reading* the responses to their
>arguments, forward progress cannot be made.
>
>I hope you can step back from whatever individual features are
>concerning you (I know you were involved in the infamous ticket #414,
>for example), and determine what actual _functionality_ is being lost,
>if any.  (Note that pixmaps on a screen do not constitute
>functionality; neither do particular menu items, dialog boxes, or
>what-have-you.  Tasks which you used to do and can no longer do
>constitute functionality.)  These are the points we should be
>addressing.  Bear in mind as well that "make it the way it used to be"
>is not necessarily forward progress; in many cases, we will replace a
>particular *mechanism* with another, and in the process change or
>improve existing functionality.  Take the time to actually evaluate
>that mechanism, before blessing or rejecting it.  Many developers have
>initially rejected particular features as they were introduced, only
>to grow to love them as they came to realize the power they actually
>represented.
>
>Ethan

As much as programmers like to push that their work is the only valuable 
part of software, GUI and placement design is just as important, it could 
just as easily be said: Why is this feature displayed here, it obviously is 
related to X other features and should be grouped with them: Or why is this 
button here, it would be easier to access in this location, or would be more 
prominent if it had this graphic instead.  In the example of the protocol 
icons, its easy to say that they were unnecessary  and clutter, that is- its 
easy to say that from the standpoint of that you didn't ever use them 
personally, therefor they are useless.

In this specific example also there was no introduction or improvement on 
the protocol icons, there were removed for "uselessness" as has been stated 
repeatedly, if this information was completely useless there would be no 
reason to display it on hover, which obviously is not the case.  It is Very 
useful information, you just believe it is displayed in the wrong place, I 
believe that it was better displayed over the availability icons, seeing how 
they were much easier to access/see then wasting time hovering over a buddy 
to receive the same information.  Logically you could have removed the icon 
from the buddy hover and claimed the same arguments on your end.  Therefor 
the removal of these "useless" icons causes me to waste time to receive 
information that before was immediately available.

The point of my previous discussion was to ask what exactly the model is for 
Pidgin, because obviously none of the features moved to plugins were 
useless, and it seems to just be cluttering up plugins.  When i began using 
Gaim/pidgin plugins were actually that, Plugins - things that were not 
default with gaim/pidgin and were downloaded seperately to enhance features 
for specific users who needed those specific features.  Now it just seems 
that everything that isn't "the stripped basics" of Pidgin are being thrown 
in as plugins in default, where they should all still be built in contained 
in preferences, why are they not, if not to protect those "ignorant users" I 
see no reason for them not to be placed in the deserving categories that 
they belong.  Obviously they are not useless features either since I'm sure 
you yourself, the other developers, and many many users of pidgin use them 
so much that they were included as plugins by default.

_________________________________________________________________
Exercise your brain! Try Flexicon. 
http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07