Some testing has been done with the new release, and the
holding of the ballot without returning it until the scroll is finished is a BIG
problem. With a short race title, it will hold the ballot for about 8
seconds; for a long race title, about 15 seconds. In the strongest way
possible, I object to this.
I'm not enamored with the scroll. It's hard enough to
get pollworkers to be able to read static displays on the LCD, let alone a
scrolling one. A static display showing the beginning text of the race
title should be sufficient. The voter will be gone by the time the ballot
is returned, and anything which creates the need for additional pollworker
training should be nothing less than desperately needed.
As far as it being an optional feature, or setting up some
kind of asynchronous code solution so that the ballot is returned before or
during the scroll, these seem like complicated solutions to what ought to be a
simple function. If it's optional, then a new flag has to be put into GEMS
to program for it. The possibility that, "...making the display code
asynchronous...would break other things." (Guy) should give pause as
well.
Sorry to jump in so vehemently, folks. I don't know that
this request is all that popular. I welcome other
opinions.
|