case for old icons: Advantagous heuristics of differentiated protocol icons

[Ash]

I see the protocol icons have been removed for simplification, and there is a very emotional response to any crit of this. I see the overall goal of network transparency, but my opinion it is not worth it for the cost of functionally debilitating opaqueness.

There are a number of distinguishing aspects of the protocols, both in functionality and application which make it desirable to easily know what the protocols are. At a glance of the old GAIM I was able to infer many things about my contacts.

FUNCTIONALLY Which protocols can be sent online/offline msgs. The retort to this was not many people use the different protocols. I contend this in untrue, I use it all the time - its quite natural. Forcing me into a behavior and robbing me of "at a glance" functionality so the developers have feel satisfied with some macroscopic goal of protocol invisibility have impaired me. Dont underestimate the power of conveying information "at a glance" - a glance is all many people care to spare.

APPLICATION I'll keep this short, there are many examples I'm sure you can find think up yourself. I have workmates who have different protocol accounts, one for work and one for personal - I have the same. Again, at a glance I can tell if which one is his personal account, avoiding them the embarrassment of having one of my casual msgs popping up when they boot up while sitting with co-workers. Another friend of mine only uses ICQ at home, and again - "at a glance" I am able to tell whether they have gotten home yet. The improved accuracy of whom it is cannot be under estimated either, I've already had the embarrassing situation of IMing "the wrong Neil" a personal msg.

The hiding of the protocols has had the exact, and expected result: It's made it difficult to infer and plan according to the different aspects of the protocols both functionally and in the way they have been adopted by my buddies. I strongly suggest you "theme" the icons, such that we have a choice.

[seanegan]

Duplicate of #414

[deryni]

To the best of my knowledge at this point all of the major protocols support offline messages. Furthermore, pidgin now includes an offline-message-to-buddy-pounce plugin which emulates offline messages on protocols for which pidgin doesn't support them. One could also create another plugin which searches for another buddy in the contact which supports offline messages or is online and send the message to them instead, that would work as well. Regardless, this fact does not require being able to see the protocol from a glance at the buddy list which is the 'feature' under discussion here. What information did you gain for immediate use by glancing at the buddy list? I have never claimed that there is no use to knowing what protocol a buddy is on, rather the claim has been that having the *buddy list* *status icon* contain the protocol was a poor place for that information as it confused things and didn't provide the information where it was needed.

The fact that no one has come up with conrete examples of where the buddy list status icon containing the protocol icon has been of immediate correct use yet indicates that your assurance that they can be thought of is worth very little beyond your belief that they must exist.

Were you the fellow in #pidgin-win32 who talked about being able to tell where your friends are by the protocol they use? Like I told that person, the fact that your buddies use different protocols in different locations makes them rather unique among the IM using populace. Most people do not differentiate location through the use of protocol, most people barely even use status messages to differentiate that. There is a reason that jabber was designed to allow for multiple simultaneous logins to one account and why AIM added that feature recently, it is *by far* the more common usage pattern. And like I told the person in #pidgin-win32 the fact that the protocol icons did what you wanted here was a coincidence and not a feature of the protocol icons. Aliases would work for you just as well, as would displaying of jabber resources, as would correctly set MSN friendly names all of which are better systems for this.

[elb]

In fact, the response to the "crit"[sic] of this has been anything but emotional; it has in fact been logical. The "crit" has been emotional, as this post continues to be.

For example, you state that the response to "Which protocols can be sent online/offline msgs." is that most people do not use multiple protocols: in fact, while this response may have been sent somewhere, it is not the response we have generally been giving. Most of the developers do use multiple protocols, and we design specifically for this case. Assuming that I understand what you meant by that sentence fragment, what you want is for Pidgin to show you what protocol your buddies are using so that you can manually select a protocol which supports offline messaging in sending a message to an offline buddy. This should, in fact, be handled entirely automatically by Pidgin; when you click on a contact which has no online buddies, it should automatically direct you to a protocol which can handle offline messaging.

For your second point, you are overloading a data point with an essentially unrelated meaning; what if your buddy happened to have their work account and home account on the same protocol? How would you solve the problem, then? I suggest to you that whatever solution you would use (or like to use, if it is not currently possible) in that case is the better solution. An immediate candidate would be to postpend (or prepend) the alias for these accounts with some sort of marker, like (H) or (W). If differentiation is very important for you, you might even want to put the buddy in two different contacts.

In short, I think that this ticket is the emotional response, not our continued logical rebuttals. I am yet to see a "problem" caused by being unable to see protocol icons which does not reduce to either 1) an interface bug which we should fix, or 2) fictitious.

[BigRedBrent]

I just like to see them. User satisfaction should have some form of priority. If adding a single simple option would satisfy a few thousand people, then why not?

[BigRedBrent]

No one is asking for it in any way to be a default option, just that the option be available.

[BigRedBrent]

"If we had only the foresight to have never introduced protocol icons to begin with, we wouldn't need to have this debate."

I would just like to point out the fact that the first time I ever used a multi protocol client it did not have protocol specific icons and the first thing I did was desperately look for a way to add that functionality to that program. So even without using a client with this option for any amount of time I still greatly desired this option, and the desire for it never left no matter how long I would go without this option. I don't know how to describe how or why people want this, but they just do, and very strongly. An option that is not default will always be wanted for this.

[BigRedBrent]

http://developer.pidgin.im/ticket/1863

"I am not sure what you think spamming the bug tracker is going to accomplish."

The spam was unintentional as already stated in that thread.

"There is no indication that there are "thousands upon thousands" of users "just like you"; there have been a dozen or so users requesting protocol icons in the buddy list, compared to the *millions* of Pidgin users out there."

I am just guessing since I am sure statistically many people think in the same way I do. Proof of this guess is irrelevant.

"As has been stated in numerous places (which you undoubtedly neglected to research or read), protocol icons could be reinstated by a plugin. We are not going to write such a plugin, but you may."

I do not have the knowlage as of yet to make such a plugin and egerly await someone who can make one.

[merwin]

What about this reasoning: I want to prune my contact list down on a certain protocol. I recently re-added an old Yahoo IM account that I hadn't used in a year or two. There are a lot of people on there that I want to remove, but I don't know which contacts are Yahoo and which are other protocols. I suppose I could mouse over each contact to find out the protocol, but that is very cumbersome and makes the process take much longer.

What if Windows decided to hide the file extension because you didn't need it, and the only way to find it was to mouse over the file. It could be argued by them that the file extension isn't necessary, and the file type icon and type description should give you all the info you want, but many people want to see a little more detail. In fact, they do hide it... but they at least give you the option of putting it back if you like to see it.

I just don't understand the argument of putting it back being complex, as it would just be an option in the configuration and another column in the contact list with the protocol of whichever contact is on-top.

And to the people who say to write a plugin yourself to do it. I'm sure that many of us would like to have the spare time to write such a plugin, however most of us don't. Why is it so difficult for one of the existing developers to implement it as a plugin that is included with Pidgin?

[elb]

Replying to merwin:

What about this reasoning: I want to prune my contact list down on a certain protocol. I recently re-added an old Yahoo IM account that I hadn't used in a year or two. There are a lot of people on there that I want to remove, but I don't know which contacts are Yahoo and which are other protocols. I suppose I could mouse over each contact to find out the protocol, but that is very cumbersome and makes the process take much longer.

I suggest signing off your other accounts for the time necessary to prune that list.

I just don't understand the argument of putting it back being complex, as it would just be an option in the configuration and another column in the contact list with the protocol of whichever contact is on-top.

It is clear from this, and your next comment, that you don't understand this because you are not a programmer. That is fine, but it does make assertions like "it would just be ..." somewhat shady. Any time there is a portion of code which is only exercised sometimes, there is disproportionate cost for maintaining that code. You are sort of correct, in that the cost is not that great, but it is greater than the value of the option (which is very nearly nil).

And to the people who say to write a plugin yourself to do it. I'm sure that many of us would like to have the spare time to write such a plugin, however most of us don't. Why is it so difficult for one of the existing developers to implement it as a plugin that is included with Pidgin?

But you assume that the regular developers do have the spare time to write such a plugin, apparently without even any idea of how much time that would be? Interesting logic...

[merwin]

Replying to elb:

I suggest signing off your other accounts for the time necessary to prune that list.

OK, that does work. Thanks for that tip.

It is clear from this, and your next comment, that you don't understand this because you are not a programmer. That is fine, but it does make assertions like "it would just be ..." somewhat shady. Any time there is a portion of code which is only exercised sometimes, there is disproportionate cost for maintaining that code. You are sort of correct, in that the cost is not that great, but it is greater than the value of the option (which is very nearly nil).

I'm not a programmer? That will very much disappoint the company that I have been working for as a developer for the last several years. They will be sad to hear that they have wasted all of that money on me... and will probably wonder how I produced so much code for them over the years :)

But you assume that the regular developers do have the spare time to write such a plugin, apparently without even any idea of how much time that would be? Interesting logic...

The icons already exist for each contact, they are just stuck in a popup instead of being displayed on the contact list. Having it display the topmost icon in the contact list itself should be very few lines of code, since the logic of displaying the icon is already there. I would write the damn plugin myself, but I have no experience in GTK, and also have no experience developing for Pidgin. Therefore, there is a huge learning curve for me to write the small amount of code. My main point in all of this is this: It seems the developers of Pidgin are telling users how they should be using IM, instead of letting the users dictate what they want in the application. One thing that I know for sure is that developers should not be the ones making usability decisions, as the average user thinks completely different.

[elb]

Replying to merwin:

Replying to elb:

But you assume that the regular developers do have the spare time to write such a plugin, apparently without even any idea of how much time that would be? Interesting logic...

The icons already exist for each contact, they are just stuck in a popup instead of being displayed on the contact list. Having it display the topmost icon in the contact list itself should be very few lines of code, since the logic of displaying the icon is already there.

I see. As we have said repeatedly, it is quite trivial -- but that does not mean it is something we choose to spend our time on.

I would write the damn plugin myself, but I have no experience in GTK, and also have no experience developing for Pidgin. Therefore, there is a huge learning curve for me to write the small amount of code.

Any programmer with more than a few thousand lines of real code under his/her belt could do it in an afternoon. I assume, since your employer has been paying you to program for many years (or whatever), that you qualify.

My main point in all of this is this: It seems the developers of Pidgin are telling users how they should be using IM, instead of letting the users dictate what they want in the application. One thing that I know for sure is that developers should not be the ones making usability decisions, as the average user thinks completely different.

The average user doesn't want protocol icons back. A few noisy users do, usually for ill-conceived reasons (as yours turned out to be, of course). If we were writing Pidgin for maximum profitability, you are completely right, we would have re-added this feature and continued to charge the same price for the software, raking in extra profit from that small minority of users who cannot stop and think about whether or not they really need protocol icons. Fortunately, Pidgin is free, and we write it in our spare time on a volunteer basis, and as such we can concentrate on writing the best software we know how, optimizing for our needs without having to compromise for that last tiny fraction of users, no matter what unfounded assertions about software design and usability are made.

I think we can chalk this subthread up as one more "need" for protocol icons which was not a need at all, and move on.

[merwin]

Replying to elb:

I see. As we have said repeatedly, it is quite trivial -- but that does not mean it is something we choose to spend our time on. Any programmer with more than a few thousand lines of real code under his/her belt could do it in an afternoon. I assume, since your employer has been paying you to program for many years (or whatever), that you qualify.

And the experience in GTK and the knowledge of Pidgin's code and plugin architecture would just poof out of nowhere? And if it would take "any developer with more than a few thousand lines of real code under his belt" an afternoon, it would stand to reason that one of the experienced Pidgin developers could do it in an hour or so.

The average user doesn't want protocol icons back. A few noisy users do, usually for ill-conceived reasons (as yours turned out to be, of course). If we were writing Pidgin for maximum profitability, you are completely right, we would have re-added this feature and continued to charge the same price for the software, raking in extra profit from that small minority of users who cannot stop and think about whether or not they really need protocol icons. Fortunately, Pidgin is free, and we write it in our spare time on a volunteer basis, and as such we can concentrate on writing the best software we know how, optimizing for our needs without having to compromise for that last tiny fraction of users, no matter what unfounded assertions about software design and usability are made.

I am stopping and thinking about it. And after using it for the entire time that it's been put in the software, it still bugs the hell out of me not to have them there.

I think we can chalk this subthread up as one more "need" for protocol icons which was not a need at all, and move on.

I'd just like to say that I used to believe was the superior IM client. However, the condescending attitude of developers such as yourself, who act like we are just ignorant idiots who can't wrap our heads around the concept of the new way, has somewhat soured my experience. Instead of just offering a plugin (which would have taken far less time than the back and forth with these "noisy users"), you get very abrasive with users who ask why it was removed. I hope that someone writes a plugin to show the icons again, so I can get back to using Pidgin again. Until then, I'm off to Trillian again

[merwin]

Replying to elb:

It is clear from this, and your next comment, that you don't understand this because you are not a programmer. That is fine, but it does make assertions like "it would just be ..." somewhat shady. Any time there is a portion of code which is only exercised sometimes, there is disproportionate cost for maintaining that code. You are sort of correct, in that the cost is not that great, but it is greater than the value of the option (which is very nearly nil).

Actually, it turns out that the cost is less that even I thought it would be. Turns out to be under 30 lines of code. Anyhoo, if you want to include the patch at any point (complete with a configuration option), it can be found here: http://merwin.bespin.org/pidgin/

But you assume that the regular developers do have the spare time to write such a plugin, apparently without even any idea of how much time that would be? Interesting logic...

Took me 2 hours to create the patch. I would assume (without looking at the plugin api) that it wouldn't be much longer to wrap it in a plugin.

[deryni]

Well done, you stepped up and actually did something about it rather than just adding to the whining that abounds about this, good job. Please take the time and make it a plugin, though for the plugin you will likely need to replace the available icon and not add a new column due to how the GtkTreeModel? stuff works.

If we had not been repeatedly attacked, insulted, spammed, etc. by all of the people who so desperately wanted this feature, we might very well have written the plugin for this ages ago. Nothing sours developers to helping people like being assaulted by the people demanding something. A large part of the reason I didn't work on it, and I feel confident that this is a reason others didn't either, is that we felt absolutely no desire to spend our time helping people who clearly had so little respect for us or the work that has gone into pidgin overall. You personally managed to mostly not do that sort of thing, and for that I thank you. If even one person had responded closer to the way you did this would have been solved the day after the release where they were removed, but people weren't that reasonable. And that was the problem.

[seanegan]

Thank you for doing this, Merwin. Please think about submitting it as a patch here on d.p.i so that we may give it proper consideration.

[merwin]

Replying to seanegan:

Thank you for doing this, Merwin. Please think about submitting it as a patch here on d.p.i so that we may give it proper consideration.

Done, http://developer.pidgin.im/ticket/2146