I thought the whole point of removing the protocol icons (which was a horrible mistake imo) was to clean the interface. Now in gaim 2.2 we are able to turn those icons on but they now sit on the right side of the buddy list in addition to the green blobs.
Why can't the developers just admit they were wrong and enable us to replace the green blobs with the protocol icon? I don't see the need for both icons. Instead of relieving clutter some of my buddies will now have 3 icons (protocol, green blob, and cellphone/hiptop). Also, having anything on the right hand side isn't easy too look at as there are no lines to guide your eyes. Sounds dumb but it's true. It takes me longer now to look at someone's nick... then find their protocol instead of just clicking on the nick like I did back in the gaim days.
I might sound ungrateful and I'll admit that if I was someone reading this I'd think the same thing. To that let me say I LOVE PIDGIN. It's fantastic and my most used piece of software. As soon as you guys offer merchandise I plan on getting some to help support additional development. I love almost everything about it but absolutely hated the removal of client icons. I tried it like etan suggested and it's been months and months, I still think it sucks. And if you disagree then why is the "show protocol icons" even an option now?
Is anyone else with me on this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If all the developers act as a single body, and we don't provide any options that we disagree with, then pidgin will no option at all.
Sometimes options exist because not all of us agree on the same thing, sometimes they exist because we think they are reasonable, sometimes they exist simply because other people want it and submitted patches to us. I don't think a single option exist because we are "wrong".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The protocol icon option was added because Justin Heiner made a patch to prove to the development team how easy it was to add them back in. His site for the patch is found here http://merwin.bespin.org/pidgin/.
It seems after enough people complaining about the missing icons the development team finally decided to implement his patch into the official source. I'm extremely happy that the patch was added but I have to agree, the green dots are pointless and should be removed/replaced with the protocol icons again as it was in Gaim or at the very least, make that an option to switch between the two. But I'm still happy about the patch so I think I will finally update my Gaim version 2.0.3 to pidgin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I couldn't agree with you more. Displaying the protocol icons was the show-stopper for me. I have friends who use Yahoo for work, AIM for home, and gTalk on their mobile. Hell if I was going to hover each name all the time to find out which protocol they're on.
Kudos to Justin.
They should have admitted they were wrong, not try to deceive us that it was so very complicated to do this, give us the option to toggle, and not give us the "everyone is wrong, we are right" attitude. It would have been a smoother transition for our "minority." I'm just very happy they finally added the icons...excuse me, included Jason's simple patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"and not give us the 'everyone is wrong, we are right' attitude"
I'll have to agree. Quite frankly, I find this anti-user attitude to be very disturbing. If there were better competitors to GAIM, I'd gladly switch to something else. I'm ready to try Trillian again.
I recently tried to suggest a change to the UI that I thought would make the functions of the "Font" and "Insert" menus appear to be clearer than a simple list, but the reaction was pretty much "we hate it" for no particular reason, other than some vague comparisons to Microsoft Office's new ribbon (which I've never actually used). I'm not sure if I was talking to the actual devs or just some users that were hanging around, though.
On the GAIM website, they link to a decent article about how it's good to have a simple UI from "Havoc" - which in turn links to an excellent online book about UI by Joe.
Apparently, they just read Havoc's article and didn't bother to read Joe's book on UI design.
Joe's book stresses a few good points:
-Metaphors are good - they're instantly recognizable .
-Sticking with users' expectations are good.
-Users hate to read, and often don't.
To that end, I've suggested some changes to the menus so they would pop up some nice and easily recognizable controls instead of a list of items. It's a compromise solution between the old way of doing things (which wasn't really broken to begin with), and the new way of doing things (which makes usability worse).
The people in the chat disliked it, but I didn't know if they were devs - so I hope some dev takes a closer look at the suggested changes and tells me for sure their thoughts about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm happy with the option to use the old formatting toolbar in the 2.2 release, but I do agree with this anti-user attitude.
It seems as though the development team has changed their UI focus to the lowest common denominator. It's resulted in an oversimplified interface, options removed entirely, etc. - and users suggesting adding more advanced stuff for those of us who want more control are basically being told that "that's too complicated and might confuse someone".
I also miss the protocol icons. The new ones are, indeed, far too bulky, and putting them on the right makes it hard to see who's using what service. I can't imagine it being programatically hard to use the old Gaim style instead of the status bubbles, but I would imagine that the response we'll hear on this is that this is clearer and easier for more users.
However, after defending the oversimplified and difficult to use formatting toolbar change, the developers seemed to have been willing to throw us that bone, so perhaps they'll re-enable this as well.
Also to cobraa1 - maybe others didn't like your suggestion because it's harder to see what you were suggesting. I completely agree with using icons instead of just text in the list of formatting optoins (when using the tiny formatting bar) - any application with a GUI is just that - graphical...and graphical representations of things are always easier to quickly recognize than just text.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No one has been told "that's too complicated and might confuse someone" what has been said is that there are things that are too confusing to be enabled by default and/or made optional in pidgin itself and that many of these things are *perfect* candidates for being made into plugins. That response, contrary to what most people seem to think, is *not* the equivalent of being blown off and is very often exactly the opposite. Generally, when we suggest that people write things as patches and plugins we fully think they should do that and that the existance of such a patch or plugin would be a useful addition to pidgin. That belief, however, does not translate into a desire to implement it in pidgin directly or to write the code ourselves.
I fail to see how the current protocol icons can be "too bulky" when they are exactly the same size as they would be if they replaced the status icons. I agree that putting them on the right makes it less apparent at a very quick glance who is using what protocol, and I think that is a good thing. I still don't think the protocol icons belong in the buddy list and dislike that they were brought back. Given that they have been though I fully agree to their having been placed as an emblem equivalent to hiptop, etc. because that is a much more appropriate location for them.
It is in fact likely not that difficult to replace the status icons with the protocol icons in a plugin, but in the same way you imagined our response I imagine that no one who actually wants this change will step up to write that plugin.
While it might be the case that graphical representations of things are quicker to identify then textual representations of things (though I would need you to cite research to prove that before I will blindly accept it), it is also the case that graphical representations are *much* more open to misinterpretation and are *much* harder to condense down to small sizes than text. As an example of this someone in #pidgin just recently asked "what is the icon that looks like a toilet s[eat]" next to people in the buddy list. I had to go through the icons one by one to even begin to guess what icon he was referring to. As it turns out he was referring to the blocked icon (http://developer.pidgin.im/viewmtn/revision/file/8bb511fc7058716755e1117ddde9b2baa349cbab/pidgin/pixmaps/emblems/16/blocked.png). I hope this illustrates my point at least a little. Also, don't forget that icon identification can be very heavily swayed by regional and cultural upbringing and context whereas a single word or two (when properly translated, which can be done with text and not with graphics) is much closer to universally understandable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Generally, when we suggest that people write things as patches and plugins we fully think they should do that and that the existance of such a patch or plugin would be a useful addition to pidgin. That belief, however, does not translate into a desire to implement it in pidgin directly or to write the code ourselves."
The problem with this is that functionality has been REMOVED - it was there before, so if anything, additional code work was required to find and remove it from the existing Gaim source code.
I dislike the size of the standard status icons, and the protocol icons are just as bulky. That, however, is easily remedied by replacing the PNG files with 10x10 versions.
"I agree that putting them on the right makes it less apparent at a very quick glance who is using what protocol, and I think that is a good thing."
Why? What if you prefer using AIM over Yahoo with someone, but they have both accounts? I'm not sure why it's a "good thing" that it's not easily apparent what protocols users are actually using. I'm not arguing; I'm just curious.
"I still don't think the protocol icons belong in the buddy list and dislike that they were brought back."
This attitude is what bothers me. If you don't like it, you aren't required to enable it. It's almost universally better to provide the option for those who DO want it, rather than take it out entirely to satisfy those who DON'T.
"While it might be the case that graphical representations of things are quicker to identify then textual representations of things (though I would need you to cite research to prove that before I will blindly accept it)"
...so if you saw a triangular stop sign somewhere, you'd be able to very quickly identify it as a stop sign? Sorry, but this doesn't fly. It's much more efficient to use universal icons for formatting (bold, italic, strikethrough, etc.) and such things. Every Pidgin user uses Office, WordPad, TextEdit, Apple Pages, OpenOffice, and/or a variety of other editors. These all use some version of those universal icons. Why try to go against that?
However, there's not much reason to keep arguing this one, since the expanded formatting toolbar was very thankfully brought back with 2.2.
"[icons] are *much* harder to condense down to small sizes than text."
The formatting icons in Gaim 1.5 (which I'm still running on the computer I'm currently using) are only 10x10 - plenty small for a drop-down menu, and still completely usable. On that note...
"Also, don't forget that icon identification can be very heavily swayed by regional and cultural upbringing and context whereas a single word or two (when properly translated, which can be done with text and not with graphics) is much closer to universally understandable."
Which is why just about every application out there that uses toolbars of some kind has graphical AND textual indictations of a button's meaning. I'm looking at my chat window in Gaim 1.5, and the buddy list icons and the chat window icons for block, remove, etc, all use text and buttons. Even better, it's possible to disable the text, the buttons, or both, depending on your needs or preferences.
I doubt it's particularly difficult to provide the options for text only, icon only, or text+icon...considering that very option existed in Gaim 1.5 for the buttons at the bottom of both the chat and the buddy list windows.
I think that what cobraa1 and I are both trying to express is that there seems to be a little bit of hostility from the developers directed at the users of this particular application. The beauty of open source is that users CAN voice their issues with the UI, and something can actually be done about it.
Some of us aren't any good at programming, so we can't write patches to fix the issues we find with the application - our only option is to write about it in an open forum such as this one and hope that perhaps others are having the same problems, which might be enough motivation for the developers to consider changing the application a bit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are numerous reasons code can be removed, the code here was removed as part of larger buddy list changes and who knows what other changes. Assuming we went in to remove this to specifically vex people who liked it is silly. And as was indicated with the patch that added them back, often the work necessary to replace things that were removed is likely even less intensive than was involved to remove it in the first place. Not to mention often bringing a better implementation, location, or featureset along with it. So claiming that because something was removed it must therefore have been wrong is just ridiculous, because that would mean no feature that ever existed could ever be removed, even if only one person wanted it anymore.
Preferring to use one protocol over another is just fine and is *exactly* what contacts and the Send To menu are for, but this has been covered a thousand times or more so I won't go into it again.
Yes, I would very easily be able to identify a large triangular sign with the word 'STOP' written in it as a stop sign, I would recognize that *much* more quickly than someone who was unfamiliar with the 'standard' octangonal red stop sign would recognize a large red octangonal *wordless* sign in front of them. Care to argue otherwise?
I don't use any of Office, WordPad, TextEdit, Apple Pages, or OpenOffice.org at all actually, so your sweeping generalization fails. Not to mention the fact that most of those applications have at least subtly differing if not wildly differing icons (at least from what I can recall from the last times I used and of them). Also, I never said anything about explicitely *not* using graphical icons, all I said was that using *only* graphical icons is not a good idea. Which is a statement I firmly stand behind.
Yes, some icons are fully usable in small sizes, many are not, text does not suffer from these problems. Text is either readable or unreadable, and size only affects the distance at which a person can comfortably read it.
Yes, using both text and icons is *exactly* what I was claiming is necessary. And that further having the option to use icons or text only provides virtually nothing in the way of utility and only serves to clutter up the code and require making sure that nothing breaks it.
My problems with the suggested dropdowns in cobraa1's screenshot are that the BIU buttons (while reasonably obvious are untranslatable and therefore require understanding the B<->Bold, I<->Italic, and U<->Underline relationship), that the smiley face and mountain icons are likewise untranslatable, contain no text at all, and require understanding that they mean insert smiley and insert image (something which any number of people may or may not realize), that packing those dropdowns requires manual GTK+ handling of things as opposed to the much simpler population of a GtkMenu and then letting GTK+ handle it all for us, and that the dropdowns are very large (but that's minor and not really important at all). Also, the inconsistency of the packing between the two dropdown is disconcerting.
I have seen *no* hostility aimed at users of this or any other application, the only time hostility has come into this at all is when the users have attacked *us* and or claimed that we are actively attempting to annoy, aggravate, harm, or disparage them. I suggest that you read through posts that you think are actively hostile on our part again and then look at the posts that caused them. The other developers and myself have done *nothing* but attempt to get users to participate in the discussion, but that participation needs to come in constructive, well thought out, and well argued manners. It is when that fails to happen that we seem not to listen because we aren't being listened to ourselves.
Writing about things in forums and tickets is a good way to be heard, but you have to usefully and constructively present your opinions and be willing to listen to the responses you get, knee-jerking whenever people tell you they think you are wrong, or failing to fully read and understand the responses you get are not good ways to get people to keep listening to you. Neither is antagonizing, insulting, or continuing to assert how much you aren't being listened to.
One can always learn to program if one has a reason to, many of the current pidgin developers learned to program (at least to a large degree) by working on pidgin.
I apologize for the length of my response but I felt you deserved a full answer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Preferring to use one protocol over another is just fine and is *exactly* what contacts and the Send To menu are for, but this has been covered a thousand times or more so I won't go into it again. "
Absolutely, but there's no reason to *not* include the protocol icons - which was done with 2.2, apparently to your dismay. I still stand by the concept that it's better to include the ability to enable features, rather than leave them out entirely.
"Yes, I would very easily be able to identify a large triangular sign with the word 'STOP' written in it as a stop sign, I would recognize that *much* more quickly than someone who was unfamiliar with the 'standard' octangonal red stop sign would recognize a large red octangonal *wordless* sign in front of them. Care to argue otherwise?"
I'd care to argue that a sign that follows both color conventions (red) and textual conventions (stop) would be most effective. In movies I've seen that take place in other countries, stop signs are different shapes, but they are nearly universally red and white. Perhaps a handicap symbol would have been a better example - the stop sign was the first thing that came to mind.
"I don't use any of Office, WordPad, TextEdit, Apple Pages, or OpenOffice.org at all actually, so your sweeping generalization fails."
You missed the part where I mentioned "and/or a variety of other editors.", so my "sweeping generalization" was covering every rich text editor with a GUI that is available. I've used a large range of them on multiple operating systems, and "bold" and "italic" buttons are universally a letter that is either (gasp) bold or italic. Text formatting buttons, aside from text and background color, are just about universal. Aligning text, changing bold or italic or underline or strikethrough - icons can very easily convey all these. The point that cobraa1 was trying to make was that that 2.1 interface took out those icons entirely, which was a bad move and a disadvantage to your entire population of users who prefer visual cues over textual ones to navigate applications.
"My problems...are that the BIU buttons (while reasonably obvious are untranslatable and therefore require understanding the B<->Bold, I<->Italic, and U<->Underline relationship),"
Except that those buttons also visually convey the formatting - the B is bold, the I is in italic, the U is underlined...again, these are buttons that are used a good number of rich text editors, both commercial and open-source. In fact, the buttons used in Gaim 1.5 and Pidgin 2.x use the letter "A" with a visual cue as to the formatting. I would highly, highly doubt that any of your non-English-speaking users have ever had trouble understanding those.
"that the smiley face and mountain icons are likewise untranslatable, contain no text at all, and require understanding that they mean insert smiley and insert image (something which any number of people may or may not realize)"
This is where UI conventions come in to play. Most users who use Pidgin have more than likely used the default apps for their chosen protocols - AIM, GTalk, Yahoo! Messenger, MSN Messenger, etc. These all follow the same UI conventions. Ever since I can remember, every iteration of all of those applications (aside from GTalk, which thankfully doesn't use emoticons at all) has used some kind of yellow happy face to convey the emoticon option. Saying that every icon needs text would be like saying that the "minimize", "maximize", and "close" buttons that are ubiquitous in Windows and many X11 window managers should have text next to them, for the extremely small subset of users who don't understand immediately what they mean. If anything, Tooltips make it very easy to know what an icon means, and your users are aware of how tooltips work. It's almost as if you're assuming that your users are so unintuitive that they require immediate textual explanation for every single field and object and feature of the application.
"but you have to usefully and constructively present your opinions and be willing to listen to the responses you get"
...and I've done my best to do this. Perhaps I'm not perfect at it (nobody is), but I've tried to objectively point out things here. I'm just talking about basic UI conventions, and the concept of providing enough features to satisfy your users. Things like the slash command issue were arbitrarily removed from Pidigin - had you kept those and put them in an "advanced" tab, your inexperienced users would ignore them, and your experienced users would appreciate the continued inclusion of those features. This isn't much an opinion as it is a logical statement about how developing software works. I manage the development of a major search engine product as part of my day-to-day job, and I have quickly learned that in order to please as many users as possible, you absolutely default to providing too many features, rather than not enough.
I'm interested to know - how many developers are actively working on Pidgin? Do you do an adequate survey of your users so that you are certain a removed feature isn't still being used by a respectable chunk of your userbase, or is it to the point where certain things are being removed "for the sake of simplicity"? Perhaps I'm incorrect here, but it certainly feels to me like the latter.
I never meant to start an argument on this forum, so I'm just going to leave things at this post. Just please do not get into the habit of oversimplifying the Pidgin interface in order to satisfy the inexperienced users, or else you're likely to find that many of the power users (of whom I'd imagine there are many for an application such as this, seeing as its beginnings were in Linux) will just give up on the application entirely.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are a number of good reasons not to include the protocol icons, namely that including them encourages habits I think are less than good, but I really don't want to get side-tracked into discussing this yet again so I'm done discussing it.
Exactly, a sign that does exactly what someone expects in all ways possible is the best of all worlds, which is what I have been saying from the very start, I think neither text only or graphics only is the correct solution, but that given a choice between text only or graphics only I would choose text only every time because it is guaranteed to be more clear under all circumstances. The handicap symbol (assuming you mean the stylized person in a wheelchair) requires that you have seen a wheelchair to understand it, which I fully grant you is likely virtually everyone but it is a greater assumption than assuming a word existing in someones vocabulary, also dictionaries exist for looking up unknown words many less image glossaries exist.
I didn't miss that you mentioned other editors, I don't use any of them either. I use vim for all my text editing needs, in fact I am writing this post and wrote the last post in vim and it doesn't provide me with any formatting buttons of any sort. And whether or not most things agree on some default is mostly unrelated to the fact that I happen to think that default is suboptimal. I also don't agree that "icons can very easily convey" any of these things, I will admit that most people have gotten very used to the buttons by now though, through much experience, some tooltips, and some experimentation. None of which changes the fact that were they to have text as well they would be more obvious.
You would be wrong to doubt that no one has ever had trouble with them, we did receive comments on them, not many, maybe only two or three ever but they were made. They were generally of the form "it would be nice if the button didn't assume a character set that I'm not using" but nonetheless people were commenting. And again, the fact that things have existed in a certain way at one point, or in certain places does not simply by virtue of existing mean it was a good idea.
Designing a UI around the proprietary clients that you assume people have used is not a good idea, that has come back to bite us in any number of places over the years, and is still happening in places, look at http://developer.pidgin.im/ticket/2295 for an example of people being confused by even the wording of one of the most basic options in the Add Account dialog. And of course the smiley face icon for insert smiley is much more readily recognizable then the mountain for insert image but drawing lines like that becomes complicated and error prone, I also have yet to understand why using an icon for these menu items instead of text is better in any way other than being what other programs do.
My window manager doesn't have window decoration buttons at all, but that's neither here nor there. =) Yes, tooltips are very helpful and are likely how many people learn what the otherwise unintuitive button icons indicate. The fact that you need tooltips to indicate a buttons function is a failure of the UI more than a testament to versatile interface design. Clearly there are cases where that is a trade-off that is worth it, I have yet to see a reason to suggest that the formatting toolbar is such a case, do you think that it is? Can you tell me why you think that?
Conventions are quite often just the best way anyone has come up with to do something so far and not the best way to do something period, so adhering to convention for the sole purpose of having done so is not an argument that carries any weight with me. If you have reasons that you think the formatting toolbar is better served by icons rather than by text (or ideally text and icons) then please lay those reasons out for me, maybe I have just missed them but I haven't seen any yet.
We strive to provide as many features in pidgin directly as is reasonably possible and to provide ways to make as many other features addable with plugins as is humanly possible, when we fail to do that we generally either have a reason or ask for someone to contribute the idea or code for the things we missed.
What about slash commands was removed from pidgin? They still work just fine, the only thing that changed was that on protocols that support slash commands natively you no longer have the option to ignore unknown commands and have them sent as a plain message, a limitation for which there are workarounds that have been used in IRC clients for decades. So I'm entirely at a loss as to what you are talking about here.
An 'advanced' tab, as has been discussed in any number of places, is seen by the pidgin developers as a crutch for not having either fully understood the issue at hand or for not being able to work out the problems at hand. There are virtually no places where we consider the inclusion of advanced or hidden preferences a correct solution and virtually always believe that picking a sane default and allowing for plugins to override things is a much better alternative, even when the plugin to do the override has yet to be written. Also, and I don't have the research links to back this up at the moment but I believe it nonetheless, most users tend to turn on 'advanced' features even when they don't understand them because they don't want to feel like they aren't advanced enough to use them.
In your day-to-day job you *need* to please your users above all else, that is something that we don't have to do when we feel there are better ways to do things. As was the case with protocol icons and contacts in the buddy list, we felt that a certain feature or lack thereof was actively hurting the optimal usage of our product and set to fixing it so that people could use it better, we have the luxury of being able to tell people that they can come with us and learn how to better interact with their client, come with us and try to help us make the changes work better for them, feel free to make whatever changes they desire to their own copies (and distribute them), or feel free to leave and find a product that suits there needs better. That is a freedom that I greatly respect and greatly enjoy, the constant insinuations by users that by having spent my time on making pidgin a better client I therefore owe them more of my time to do the things they want is offensive and insulting to me, and does little more than make me not want to spend time on the project at all.
The list of active pidgin developers is contained in the About box of every release of pidgin and is changed as people come and go. We do not explicitely do any polls, we discuss our proposals in open forums both here (when people ask), on IRC, on XMPP, and on the mailing lists. We make mention of them in commit messages and some of us in blog posts, we then utilize the ultimate polling method to determine if people agree with us, we release a new version.
We never remove features that have a concrete use we can think of or one which people can unequivocably illustrate to us, we remove features no one can defend in a reasonable fashion (the protocol icons fall into this category for me), features that are broken by design (the MSN close window notifications for example), features that by their existance cause people confusion (ideally leaving the door open for plugins to reimplement them for people that care, the multiple status boxes of the early betas and the protocol icons are examples here, not that anyone wrote a protocol icon plugin), and features that by existing cause people to use them as crutches instead of developing better habits and/or letting pidgin make their work more easy (again the protocol icons fall in here as far as I am concerned). We have never removed anything purely to make things simpler if there was *any* reasonable reason it should stay (this is a claim I make boldly and am willing to do my best to defend should anyone question specific removals).
The only 'power users' I have seen even indicate that they want to give up are the people who are too lazy to put in any effort of their own to make pidgin work better for them, virtually everyone who actively wants to make it better stays and helps, even if that entails writing a plugin only they will use (which happens in #pidgin all the time).
I said it before and I will say it again, reread things carefully before you continue assuming you understand what was going on. Unless I missed it I didn't see any indications in this thread at all about the actual problems cobraa1 has with the compact formatting toolbar. And as for the original poster his entire intention seems to have been to request an apology from us for making a change I still firmly believe in and to chastise us (though politely and in a grateful way, or something like that) for not putting them back in exactly the way he wanted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I will reply mostly to the post right after mine, although I may try to touch on a couple other points.
"While it might be the case that graphical representations of things are quicker to identify then textual representations of things (though I would need you to cite research to prove that before I will blindly accept it), it is also the case that graphical representations are *much* more open to misinterpretation and are *much* harder to condense down to small sizes than text."
Small sizes are to be avoided anyways, as they lead to usability issues for the visually impaired and those with high resolution monitors.
"though I would need you to cite research to prove that before I will blindly accept it"
Sure, not a problem.
A study of 112 university students was taken to determine the recall ability of text, graphics, and sound:
The groups with graphics had an overwhelming increase of recall.
In addition, a study was also done with 108 experienced users, with the result being that graphics and text together is more usable than either one of them alone:
That being the case, I think a menu with both text and icons would greatly increase the usability of the menus.
I would agree, therefore, that my initial attempt to create a better interface was not optimal. I will attempt to create a better design in the near future. It would appear that combining both text and graphics is far superior than either text alone or graphics alone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your first study, while interesting, is not on point. My comment was about the recognition speed of graphics versus the recognition speed of text and not the recall percentages of the information they present, which your linked studies doesn't cover.
And yes, the fact that text and images is much better than either text or graphics alone was the main thrust of my point this entire time (the other half being that I believe text alone is better than graphics alone for the internationalization benefits andthe fact that word definitions are findable more easily then a picture's meaning is).
Thank you for taking the time to read and understand my posts before responding and I look forward to seeing your next attempt. Though as bsponline said the devel mailing list is generally a better place for that sort of discussion then this forum is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"maybe others didn't like your suggestion because it's harder to see what you were suggesting."
Yeah. When I get the time, I'll try to do a better mockup. Perhaps an animated GIF showing the dialog box with the menus to really show what I'm thinking about.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am always amazed by this "every developer is wrong, we are right" anti-developer attitude, particularly from the users who have never written a line of code or designed a UI.
But hey, you are always entitled for a full refund :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"I am always amazed by this "every developer is wrong, we are right" anti-developer attitude, particularly from the users who have never written a line of code or designed a UI."
Except that I actually DO UI design work on a regular basis, so I have some semblance of an idea about how to meet the needs of the broadest range of users in an application...
:P
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The protocol icons were added back because someone who wanted it back wrote a patch, which is exactly what we asked people to do in the first place if you will recall. Once the patch was written someone felt that it was simple enough to add and was thus included (a decision that many of us still don't support but so no point in fighting because it wouldn't help anything).
I still have no idea why you need to find out what protocol someone is using before you click on them to open the conversation window.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"I still have no idea why you need to find out what protocol someone is using before you click on them to open the conversation window."
But part of your responsibility as a developer is to recognize when your users want or need a feature, even if YOU specifically see no need for it.
I think that is waht's frustrating some of the users on this forum - it seems as though your personal ideas about the UI are overruling what the users want. It's great that you included the patch in 2.2, but your attitude about it is a little off.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, actually it isn't my responsibility to do anything of the sort, I have no responsibilities to any user of this software, that is what you need to understand. I do this because I want to, not because I owe anyone anything.
That being said, I should listen to people when they request things, and I do. In this case, as has been pointed out numerous times, I think the *real* reasons most people wanted protocol icons were due to bugs in pidgin, flaws in our protocol support, and flaws in our protocol-agnostic metaphor fixing those issues is *much* more important that actually adding back protocol icons. It is exactly that decision that you (and the rest of the protocol icon wanting crowd) has *never* acknowledged and never been able to refute. Every time (save a couple of cases which I chalked up to personal preference with no other benefit) we have asked for concrete examples or scenarios of uses for the protocol icons we have been able to explain that they are in fact not the correct solution to the issue but a crutch and that we would much prefer the correct solutions to be found and implemented. I really don't want to explain all that again, so please go look at all of the arguments for protocol icons (and our responses) closely again. If you *still* think you have a new and compelling case for them you are always free to mention it (though now that we have compromised your case would need to be even stronger to be worth it).
Our 'personal' ideas aren't overruling anything, our design goals are, as are our informed opinions about what the majority of our users want and like (opinions formed based on countless hours of support for those users), you and the other commentors do not have those same hours of support time and as such are in a much worse position to claim things about the majority of pidgin users. And again, we don't owe you anything. We aren't beholden to doing things just because users want them, if we felt like it we could entirely stop supporting pidgin tomorrow and there isn't a thing anyone could do about it other then step up and start maintaining it themselves. So *please* think before you start claiming that we need to listen or have a responsibility to listen to people who don't (generally) have the common courtesy to treat us as human beings and who don't (again generally) seem to even take the time to read our direct responses.
My point here was not to be insulting to to indicate that we don't listen to people, but rather that any listening we do do (and it is a lot) is purely because we want to help and are freely giving of our time and of our effort so that you (and the other users) can have a free and open source IM client that both users and developers can like and enjoy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Theres no point in arguing. Etan Reisner is single minded and shoots for the things only he and the other develop team feel should be added, as he should since he actually programs.
I do disagree with his mentality but there's really nothing we can do as normal users except to bitch and moan enough to get our point across and hope that someone will create a patch or modify the damn source code. It's a shame Pidgin/Gaim develop team turned out like this but ehh I guess it's a plus that it's still being worked on. Let's hope someone corrects/adds all the things people actually want as apposed to removing them, in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you understand that sarcastically and rudely responding to disgruntled users is not helping your case at all?
I'm amazed that the formatting toolbar was actually fixed. After reading your responses to users, I figured that you'd leave it at asking me to give specific reasons for why I wanted it back (which I did, and I was rebuffed with information on why I don't need to "remove formatting button" - which I still use on a regular basis, and how I can use keyboard shortcuts to format my text), and it would never actually get fixed. Was it that hard to implement? Wouldn't it have been easier to just let those of us who like the older interface have the option to use it, rather than turn it into a discussion and a flamewar?
There are a number of things that have been taken out of Pidgin - many for the sake of simplicity, which I have stated repeatedly should not be a priority in an application that started out as a Linux project and still sees a good number of advanced users. I'm sure that you have some justification for every single one of these changes, and the problem is that the attitude we've gotten from you is that you will stubbornly stand by your justifications to the bitter end, and will only implement changes that users loudly demand (and then slip little underhanded comments into your forum posts about how much you hate that change or don't understand why ANYONE would want that).
I could go through the list of Pidgin preferences I wish were still there from Gaim 1.5, but what's the point? You've made it clear that you know what's best for us, and that you're not interested in making reversions to the preferences or options in the application.
What I find interesting is that in your effort to convince your users that they really didn't want protocol icons (because you don't want them yourself), you ignored your user's request to know how to make Pidgin behave like Gaim, where you could select an protocol to prioritize for a contact. It took me two minutes to figure out, first by usin Gaim 1.5 and then by performing the same action in Pidgin, that manually moving one protocol to the top of the list for a contact will force Pidgin to first IM via that protocol (if it's online).
Some excerpts from your response to that thread on protocol icons:
"There is no good way to have pidgin remember 'always IM this buddy in the contact' and 'always send files to this buddy in the contact'."
I've already shown that, at least where IM is concerned, this IS very easily doable.
"That being said, since file transfer is usually a more deliberate action then IM anyway, the fact that you can right-click the contact, navigate down to the correct buddy submenu and hit Send File directly on that buddy is not too much of a hardship"
Actually, the cardinal rule in UI design is to limit the number of clicks to as few as possible. For instance, the release of Pidgin 2.2 has moved the "show" options for the buddy list to a submenu. This requires extra clicks (e.g. extra menus), and it's not actually necessary. There was no reason to move those menu items to a submenu, especially since they've been in the main "Buddies" menu for as long as I've used Gaim/Pidgin. And, once again - why not make it an either/or option? For those who rarely use those, allow them to enable the submenu. For those who prefer to have them quickly accessible, allow the old style.
Another user posted in that same thread, three things that bothered him about the UI changes in Pidin.
(1)(2) He didn't appreciate that the hiptop and mobile icons had been combined into one. Your response?
"Are you sure that pidgin doesn't distinguish between hiptop and mobile? If so I wonder if that was intentional. But this has little to nothing to do with the main point of this post."
I have no AIM friends who use hiptops, so I can't answer your question. But the "that's not what the OP asked" attitude is completely unnecesssary. This is a forum for users. I'm sure you've participated in other forums, and very frequently a user will ask a question that is indirectly related to the original topic of the thread. Ignoring the user because "that's not what the OP asked" is rude and unneeded.
(3) Again with the protocol icons. Your response was what I now expect from you:
"The protocol that a buddy is using is unimportant information in virtually all cases"
How did you determine this? What about users that simply prefer to use one protocol over another, and want to be able to easily see what protocol an account is on? Why, why, WHY do you insist on rejecting this as a complaint? Multiple users have mentioned it. You insist that they apparently don't know what they're talking about, and don't really want the protocol icons. Yes, it was implemented in the latest release, but the implementation wasn't all that clean (since I'm guessing the guy who wrote the patch just did it as a quick fix to an existing problem in the interface), and the users that have since mentioned they are dissatisfied with the half-assed implementation are being brushed off because you still vehemently insist that users don't need protocol icons, no matter what they say.
The last one is my favorite one.
(4) He doesn't like the larger status icons. The reason why I like your response so much, is because it's so completely wrong, as I had to prove to you with a side-by-side screenshot, because you refused to believe that HOLY SHIT A USER MIGHT KNOW WHAT THEY'RE TALKING ABOUT:
"While the icons themselves are in fact larger the size of the buddy list rows has not changed, as you can see in your screenshot quite clearly, because the windows are the same height and show the same number of buddies, and the rows all line up, so this isn't really an issue."
Imagine that! 10x10 icons DO make a very long buddy list substantially more usable by way of showing more contacts. And, it results in the interface being cleaner and less messy.
And this just about sums up your attitude about your users:
"You are free to stay with whatever version of gaim/pidgin you want no one ever forces you to upgrade. You are free to disagree with our design decisions all you like but unless you can convince us that a decision we made was wrong for some real reason we are unlikely to reconsider, especially when virtually everyone gets used to the new icons in less than a couple of hours and there have only been about 10 people who have complained about the new icons more than 'oh, this is different'."
Of course I could use Gaim 1.5. Of course, it's very unstable and crashes constantly. I could use the initial Pidgin release, but it hung CONSTANTLY. I could use Pidign 2.1, but I'd have to use that atrocious crippled formatting toolbar. Pidgin 2.2 brings back the toolbar, but messes up the view options for my buddy list. I don't seem to have a choice. I can stay will old, buggy, unpatched, unfixed versions, or I can upgrade and be stuck with a crippled interface and the removal of multiple features that I used on a regular basis in the application.
"...unless you can convince us that a decision we made was wrong for some real reason we are unlikely to reconsider..."
This is completely subjective, and it absolutely screws over anyone who is either not in your good graces or doesn't know the secret of how to convince you that taking out longstanding features of an application really isn't a good idea. We can't win. You've backed us into a corner, and you've basically told us that unless we can twist your arm and force you to see things our way, we as users are inconsequential, and you are more concerned with meeting your own personal needs, or meeting the needs of the absolute lowest common denominator (aka the stupidest users who can barely turn on their computer without help).
Now. While this may not be your actual attitude, it certainly appears that way, and you continuing to accuse us of being ignorant or knee-jerk, instead of taking the higher road and objectively listening to your users, isn't helping your case at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if the developers continue to ignore their users, then most of them will get tired of their attitudes and move on to another client. maybe then they will be happy to develop pidgin for themselves a handful of ppl. i know i'm currently thinking abt switch to kopete permanantly, and i dont think i will come back to pidgin when they wake up from this dream world some of them seem to live in.
maybe etan should stick to developing console apps, cause he doesnt have a clue abt guis. the length of his posts seem to make him believe he is somehow making any sense.
shifuimam has made complete sense and obviously has real world experience with GUI development. he has made his points very clearly, yet etan doesnt seem to have a clue.
i dont know why etan continues his FUD, maybe hes one of few who gets paid to do it :-/ , or he believes normal users are actually stupid enough to believe all the rubbish he writes.
dont get me wrong, etan does help alot of users here, and i am appreciative of the work he does, but when he talks complate rubbish, then i start to wonder what he is trying to do here :-/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would you mind telling me what 'complete rubbish' I have been continually saying? Would you care to point out significant places where my points haven't eventually been confirmed or agreed upon by both cobraa1 and shifuimam? Other than that they still want protocol icons (and I don't) I can't think of any.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought the whole point of removing the protocol icons (which was a horrible mistake imo) was to clean the interface. Now in gaim 2.2 we are able to turn those icons on but they now sit on the right side of the buddy list in addition to the green blobs.
Why can't the developers just admit they were wrong and enable us to replace the green blobs with the protocol icon? I don't see the need for both icons. Instead of relieving clutter some of my buddies will now have 3 icons (protocol, green blob, and cellphone/hiptop). Also, having anything on the right hand side isn't easy too look at as there are no lines to guide your eyes. Sounds dumb but it's true. It takes me longer now to look at someone's nick... then find their protocol instead of just clicking on the nick like I did back in the gaim days.
I might sound ungrateful and I'll admit that if I was someone reading this I'd think the same thing. To that let me say I LOVE PIDGIN. It's fantastic and my most used piece of software. As soon as you guys offer merchandise I plan on getting some to help support additional development. I love almost everything about it but absolutely hated the removal of client icons. I tried it like etan suggested and it's been months and months, I still think it sucks. And if you disagree then why is the "show protocol icons" even an option now?
Is anyone else with me on this?
If all the developers act as a single body, and we don't provide any options that we disagree with, then pidgin will no option at all.
Sometimes options exist because not all of us agree on the same thing, sometimes they exist because we think they are reasonable, sometimes they exist simply because other people want it and submitted patches to us. I don't think a single option exist because we are "wrong".
The protocol icon option was added because Justin Heiner made a patch to prove to the development team how easy it was to add them back in. His site for the patch is found here http://merwin.bespin.org/pidgin/.
It seems after enough people complaining about the missing icons the development team finally decided to implement his patch into the official source. I'm extremely happy that the patch was added but I have to agree, the green dots are pointless and should be removed/replaced with the protocol icons again as it was in Gaim or at the very least, make that an option to switch between the two. But I'm still happy about the patch so I think I will finally update my Gaim version 2.0.3 to pidgin.
I couldn't agree with you more. Displaying the protocol icons was the show-stopper for me. I have friends who use Yahoo for work, AIM for home, and gTalk on their mobile. Hell if I was going to hover each name all the time to find out which protocol they're on.
Kudos to Justin.
They should have admitted they were wrong, not try to deceive us that it was so very complicated to do this, give us the option to toggle, and not give us the "everyone is wrong, we are right" attitude. It would have been a smoother transition for our "minority." I'm just very happy they finally added the icons...excuse me, included Jason's simple patch.
"and not give us the 'everyone is wrong, we are right' attitude"
I'll have to agree. Quite frankly, I find this anti-user attitude to be very disturbing. If there were better competitors to GAIM, I'd gladly switch to something else. I'm ready to try Trillian again.
I recently tried to suggest a change to the UI that I thought would make the functions of the "Font" and "Insert" menus appear to be clearer than a simple list, but the reaction was pretty much "we hate it" for no particular reason, other than some vague comparisons to Microsoft Office's new ribbon (which I've never actually used). I'm not sure if I was talking to the actual devs or just some users that were hanging around, though.
On the GAIM website, they link to a decent article about how it's good to have a simple UI from "Havoc" - which in turn links to an excellent online book about UI by Joe.
http://www.joelonsoftware.com/uibook/fog0000000249.html
Apparently, they just read Havoc's article and didn't bother to read Joe's book on UI design.
Joe's book stresses a few good points:
-Metaphors are good - they're instantly recognizable .
-Sticking with users' expectations are good.
-Users hate to read, and often don't.
To that end, I've suggested some changes to the menus so they would pop up some nice and easily recognizable controls instead of a list of items. It's a compromise solution between the old way of doing things (which wasn't really broken to begin with), and the new way of doing things (which makes usability worse).
http://img253.imageshack.us/img253/870/path8068wk9.png
The people in the chat disliked it, but I didn't know if they were devs - so I hope some dev takes a closer look at the suggested changes and tells me for sure their thoughts about it.
I'm happy with the option to use the old formatting toolbar in the 2.2 release, but I do agree with this anti-user attitude.
It seems as though the development team has changed their UI focus to the lowest common denominator. It's resulted in an oversimplified interface, options removed entirely, etc. - and users suggesting adding more advanced stuff for those of us who want more control are basically being told that "that's too complicated and might confuse someone".
I also miss the protocol icons. The new ones are, indeed, far too bulky, and putting them on the right makes it hard to see who's using what service. I can't imagine it being programatically hard to use the old Gaim style instead of the status bubbles, but I would imagine that the response we'll hear on this is that this is clearer and easier for more users.
However, after defending the oversimplified and difficult to use formatting toolbar change, the developers seemed to have been willing to throw us that bone, so perhaps they'll re-enable this as well.
Also to cobraa1 - maybe others didn't like your suggestion because it's harder to see what you were suggesting. I completely agree with using icons instead of just text in the list of formatting optoins (when using the tiny formatting bar) - any application with a GUI is just that - graphical...and graphical representations of things are always easier to quickly recognize than just text.
No one has been told "that's too complicated and might confuse someone" what has been said is that there are things that are too confusing to be enabled by default and/or made optional in pidgin itself and that many of these things are *perfect* candidates for being made into plugins. That response, contrary to what most people seem to think, is *not* the equivalent of being blown off and is very often exactly the opposite. Generally, when we suggest that people write things as patches and plugins we fully think they should do that and that the existance of such a patch or plugin would be a useful addition to pidgin. That belief, however, does not translate into a desire to implement it in pidgin directly or to write the code ourselves.
I fail to see how the current protocol icons can be "too bulky" when they are exactly the same size as they would be if they replaced the status icons. I agree that putting them on the right makes it less apparent at a very quick glance who is using what protocol, and I think that is a good thing. I still don't think the protocol icons belong in the buddy list and dislike that they were brought back. Given that they have been though I fully agree to their having been placed as an emblem equivalent to hiptop, etc. because that is a much more appropriate location for them.
It is in fact likely not that difficult to replace the status icons with the protocol icons in a plugin, but in the same way you imagined our response I imagine that no one who actually wants this change will step up to write that plugin.
While it might be the case that graphical representations of things are quicker to identify then textual representations of things (though I would need you to cite research to prove that before I will blindly accept it), it is also the case that graphical representations are *much* more open to misinterpretation and are *much* harder to condense down to small sizes than text. As an example of this someone in #pidgin just recently asked "what is the icon that looks like a toilet s[eat]" next to people in the buddy list. I had to go through the icons one by one to even begin to guess what icon he was referring to. As it turns out he was referring to the blocked icon (http://developer.pidgin.im/viewmtn/revision/file/8bb511fc7058716755e1117ddde9b2baa349cbab/pidgin/pixmaps/emblems/16/blocked.png). I hope this illustrates my point at least a little. Also, don't forget that icon identification can be very heavily swayed by regional and cultural upbringing and context whereas a single word or two (when properly translated, which can be done with text and not with graphics) is much closer to universally understandable.
"Generally, when we suggest that people write things as patches and plugins we fully think they should do that and that the existance of such a patch or plugin would be a useful addition to pidgin. That belief, however, does not translate into a desire to implement it in pidgin directly or to write the code ourselves."
The problem with this is that functionality has been REMOVED - it was there before, so if anything, additional code work was required to find and remove it from the existing Gaim source code.
I dislike the size of the standard status icons, and the protocol icons are just as bulky. That, however, is easily remedied by replacing the PNG files with 10x10 versions.
"I agree that putting them on the right makes it less apparent at a very quick glance who is using what protocol, and I think that is a good thing."
Why? What if you prefer using AIM over Yahoo with someone, but they have both accounts? I'm not sure why it's a "good thing" that it's not easily apparent what protocols users are actually using. I'm not arguing; I'm just curious.
"I still don't think the protocol icons belong in the buddy list and dislike that they were brought back."
This attitude is what bothers me. If you don't like it, you aren't required to enable it. It's almost universally better to provide the option for those who DO want it, rather than take it out entirely to satisfy those who DON'T.
"While it might be the case that graphical representations of things are quicker to identify then textual representations of things (though I would need you to cite research to prove that before I will blindly accept it)"
...so if you saw a triangular stop sign somewhere, you'd be able to very quickly identify it as a stop sign? Sorry, but this doesn't fly. It's much more efficient to use universal icons for formatting (bold, italic, strikethrough, etc.) and such things. Every Pidgin user uses Office, WordPad, TextEdit, Apple Pages, OpenOffice, and/or a variety of other editors. These all use some version of those universal icons. Why try to go against that?
However, there's not much reason to keep arguing this one, since the expanded formatting toolbar was very thankfully brought back with 2.2.
"[icons] are *much* harder to condense down to small sizes than text."
The formatting icons in Gaim 1.5 (which I'm still running on the computer I'm currently using) are only 10x10 - plenty small for a drop-down menu, and still completely usable. On that note...
"Also, don't forget that icon identification can be very heavily swayed by regional and cultural upbringing and context whereas a single word or two (when properly translated, which can be done with text and not with graphics) is much closer to universally understandable."
Which is why just about every application out there that uses toolbars of some kind has graphical AND textual indictations of a button's meaning. I'm looking at my chat window in Gaim 1.5, and the buddy list icons and the chat window icons for block, remove, etc, all use text and buttons. Even better, it's possible to disable the text, the buttons, or both, depending on your needs or preferences.
For instance...
Dropdown menus with icons + text:
https://oncourse.iu.edu/access/content/user/cstrodtb/screenshots/pidgin-menu-example.png
Dropdown menus with a horizontal icon bar:
https://oncourse.iu.edu/access/content/user/cstrodtb/screenshots/pidgin-menu-example-3.png
I doubt it's particularly difficult to provide the options for text only, icon only, or text+icon...considering that very option existed in Gaim 1.5 for the buttons at the bottom of both the chat and the buddy list windows.
I think that what cobraa1 and I are both trying to express is that there seems to be a little bit of hostility from the developers directed at the users of this particular application. The beauty of open source is that users CAN voice their issues with the UI, and something can actually be done about it.
Some of us aren't any good at programming, so we can't write patches to fix the issues we find with the application - our only option is to write about it in an open forum such as this one and hope that perhaps others are having the same problems, which might be enough motivation for the developers to consider changing the application a bit.
There are numerous reasons code can be removed, the code here was removed as part of larger buddy list changes and who knows what other changes. Assuming we went in to remove this to specifically vex people who liked it is silly. And as was indicated with the patch that added them back, often the work necessary to replace things that were removed is likely even less intensive than was involved to remove it in the first place. Not to mention often bringing a better implementation, location, or featureset along with it. So claiming that because something was removed it must therefore have been wrong is just ridiculous, because that would mean no feature that ever existed could ever be removed, even if only one person wanted it anymore.
Preferring to use one protocol over another is just fine and is *exactly* what contacts and the Send To menu are for, but this has been covered a thousand times or more so I won't go into it again.
Yes, I would very easily be able to identify a large triangular sign with the word 'STOP' written in it as a stop sign, I would recognize that *much* more quickly than someone who was unfamiliar with the 'standard' octangonal red stop sign would recognize a large red octangonal *wordless* sign in front of them. Care to argue otherwise?
I don't use any of Office, WordPad, TextEdit, Apple Pages, or OpenOffice.org at all actually, so your sweeping generalization fails. Not to mention the fact that most of those applications have at least subtly differing if not wildly differing icons (at least from what I can recall from the last times I used and of them). Also, I never said anything about explicitely *not* using graphical icons, all I said was that using *only* graphical icons is not a good idea. Which is a statement I firmly stand behind.
Yes, some icons are fully usable in small sizes, many are not, text does not suffer from these problems. Text is either readable or unreadable, and size only affects the distance at which a person can comfortably read it.
Yes, using both text and icons is *exactly* what I was claiming is necessary. And that further having the option to use icons or text only provides virtually nothing in the way of utility and only serves to clutter up the code and require making sure that nothing breaks it.
My problems with the suggested dropdowns in cobraa1's screenshot are that the BIU buttons (while reasonably obvious are untranslatable and therefore require understanding the B<->Bold, I<->Italic, and U<->Underline relationship), that the smiley face and mountain icons are likewise untranslatable, contain no text at all, and require understanding that they mean insert smiley and insert image (something which any number of people may or may not realize), that packing those dropdowns requires manual GTK+ handling of things as opposed to the much simpler population of a GtkMenu and then letting GTK+ handle it all for us, and that the dropdowns are very large (but that's minor and not really important at all). Also, the inconsistency of the packing between the two dropdown is disconcerting.
I have seen *no* hostility aimed at users of this or any other application, the only time hostility has come into this at all is when the users have attacked *us* and or claimed that we are actively attempting to annoy, aggravate, harm, or disparage them. I suggest that you read through posts that you think are actively hostile on our part again and then look at the posts that caused them. The other developers and myself have done *nothing* but attempt to get users to participate in the discussion, but that participation needs to come in constructive, well thought out, and well argued manners. It is when that fails to happen that we seem not to listen because we aren't being listened to ourselves.
Writing about things in forums and tickets is a good way to be heard, but you have to usefully and constructively present your opinions and be willing to listen to the responses you get, knee-jerking whenever people tell you they think you are wrong, or failing to fully read and understand the responses you get are not good ways to get people to keep listening to you. Neither is antagonizing, insulting, or continuing to assert how much you aren't being listened to.
One can always learn to program if one has a reason to, many of the current pidgin developers learned to program (at least to a large degree) by working on pidgin.
I apologize for the length of my response but I felt you deserved a full answer.
"Preferring to use one protocol over another is just fine and is *exactly* what contacts and the Send To menu are for, but this has been covered a thousand times or more so I won't go into it again. "
Absolutely, but there's no reason to *not* include the protocol icons - which was done with 2.2, apparently to your dismay. I still stand by the concept that it's better to include the ability to enable features, rather than leave them out entirely.
"Yes, I would very easily be able to identify a large triangular sign with the word 'STOP' written in it as a stop sign, I would recognize that *much* more quickly than someone who was unfamiliar with the 'standard' octangonal red stop sign would recognize a large red octangonal *wordless* sign in front of them. Care to argue otherwise?"
I'd care to argue that a sign that follows both color conventions (red) and textual conventions (stop) would be most effective. In movies I've seen that take place in other countries, stop signs are different shapes, but they are nearly universally red and white. Perhaps a handicap symbol would have been a better example - the stop sign was the first thing that came to mind.
"I don't use any of Office, WordPad, TextEdit, Apple Pages, or OpenOffice.org at all actually, so your sweeping generalization fails."
You missed the part where I mentioned "and/or a variety of other editors.", so my "sweeping generalization" was covering every rich text editor with a GUI that is available. I've used a large range of them on multiple operating systems, and "bold" and "italic" buttons are universally a letter that is either (gasp) bold or italic. Text formatting buttons, aside from text and background color, are just about universal. Aligning text, changing bold or italic or underline or strikethrough - icons can very easily convey all these. The point that cobraa1 was trying to make was that that 2.1 interface took out those icons entirely, which was a bad move and a disadvantage to your entire population of users who prefer visual cues over textual ones to navigate applications.
"My problems...are that the BIU buttons (while reasonably obvious are untranslatable and therefore require understanding the B<->Bold, I<->Italic, and U<->Underline relationship),"
Except that those buttons also visually convey the formatting - the B is bold, the I is in italic, the U is underlined...again, these are buttons that are used a good number of rich text editors, both commercial and open-source. In fact, the buttons used in Gaim 1.5 and Pidgin 2.x use the letter "A" with a visual cue as to the formatting. I would highly, highly doubt that any of your non-English-speaking users have ever had trouble understanding those.
"that the smiley face and mountain icons are likewise untranslatable, contain no text at all, and require understanding that they mean insert smiley and insert image (something which any number of people may or may not realize)"
This is where UI conventions come in to play. Most users who use Pidgin have more than likely used the default apps for their chosen protocols - AIM, GTalk, Yahoo! Messenger, MSN Messenger, etc. These all follow the same UI conventions. Ever since I can remember, every iteration of all of those applications (aside from GTalk, which thankfully doesn't use emoticons at all) has used some kind of yellow happy face to convey the emoticon option. Saying that every icon needs text would be like saying that the "minimize", "maximize", and "close" buttons that are ubiquitous in Windows and many X11 window managers should have text next to them, for the extremely small subset of users who don't understand immediately what they mean. If anything, Tooltips make it very easy to know what an icon means, and your users are aware of how tooltips work. It's almost as if you're assuming that your users are so unintuitive that they require immediate textual explanation for every single field and object and feature of the application.
"but you have to usefully and constructively present your opinions and be willing to listen to the responses you get"
...and I've done my best to do this. Perhaps I'm not perfect at it (nobody is), but I've tried to objectively point out things here. I'm just talking about basic UI conventions, and the concept of providing enough features to satisfy your users. Things like the slash command issue were arbitrarily removed from Pidigin - had you kept those and put them in an "advanced" tab, your inexperienced users would ignore them, and your experienced users would appreciate the continued inclusion of those features. This isn't much an opinion as it is a logical statement about how developing software works. I manage the development of a major search engine product as part of my day-to-day job, and I have quickly learned that in order to please as many users as possible, you absolutely default to providing too many features, rather than not enough.
I'm interested to know - how many developers are actively working on Pidgin? Do you do an adequate survey of your users so that you are certain a removed feature isn't still being used by a respectable chunk of your userbase, or is it to the point where certain things are being removed "for the sake of simplicity"? Perhaps I'm incorrect here, but it certainly feels to me like the latter.
I never meant to start an argument on this forum, so I'm just going to leave things at this post. Just please do not get into the habit of oversimplifying the Pidgin interface in order to satisfy the inexperienced users, or else you're likely to find that many of the power users (of whom I'd imagine there are many for an application such as this, seeing as its beginnings were in Linux) will just give up on the application entirely.
There are a number of good reasons not to include the protocol icons, namely that including them encourages habits I think are less than good, but I really don't want to get side-tracked into discussing this yet again so I'm done discussing it.
Exactly, a sign that does exactly what someone expects in all ways possible is the best of all worlds, which is what I have been saying from the very start, I think neither text only or graphics only is the correct solution, but that given a choice between text only or graphics only I would choose text only every time because it is guaranteed to be more clear under all circumstances. The handicap symbol (assuming you mean the stylized person in a wheelchair) requires that you have seen a wheelchair to understand it, which I fully grant you is likely virtually everyone but it is a greater assumption than assuming a word existing in someones vocabulary, also dictionaries exist for looking up unknown words many less image glossaries exist.
I didn't miss that you mentioned other editors, I don't use any of them either. I use vim for all my text editing needs, in fact I am writing this post and wrote the last post in vim and it doesn't provide me with any formatting buttons of any sort. And whether or not most things agree on some default is mostly unrelated to the fact that I happen to think that default is suboptimal. I also don't agree that "icons can very easily convey" any of these things, I will admit that most people have gotten very used to the buttons by now though, through much experience, some tooltips, and some experimentation. None of which changes the fact that were they to have text as well they would be more obvious.
You would be wrong to doubt that no one has ever had trouble with them, we did receive comments on them, not many, maybe only two or three ever but they were made. They were generally of the form "it would be nice if the button didn't assume a character set that I'm not using" but nonetheless people were commenting. And again, the fact that things have existed in a certain way at one point, or in certain places does not simply by virtue of existing mean it was a good idea.
Designing a UI around the proprietary clients that you assume people have used is not a good idea, that has come back to bite us in any number of places over the years, and is still happening in places, look at http://developer.pidgin.im/ticket/2295 for an example of people being confused by even the wording of one of the most basic options in the Add Account dialog. And of course the smiley face icon for insert smiley is much more readily recognizable then the mountain for insert image but drawing lines like that becomes complicated and error prone, I also have yet to understand why using an icon for these menu items instead of text is better in any way other than being what other programs do.
My window manager doesn't have window decoration buttons at all, but that's neither here nor there. =) Yes, tooltips are very helpful and are likely how many people learn what the otherwise unintuitive button icons indicate. The fact that you need tooltips to indicate a buttons function is a failure of the UI more than a testament to versatile interface design. Clearly there are cases where that is a trade-off that is worth it, I have yet to see a reason to suggest that the formatting toolbar is such a case, do you think that it is? Can you tell me why you think that?
Conventions are quite often just the best way anyone has come up with to do something so far and not the best way to do something period, so adhering to convention for the sole purpose of having done so is not an argument that carries any weight with me. If you have reasons that you think the formatting toolbar is better served by icons rather than by text (or ideally text and icons) then please lay those reasons out for me, maybe I have just missed them but I haven't seen any yet.
We strive to provide as many features in pidgin directly as is reasonably possible and to provide ways to make as many other features addable with plugins as is humanly possible, when we fail to do that we generally either have a reason or ask for someone to contribute the idea or code for the things we missed.
What about slash commands was removed from pidgin? They still work just fine, the only thing that changed was that on protocols that support slash commands natively you no longer have the option to ignore unknown commands and have them sent as a plain message, a limitation for which there are workarounds that have been used in IRC clients for decades. So I'm entirely at a loss as to what you are talking about here.
An 'advanced' tab, as has been discussed in any number of places, is seen by the pidgin developers as a crutch for not having either fully understood the issue at hand or for not being able to work out the problems at hand. There are virtually no places where we consider the inclusion of advanced or hidden preferences a correct solution and virtually always believe that picking a sane default and allowing for plugins to override things is a much better alternative, even when the plugin to do the override has yet to be written. Also, and I don't have the research links to back this up at the moment but I believe it nonetheless, most users tend to turn on 'advanced' features even when they don't understand them because they don't want to feel like they aren't advanced enough to use them.
In your day-to-day job you *need* to please your users above all else, that is something that we don't have to do when we feel there are better ways to do things. As was the case with protocol icons and contacts in the buddy list, we felt that a certain feature or lack thereof was actively hurting the optimal usage of our product and set to fixing it so that people could use it better, we have the luxury of being able to tell people that they can come with us and learn how to better interact with their client, come with us and try to help us make the changes work better for them, feel free to make whatever changes they desire to their own copies (and distribute them), or feel free to leave and find a product that suits there needs better. That is a freedom that I greatly respect and greatly enjoy, the constant insinuations by users that by having spent my time on making pidgin a better client I therefore owe them more of my time to do the things they want is offensive and insulting to me, and does little more than make me not want to spend time on the project at all.
The list of active pidgin developers is contained in the About box of every release of pidgin and is changed as people come and go. We do not explicitely do any polls, we discuss our proposals in open forums both here (when people ask), on IRC, on XMPP, and on the mailing lists. We make mention of them in commit messages and some of us in blog posts, we then utilize the ultimate polling method to determine if people agree with us, we release a new version.
We never remove features that have a concrete use we can think of or one which people can unequivocably illustrate to us, we remove features no one can defend in a reasonable fashion (the protocol icons fall into this category for me), features that are broken by design (the MSN close window notifications for example), features that by their existance cause people confusion (ideally leaving the door open for plugins to reimplement them for people that care, the multiple status boxes of the early betas and the protocol icons are examples here, not that anyone wrote a protocol icon plugin), and features that by existing cause people to use them as crutches instead of developing better habits and/or letting pidgin make their work more easy (again the protocol icons fall in here as far as I am concerned). We have never removed anything purely to make things simpler if there was *any* reasonable reason it should stay (this is a claim I make boldly and am willing to do my best to defend should anyone question specific removals).
The only 'power users' I have seen even indicate that they want to give up are the people who are too lazy to put in any effort of their own to make pidgin work better for them, virtually everyone who actively wants to make it better stays and helps, even if that entails writing a plugin only they will use (which happens in #pidgin all the time).
I said it before and I will say it again, reread things carefully before you continue assuming you understand what was going on. Unless I missed it I didn't see any indications in this thread at all about the actual problems cobraa1 has with the compact formatting toolbar. And as for the original poster his entire intention seems to have been to request an apology from us for making a change I still firmly believe in and to chastise us (though politely and in a grateful way, or something like that) for not putting them back in exactly the way he wanted.
Yikes, so many replies!
Well, I will reply mostly to the post right after mine, although I may try to touch on a couple other points.
"While it might be the case that graphical representations of things are quicker to identify then textual representations of things (though I would need you to cite research to prove that before I will blindly accept it), it is also the case that graphical representations are *much* more open to misinterpretation and are *much* harder to condense down to small sizes than text."
Small sizes are to be avoided anyways, as they lead to usability issues for the visually impaired and those with high resolution monitors.
"though I would need you to cite research to prove that before I will blindly accept it"
Sure, not a problem.
A study of 112 university students was taken to determine the recall ability of text, graphics, and sound:
http://www.humanfactors.com/downloads/july98.asp
The groups with graphics had an overwhelming increase of recall.
In addition, a study was also done with 108 experienced users, with the result being that graphics and text together is more usable than either one of them alone:
http://www.humanfactors.com/downloads/apr00.asp
That being the case, I think a menu with both text and icons would greatly increase the usability of the menus.
I would agree, therefore, that my initial attempt to create a better interface was not optimal. I will attempt to create a better design in the near future. It would appear that combining both text and graphics is far superior than either text alone or graphics alone.
I suggest that you send any designs to pidgin-devel mailing list, far more developers look at that than this.
Your first study, while interesting, is not on point. My comment was about the recognition speed of graphics versus the recognition speed of text and not the recall percentages of the information they present, which your linked studies doesn't cover.
And yes, the fact that text and images is much better than either text or graphics alone was the main thrust of my point this entire time (the other half being that I believe text alone is better than graphics alone for the internationalization benefits andthe fact that word definitions are findable more easily then a picture's meaning is).
Thank you for taking the time to read and understand my posts before responding and I look forward to seeing your next attempt. Though as bsponline said the devel mailing list is generally a better place for that sort of discussion then this forum is.
"maybe others didn't like your suggestion because it's harder to see what you were suggesting."
Yeah. When I get the time, I'll try to do a better mockup. Perhaps an animated GIF showing the dialog box with the menus to really show what I'm thinking about.
I am always amazed by this "every developer is wrong, we are right" anti-developer attitude, particularly from the users who have never written a line of code or designed a UI.
But hey, you are always entitled for a full refund :-)
"I am always amazed by this "every developer is wrong, we are right" anti-developer attitude, particularly from the users who have never written a line of code or designed a UI."
Except that I actually DO UI design work on a regular basis, so I have some semblance of an idea about how to meet the needs of the broadest range of users in an application...
:P
The protocol icons were added back because someone who wanted it back wrote a patch, which is exactly what we asked people to do in the first place if you will recall. Once the patch was written someone felt that it was simple enough to add and was thus included (a decision that many of us still don't support but so no point in fighting because it wouldn't help anything).
I still have no idea why you need to find out what protocol someone is using before you click on them to open the conversation window.
"I still have no idea why you need to find out what protocol someone is using before you click on them to open the conversation window."
But part of your responsibility as a developer is to recognize when your users want or need a feature, even if YOU specifically see no need for it.
I think that is waht's frustrating some of the users on this forum - it seems as though your personal ideas about the UI are overruling what the users want. It's great that you included the patch in 2.2, but your attitude about it is a little off.
No, actually it isn't my responsibility to do anything of the sort, I have no responsibilities to any user of this software, that is what you need to understand. I do this because I want to, not because I owe anyone anything.
That being said, I should listen to people when they request things, and I do. In this case, as has been pointed out numerous times, I think the *real* reasons most people wanted protocol icons were due to bugs in pidgin, flaws in our protocol support, and flaws in our protocol-agnostic metaphor fixing those issues is *much* more important that actually adding back protocol icons. It is exactly that decision that you (and the rest of the protocol icon wanting crowd) has *never* acknowledged and never been able to refute. Every time (save a couple of cases which I chalked up to personal preference with no other benefit) we have asked for concrete examples or scenarios of uses for the protocol icons we have been able to explain that they are in fact not the correct solution to the issue but a crutch and that we would much prefer the correct solutions to be found and implemented. I really don't want to explain all that again, so please go look at all of the arguments for protocol icons (and our responses) closely again. If you *still* think you have a new and compelling case for them you are always free to mention it (though now that we have compromised your case would need to be even stronger to be worth it).
Our 'personal' ideas aren't overruling anything, our design goals are, as are our informed opinions about what the majority of our users want and like (opinions formed based on countless hours of support for those users), you and the other commentors do not have those same hours of support time and as such are in a much worse position to claim things about the majority of pidgin users. And again, we don't owe you anything. We aren't beholden to doing things just because users want them, if we felt like it we could entirely stop supporting pidgin tomorrow and there isn't a thing anyone could do about it other then step up and start maintaining it themselves. So *please* think before you start claiming that we need to listen or have a responsibility to listen to people who don't (generally) have the common courtesy to treat us as human beings and who don't (again generally) seem to even take the time to read our direct responses.
My point here was not to be insulting to to indicate that we don't listen to people, but rather that any listening we do do (and it is a lot) is purely because we want to help and are freely giving of our time and of our effort so that you (and the other users) can have a free and open source IM client that both users and developers can like and enjoy.
Theres no point in arguing. Etan Reisner is single minded and shoots for the things only he and the other develop team feel should be added, as he should since he actually programs.
I do disagree with his mentality but there's really nothing we can do as normal users except to bitch and moan enough to get our point across and hope that someone will create a patch or modify the damn source code. It's a shame Pidgin/Gaim develop team turned out like this but ehh I guess it's a plus that it's still being worked on. Let's hope someone corrects/adds all the things people actually want as apposed to removing them, in the future.
Thank you deathfired for so eloquently proving my point.
shifuimam take a look at this post carefully and tell me it doesn't translate to exactly the things I have been saying the entire time?
Do you understand that sarcastically and rudely responding to disgruntled users is not helping your case at all?
I'm amazed that the formatting toolbar was actually fixed. After reading your responses to users, I figured that you'd leave it at asking me to give specific reasons for why I wanted it back (which I did, and I was rebuffed with information on why I don't need to "remove formatting button" - which I still use on a regular basis, and how I can use keyboard shortcuts to format my text), and it would never actually get fixed. Was it that hard to implement? Wouldn't it have been easier to just let those of us who like the older interface have the option to use it, rather than turn it into a discussion and a flamewar?
There are a number of things that have been taken out of Pidgin - many for the sake of simplicity, which I have stated repeatedly should not be a priority in an application that started out as a Linux project and still sees a good number of advanced users. I'm sure that you have some justification for every single one of these changes, and the problem is that the attitude we've gotten from you is that you will stubbornly stand by your justifications to the bitter end, and will only implement changes that users loudly demand (and then slip little underhanded comments into your forum posts about how much you hate that change or don't understand why ANYONE would want that).
I could go through the list of Pidgin preferences I wish were still there from Gaim 1.5, but what's the point? You've made it clear that you know what's best for us, and that you're not interested in making reversions to the preferences or options in the application.
What I find interesting is that in your effort to convince your users that they really didn't want protocol icons (because you don't want them yourself), you ignored your user's request to know how to make Pidgin behave like Gaim, where you could select an protocol to prioritize for a contact. It took me two minutes to figure out, first by usin Gaim 1.5 and then by performing the same action in Pidgin, that manually moving one protocol to the top of the list for a contact will force Pidgin to first IM via that protocol (if it's online).
Some excerpts from your response to that thread on protocol icons:
"There is no good way to have pidgin remember 'always IM this buddy in the contact' and 'always send files to this buddy in the contact'."
I've already shown that, at least where IM is concerned, this IS very easily doable.
"That being said, since file transfer is usually a more deliberate action then IM anyway, the fact that you can right-click the contact, navigate down to the correct buddy submenu and hit Send File directly on that buddy is not too much of a hardship"
Actually, the cardinal rule in UI design is to limit the number of clicks to as few as possible. For instance, the release of Pidgin 2.2 has moved the "show" options for the buddy list to a submenu. This requires extra clicks (e.g. extra menus), and it's not actually necessary. There was no reason to move those menu items to a submenu, especially since they've been in the main "Buddies" menu for as long as I've used Gaim/Pidgin. And, once again - why not make it an either/or option? For those who rarely use those, allow them to enable the submenu. For those who prefer to have them quickly accessible, allow the old style.
Another user posted in that same thread, three things that bothered him about the UI changes in Pidin.
(1)(2) He didn't appreciate that the hiptop and mobile icons had been combined into one. Your response?
"Are you sure that pidgin doesn't distinguish between hiptop and mobile? If so I wonder if that was intentional. But this has little to nothing to do with the main point of this post."
I have no AIM friends who use hiptops, so I can't answer your question. But the "that's not what the OP asked" attitude is completely unnecesssary. This is a forum for users. I'm sure you've participated in other forums, and very frequently a user will ask a question that is indirectly related to the original topic of the thread. Ignoring the user because "that's not what the OP asked" is rude and unneeded.
(3) Again with the protocol icons. Your response was what I now expect from you:
"The protocol that a buddy is using is unimportant information in virtually all cases"
How did you determine this? What about users that simply prefer to use one protocol over another, and want to be able to easily see what protocol an account is on? Why, why, WHY do you insist on rejecting this as a complaint? Multiple users have mentioned it. You insist that they apparently don't know what they're talking about, and don't really want the protocol icons. Yes, it was implemented in the latest release, but the implementation wasn't all that clean (since I'm guessing the guy who wrote the patch just did it as a quick fix to an existing problem in the interface), and the users that have since mentioned they are dissatisfied with the half-assed implementation are being brushed off because you still vehemently insist that users don't need protocol icons, no matter what they say.
The last one is my favorite one.
(4) He doesn't like the larger status icons. The reason why I like your response so much, is because it's so completely wrong, as I had to prove to you with a side-by-side screenshot, because you refused to believe that HOLY SHIT A USER MIGHT KNOW WHAT THEY'RE TALKING ABOUT:
"While the icons themselves are in fact larger the size of the buddy list rows has not changed, as you can see in your screenshot quite clearly, because the windows are the same height and show the same number of buddies, and the rows all line up, so this isn't really an issue."
For clarification: http://shifuimam.googlepages.com/buddylist.png
Imagine that! 10x10 icons DO make a very long buddy list substantially more usable by way of showing more contacts. And, it results in the interface being cleaner and less messy.
And this just about sums up your attitude about your users:
"You are free to stay with whatever version of gaim/pidgin you want no one ever forces you to upgrade. You are free to disagree with our design decisions all you like but unless you can convince us that a decision we made was wrong for some real reason we are unlikely to reconsider, especially when virtually everyone gets used to the new icons in less than a couple of hours and there have only been about 10 people who have complained about the new icons more than 'oh, this is different'."
Of course I could use Gaim 1.5. Of course, it's very unstable and crashes constantly. I could use the initial Pidgin release, but it hung CONSTANTLY. I could use Pidign 2.1, but I'd have to use that atrocious crippled formatting toolbar. Pidgin 2.2 brings back the toolbar, but messes up the view options for my buddy list. I don't seem to have a choice. I can stay will old, buggy, unpatched, unfixed versions, or I can upgrade and be stuck with a crippled interface and the removal of multiple features that I used on a regular basis in the application.
"...unless you can convince us that a decision we made was wrong for some real reason we are unlikely to reconsider..."
This is completely subjective, and it absolutely screws over anyone who is either not in your good graces or doesn't know the secret of how to convince you that taking out longstanding features of an application really isn't a good idea. We can't win. You've backed us into a corner, and you've basically told us that unless we can twist your arm and force you to see things our way, we as users are inconsequential, and you are more concerned with meeting your own personal needs, or meeting the needs of the absolute lowest common denominator (aka the stupidest users who can barely turn on their computer without help).
Now. While this may not be your actual attitude, it certainly appears that way, and you continuing to accuse us of being ignorant or knee-jerk, instead of taking the higher road and objectively listening to your users, isn't helping your case at all.
if the developers continue to ignore their users, then most of them will get tired of their attitudes and move on to another client. maybe then they will be happy to develop pidgin for themselves a handful of ppl. i know i'm currently thinking abt switch to kopete permanantly, and i dont think i will come back to pidgin when they wake up from this dream world some of them seem to live in.
maybe etan should stick to developing console apps, cause he doesnt have a clue abt guis. the length of his posts seem to make him believe he is somehow making any sense.
shifuimam has made complete sense and obviously has real world experience with GUI development. he has made his points very clearly, yet etan doesnt seem to have a clue.
i dont know why etan continues his FUD, maybe hes one of few who gets paid to do it :-/ , or he believes normal users are actually stupid enough to believe all the rubbish he writes.
dont get me wrong, etan does help alot of users here, and i am appreciative of the work he does, but when he talks complate rubbish, then i start to wonder what he is trying to do here :-/
Would you mind telling me what 'complete rubbish' I have been continually saying? Would you care to point out significant places where my points haven't eventually been confirmed or agreed upon by both cobraa1 and shifuimam? Other than that they still want protocol icons (and I don't) I can't think of any.