Use case for per-protocol icons

[Etan Reisner]

On Mon, Aug 06, 2007 at 11:15:51PM -0400, Josh Williams wrote:
> On 8/6/07, Sean Egan <seanegan at gmail.com> wrote:
> > As I've stated before (http://pidgin.im/~seanegan/blog/momentum.html),
> > you miss the protocol icon because you grew to depend on it. It's our
> > fault for introducing it to begin with; sorry about that. As we've
> > been saying, all the arguments in favor of protocol icons are either a
> > consequence of coincidence (the "I use Yahoo! at work, and so Yahoo
> > icons indicate co-workers to me" argument) or failures in other parts
> > of the UI ("How do I know which 'Sean' to send a file to anymore?").
> > Protocol icons are merely a band-aid over these. A band-aid people
> > have grown dependent on.
>
> That does not account for the completely protocol-dependent
> functionality, such as /nudge, /buzz, etc.

The fact that /nudge and /buzz have separate commands is a BUG not a
desirable feature. They should both work for both protocols as well as
there being a protocol-agnostic command like /attention which Just Works.
Again, the point here being that you *shouldn't* need to know about the
protocols in question in any cases where it is at all possible to avoid
requiring you to know. The fact that you seem to keep wanting the
information available simply because it has always been available is at
odds with our design goals, if you don't like our design goals that is
fine, but please do us the courtesy of not liking them for valid reasons
and after trying to understand them.

> Personally, I do not even group people's accounts into one contact.
> It's a PITA because I make heavy usage of each protocol's features.

What features? What does combining people make more difficult? Have you
tried it recently?

> > Pidgin should emphasize the people over the technology. Where it fails
> > to do so, those failures should be addressed.
>
> I suppose that's just a core principle that we disagree about. I'm in
> favor of emphasising people, but not at the expense of reduced
> functionality (in this case, addressing the UI as technology).

There has *never* been a time when we have suggested that making pidgin
protocol agnostic should come at the cost of any functionality, the fact
that you seem to think we have indicates that you need to pay more
attention to the goals we are trying to meet and the arguments we have
been making. Our *entire* goal has been to make as much of pidgin as is
possible cross-protocol while *not* papering over differences that are
insurmountable.

> > One half of one second. That is how long it takes you to discover what
> > protocol someone is using. If you're really impatient, you can change
> > the tooltip_delay preference in prefs.xml to 1 millisecond:
> > essentially instant.
>
> One half of one second *plus the use of your mouse*. I don't know
> about you, but I avoid using the mouse (don't say I'm the only one -
> even RMS has told me he does the same), *especially* for trivial
> things that should be shown to me anyways. (eg., I prefer gmail over
> AOL mail partially because I don't want to click "Inbox" before I see
> my mail; it should 'just be there'.)

As we have stated multiple times we do not believe the protocol should be
shown to you at all times because we believe (and have experiences to back
us up) that it is confusing and extraneous, and that virtually all
circumstances where people believe they need it can be better served by
other mechanisms, mechanisms we have striven (and are continuing to
strive) to implement.

I would ask you to explain what features you use require you to over over
the contact to determine the protocol before activating but I don't
imagine you would usefully answer the question this time or listen to and
understand the answers given to you this time. So instead, I will simply
suggest that you try to look at the arguments you have been making and the
responses we have been giving you from a position that is open to
reinterpreting things, as well as suggesting that perhaps you should
attempt to use contacts again as they have been improved and many of your
complaints just don't apply as much as you think they do.

Arguing about an interface/design/system that you haven't really tried to
use is a futile fruitless endeavour.

> >                                       I don't think there's an argument
> > to be made that the cost of having protocol icons on the buddy list do
> > not outweigh the benefits.
>
> I am still not even convinced that there really *are* any benefits of
> the green circle. The only argument for it I can see is that you think
> it looks nicer, but that's merely a matter of opinion.

The benefits of the single status icon meaning available are that it is a
significantly simpler model to comprehend, which makes many people happy
(yes we got complaints about the protocol icons). Along with the fact that
the model is conceptually simpler it means scanning your buddy list for
online buddies is simpler because you only have one available icon/color
to scan for. Not to mention the fact that it means theming is simpler
because you only have to replace one icon for each status type.

> > If you think that creating a QT UI is the most productive way to solve
> > your dilemna, God bless you. I wish you the best of luck.
>
>
> >                                                                        If you want
> > to work on figuring out new, better ways of resolving your problems,
> > I'd be glad to hear to them.
>
> No you wouldn't. You've already stated that you don't _care_ about my
> problems. You prefer simplicity over functionality. If that's the way
> you like it, God bless you, too. I simply differ in fundamental design
> concepts, so I have no intention of contributing to the pidgin UI.

I challenge you to produce a quote where pidgin has stated that we prefer
"simplicity over functionality". Likewise no one has asked you to
contribute to pidgin if you don't want to, what we have suggested is that
it would be immensely simpler for you and more immediately productive for
you and all those users like you if you were to provide us with _new_
reasons why the protocol icon is the correct solution to some problem you
are having, or even suggestions for additional ways in which we can solve
your actual problems and not just more harping on your desire for protocol
icons because you liked them.

<snip an entirely non-sensical argument>

Your plan to 'fork' the entirety of pidgin, libpurple, and finch is an
insane over-reaction to your over-wrought response to this 'discussion'.
An enormous amount of work was put into libpurple so that alternative UIs
could be written without needing any access to libpurple upstream
management. If you want a Qt native UI by all means create one, we welcome
any and all alternative UIs to libpurple and any libpurple improvements
that fall out of more people working on it.

If you are so angry over our continued defense of what we believe to be reasoned, reasonable, and carefully thought-out changes to pidgin (just one of the libpurple UIs mind you) that you are eager to expend tremendous amounts of effort on renaming unrelated projects then you are right we don't want to deal with you anymore or listen to any comments you might have.

If, on the other hand, you actually do want to help make things better
(whether that is libpurple, pidgin, or your-Qt-UI) we are more than happy
to have useful, constructive conversations about this stuff.

	-Etan