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:
> >                                              and 2) encouraging
> > poor usage habits and discouraging improvements to the interface,
> > thereby.
> 
> "Poor usage habits"? We like to know what protocol we're on, that's
> all. This has nothing to do with our "poor usage habits". Are you
> implying that it is a poor usage habit to, for example, use the /nudge
> command on MSN or the /buzz command on Yahoo?

This is *precisely* what I'm talking about, yes!  If you don't
understand the following argument, then this is absolutely the source
of the disconnect, and we simply believe that you are wrong, plain and
simple.  The user should not have to KNOW that MSN uses nudge and
Yahoo! uses nudge -- the user should simply say "I want to get my
friend's attention", and Pidgin should handle "nudging" or "buzzing";
these names are essentially arbitrary labels for the same thing, which
differ only because the protocol servers have a meaningless difference
in terminology.

So, yeah, that's poor usage habit encouraged by a mistake in the
existing interface.  Perhaps there should be only one command, say,
/alert, which performs a nudge on MSN, a buzz on Yahoo!, some sort of
notify event on XMPP, a "poke" on some hypothetical Facebook IM, etc.

> Your idea of good "usage habits" seems to be conforming to simplicity
> with less functionality. This is fine and dandy if you prefer to be
> treated as a stupid child who may only do what his elders instruct him
> to, but there others of us who prefer to have more control over our
> software.

Not at ALL, and the fact that you persist in thinking that it does is
what frustrates us.  We want _all_ of the functionality to be there,
with none of the cruft.

> > "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.)
> 
> It's certainly enough users for you to be tired of hearing the
> complaints, isn't it?

Yeah -- and it's about half a dozen, so far.  It only takes one user
who persists in repeating the same arguments over and over without
considering the responses, frankly.

> > 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?)
> 
> It would be a fork because I have no intention of submitting any of my
> QT work to Pidgin. I have no desire to be affiliated with it (please
> note that I said Pidgin, not libpurple).

Of course, the Qt work would not be part of Pidgin.

> As for the dead forks, this fork actually has a good reason to exist.
> No, not just because I'm complaining about the new UI. If that were
> the case, I'd just modify Pidgin's source for my own personal use.
> 
> My main reason for this project is to write an interface that's native
> to KDE, obviously, which is something I have wanted for a long time.
> The recent arguments have only given me more incentive to write it.

A native KDE interface is a laudable goal.

> > 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.
> 
> Again, not each protocol is identical in functionality.

And where they are not, we should find meaningful ways to
differentiate -- I challenge you to find a place where a protocol icon
is truly the best way.

> > No, you really do have write access. [..]
> 
> Yes, I have write access to _my copy_. I'm talking about the official
> repository here.
> 
> >  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.
> 
> I know the ins and outs of pidgin very well, thank you. No, I've never
> used monotone (svn here), but your argument is moot - a small
> technicality in the wording. The point is that I don't have the
> permissions to choose which UI is put into the official repository and
> eventually released on sourceforge.

Of course not.

> > 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!)
> 
> By "fork", I mean I'm using the pidgin source tarball as the base of
> the program. libpurple will be renamed to libim, finch to tim, and
> pidgin to kim. Pidgin is the only component that will be re-written
> from scratch (probably, that is; maybe finch, as well).
> 
> When I say I'm creating a "fork of pidgin", I am referring to the
> project as a whole - libpurple, finch, and pidgin.

Yeah, that's a terrible idea, a waste of time, and a waste of
resources.  You should at least use libpurple as-is, as an installed
library, as, e.g., Adium does.  Anything else is lost effort.  That
said, if you do use monotone, or another capable distributed VCS,
changes to libpurple could conceivably be ported back and forth
without contortionist effort, if there were anything worthwhile to
move in the "back" direction.

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/e9b5f295/attachment.sig>