Direction of Pidgin development

[Ethan Blanton]

Andrew Roeder spake unto us the following wisdom:
> After reviewing a lot of the complaints coming with 2.0.0 and its releases 
> and the solutions that are/will be offered by the developers.  Am I wrong is 
> the thought process that it seems Pidgin is moving towards a focus a 
> userbase of more un-intelligent, uninformed, (if you'll forgive the bad 
> analogy) Window's type users.  Catering to people who don't know what their 
> software does, how it works, or what it can do.

Yes, you are wrong.  We believe that Pidgin is moving toward a focus
on being better for people who want to use their software to get
things done.  Keep in mind that our *primary* focus (at least, my
primary focus, before I speak for other developers) is making Pidgin
better for _our own_ use.  We would not cripple things which inhibit
our own use cases.

Pidgin developers, by and large, are _far_ from uninformed IM users.
;-) Most of us have several (if not dozens) of IM accounts, covering
most of the services represented in the Pidgin capability list (I have
to admit that I don't have a QQ account, nor do I use SameTime).  We
are "power users" of IM functionality, for the most part.

> Should this be the focus? Ofcourse Pidgin should be easier, but should we 
> need to maintain upwards of 20 "plugins" to maintain Pidgin in a form that 
> is lush to a user who is aware of what Pidgin can do for them?  At this 
> point in time there is -no- problem with the removal of features and 
> replacement with plugins, however is this the best approach at supplying a 
> great messenger.

I'm not sure I understand what you're saying about "-no- problem with
removal of features and replacement with plugins" -- in the recent
betas, we have both moved features from Pidgin to plugins, and moved
features from plugins to Pidgin.  It is more about providing a
coherent and powerful feature set, than it is about making things
"easier", "smaller", or whatever one might claim.  Things which users
generally will not need, or which we think are a bad idea (and, yes,
we do make that call from time to time) get pushed out into plugins or
removed entirely; things which we come to believe are important or
especially powerful get pulled into Pidgin or libpurple (even if they
had previously been pushed out!) to become part of the program itself.

> Back the point of this, with, users wanting to fulfill Pidgin's potential 
> now have to drudge through plugins and popup a window to set individual 
> plugin settings, this is not "easier", hiding these options in such a 
> fashion protects the ignorant users but merely hinders the time it takes to 
> explain/setup Pidgin yourself, or for someone else who is looking for these 
> features.

Again, we're not especially trying to "protect ignorant users".  If a
feature is confusing, it is certainly something which should be
evaluated, and decisions are often made which eliminate confusion, but
I think that the logic you think we are using is not at all how it
really goes on.  Let me sketch what I think you are thinking, and then
what is really happening:

Your assumption:

  "Users are really confused by feature X.  We should remove feature X
  so that users aren't confused."

The reality:

  "Feature X really isn't very useful, and it confuses users.  We
  should remove feature X."

Or, even more likely:

  "Feature X is poorly designed.  We can change the way Pidgin works
  to replace feature X's functionality with a different mechanism
  which will have the bonus benefit of being less confusing to users
  than feature X was."

> I for one feel no loss of usability with Pidgin yet, but I do feel that I'm 
> using a program no longer actually built for me, it is built for the "dumb 
> wanting easy" which is what every opponent messenger seems to target.

I am sorry you feel that way, because that is not what we are doing.

Part of the problem here, is that often times users become emotional
about not just features, but the particular way in which features are
implemented, and become unable to see the forest past all of the
trees.  The protocol icons are a prime example of this; we removed
user interface clutter which had very real detriments (making the
buddy list more difficult to scan; placing emphasis on unimportant
information, inadvertently magnifying its perceived importance; and,
of course, ugliness), replacing their *functionality* with a user
interface paradigm which obviates their existence.  They remain
visible where they are needed, but are hidden where they are not.
Everyone wins.  However, some users keep coming up with the same lame
arguments over and over to justify the visibility of protocol icons,
regardless of the fact that those individual uses have been rebutted
specifically in numerous ways and on multiple occasions.  For example,
"not all protocols support offline messaging!" keeps coming up,
despite the fact that we have stated that the new paradigm would hide
these consequences from you, *automatically* selecting buddies from
within a contact which support offline messaging over buddies which do
not, when necessary.  The proponents of reversing this change continue
to forward this argument, despite that it has been addressed; until
said proponents start actually *reading* the responses to their
arguments, forward progress cannot be made.

I hope you can step back from whatever individual features are
concerning you (I know you were involved in the infamous ticket #414,
for example), and determine what actual _functionality_ is being lost,
if any.  (Note that pixmaps on a screen do not constitute
functionality; neither do particular menu items, dialog boxes, or
what-have-you.  Tasks which you used to do and can no longer do
constitute functionality.)  These are the points we should be
addressing.  Bear in mind as well that "make it the way it used to be"
is not necessarily forward progress; in many cases, we will replace a
particular *mechanism* with another, and in the process change or
improve existing functionality.  Take the time to actually evaluate
that mechanism, before blessing or rejecting it.  Many developers have
initially rejected particular features as they were introduced, only
to grow to love them as they came to realize the power they actually
represented.

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