Yes, you read correctly. We finally quit being lazy and released a new Purple Plugin Pack. Ironically, this comes barely after our Debian packager uploaded a build of version 2.2.0 (our last release) for inclusion in unstable (cue evil laughter here).
New in this release is the inclusion of Andrew Pangborn's Enhanced History plugin that replaces the stock History plugin by adding several excellent features useful for the obsessive-compulsive who close their IM windows as often as possible. It is, of course, also immensely useful for the more normal people among us. :)
I also ripped out a plugin I never should have included in the first place--the broadcast plugin. Never again will it see the light of day.
The biggest thing in the release though is the major bugs we've fixed. We've been plagued with build system bugs that I couldn't fix. Gary finally got around to fixing them, so hopefully never again will we hear people having trouble because they have to build all the plugins all the time. We also fixed several plugin bugs, including the crash in the xchat-chats plugin that Pidgin 2.4.0 caused.
Enjoy!
Monday, March 17, 2008
Sunday, March 9, 2008
The Cost of Progress and Options
We recently released Pidgin 2.4.0 with a UI change that seemed inocuous to me. The change was actually in four parts.
We've had the idea for quite some time to put typing notifications in the conversation history area in Pidgin, just like Finch has always done and Adium has done for as long as I can remember. Code wizard that he is, Sadrul pounded this out in pretty short order. Sure it had some bugs, but given enough feedback, he was able to fix most of the issues with it. There are a few minor problems left, but I'm confident they can be worked out over time. This change proved controversial. At least one of our developers still doesn't like it. I do, but I'm a fan of a few different UI changes that have been made in the last year. I think it's safe to say we're going to stick with this change.
After the typing notification change, the old icon in the menutray was removed. The same developer who dislikes the history area notification also hates the removal of this icon. I personally don't care one way or the other--both notifications affect only the currently visible conversation, and other notification methods exist, such as the Guifications plugin. This change has also proven to be controversial, but I believe that's mostly because this change and the history area notification happened in the same release.
The next big change was the removal of the bar that allowed manual resizing of the conversation input area. This has caused far more uproar than I ever expected. The closely-related fourth change is that the auto-resizing of the input area is now a first-class citizen and cannot be disabled. Again, this caused much more of an uproar than I expected. The same developer I mentioned above also disliked these changes quite strongly.
These changes are each quite innocent on their own. The combination, however, has caused a flood of complaints over the changes in behavior. I'd like to detail some reasons for the changes and why there is a cost associated with restoring them.
The typing notifications in the history area have been requested numerous times over the years. To me it seemed reasonable, considering that libpurple's other two UI's have the same behavior. Granted, there is no real reason for the change to have happened, but it's not the end of the world. There is no loss of functionality and no "usability" issues as have been claimed. Anyone who wants the old typing icon back can fairly trivially write a plugin to restore it.
The input area is a whole new beast. We introduced an autoresizing input area sometime back in the 2.0.0 betas, before we renamed to Pidgin. Most people never saw this because we showed the buddy icon of the person we were conversing with to the left of the input area, and we forced the input area to be the larger of the minimum size (1 line, I think?) or the height of the buddy icon. This had some interesting bugs, too, as under some circumstances the size would be saved there because of the manual resizing option, so the input area would not autoresize. Another fun bug came with pasting text. Pasting sufficiently large quantities of text with a sufficiently small IM window would cause the autoresize to expand the IM window in very strange ways, sometimes resulting in conversation windows larger than the screen. There was also a bug in which dragging the manual resizing bar would not save the size of the input area correctly, so using it to work around the other bugs wasn't guaranteed to work either.
Sean decided to scrap the manual resizing because it significantly simplified fixing some of the autoresize bugs that he had fixed. Anyone thinking it's laziness may be justified in that opinion; I don't really know or care. I don't think it matters much, but apparently some users think it does. Yes, there are some bugs still, the most notable being the 1-pixel bug where a new conversation has an input area that's only about 1 pixel high. The changes also seem to have caused a crash in the xchat-chats plugin, which hijacks the history area of the conversation window and replaces it with the same widget xchat uses for irc channels. The plugin does this only for chats. There's also the fact that the lower and upper thresholds for resizing don't work well for rather large IM windows. On the mailing lists, we've already determined that what we have is not the optimal solution (thanks to a few helpful users--a very rare breed), and we are working towards making it better. We won't, however, bring back the manual resizing anytime soon.
The whole debate over manual resizing brings us to another debate--a ton of users are demanding that the automatic resizing vs manual resizing be a preference. We're not willing to do that, as it incurs a cost we're not willing to bear. Ethan Blanton said it best himself in a message to the support list:
Making both behaviors available will certainly cause additional bugs and stupid behaviors that would not appear if we were to leave well enough alone or even to revert to the previous behavior. Reverting to the previous behavior, however, again introduces complex interactions that we're not exactly excited about having, not to mention brings back the bugs that were successfully eliminated with its removal.
Aside from all this is the fact that while we could keep the same interface forever, we don't feel it's necessarily a good idea. Experimenting with the user interface is a way to achieve progress--we can't learn without experimentation, and what we learn from said experiments helps us to make Pidgin a better application. Yes, it causes friction with users and some developers, but it is a necessary process. That's the important thing to keep in mind--we're not taking features away in an attempt to punish users or see how far we can push users. Our changes are legitimate attempts to improve Pidgin's interface, reduce the number of bugs present, and make Pidgin the best we can for our own needs.
In that vein, we are fully aware that we cannot make everyone happy with our UI. It's simply impossible. There are numerous other messengers out there, many of which will certainly meet some users' needs better than we can. We also now have libpurple as a real, usable entity which anyone can use to get our protocol support while getting a UI completely different from ours. This raises my final point--there are options in the IM application space, even though they may be expensive for users to bear the consequences of.
We've had the idea for quite some time to put typing notifications in the conversation history area in Pidgin, just like Finch has always done and Adium has done for as long as I can remember. Code wizard that he is, Sadrul pounded this out in pretty short order. Sure it had some bugs, but given enough feedback, he was able to fix most of the issues with it. There are a few minor problems left, but I'm confident they can be worked out over time. This change proved controversial. At least one of our developers still doesn't like it. I do, but I'm a fan of a few different UI changes that have been made in the last year. I think it's safe to say we're going to stick with this change.
After the typing notification change, the old icon in the menutray was removed. The same developer who dislikes the history area notification also hates the removal of this icon. I personally don't care one way or the other--both notifications affect only the currently visible conversation, and other notification methods exist, such as the Guifications plugin. This change has also proven to be controversial, but I believe that's mostly because this change and the history area notification happened in the same release.
The next big change was the removal of the bar that allowed manual resizing of the conversation input area. This has caused far more uproar than I ever expected. The closely-related fourth change is that the auto-resizing of the input area is now a first-class citizen and cannot be disabled. Again, this caused much more of an uproar than I expected. The same developer I mentioned above also disliked these changes quite strongly.
These changes are each quite innocent on their own. The combination, however, has caused a flood of complaints over the changes in behavior. I'd like to detail some reasons for the changes and why there is a cost associated with restoring them.
The typing notifications in the history area have been requested numerous times over the years. To me it seemed reasonable, considering that libpurple's other two UI's have the same behavior. Granted, there is no real reason for the change to have happened, but it's not the end of the world. There is no loss of functionality and no "usability" issues as have been claimed. Anyone who wants the old typing icon back can fairly trivially write a plugin to restore it.
The input area is a whole new beast. We introduced an autoresizing input area sometime back in the 2.0.0 betas, before we renamed to Pidgin. Most people never saw this because we showed the buddy icon of the person we were conversing with to the left of the input area, and we forced the input area to be the larger of the minimum size (1 line, I think?) or the height of the buddy icon. This had some interesting bugs, too, as under some circumstances the size would be saved there because of the manual resizing option, so the input area would not autoresize. Another fun bug came with pasting text. Pasting sufficiently large quantities of text with a sufficiently small IM window would cause the autoresize to expand the IM window in very strange ways, sometimes resulting in conversation windows larger than the screen. There was also a bug in which dragging the manual resizing bar would not save the size of the input area correctly, so using it to work around the other bugs wasn't guaranteed to work either.
Sean decided to scrap the manual resizing because it significantly simplified fixing some of the autoresize bugs that he had fixed. Anyone thinking it's laziness may be justified in that opinion; I don't really know or care. I don't think it matters much, but apparently some users think it does. Yes, there are some bugs still, the most notable being the 1-pixel bug where a new conversation has an input area that's only about 1 pixel high. The changes also seem to have caused a crash in the xchat-chats plugin, which hijacks the history area of the conversation window and replaces it with the same widget xchat uses for irc channels. The plugin does this only for chats. There's also the fact that the lower and upper thresholds for resizing don't work well for rather large IM windows. On the mailing lists, we've already determined that what we have is not the optimal solution (thanks to a few helpful users--a very rare breed), and we are working towards making it better. We won't, however, bring back the manual resizing anytime soon.
The whole debate over manual resizing brings us to another debate--a ton of users are demanding that the automatic resizing vs manual resizing be a preference. We're not willing to do that, as it incurs a cost we're not willing to bear. Ethan Blanton said it best himself in a message to the support list:
Each individual option may be simple or trivial, but they add up. Options to do with UI behavior are _particularly_ expensive, due to their frequent interactions with the vagaries of UI toolkit behaviors, etc.
This expense takes the form, mostly, of subtle bugs and extra programmer effort. We have had numerous examples of options which appear to be simple on the surface causing numerous bugs and undesirable behaviors. A recent and memorable example of this was the option for persistent conversations -- I think we all agree that the ability to have conversations "open" without an open window is one which is appreciated by many users, but this seemingly simple feature has caused quite an avalanche of small and not-so-small bugs. In fact, there is speculation that the one pixel high input area which some people are seeing stems from this very option.
Anyone who tells you that options are not expensive is either not a programmer, or has never worked on a large program. It is true that orthogonal options in a clean code base can be implemented with little cost in *many* circumstances, but even the most forward-thinking and competent programmers will be blind-sided by subtle interactions on occasion, especially when throwing third-party libraries and code into the mix.
Making both behaviors available will certainly cause additional bugs and stupid behaviors that would not appear if we were to leave well enough alone or even to revert to the previous behavior. Reverting to the previous behavior, however, again introduces complex interactions that we're not exactly excited about having, not to mention brings back the bugs that were successfully eliminated with its removal.
Aside from all this is the fact that while we could keep the same interface forever, we don't feel it's necessarily a good idea. Experimenting with the user interface is a way to achieve progress--we can't learn without experimentation, and what we learn from said experiments helps us to make Pidgin a better application. Yes, it causes friction with users and some developers, but it is a necessary process. That's the important thing to keep in mind--we're not taking features away in an attempt to punish users or see how far we can push users. Our changes are legitimate attempts to improve Pidgin's interface, reduce the number of bugs present, and make Pidgin the best we can for our own needs.
In that vein, we are fully aware that we cannot make everyone happy with our UI. It's simply impossible. There are numerous other messengers out there, many of which will certainly meet some users' needs better than we can. We also now have libpurple as a real, usable entity which anyone can use to get our protocol support while getting a UI completely different from ours. This raises my final point--there are options in the IM application space, even though they may be expensive for users to bear the consequences of.
Subscribe to:
Posts (Atom)