I like Unicon's user interface solution to balance of protection against accidental development issue vote removal and convenience in executing vote changes, and say so in this post, complete with screenshot.
on the Fluid project "work" email discussion list
of patterns for confirming important user actions and providing easy "undo" for potentially erroneous user action. I appreciate that where to fall on the tradeoff continuum depends on how much information stands to be lost, how painful it is to manually undo the change, and how technically feasible it is to implement a more compelling user experience. Nonetheless, I wanted to share the anecdote of how Unicon's Cooperative Support program web interface implements the issue "un-voting" activity. When reviewing one's list of voted issues, it's easy to remove a vote. You know, I just don't think this issue's that important anymore, I'm withdrawing my vote in order to encourage the Cooperative Support team to instead work on developing open source project enhancements and fixes that are more important to me.
I think this combination of ease of removal and casual opportunity to undo works well because of the ease of recovering manually from process failure (worst case, a vote is lost and a user needs to figure out what issue it was that he or she wished to vote for and enter the vote anew), low stakes nature of the activity (it's not that huge of a problem if one's cooperative development votes aren't exactly as desired), and ease of including undo in the workflow. If a great deal more data entry were involved, if the consequences of an erroneous voting change were greater, or if it were more difficult to implement an undo feature, the appropriate user experience might be different. As Daphne notes in the Fluid discussion thread, managing user expectations so as to be able to take advantage of opportunities to offer ease of use in applying changes via the user interface supported by an ability to undo changes is difficult when this is to be offered alongside other paths to change the system involving more of a "confirm important change" pattern than an "easily change and easily undo" pattern. I'm fortunate here at Unicon to be able to work with talented designers and developers who have applied some thought to this in implementing the issue voting capabilities enjoyed by our subscribers, and who can put even more thought and design into the software projects we deliver for customers. I hope this post will help offer one more small example of use of the "undoable" pattern in user interface design and thereby help support discussion in the Fluid project. If it also helps people to become jealous of the ease of voting (and un-voting) enjoyed by Cooperative Support program subscribers, I won't mind that either.