protocol icons

[Luke Schierer]

> Comment (by Apewall):
> 
>  The only method that I think would even remotely work is having two forks
>  of Pidgin for basic and advanced users, but I don't think the Pidgin
>  Developers should have to do this, its just a waste of work.  Time would
>  be better spent in my opinion by having all "advanced user features"
>  available from the start, and compiling a documentation that is easy for
>  users to understand when they run into problems.(Though we all know that
>  people tend to go rushing to IRC to ask for an answer rather than the two
>  clicks to the pages of the documentation to receive the same answer.)
> 
>  My issue is not specifically with this, if a plugin was made available
>  default with pidgin that added the wanted icons to the
>  buddylist/conversation windows I'd use it, be content and go on.  But is
>  the goal to create a client that is easy for the dumb user, or to create a
>  full and rich client for the extensive user?
> 
>  I really think that the current plugins list is probably just a misnamed
>  "advanced users" hideout, as rest assured most users aren't going to delve
>  in there and start looking for features.(Basicly, when you remove features
>  from something and you are going to expect many complaints about it - its
>  probably notable enough to make the addition of a default plugin, which
>  the "newbie" users wont notice, but the rest of us will enjoy and our
>  ideal of Pidgin will remain.)

The goal here is to create a client that we, those we know, and users
like us and like those we know, would want to use.  We strongly believe
that in doing so, as we have done for the past 6 years, we will continue
to meet the needs of the many thousands of Pidgin users out there.

Several years ago, I was presented with an argument that there is no
such thing as an "advanced" computer user.  That someone who is an
"expert" or "advanced" user of one program or even of many programs is
not necessarily going to be an "advanced" or "expert" user of Pidgin,
and may not even want to be one.  Though I have not presented that
argument in a full form, I think it is sufficiently self-evident that it
needs no defense.

>From this I concluded that very few people really *want* to be an
advanced user of an IM application, and that those few who do are almost
all either IM developers, or potential IM developers/plugin authors.  

As I was thinking about these things, and as other Pidgin developers
were thinking about them with me, I came to read (I am not sure if I
read it first, or if another developer pointed me at it) an article
talking about the reality that many preferences are not really
necessarily.  They exist because someone changed the behavior of a
program in a way that user B did not like.  Not wanting to say "this
change is wrong for all users," or perhaps not being able to defend such
a position, user B asked that it be made optional.  Looking at our own
preferences at the time, it was IMMEDIATELY obvious that some of our
preferences existed for PRECISELY this reason.  

The article continued, saying that in fact, in many cases, the right
answer was that *neither* behavior was correct, but that there was an
underlying issue here that if addressed, would negate the need for a
preference.  This seemd persuasive.

I think that most of the arguments for protocol icons in the buddy list
fall into this category.  Things do not work quite right, and having the
protocol icon allows you to work around the flaw.  It doesn't solve the
flaw, but it lets you work around it.  Not having the protocol icon does
not stop you from working around these flaws, but it does require
_different_ work arounds.  

I would argue, that as far as work arounds go, the ones we have been
suggesting are superior to protocol icons in the buddy list.  That is,
however, largely a side point.  Most of these things, particularly the
handling of file transfer and offline messages, represent bugs that can
and should be fixed.  Some of them, like offline messages, represent
bugs that can relatively easily be fixed now that our attention has been
drawn to them.  

As the bugs cease to exist, your need for _any_ work around, either
those we have proposed, or the protocol icons, will cease.

luke