The latest ballots

[stratofax]

Here's a place to put ballot PDFs as they roll off the production line. Comments welcome!

[stratofax]

t's Friday, that means it's time for a new generated ballot. Today's single-precinct ballot includes:

• Correct voting instructions for both plurality and "n of m" candidate contests
• Party abbreviations, below candidate names, where available
• Ballot measures in a single column layout
• Minor layout and spacing improvements

The enclosed ballot was generated with the command:

ballotmaker demo

I'm pleased to say that all automated tests (pytest and linting on Python 3.8, 3.9 and 3.10 on Mac, Windows, and Linux) pass -- that's 9 total automated tests, all green

PDF, 168KB:
ballot_demo_2022_08_26T115245.pdf
.

[stratofax]

@ion-oset @cwulfman I thought a discussion would be a good place to at least track updated ballot releases.

[stratofax]

@trustthevote some minor layout changes and the ballot now fits easily on two pages.
ballot_demo_2022_08_29T161428.pdf

[stratofax]

More improvements to the layout, including

• a smaller header
• tighter spacing for instructions
• wider columns for candidates
• tighter spacing between candidates and ballot measure replies

All of these modifications will help to reduce total page count.

ballot_demo_2022_08_30T201359.pdf

[stratofax]

I'm posting a day early this week, because I'll be out of the office all day tomorrow. I believe this ballot sample addresses all five of the issues still open on 1. Generate flat PDFs from Jetsons EDF Milestone:

• Update candidate order
• Implement multi-candidate tickets
• Track write in candidates
• Add write in slots to candidate contests
• Generate flat file PDFs from an EDF (this is the parent issue for all the other issues in this milestone)

Feedback appreciated!

ballot_demo_2022_09_01T161159.pdf

[stratofax]

Ballot with clickable check boxes placed correctly in the candidate contest tables.

As soon as I get the Sept data hooked in, I’ll add the actual candidate IDs; right now I’m using the Candidate Name. As a result, you can check or uncheck a Write In and they’ll all toggle because they share the same name.

I set the checkmark to “checked” because you can’t see the location of the unchecked checkboxes in many PDF readers (like, say, Mac Preview).
ballot_demo_2022_09_12T140128.pdf

[trustthevote]

Great to see the embedding here.

But you do know it is not a checkbox to be embedded? And it is not for interactive use, at least not this iteration

Not a checkbox but an oval, behind which is the item named with the ballot-selection-id. Cliff has worked example of output.

FYI, the apps job is to find the named item of a ballot-selection-id of a selection that the user made; and then replace it with a graphic of the filled oval

[stratofax]

@trustthevote I reviewed @cwulfman code again to confirm that he also used a checkbox object embedded in the PDF form. The checkbox will be labelled internally with the ballot-selection-id (as you noted, embedded in the PDF) and the specific coordinates are available for another program to read (like, say Markit). So I think we're talking about the same thing?

The white oval still needs to be drawn over the checkbox; I'll do that in the final version. I didn't do that (and I checked the check boxes) so I could confirm the alignment of the form object is correct, not to offer interactive features. This is more of a "behind-the-scenes" version of the ballot that tests alignment.

I'm also inferring from your response that we don't need text entry fields for write in candidates.

[stratofax]

I found a version of @cwulfman's PDF output that uses radio (round) buttons. Unfortunately, it doesn't look like these round buttons can be transformed into ovals. I'll do some further tests but I think I'm going to have to cover the form objects with an oval drawing, as described above.

[stratofax]

@trustthevote @ion-oset @cwulfman Here's four (4) ballots generated directly from the September test data JSON file, including the invisible widgets, intended to fulfill the Phase 2 requirements. Please review.

precinct_1_downtown_2022_09_16T204516.pdf
precinct_2_spacetown_2022_09_16T204516.pdf
precinct_3_spaceport_2022_09_16T204516.pdf
precinct_4_bedrock_2022_09_16T204516.pdf

[stratofax]

To clarify: this set of ballots, with the widgets hidden, is intended for acceptance testing and review.

[stratofax]

Here's the same set of ballots, but with the form widgets made visible.

precinct_1_downtown_2022_09_16T204852.pdf
precinct_2_spacetown_2022_09_16T204852.pdf
precinct_3_spaceport_2022_09_16T204852.pdf
precinct_4_bedrock_2022_09_16T204852.pdf

[trustthevote]

Lots of progress!b Maybe not done though I need @cwulfman to examine the internals of these 4 widgetized documents to make sure that they are widgetized in the same way as the placeholders that Cliff made for the app to use. If they are not widgetized the same way, then likely they won't work with the app.

I suspect that they are not widgetized the same way, because they look different in both adobe and preview than the placeholders:

1. The write-in blocks have a background color, instead of being background white, which is probably a no-no somewhere

2. The widgets are larger than the ovals, and on top. The ovals are obscured, and some weird non oval thing (the widget) is showing. This means that the blank ballot layout review by EOs will fail.

In phase one, we had some very basic ballots that proved methods for having a widgetized blank ballot with just an oval showing, and I believe that Cliff used the same techniques in his placeholders. This is important, because the app only deals with the widgets for a voter's selections, getting the location of the oval, deleting the widget, overlaying with a filled oval. For the non-selections, the widgets will still be there, hence must be obscured by the white oval.

In the previous version I saw checkbox widgets that were invisible when unchecked, and they would be fine if the white oval was on top.

I think that Cliff is going to need to look at the widgetization code, compare to his version, and maybe to the phase 1 versions, which Anne has somewhere.

[stratofax]

@trustthevote I just want to double check to ensure that you reviewed the version of the ballots where the widgets were not displayed. Please check the files on this comment, above: #91 (comment)

[stratofax]

As noted, the ballots that display the widgets are for technical review; the other set, with widgets hidden, are for acceptance testing

[ion-oset]

The widgets for technical review PDF was helpful for me in understanding how this works 👍🏼

[cwulfman]

I've done a quick review, and it looks good to me. The ids on the checkbox fields appear to correspond with the ids in the EDF, and the write-in text field obeys the convention. I think Matt Beattie needs to test them against his code now.

[stratofax]

In addition to being essential to line up the widgets on each page of the ballot, the "widgets visible" option also demonstrated that hiding or showing the widgets doesn't affect the position of any other elements on the page -- at least in any way I've been able to detect.

I also owe Matt B. and the Markit team a filled-in, black oval that he can place on the page. I'll work up a PNG file for him and post a copy here.