A blog about someones first time with a Linux desktop which mentions Pidgin
elb at pidgin.im
Tue Apr 29 11:56:26 EDT 2008
Felipe Contreras spake unto us the following wisdom:
> 2008/4/29 Ethan Blanton <elb at pidgin.im>:
> > Some of the points in this post are things we have discussed several
> > times; for example, the text prompt in the buddy list and the open add
> > account dialog on startup with no configuration came from such
> > discussions. We aren't sure how to "fix" some of the problems, though
> > -- for example, the confusion about multiple protocols in the add
> > account dialog. A multiprotocol messenger just has multiple
> > protocols, and there's not a lot we can do about it. We might be able
> > to make it "friendlier" (quotes intentional) by changing to a
> > wizard-style addition, but only at the expense of annoying a large
> > portion of our userbase (including most of the developers) who
> > *expect* Pidgin to me multiprotocol. This part is tough.
> Why does everything needs to have a compromise? Specially when you are
> _adding_ something.
In this case, it absolutely is a compromise. This dialog pops up of
its own accord when you start Pidgin for the first time. I might buy
the claim that it's not an important compromise (you can just close
it), but claiming it's not a compromise is unreasonable.
> > > * The local alias field is completely confusing
> > It does seem to confuse some people, and not just on account addition.
> > (Some people set an alias and then are later upset that things like
> > nick changes on IRC are not reflected in the local UI.) However, it's
> > also a useful and very Pidgin-esque feature; do you have any
> > suggestions for how to make it less confusing?
> For starters move it away from the "Login options", which by the way
> are not really options but actually properties of the account itself.
I agree, this term could be changed for the better. "Account
properties" is probably superior. We can likely come up with
something even better than that.
> The account's "Local Alias" has been used as the user's private alias.
> Create a field for the user's private alias and soon the usefulness of
> an account's alias is diminished if not gone.
I think this is a continuation of the obvious communication failure
with respect to aliases -- the local alias *is* the user's private
alias, and there is no other field for this. Why would there be?
What field for private alias are you suggesting which is different
from this? Are you asking for a global local alias, rather than
per-account local aliases?
> > Maybe. "Screen name" is very familiar to a huge number of users, as
> > well, because it's what AIM uses. This assertion is another
> > protocol-centric assumption.
> > I'm inclined to agree that username is better on the whole, but
> > there's not just one side to this issue.
> The name of Internet users surpasses by far the amount of AIM users,
> and there username is the de facto standard.
Sure ... but domain is important. :-) I'm agreeing that username is
probably a better term, but protocol-centric arguments are certainly
annoying when they don't take into account the whole picture.
> In anyway, I can't believe users really asked for it and developers
> even though were strongly opposed to the idea changed the default
> behavior out of the kindness of their heart. There is a difference
> between empathic listening and user-stop-bitching strategies.
Then perhaps you should review actual history, rather than make up how
you think it might have been.
For the record, I have never agreed that this is a good plan, or even
that "docklets" are a good idea. I subscribe to the belief that
notification areas are for notifications, not persistent little icons
that you just happen to want to have on screen but couldn't find a
better location. Maybe this comes from using a competent window
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...
Size: 189 bytes
Desc: Digital signature
More information about the Devel