OVERALL:
The system should become sufficiently secure, sophisticated, flexible, and robust, that it could theoretically handle a major student election, such as one for the general students' association. (The odds of actually hosting such an election are quite small, due to fear and uncertainty surrounding online voting, but it is nonetheless a good benchmark to shoot for.)
SHORT-TERM GOAL:
By the time the 2010 general elections for the students' association arrive, CURED should be ready to setup an unofficial parallel election, with all the same candidates and positions (complete with campaign information and pictures taken from their elections website). People could then be encouraged to go online and cast a ballot using CURED after they've cast a ballot in the real election. Not only could this prove (or disprove) that online voting through CURED is a viable option, but it could also show what proportion of students would be willing to cast a ballot online.
TASKS:
- Look into obtaining a proper security certificate, on the basis that we are processing student login information and we want to eliminate any risk. (It is currently understood that the certificate is in place, but there are still issues as CURED is not directly on EngSoc's servers.) Also, verify that our method of login validation is, in fact, secure :)
- Seek our more program codes for the VP Internal to add to the system. The University was not originally willing to release this information to EngSoc when the current Banner system was introduced, so this may need to be done by having friends in other programs submit their login information through EngSoc's program code web tool.
- Make a DQ's option: Allow the CEO to mark a candidate as DQ'd. This would prevent a candidate's results from being listed on the results website (have them listed as DQ'd and their votes added to the spoiled count), but would not actually delete their results from the system (so that if they successfully appeal their DQ their results can then be displayed). DQ's prior to the ballot would have to be discussed... if they're DQ'd before the vote, and as such are not displayed on the ballot, and then un-DQ'd, they would either be on the ballot for only some of the time (unfair), or would show up on the results page with a 0 vote count (unrepresentative and confusing), depending on when the DQ was reversed.
- Change the setting of how the eligibility of positions are set. Find a way to let CEO's set the eligibility on the same page as they create a new position with, instead of forcing them to edit the position they just created in order to do it. The current method is in place because there needs to be a position ID number that the eligibility requirements can be applied to, and that number is not available until the position is created. The solution might be to have the EJB respond to the create position request with the position ID, and have some other way (all negative numbers?) to identify that an error has occurred.
- Change the web interface - in part to update it and improve it (as things like the navigation menu are static in each JSP file), but also to remove graphical elements that were based on the university's branding guide.
- Change the display of results:
- Spoiled ballots should really be part of the percentage of votes, possibly having its own bar on the results graphs.
- The number of valid votes (including spoiled votes) should be tracked for each position. This would allow us to show what percentage of actual voters voted for a candidate in a multiple seat election, instead of the current method of calculating their percentage against the sum of all individual votes for all candidates. So, if 200 ballots were cast in a 2-seat election, and candidates A, B, and C have 180, 60 and 140 votes respectively, the system would correctly show 90%, 30% and 70% (instead of 47%, 16% and 37%). This would also require a change to how the EJB sends percentages to the JSP page.
- Allow the CEO to change the order of positions or candidates. Currently, the order of entry into the system is the order displayed, so if the CEO forgets to add something it can only be tacked on at the end (unless you delete everything and start over).
- Allow for multiple CEOs. Currently there are multiple VP Internal accounts possible (to facilitate transition from one exec to the next), but only one CEO is allowed per election
- Add eligibility options to allow an entire degree (eg. anyone whose program code starts with BENG), any undergraduate student (if their program code starts with a B?), anyone who is a student (if their program code isn't blank), etc etc. Also (or alternatively), consider creating automatic groupings, where a single check will automatically assign a preset group of program codes to a position's eligibility. Currently, if all of engineering (for example) is eligible to vote for a position, program codes for each individual stream and option must all be checked, and it is possible that new programs might not be in the database yet.
- Some characters break the system when input into text fields... I don't know how we missed this, but this obviously shouldn't happen.
- Currently, a CEO could close the polls early, peek at the partial results (as they are automatically released once polls close), and then re-open the polls before anyone notices what happened. That's not good. The ability to extend polling hours is important, however, so we need to look at other ways of addressing this problem:
- Results should be withheld until the CEO approves their release. (Individually approving the release of each race's results might also be an option to consider, if it is appropriate to release some results but not others.) However, further discussion is required as to how much information the CEO should be shown in order to make that decision...
- Running totals should also be available to the CEO, to satisfy their curiosity of how the election is going. The CEO should be able to see the total number of people who have cast ballots in the election, as well as the number of voters for each race.
- A changelog has also been suggested as a possible option, so that any changes to polling times would be made public. However, further discussion would be required to determine the best implementation of this.
- Provide the CEO with a URL that links directly to their election's front page. This would allow non-web-savvy CEOs to simply copy and paste the link into emails promoting the election, as well as do things like setting it as the homepage on sanctioned computers.
- Add more configuration options to the VP Internal section of the web interface - like the database name and password. Essentially, things that might need to change but are currently hard-coded.
- Look at overhauling the CEO's interface: Right now, raw HTML tags can be inserted into the fields (elections information, candidate profile, etc). While this means that HTML-savvy CEOs can format the information however they like, it also means that CEOs that don't know HTML can't do simple things like line breaks. Is there a better way that we can do this?
AND FINALLY:
At some point, seek the assistance of other campus groups; the IEEE Computer Society, and the Computer Science Society could be approached and asked to try to break or hack the system. This will help identify as many bugs and loopholes as possible.
[ Return home ]
+