Roadmap to 1.3.0
Waldemar Bautista
- PostgreSQL support
- installer enhancement
Please add more TODOs if necessary. I'll add this in Issues so please
add your TODOs there too.
--
Waldemar Amado Bautista
Darwin Bautista
<waldemar...@gmail.com> wrote:
>
> Here are the TODOs before we can release 1.3.0:
> - PostgreSQL support
> - installer enhancement
>
> Please add more TODOs if necessary. I'll add this in Issues so please
> add your TODOs there too.
Terminologies (string modifications):
- Vote (button) -> Verify Ballot
- Confirm (button) -> Cast Ballot
- Confirm Vote (title) -> Verify Ballot
- Result -> Results
Revamp/improve results page
- add some statistics (percentage of votes per candidate, maybe add a
nice horizontal bar graph too)
- remove unnecessary details (candidate photo, etc.)
Candidates Management
- add option to group candidates by party
'Fading' flash messages (a la WordPress) - not really fading, but the
color changes from some initial color, say yellow, to a final color
(green - info message; red - error message).
None of them are 'officially' TODOs (i.e., some are just suggestions, ideas).
I need the opinion of the other devs.
--
~dmb
Waldemar Bautista
> Terminologies (string modifications):
> - Vote (button) -> Verify Ballot
> - Confirm (button) -> Cast Ballot
Is this correct? I think they should be swapped.
> Revamp/improve results page
> - add some statistics (percentage of votes per candidate, maybe add a
> nice horizontal bar graph too)
I forgot to mention this but this is included in the old version. The
only question is what statistics should we include?
> - remove unnecessary details (candidate photo, etc.)
I think this is ok since the details are hidden by default and is optional.
> Candidates Management
> - add option to group candidates by party
How about we list the candidates in the party view and link the party
name in the candidates to that view? And speaking of views, we can
add a view to all since when you click the name, it goes to the edit
page.
--
Waldemar Amado Bautista
Darwin Bautista
<waldemar...@gmail.com> wrote:
>
> On Fri, Feb 22, 2008 at 12:10 PM, Darwin Bautista <djcl...@gmail.com> wrote:
> > Terminologies (string modifications):
> > - Vote (button) -> Verify Ballot
> > - Confirm (button) -> Cast Ballot
>
> Is this correct? I think they should be swapped.
Yes because the Vote button gives an implication that it does cast the
ballot (immediately) when in fact it does not. It only directs the
voter to the 2nd phase which is the verification of the ballot. On the
other hand, the Confirm button should be 'renamed' to 'Cast Ballot'
for consistency and clarity. Also, the 'GO BACK' link should be
replaced by a 'Modify Ballot' or 'Modify Votes' button.
>
> > Revamp/improve results page
> > - add some statistics (percentage of votes per candidate, maybe add a
> > nice horizontal bar graph too)
>
> I forgot to mention this but this is included in the old version. The
> only question is what statistics should we include?
For now, I think the inclusion of the vote percentage per candidate
would do. We should also put another 'box' at the top to include the
total number of voters, the number of voters who actually voted, the
number who didn't, and the respective percentages.
>
> > - remove unnecessary details (candidate photo, etc.)
>
> I think this is ok since the details are hidden by default and is optional.
>
>
> > Candidates Management
> > - add option to group candidates by party
>
> How about we list the candidates in the party view and link the party
> name in the candidates to that view? And speaking of views, we can
> add a view to all since when you click the name, it goes to the edit
> page.
Good idea. (although I didn't quite get what the second sentence meant. :D)
--
~dmb
Waldemar Bautista
> Yes because the Vote button gives an implication that it does cast the
> ballot (immediately) when in fact it does not. It only directs the
> voter to the 2nd phase which is the verification of the ballot.
No. It does cast the ballot. We only chose to save it in session
rather than the database so that changing of votes, if the voter needs
to, will not include database queries. We can save it immediately to
the database but what will the system gain from it?
The button should tell the voter what action he/she will do. If it
states 'Verify Ballot', that will be confusing since he/she has not
yet cast a ballot so what will he/she verify? It is logical that
something must be done first before it can be verified. In our case,
the voter should vote first before confirming his/her votes.
Therefore, in your proposal, a voter must cast a ballot first before
verifying that ballot.
> > How about we list the candidates in the party view and link the party
> > name in the candidates to that view? And speaking of views, we can
> > add a view to all since when you click the name, it goes to the edit
> > page.
>
> Good idea. (although I didn't quite get what the second sentence meant. :D)
What I'm saying is let's include a view candidate, view party, view
position, and view voter. In our current system, when you click a
name, it goes to the edit page. We can change that to go to the view
page since we have an edit link in the action column. If we implement
this, we can include the party's candidates in the view party page.
--
Waldemar Amado Bautista
Darwin Bautista
<waldemar...@gmail.com> wrote:
>
> On Fri, Feb 22, 2008 at 2:49 PM, Darwin Bautista <djcl...@gmail.com> wrote:
> > Yes because the Vote button gives an implication that it does cast the
> > ballot (immediately) when in fact it does not. It only directs the
> > voter to the 2nd phase which is the verification of the ballot.
>
> No. It does cast the ballot. We only chose to save it in session
> rather than the database so that changing of votes, if the voter needs
> to, will not include database queries. We can save it immediately to
> the database but what will the system gain from it?
>
> The button should tell the voter what action he/she will do. If it
> states 'Verify Ballot', that will be confusing since he/she has not
> yet cast a ballot so what will he/she verify? It is logical that
> something must be done first before it can be verified. In our case,
> the voter should vote first before confirming his/her votes.
> Therefore, in your proposal, a voter must cast a ballot first before
> verifying that ballot.
Oh, ok. So:
Vote (button) -> Cast Ballot
Confirm (button) -> Confirm Ballot
Confirm Vote (title) -> Verify Ballot
GO BACK (link) -> Modify Ballot (button)
Is this ok?
>
> > > How about we list the candidates in the party view and link the party
> > > name in the candidates to that view? And speaking of views, we can
> > > add a view to all since when you click the name, it goes to the edit
> > > page.
> >
> > Good idea. (although I didn't quite get what the second sentence meant. :D)
>
> What I'm saying is let's include a view candidate, view party, view
> position, and view voter. In our current system, when you click a
> name, it goes to the edit page. We can change that to go to the view
> page since we have an edit link in the action column. If we implement
> this, we can include the party's candidates in the view party page.
Ah, I see.
--
~dmb
Waldemar Bautista
> Vote (button) -> Cast Ballot
> Confirm (button) -> Confirm Ballot
> Confirm Vote (title) -> Verify Ballot
> GO BACK (link) -> Modify Ballot (button)
>
> Is this ok?
This is ok but 'Confirm Ballot' can also be 'Verify Ballot' so that
the button and the title are the same.
--
Waldemar Amado Bautista
Darwin Bautista
By the way, are you ok with the 'fading' ('changing color' to be more
precise) flash messages? It's just a really minor UI enhancement but
it needs one more JS file (jquery.color.js). If you guys think it adds
up to the bloat (although I don't think Halalan is bloated), then we
can just scrap it.
--
~dmb
Waldemar Bautista
> By the way, are you ok with the 'fading' ('changing color' to be more
> precise) flash messages?
I'm ok with this but please retain the color scheme (green for
positive messages and red for negative messages).
--
Waldemar Amado Bautista
Darwin Bautista
By the way, since 'Confirm Vote' will be renamed to 'Verify Ballot',
should I rename voter/confirm_ballot.php -> voter/verify_ballot.php
and halalan_voter_confirm_vote_* -> halalan_voter_verify_ballot_* for
consistency?
--
~dmb
Waldemar Bautista
> By the way, since 'Confirm Vote' will be renamed to 'Verify Ballot',
> should I rename voter/confirm_ballot.php -> voter/verify_ballot.php
> and halalan_voter_confirm_vote_* -> halalan_voter_verify_ballot_* for
> consistency?
I'm not really sold on the idea of changing 'Vote' to 'Cast Ballot',
etc because I find 'Vote' to be simpler and easier to understand than
'Cast Ballot', etc but you can do whatever you want as long as it does
not break the system.
--
Waldemar Amado Bautista
Waldemar Bautista
> - PostgreSQL support
Now in trunk. Finally. Please test carefully. I haven't tested all
possible cases yet.
--
Waldemar Amado Bautista
Darwin Bautista
> - PostgreSQL support
> - installer enhancement
>
> Please add more TODOs if necessary. I'll add this in Issues so please
> add your TODOs there too.
How about we create "Voter Groups" (for the lack of a better term)
which is pretty much what Parties are for Candidates? With this, we
can put all voters from different colleges in a single db and still
come up with nice statistics per college. Of course, there would
always be that implicit "Default" voter group if no voter groups are
created.
--
~dmb
Waldemar Bautista
> How about we create "Voter Groups" (for the lack of a better term)
> which is pretty much what Parties are for Candidates?
Actually, we have this but only implicitly. A voter group in the
current setup is composed of all voters who can vote for the same
specific positions. We can expand this and create a true group
wherein we can add voters and the positions they can vote for
separately.
--
Waldemar Amado Bautista
Waldemar Bautista
I think we can release 1.3.0 after the installer enhancement and other
issues that can . We can move the grouping of voters to 1.4.0.
What do you think?
--
Waldemar Amado Bautista
Darwin Bautista
Will 1.3.0 include Issue 29?
--
~dmb
Darwin Bautista
BTW, since voter login is already restricted to one at a time,
shouldn't we restrict the admin login as well?
--
~dmb
Waldemar Bautista
Yes.
--
Waldemar Amado Bautista
Waldemar Bautista
> BTW, since voter login is already restricted to one at a time,
> shouldn't we restrict the admin login as well?
I'm planning to do this when I start the audit trails for 1.4.0. I'll
also include a profile page for the admin.
--
Waldemar Amado Bautista
Darwin Bautista
This is fine with me.
--
~dmb
Waldemar Bautista
The installer has not received that much enhancement but I think we
should release 1.3.0 in a few days since we need a working one because
the random order issue has left users, who don't know about the fix
(turning random order off), with broken installation.
--
Waldemar Amado Bautista
Waldemar Bautista
as the release date for 1.3.0 to celebrate Independence Day. A PDF
version of the documentation will also be released courtesy of
Bonyang.
--
Waldemar Amado Bautista
Antonio San Miguel
Antonio Mari T. San Miguel
University of the Philippines Linux Users' Group
http://uplug.org
Halalan, an Open Source Voting System
http://halalan.uplug.org
http://code.google.com/p/halalan