I HATE the lack of protocol icons

[Ethan Blanton]

I have been advised not to dig in here ... but I can't stand the
confusion, so here goes.

Eric Seelig spake unto us the following wisdom:
> Or to be more accurate, I dislike the new icons in general.

This is certainly a valid opinion; I'm not fond of some of them,
myself.  I generally think they are better than what we had before,
however.  I think replacing the green ball with Hylke's new purple
feather icon would go a long way toward improving the state of
affairs.

>   The clock icon was initially confusing as to whether it meant away
>   or idle, the new "now online" icon with an arrow pointing AWAY FROM
>   the buddy list is certainly confusing enough, all of the green dots
>   are rather annoying to look at, and in spite of the fact that you
>   stonewalled on several valid responses on
>   http://developer.pidgin.im/ticket/414, there are several good
>   reasons why there should be *at least an option* to retain the
>   multiple/old icons, and "I don't want to code it again" isn't really
>   a good argument for the opposite, when what a lot of users find
>   appealing about one piece of software over another is the basic
>   design/UI.

I was going to break this up and reply to it part-by-part, but,
unbelievably, it's one sentence.  There has been quite a bit of
discussion about the join/part icons, in particular with regards to
the arrows pointing in a confusing direction.  I think the general
consensus is that these need to change in some way, but I'm not sure
what is going on on that front.  As I said, I prefer the feather to
the green dot.

I have read 414 with an objective eye on several occasions, and I do
not believe that any "valid responses" were stonewalled; most of them
were *invalid* responses, like the ones you list below, which are
related directly to other Pidgin bugs or confusion about the
functionality of contacts.

At no point was "I don't want to code it again" forwarded as a reason
for maintaining the new protocol-less buddy list, although, if it
*were*, contrary to your assertion, it is a fabulous argument for
keeping it.  I don't know if you noticed this, but Pidgin is Free
Software, free in every sense of the word.  Not only did you not pay a
single dime for it (which greatly reduces the validity of any claims
you might make about your importance, what you deserve, or why we
should cater to you, specifically), but the source code is available
for any interested party to change the buddy list behavior, should
they so desire.  It *is* interesting that, like many other undesirable
features, the intersection of Those Who Want and Those Who Can is
apparently entirely empty.  There is probably an interesting
anthropology paper in the topic, if one cared to dig it out.

> For one thing, I don't like to use "show buddy details" to see identifying
> buddy icons, because I usually can't see my full buddy list that way, so the
> protocols did help visually to identify some users.

Buddy icons do not show up with or without buddy details, I'm not sure
where this statement comes from.

> When I know that a few given friends only might be using Google Talk
> or MSN, the corresponding icon helps to more immediately identify that
> the person online is one of only a certain few: "Hey, that can only
> either be Fabio or Karen, and neither are online much - I should send
> a message."

This is an interesting statement in some ways, but like many other
arguments, it is entirely coincidental.  It *just so happens* that you
have only a few friends on a particular protocol; that mapping will
not work for any large number of users, and in fact is unlikely to be
reliably *useful* for users who are in such a situation.  The
probability is just as good that the one or two users you know on a
particular protocol are online all the time, as that they are not
online much.

One can of course make up a completely hypothetical scenario to back
up just about anything.

>  Likewise, while most of my friends in the US use AIM, most of my
>  overseas friends use MSN, so that in itself is a sort of automatic
>  visual organization.  And finally, YES, YES, it very much helps to
>  know whether someone is using AIM or Google Talk at the time, no
>  matter what you say, and I don't want to have to dig around and
>  "expand" anything to know whether or not I can send the person a file
>  at the moment. 

As I am sure you read in 414, the file transfer concern is a bug in
the Pidgin user interface; Pidgin should make this sort of capability
concern seamless regardless of protocol.  For example, you also cannot
send a large file to a user of AIM on their cellular phone, even
though the AIM protocol is capable of file transfer.  The same few
flawed straw man arguments keep coming up over and over for this
functionality, which is why no reversals of opinion have been made.
If and when we actually see a new and *reasonable* argument, minds
might change -- re-hashing the same, tired, invalid arguments over and
over doesn't do anything but wear out the developers, who have plenty
of other things to do with their time than try to reformulate the same
ideas in a different fashion, hoping that *this time* the complainant
will bother to read and comprehend them.

> The quote-unquote fix of creating two separate names with "(MSN)" or
> something tacked on the end is pretty lame.  You know how annoying it
> is when cell phone address books won't let you share a name between
> home and mobile numbers, and you have to type everything out to
> differentiate the two?  Yeah, that's what you just did.

This isn't really a valid parallel at all, because this is what
contacts are for.  You can still share the same information by way of
contacts, while providing additional information where appropriate on
the buddies within a contact.

> When you were Gaim, you svengalied me away from using Trillian and meebo.com
> - meebo for Google functionality, and Trillian for sending files.  If this
> doesn't change soon, I'll probably change back.  Such is the fickleness of a
> user looking at unnecessarily poor design.

If Pidgin does not fit your requirements, feel free to use something
else.  It's not like you paid for it, and we're going to have to bear
the cost of restocking when you return it.  Threatening us with your
departure is both ineffective and childish.

As Etan has pointed out on *numerous* occasions, the functionality you
so crave is trivial to implement as a plugin, independent of the
Pidgin core.  It would also be simple to implement in the core, in a
patched version (dare I say "fork"?) of the Pidgin UI.  Anyone who so
desires is free to step up to the plate and implement these protocol
icons.  Please note that "But I am not a programmer [and so you should
do it for me]" is not a valid response; we, as the primary developers
of Pidgin, have a limited amount of time to spend on the project, and
we should be free to spend it on the features and functionality that
we care about.  Choosing to give our work away for free does not put
us in the debt of the recipients of our generosity.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070611/314844f9/attachment.sig>