Use case for per-protocol icons

[Ethan Blanton]

Josh Williams spake unto us the following wisdom:
> On 8/6/07, Ethan Blanton <elb at pidgin.im> wrote:
> > You are asking for a "feature" which is 100% _less optimal_ than what
> > we are proposing.  There may be rough edges on the current UI (I don't
> > know, I don't use, for example, MSN chat, which appears to be what
> > you're talking about), but this is no reason to throw the baby out
> > with the bathwater.
> 
> How is this "_less optimal_"? The *only* difference is the icon. We
> can have both the icon _and_ your system in the same UI.

The icon is 1) distracting, nonintuitive clutter, and 2) encouraging
poor usage habits and discouraging improvements to the interface,
thereby.

> > I don't know who would have told you this; we have stated on *many*
> > occasions that both the buddy list and the conversation can
> > _trivially_ be decorated with an icon through the plugin interface.
> 
> I think the issue we're debating is what the _default_ interface is,
> with no plugins, hacks, or themes.  Perhaps we should asking ourselves
> this: Do we want everyone who uses Pidgin for the first time to have a
> bad experience?

"Everyone" does not think it's a bad experience.  The people in the
"bring back protocol icons" camp *really* need to get this through
their heads -- we're talking about a small number of people, here, who
really want protocol icons and have not either found the New Way
superior or never noticed in the first place.  (Note that most single
account users fall into the latter category.)

> > This is, again, documented on this list and in the bug tracker, as
> > well as having been discussed on multiple occasions on IRC and in the
> > jabber conference.
> 
> IE6 has an addon for tabs. Does that mean I should start using it?

That depends -- do you want tabs in IE6?

> > We have reworded, restated, copied and pasted, blogged about,
> > documented on the wiki, and discussed our reasons times beyond number.
> > I fail to see why you think your specific case merits Yet Another
> > Explanation; we really *have* done our due diligence, here.  I fear
> > I'm encouraging bad behavior with even the explanation I gave above.
> 
> I have been keeping up on these issues since Pidgin 2 was first
> released. I was in the IRC channel while they were releasing it, and
> not two hours after they left the channel, several people joined to
> complain about the ambiguous icons.
> 
> Yes, you have reworded, restated, copied and pasted, blogged about,
> and documented in the wiki _many_ times, but basically what you're
> saying is that you do not care what the users want. (Which is why I'm
> working on a QT fork atm.)

A few users, not by any means the majority, or possibly even a
significant minority.

Any QT interface would *not* be a fork, it would simply be yet another
interface to libpurple -- which we wholeheartedly endorse.  If you're
forking to achieve this, then I'll tell you two things up front:
you're wasting a lot of time, and you're doomed to failure.  The
former is simply true, the latter is just an educated guess based on
the dozens of dead Gaim forks from the past.  See the 0.60 era for
examples.  (Would you believe that people just like you, with the same
tired arguments, lobbied for things as bizarre as a reversion to Gtk
1.x?)

> > We are *not* ignoring the problem here, and nor are we ignoring the
> > specific complaints.  We've just heard it all before, and it saves
> > everyone's time if the complainants can brush up on their history
> > before accusing us of malpractice.
> 
> Or, maybe, after the 10th thousand complaint, you'll finally go back
> to the UI people preferred. I have many users on my network who have
> specifically requested Gaim 2 beta 6 to be installed instead of Pidgin
> for these specific UI issues we've been discussing (not just the
> icons).

It's too bad that you're not showing them contacts or the new
mechanisms put in place to solve the problems they had before, which
they unfortunately had to solve with protocol awareness.  Maybe a
future administrator will help them out.

> > One last time ... if you have anything _new_ to bring to the table,
> > let us have it.
> 
> No, we don't _want_ something new. We just want this particular part
> of the UI to be the way it *used* to be. You still have not given us
> any reason that the green icon is _better_, except that you think it
> looks nicer to have all the protocols to look the same. But there's
> one problem with that theology; the protocols are _different_. They
> all have unique things about them, so we'd like to be able to just
> glance at the handy-dandy icon to see which protocol we're using.
> That's all, plain and simple.

Users shouldn't have to know that they're different, and that's the
part you (and yours) don't seem to get.  We're pushing in that
direction, and, I think, making progress.

> If you developers prefer the new UI, why don't you make *it* an option
> in the preferences or a plugin? The only thing stopping _us_ is that
> we do not have write access to the versioning database, so we are
> forced to just suck it up whenever you make crappy decisions (sounds a
> lot like GNOME vs. KDE, doesn't it?).

No, you really do have write access.  I have to assume from all your
talk that you simply don't bother to learn very much about your tools
-- first Pidgin, and now monotone.  You can commit to your monotone
database the same as we can to ours.  You can't sync your
im.pidgin.pidgin to pidgin.im, but you can sync it to *your* server,
and any interested party can trivially track both trees and integrate
changes back and forth as they like.  I'll even go so far as to say
that, if you come up with a significant body of usable code (just
adding protocol icons back to the buddy list is not relevant, but a Qt
UI would be), we will either give you write access to
im.pidgin.pidgin, or to your own branch for your UI, whichever is more
appropriate.  Personally, I suspect that you'll rapidly find out that
this whole "free software" thing is a lot more work than you thought,
but I'd love to be wrong.

> FORK! FORK! If you're interested in writing a QT interface to
> libpurple, drop me a message. I've already started on one, and I'd be
> glad to have your help =)

If you're really looking at this as a fork, I hope no one wastes their
time on you.  (Particularly if it's for something as stupid as
protocol icons!) If you actually mean that you're writing an
alternative Qt interface to the same libpurple backend, I hope lots of
KDE users take you up on it, and you write the best Qt messenger the
world has ever seen.

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/20070806/87855d0f/attachment.sig>