How about this, have BS show 3 pieces of data in the
Create Cards module, all Base Precincts matched with Ballot Style matched with
a Number to program into the Encoder. The number would be the same for BPs in
one Report Precinct that share a ballot style, but different for BPs in
separate Report Precincts sharing a ballot style – like sequencing OS ballots.
This set of data could also be a report in GEMS (or printable on the TS printer
if changing GEMS is not viable) This printout could be used as a cross-reference
to eliminate some of the ambiguities that creep in due to the variations in
circumstances that are explored in my lengthy free-association
J session
below. I expect this would involve substantial programming changes of BS, but maybe
it is worth considering. If not, toss it out without further review.
In training, I considered programming only one of the Base Precincts
listed in BS Create Cards, but my concern was that in some instances, some of
the BPs would be needed and some would not. As Ken said, selecting which to
omit and which to program is tricky. Another problem is when only some of the BPs were not needed and
left off (either by deletion in the database or by BS or by the person
programming the Encoders) but more than one
are still needed, with which of
the remaining BPs would the omitted ones be grouped? This ambiguity can
possibly be solved by the option in paragraph 1.
In class we went with the option of deleting in the election database
those BPs that are not needed. This worked well with only one ballot style per
report precinct, but the user must be careful to only delete unneeded BPs. And,
it is not an obvious thing to do – it requires training to let people know they
need to do it. If BS can easily determine which BPs to leave off the list in
the Create Cards module, then this may be an option (note that for multiple report precincts, same style
ballots do not mean unneeded
variations). Same concern arises about the ambiguity of which encoder key to
map the omitted BPs.
From what I understand, consideration is being given to attaching a
“code sheet” to the Encoders (likely this is already done in some form) that
shows the pollworker which number to use to create a card for the various ballot
styles or BPs that require differentiation. If such a code sheet is used, then
pollworkers would know which encoder number to create a card from based upon
the code sheet entry. Also, the voter registration systems I have seen do not
always specify a base precinct or split in the precinct register, they
sometimes specify a ballot style next to the voter’s name. The code sheet could
be tailored to handle whatever info was in the precinct register and be used as
the translator between the Voter’s data and the Encoder number, regardless of
data types. Of course the Code Sheet would likely need to be constructed and
tailored outside of GEMS. (Unless
the option explored in paragraph 1 is used.)
The various options above begin to sound more complicated than just
programming all of the base precincts into the encoder. But in my class, one
county has 13 bases in one report precinct, with only one ballot style. If I
understand that one Encoder can only hold 8 positions, then 2 encoders would be
needed to handle all of the complexity when really only one ballot style is involved.
Like Ken said, no easy answers.
Mark
Earley
850 422-2100 - office/fax
850 322-3226 - cell
-----Original
Message-----
From: owner-support@gesn.com
[mailto:owner-support@gesn.com]On Behalf Of Ken
Clark
Sent: Thursday, June 13, 2002
11:11 PM
To: support@gesn.com
Subject: RE: Programming Encoder
w/ 1 ballot style, multiple base pcts
This is a good
question. Standard operating
procedure is to either ignore the extra base precincts, or delete them from the
database if they are too hard to ignore.
You can just program the
base precincts that matter onto the Card Encoder: If you think about it, what is to stop you. That can be tricky though, since the BS
Create Card dialog doesn’t tell you which base precincts are with which
ballots. If you want them gone, I
suggest deleting them from the database.
I would really like to
have this improved structurally, since it comes up a lot, but I have never been
entirely happy with any of the potential solutions I have come up with. We could pick the first base precinct for each ballot in the
report precinct, and display only that base precinct only in the list. Ballot Station knows that it is the same ballot for
multiple base precincts after all.
But is that base precinct label really what the poll-worker wants to
see? Poll workers are working from
a voter registration list, and those lists are by some kind of base precinct
(by any other name). If we just
show the first base precinct, will they always be able to figure out what
selection they should be making, or will it mean that base precincts that are
in their poll book are missing?
The other suggestion that
has been thrown around is to have a checkbox in GEMS to mark a base precinct as
“inactive”. All fine and dandy,
but clicking on the checkbox is exactly as easy as deleting it, so the idea is
not very inspiring.
As always, ideas on “how
it should work” are encouraged.
Ken
-----Original
Message-----
From: owner-support@gesn.com
[mailto:owner-support@gesn.com] On Behalf Of Mark
S Earley
Sent: Thursday, June 13, 2002 5:32
PM
To: Support
Subject: Programming Encoder w/ 1
ballot style, multiple base pcts
When using a database that has multiple Base
Precincts associated with a Report Pct, create voter card window in BS shows
all of the bases even though they all have the same ballot style. Is this
expected behavior? Does one need to program all of these base precincts into
the Encoders for use at the polls or should they delete any unnecessary Bases
from a Master Database when being used on a less complex election?
Mark
Earley
850 422-2100 -
office/fax
850 322-3226 - cell
