Write-in

Hey Patrick, the ability to have user-submitted (or write-in) choices doesn't exist yet. It is on the todo list though. If you or someone else wants to tackle the issue that would be great, and I will probably make it a specific goal of mine in January or February.

Just wanted to add a 'me too' comment here, I haven't yet found any module for Drupal that provides this feature. I think it'd be a great community feature, as such a user extensible poll alongside with multiple choice selection could make a great overview for example about which movies, games, etc. the users like and so on.

I am considering building a whole site just for the capability to support the write-in type of feature, so I would definitely like to see this option. If you wanted to make it even better, then "Other" could open a whole sub-form (more than one field/check boxes/radio buttons) on the page.

If you want more info on what I'm planning here, I'll be happy to explain it.

I'd love to be able to tackle this stuff, but, in addition to being a Drupaller for only a month, I'm still very much a php newbie.

this feature would make my life so much easier :)

I know this is somewhat complex, but it would also be great if a user with the right permissions could look at the write-in candidates and merge those that are obviously the same. For instance, if someone writes "Joe Bloggs" and someone else writes "Joe Blogs", these two candidates should be treated as one if the admin user decides as such.

Just wondering if ChrisKennedy is still working on this.

Once Other is submitted, it must (should) be approved before appearing in the list for the next participant/viewer.

I need to run elections for a university's student association. According to the parliamentary procedures we follow, we can't display names to new voters that users have already voted as write-ins.

Any idea on a rough timeframe for support for write-ins in Instant Runoff voting? If it would help, my university's student association may be willing to help support development financially.

Thanks to everyone who's worked on this module - it is pretty darn awesome!

I am in the process of trying to tackle this issue. I'll post a patch when I have something semi-usable (next few days hopefully). This will be my biggest Drupal coding challenge so far and I'm bound to need a bit of help...

Here's what I'm thinking. I'll add a column to the {advpoll} table called 'writeins', a poll setting denoting whether eligible voters should be able to write-in a choice. When an eligible voter views a poll that has this setting enabled, an additional choice will be available in the form of a text field. In the case of a ranking poll, a select box for ranking will also be provided. If the optional write-in textfield is empty, it has no effect (and an error is set if the empty choice is ranked). Otherwise, the value of the textfield is added to the {advpoll_choices} table. So far, pretty simple.

One thing I'm not sure about is when votes are tabulated. I realize that there are three settings in Voting API for this (after every vote, at cron time, or never/manually). I'm a bit fuzzy on how Advanced Poll deals with vote tabulation. Anyone care to provide some useful direction here? Does Advanced Poll have a way to tabulate votes if the Voting API setting is "manual"? For the time being, I'll assume that this has been set to manual.

To make the write-in votes users submit useful, there has to be a way for a designated person (I suppose one with the "administer polls" permission) to merge similar write-in votes. For example, at my university there was a campaign to write in a Misha Teplitskiy (see mildly amusing campaign website). No one could spell his name so there were votes for variations on his name. Any suggestions on the best way to tackle this? My initial thoughts are that to start, an admin should not be able to merge a non-write-in choice into another choice. On the other hand, he should be able to merge a write-in choice into either another write-in choice or into a non-write-in choice. Do you agree with this? If so, I suppose this requires a new column in {advpoll_choices} denoting whether a given choice was a write-in. In any event, when a choice is merged into another choice, the choice being merged is deleted from the {advpoll_choices} table. I guess that all this happens on some multistep form (?) prior to tallying the votes. When the admin is happy that there are no more duplicate votes, he has the votes tallied (how please?).

Looking forwards to your thoughts!
J.D.

Glad to hear that you will work on this :)

I think we should have a specific permission for "add write-ins", that way sites have more flexibility in who gets to use this functionality.

Also, imo there should be an option to list previous write-in choices in future ballots. This has two advantages: it reduces the need for merging, and it's more democratic because it lets the participants influence the available choices. I do see why it would not be appropriate in some cases depending on election rules, so I think it's good to keep it as an option rather than a requirement.

Yes, you will want to add a column to advpoll_choices to designate whether or not that choice is a write-in. This opens up another possibility: add the write-in flag/toggle to the edit-choices section of the edit-poll page. That way if the site is configured to not show write-in choices on future ballots, an admin could "bless" valid/popular write-in choices by unchecking that flag and showing it on future ballots. This would reduce the need for merging while also not letting everyone automatically have their write-in choices show up on future ballots.

Vote tallying is not much of an issue. Simply call votingapi_recalculate_results('advpoll', $node->nid); to have votingapi recalculate the results - simply call this function after each merger to update the vote counts. Keep in mind that when you're merging choices you will need to update the individual ballots who voted for the "duplicate" choice and change their vote to the new merged value.

You're correct that only write-in choices should be allowed to be merged into other write-in or non-write-in choices.

Exciting news, and nice to see more contributers! I'll be watching this issue to help with testing and code review.

Thanks for the support guys (and all your work on this module)!

I hadn't considered an "add write-in" permission, but it certainly makes sense so I'll add that in.

I agree regarding an option to list previous write-in choices in future ballots. Consider it added.

A write-in flag/toggle to the edit-choices section of the edit-poll page sounds good too so I'll see what I can do. What do I need to know about AJAX here?

I'm glad to hear the recalculation of votes is so simple.

Any tips on where/how to implement the interface for merging votes? Perhaps next to "View" and "Edit" as a tab for the node?

Thanks,
J.D.

A new tab would work I guess, with the downside that a poll already can have quite a lot of tabs. Or maybe the Votes tab can be used for this as well. I'm also thinking of the possibility of adding this to the edit page with a checkbox and a new button next to add choice. Something like:

Choice 1:
[x] [_____________________________________] Remove

Choice 2:
[x] [_____________________________________] Remove

Choice 3:
[ ] [_____________________________________] Remove

[Add choice] [Merge selected choices]

Where would you choose which choice to merge the selected choices into?

Voting wise, does it matter? Isn't it a just matter of giving the merged choice the right name? In that case we could give the new merged choice a "merged name", something like: "Choice 1 text | Choice 2 text" and let the user manually change the name of the new choice.

A status message could give a hint: "Choice 1 text and Choice 2 text merged into Choice 1 text | Choice 2 text. You probably want to change this name to something else."

Or we could select the name depending on some rules, e.g. most votings, not a write-in etc.

Or, this is just a bad idea... :)

Imo the simplest interface is a "Merge write-in choice" fieldset on the edit poll page (don't show it when creating a new pol or if write-ins aren't enabledl). It would be collapsed by default since it won't be used too much.

Then just do:

Merge [1. List of write-in choices] into [2. List of all choices] [Merge button]

If jQuery's enabled you could dynamically remove the item selected in select #1 from select #2, but you would still want to do a server-side check that they're different. And if the choice is removed dynamically using jQuery you'll want to also remove it from these lists (although now that I think about it, we don't delete the votes for the removed choices, do we?). Anyway no need to worry about jQuery/AJAX until the patch starts to come together with basic server-side functionality.

The hardest part is figuring out what to do with existing ranking votes. It will be tricky to implement the exact algorithm but you will want to do something to the effect of:

0. Loop through all the voters.
1. If they haven't already voted for the existing choice, replace any votes for the merged choice with the existing choice.
2. If they already voted for the existing choice just delete the merged choice rank.
3. For any voters who utilized the last ranking (i.e. the worst ranking, which now shouldn't exist since we lost one choice), renumber the votes so that they fit within the n -1 number of choices. This is hard because you'll need to find out where the first "gap" in the rankings is, and increment the rank for all votes below that gap. For example, if their vote had been (choice => rank): A => 1, B => 2, C=> 3, D=>4, E=>5 and C is merged with A, the revised vote after step #2 is A => 1, B => 2, D => 4, E => 5. But D & E are being unfairly penalized with ranks of 4 and 5 because there are now only 4 possible ranks. So D needs to be shifted up to rank 3 and E to rank 4.
4. Then, once you've fiddled with the votes and fixed them up, recalculate the results.

For binary votes you won't have to worry about step #3, you'll just need to do #1, #2, and #4.

I've got most stuff working for binary polls and i just started on ranking polls. I'm strongly incentivized to get this done soon because I basically need to use it on June 12. I'll post a patch here ASAP.

This is a patch on HEAD from May 24, 2007. I've never been very good at rolling patches, so please tell me if I've done anything wrong. I have *lightly* tested the patch - please help me find all the sneaky bugs!

added functionality:
- "add write-ins" permission
- "allow write-ins" and "display write-ins [to future voters]" settings for node add/edit
- jQuery adds and removes the last choice from the maxChoices select field when the "allow write-ins" box is checked/unchecked
- with no javascript, an extra choice is added to maxchoices
- identical write-in votes are seen as one advpoll_choices entry

to do:
- ability to toggle whether a choice is seen as a write-in or not on the node edit page
- merging votes
- remove write-in vote choice from advpoll_choices if, the last vote for that choice is cancelled

known issues:
- write-in related form elements don't show up in node add/edit preview - I have no idea why
- submitting the node-edit form for a poll resets any write-in choices as ballot choices - this is because advpoll_update() calls _advpoll_insert_choices(), which deletes and then re-inserts all the choices from advpoll_choices. I need some guidance here. If it is deleting choices and then re-adding them, can't things like the poll offset change, drastically altering the outcome of a poll that has already had votes?

Thanks,
J.D.

I can't apply the patch. I'm no CVS/patch/diff expert but there is good documentation available: http://drupal.org/patch/create, more is in the handbook.

Look how Chris patches look like. I think the important thing is create the patch within the advpoll folder ("Check your directory" in the link above).

Also make sure you are using the Drupal-5 branch, that is where all current developing take place. The easiest in the long run is to checkout using CVS.

Looking forward reviewing this patch ;)

Alright, here it goes again. This is against the latest from DRUPAL-5. I think something might be screwy with line endings despite my having set Eclipse to use unix line endings. I think the compare editor in Eclipse decided to ignore my preference.

New known issue that needs fixing:
- validation of binary vote submission doesn't recognize that the write-in option is selected if maxchoices==1

It could have been my mistake, my last commit messed up the line endings for binary.inc and rankings.inc. Fixed that and re-rolled your patch against latest Drupal-5.

Did a quick test. Seems good! One issue: when getting the result back with AJAX the write-in is not rendered.

I have made some bug fixes in this patch including the issue you described.

Question: does the "Total votes" displayed in poll results equal the number of voters? If so, it should probably be "Total Voters".

Binary polls should now be working just fine with write-ins - please let me know if they are not! I am still debugging ranking polls.

forgot something...

Ranking polls seem to be working as well. When you get the chance, please test the patch (v3) as best you can.

Great job on this - it is really looking good. And sorry for the delay in reviewing. Anyway here are some initial thoughts:

[advpoll.install]

* The column names for writeins and displaywriteins both have an apostrophe rather than a backtick at the end, inside of advpoll_install().
* I'm pretty sure that the pgsql update code is wrong in advpoll_update_2(). Check out the examples at the end of modules/system/system.install for core Drupal; they all use db_change_table() for pgsql.

[includes/binary.inc]

* I find it unintuitive to have a write-in checkbox that has to be checked when submitted a new write-in vote. It would be better if that checkbox were removed - filling in the write-in text box already shows that the user wants to vote for that person.

[includes/ranking.inc]

* If possible the drop-down for the write-in vote should be placed next to the write-in text box.
* Using jQuery, we should remove the n+1 choice and only re-insert it if the write-in vote box isn't blank. Same for the write-in drop-down box.

[General]
* In t() strings, avoid \' if at all possible - it isn't escaped by extractor.php. Instead, enclose the string with double quotes so that you don't have to escape the single quote.
* Coding style - pretty good but still have errors, see http://drupal.org/node/318 . In particular, you need a space between IF and the first parenthesis; code comments should almost always start with a capital letter and end in an period, unless it's a very short comment.
* Yes, "Total votes" can be changed to "Total voters", which might be more intuitive.

Also, regarding #17: yes, theoretically the vote offset could change when the choices are deleted and then reinserted, which would alter the results if votes were already in. Eventually I would like to implement permanent IDs for each choice so that you can re-order choices and the votes won't change due to different offsets, but this isn't a critical feature.

Thanks for the feedback.

Regarding needing to check a box to write-in a vote, I did this to prevent voters from writing in something like "none" or "N/A" if they are not writing something in. What are your thoughts given this?

Votes can only be merged once there have been some votes. Given that editing a node after there have been votes is currently a bad idea, I suppose it makes sense to put the write-in vote merging capability somewhere other than on the node edit page, at least for now. I'm leaning towards a tab for the node unless someone has another idea.

Okay that is fair reasoning. In that case what about hiding the write-in text field by default and showing it once the checkbox or ranking is selected/changed.

I won't be able to test this patch as I'm away from my developing box. Some code style and UI comments though:

1. Be consistent with the use of write-in/write-ins/writein. This goes for code comments as well as for variables and database tables. If possible, I think "write-in" should be used at most of these places.

2. The write-in options on the edit screen could be moved down (bottom?) in the poll settings fieldset. If there will only be two choices I prefer not having them in a collapsible fieldset, especially as the second option can be hidden initially.

3. Would only a checkbox and textfield (no label) be intuitive enough on the vote page? E.g.:
[ ] Choice a
[ ] Choice b
[x] [________________]

I'm also thinking the checkbox can be checked automatically when the user enters something in the textfield. But all those jQuery enhancements can wait.

Changes in this patch:
- fixed [advpoll.install] issues from #24
- fixed [General] issues from #24
- brought write-in node settings out of their fieldset
- the "display write-ins" node setting is shown/hidden by jQuery when the "allow write-ins" node setting is checked/unchecked
- added missing t() to description of $form['settings']['algorithm']
- added missing $Id$ to top of advpoll.module (not sure why it disappeared)

To do:
- ability to toggle whether a choice is seen as a write-in or not on the node edit page
- merging votes - to be in a tab for the node
- remove write-in vote choice from advpoll_choices if, the last vote for that choice is cancelled
- hide write-in text field by default and show it once the checkbox or ranking is selected/changed

Known issues:
- write-in related form elements don't show up in node add/edit preview - I have no idea why
- submitting the node-edit form for a poll resets any write-in choices as ballot choices

Misc:

I haven't been able to figure out how to position the write-in text field to the right of the checkbox/radio/select input field for write-ins. I'm sure you'll have better luck.

I tried to implement hiding the write-in text field by default and showing it once the checkbox or ranking is selected/changed, but ran into trouble when it came to radio fields in binary polls with maxchoices==1 so I removed what little I had done on this.

RE item 1 in #28, I have been using "write-in" and "write-ins" in all comments and output to the user and "writein" and "writeins" in all actual code and in the database. My reasoning is that "write-in" is nicer to look at than "writein", but I don't want to cause any problems by introducing punctuation into variables and table names. There are no database tables in core that contain a hyphen. I have been using the singular and plural versions of "write-in" and "writein", but for different uses. For example, advpoll.writeins is named such because a given poll may or may not support write-ins while advpoll_choices.writein is named such because a given choice may or may not be a "write-in". I find this less confusing and it reduces the chance of referring to the writein column in the wrong table. Thoughts?

RE item 2, I like having the write-ins checkbox at the top of the settings fieldset because it is closer to the choices it directly relates to. I am not attached to this though. I agree with your comments on the fieldset.

RE item 3, I think it is probably intuitive enough, though it is more foolproof if the user has to specifically check a box for a write-in to be processed as a vote (and not return an error).

I will have Internet access and may voice my opinions on this issue, but I am changing continents tomorrow and will not be able to continue development of this patch until mid-late August. I hope you'll continue on it in my absence. If you don't get to merging votes, I'll implement that in late August. Thanks for all the support!

J.D.

Synced with the recent changes. Still needs all the work described in #29.

Fixed a few syncing issues and did an initial implementation of showing/hiding the write-in textbox, based on if the write-in choice has been selected. It did turn out to be a little tough to get it working for radios+checkboxes+selects.

Just skimmed through the JS. Can we have a better ID than "#writein_choice", eg "#writein-choice"?

Roger that.

Update:
* Synced with CVS.
* Took out the optional coding style changes. These should be fixed but in a separate patch.
* I removed the functionality to let you submit an extra choice if writeins are enabled. I realized that it would mess up the voting algorithms by rewarding people for submitting a writein and then ranking their least-favorite candidate even lower. I lost the link but San Francisco's IRV+write-in rules also keep the max number of choices constant.
* Added a per-mode cancel vote hook to allow for special functionality, especially for write-ins.

Making progress... I think everything is implemented except for the actual merging process. I should be able to finish that tomorrow.

Outside of the writein-specific changes, I made it not renumber the vote_offsets when removing a choice. This was necessary so that the results didn't get messed up if a choice was added after a write-in had been added, and then the write-in was removed because the last vote for it was canceled. Plus it's handy to actually let people add/remove choices during the voting process, and this change should let us eventually implement drag and drop re-ordering of choices on the node edit page. Just to be safe I added a recommendation not to edit choices after voting has started.

Now with merging support (easier than I thought now that write-ins don't give you an extra choice). Everything seems to be working okay from my end.

Did a code review and corrected a lot of coding style errors. Also fixed some display bugs for ranking votes.

First limited tests. This is for the patch in #36, just ignore the stuff you already fixed in the last patch.

1. Default content type settings doesn't get saved.
2. "Display write-in votes as choices for future voters" on the edit page doesn't get saved.
3. When clicking the write-in choice, the appearing textfield should get focus [0].focus()
4. Minor: "This code is used on the node edit page as well as the content-type ..." should be "This code is used on the node edit page as well as the on content-type ..."
5. //$("#writein-choice")[$(this).val() > 0 ? "show" : "hide"](); should be removed.
6. Is there are reason why you use px instead of em for html.js input#writein-choice ?
7. The two "display: none" could be merged.
8. "on" should be "one" in // Now add on extra choices if we need to
9. Minor: $default should be $defaults at line 347 (nice code!)
10. Some spacing around line 368
11. Should exit; be exit(); ?
12. t('Write-ins promoted') - should be singular and plural form.
13. I'm not found of the user of $temp, but maybe it's the best way.
14. isset($node->choice[$choice])?<code> and <code>($first_one? '' : ', ') - space before the "?"
15. Personally I prefer if long code lines is not breaked, I think it's easier to read.
16. t('Write-in merged.') - plural?
17. Voting with a empty write-in checked doesn't give an error (but the vote doesn't seem to be recorded).

Thanks for the thorough review - this should fix the remaining problems (except #8 and #16, which don't need to be changed).

Missing punctation for "Write-in promoted".

If I create a write-in and then I cancel the vote, the write-in is removed if no one else has voted on it, is that intentional?
But, if I create a write-in, edit the poll, and *then* cancel the write-in, the write-in is not removed.

Is it ok for one user to submit several write-ins by cancelling his/her vote (this is possible with the example above and if another user has voted on the write-in)?

It might look better if the textfield is inserted before "(write-in)": [x] ______________ (write-in)

One more thing. On the result page it's displayed if a choice is a write-in, but not on the form. Intentional?

This check doesn't seem to work (tested with JavaScript turned off):
// The write-in option is not selected, but there is something in the write-in textbox.

What I also noticed with JS off is the label and that the texfield is below the checkbox on the vote form. Why not remove the label and add the "container inline" class to style it inline. Could save some code?

Fixed the punctuation, the write-in flag not being saved when editing the poll, the write-in validation, and the "(write-in)" being displayed on the vote form.

Yes, it's intentional that a write-in choice is removed if no one else voted on it. This prevents a user from canceling their vote and adding infinite write-choices. But if someone else has voted for it, it shouldn't be removed.

I tried putting the text box to the left of the (write-in) label in an earlier version, but it won't work because it's inside of the so clicking it will de-activate & hide the write-in box.

The non-JS version of the input box can't be moved next to the write-in option because of the way the options code works (there might be another way to do it though). I think it looks okay the way it is.

Converted the write-in show/hide javascript to use a class rather than an id, so that it works for multiple polls on a page (e.g. the front page).

Fair enough.

var poll = $(this); could be var poll = this;

Sidenote: I think a good practice is to write $variablename (instead of just variablename) when the variable is an jQuery object (I just started with this).

One last thing, then this should be ready to go: The write-in textfield should be emptied when the choice is unchecked.

Fixed $(this) and clearing the write-in value when unchecked (good call). I also fixed a focus bug for ranking polls, and a bug where the write-in field was being inserted at the first clicked choice for binary polls.

Oh in #43 I meant to say ...it won't work because it's inside of the label so clicking it will de-activate... - just noticed that I forgot to escape the html on that.

I know :). I guess you could take out the text inside the label and just put it after the text field. Seems like too much code, and it looks ok now.

The textfield is not shown for rankings (select) in Safari 3 (win). I did a quick test and it seems that the click event is not fired. Tried to attach it to the option instead but no difference.

Safari is pure evil. I added the change() event in addition to click(), and it works in Safari now.

Did you see any problems with just using change() (remove click() altogether). Personally I actually think "change" makes sense in a select context, but it should be commented why we use it instead of click().

Good point - change() it is.

Let's get this in. :)

Woo finally :) http://drupal.org/cvs?commit=80033

Now that that's in, time to do a thorough coding style cleanup of the everything else.

Just what I thought! I just skimmed through and just looked at the order of functions, what a mess...

Really nice work on this patch. I guess you have the same feeling as I, clean up and then do a beta release?

And you bet it feels good when you talk about code style ;D

Yep, exactly what I was thinking. I think we can probably do a full 1.0 release in 2-3 weeks too.

Oh yeah,

I run a user group and I wanted to have a poll on what to server at the meeting, pizza, sandwiches etc. It would be great to allow the users in the group add their favorite thing to the list to be voted on.

I can't seem to find this functionality anywhere, hopefully now that 2 people are asking for it, it might.......
PLease.....Pretty please......For the hungry users....

Antonio
:)

Oh yeah,

I run a user group and I wanted to have a poll on what to serve at the meeting, pizza, sandwiches etc. It would be great to allow the users in the group add their favorite thing to the list to be voted on.

I can't seem to find this functionality anywhere, hopefully now that 2 people are asking for it, it might.......
PLease.....Pretty please......For the hungry users....

Antonio
:)