Use case for per-protocol icons

[Andrew Roeder]

On 8/06/07, Luke Schierer lschiere at pidgin.im wrote:

>What if the buddy *is* on msn, but that is not the top buddy?  You would
>think, according to your logic, that they could not be invited.


Which currently you will have to mouse over each buddy to find out if they 
are on a different protocol, which is completely acceptable for this usage 
case.

This is more of a failure to know which buddies are -really- 
expandable(using multiple protocols) and which are not.

>So basically, you think that all technical considerations, all usability
>testing, so on and so forth, are always useless.  You think that once a
>decision has been made, it can never be reconsidered, it can never be 
>changed.  At best, that behavior can only ever become optional.

Some GUI changes to 2.0 were accepted gladly, this one was not.

>I'm sorry, at that point, we are not looking at a project I would want
>to work on.  I believe very strongly that we in open source have a real
>chance to make mistakes, and to correct them.  I believe that we have a
>real oportunity to realize that there is a better way to do things now
>and then.

If you have a better way to achieve these that is one thing, but as in the 
usage example I gave, I see no better way to achieve it, and have not been 
given an alternative idea.

>This is really the reverse.  Last paragraph you argued that logic is
>irrelevent, because users are so illogically attached to their
>environments.  Now you claim that users are logical.  You cannot have it
>both ways.

I'm really at a loss to respond to this Luke, it isn't an argument at all 
but more of a reason to ignore my point without giving a real counter or 
alternative.

>They also hid information.  They also obscured ideas. People formed
>impressions from these icons that they won't form without them.

Hid information? I don't believe so, unless you think they hid other 
protocols the user is on, which is still the case.

Obscured ideas? What?

People formed impressions?  I'm not sure what you mean impressions, this is 
not as if these icons were misleading people to debauchery, they displayed 
information, it was not false information.
>luke


On 8/06/07, Ethan Blanton elb at pidgin.im wrote:
>None of that is really what happens.  It just so happens that a small
>number of users, including yourself, appear to be incapable of logical
>argument or decision-making.  We have presented, for *every single*
>use case that has come up (unless I'm forgetting something), a
>superior way to solve the problem to using protocol icons.  A few of
>them do not exist in the current Pidgin UI, or did not at the time of
>discussion and have since been implemented.

Except for the one I just stated in my previous mailing list post, which I 
have not seen arise except from my own arguments, which you yourself decided 
not to respond to, but instead felt it necessary to tell me that I'm 
illogical and bad at decisions.

Excerpt:
As I said previously on this subject, currently you must mouseover to find
the protocol of a buddy in the buddy list, even if I have their "aliases"
expanded or not together, when you want to rightclick on a buddy to use a
feature, you may find that many options are not present, or that you can
invite some buddies to a chat while others you can not(because they are on a
different protocol.)  Having the icons clearly displayed constantly in the
buddy list on a per-buddy-account basis alleviates that, allowing you to
immediately know who is on what protocol, so you immediately know which
buddies you may invite to chat on a protocol, and what features you may use
for that buddy(s).

If you have an alternative idea to this problem, please tell me what it is.

>"I want it because I want it" is not a good reason for a feature.  The
>beautiful thing about Open Source, however, is that you don't *have*
>to have buy-in from us, just because you want something that we don't.
>Go to it.

It is my understanding that the Plugin system as is currently can't 
accommodate the change, forking a separate version of Pidgin for one UI 
change would probably be more unaccepted than the change itself.

~
I'm not attacking the Pidgin development cycle by my previous statement, but 
the now hostile responses given whenever this subject is risen.  If you must 
repeat your reasons, simply copy and paste them, please do not just say 
"This has been discussed and we have better ways."

_________________________________________________________________
Tease your brain--play Clink! Win cool prizes! 
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2