Direction of Pidgin development

Etan Reisner pidgin at unreliablesource.net
Fri May 4 01:21:45 EDT 2007


On Fri, May 04, 2007 at 12:57:53AM -0400, Andrew Roeder wrote:
<snip>
> 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.

The entire point of Ethan's email was exactly that the placement of items
in the UI and the overall UI itself is a large part of what we take into
consideration when making our changes. In this case it was a huge part of
the consideration. The relevant sections of his email should re readily
apparent if you go back and read it again.

The protocol icons were unnecessary in the buddy list for *all* uses that
we could come up with and for virtuall all uses that *anyone* has put
forward yet. If you have some use for them or some scenario in which
having them in the status column is the correct thing to do PLEASE tells
me, I would LOVE to hear it.

> 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.

There was marked improvement on the protocol icons when you consider that
there were being used as *status* icons. There is nothing inherent in the
AIM running man, or the MSN butterfly, or the Yahoo! Y, or the XMPP/Jabber
lightbulbs that means 'available', and in fact (as Ethan stated) having
multiple icons mean available made it more complicated, more discordant,
and more work to scan for buddy 'status'. Now, before you jump all over me
and say that there isn't anything inherent in a green circle that means
'available', I will readily admit that point, and you know what? I don't
much like the green circle myself. That being said, the fact that the
green circle is *on* icon and is unencumbered by *any* inherent meaning
means that people can easily and quickly form a strong and lasting
association between the two things. 'green circle' == 'available'. And
*that* is a good thing, and a consideration that went into our choice to
change icons.

When do you need to retrieve the protocol information for your buddies?
Under what circumstances? As a means to doing what actions? What
percentage of the actions that you use pidgin for require you to know that
information?

Consider the above questions carefully please. I am willing to bet that
you will find that there are, at best, a very small set of cases in which
you need that information, and that the percentage of your interaction
with pidgin that those actions make up is also very small. And further,
that with the changes we have made and the changes we still plan to make,
that even the small set of cases where you need to know can be reduced
and/or better served with the protocol information in other locations and
not in the status column.

> 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.

I don't know when you started using gaim/pidgin but it has been coming
with plugins which added features (some of which are rather 'essential')
for the entirety of my involvment with the project.

There is no clear-cut line as to what goes into pidgin and what goes into
a plugin, things move as they need to and as they fit.

You seem to have this feeling that a plugin is somehow a second-class
citizen style of preference, I have no idea where this feeling comes from
or what you base it on but I can tell you that it is just wrong. It may
apply to other projects I don't know, but it most certainly *does not*
apply to pidgin, it never has and it never will. Things that logically and
logistically make more sense as a plugin are made plugins. Those reasons
can range from it being simpler to implement that way and it making a good
example of how to do a certain class of action from a plugin so that other
people can see how it is done to we just don't feel like it is 'important'
enough (for some definition of important) to belong in pidgin itself.
An important thing to note here is that there is absolutely *no*
functional difference between a preference and an included plugin, none.
Anyone who has used pidgin for any length of time will have run across the
plugins and looked at them, this is borne out by years of people asking us
about the default plugins that come with pidgin, many of these people
having just installed it earlier that day for the first time.

There is no pejorative status to be associated with being a plugin, there
is no malice to the decisions that make certain things plugins, they are
just self-contained preference units. I can start referring to them as
SPUs in the future if that would make you feel better. Because let me
assure you, the plugins themselves don't feel hurt, and neither do any of
the plugin authors. Ask them yourself if you don't believe me (the authors
not the plugins obviously).


    -Etan



More information about the Devel mailing list