Preliminary Architecture document

This is very initial (please help). I created an Architecture link at:

    http://evm2003.sourceforge.net

That is, it goes to:

    http://evm2003.sourceforge.net/architecture.html

I created this document by slightly modifying a previous mailing list
note I wrote to convert it to APT format; then I used aptconvert to
create the HTML. The APT format document is below (just to show folks
what it looks like; I reckon I'll check it in to sourceforge at some
point to)--as noted earlier, APT is easier to modify than most formats,
and can be converted to HTML, LaTeX, DocBook, etc., as needed.

Yours, David...

------------------------------------------------------------------------

  ------------------------------------------------------------
             Electronic Voting Project Architecture
  ------------------------------------------------------------
                         David Mertz
  ------------------------------------------------------------
                  Thursday, September 11, 2003

{{{http://evm2003.sourceforge.net}EVM 2003 Homepage}}

The Standard Ballot System

 [[1]] The ballot sample at:

       {{http://home.earthlink.net/~adechert/ballot-mockup3.gif}}

       should be taken fairly seriously in the sense that we want to
       look *exactly* like that for the demo. I have some reservations
       on the checkbox/radiobutton/deselect design, but not to rule out
       this design as an initial target.

 [[2]] The resolution of the touchscreen hardware WILL BE exactly
       1280x1024. Developers hopefully have monitors that can display
       that resolution for testing.

 [[3]] I believe wxPython is a reasonable choice (I've installed it
       successfully on my PowerBook/OSX, so I can test code now), but
       want to make sure that you can eliminate all frame elements
       within a wxPython application (and maximize the window interior).
       Also, we need to be able to customize the appearance of radio
       buttons to look like the sample.

 [[4]] I believe that we should separate the ballot data into three
       components each with an appropriate XML format:

       * ballot-style.xml

       * ballot-placements.xml

       * ballot-election.xml

       []

    [[a]] The first file defines a set of visual appearances for
          elements such as fonts, line styles, colors, etc. For the
          demo, we will define EXACTLY ONE ballot style, e.g.:

+------------------------------------------------------------------------
<ballot-style>
  <bg-color>lavender</bg-color>
  <per-candidate-sep>thin line</per-candidate-sep>
  <party-font size="11" face="helvetica" style="bold"/>
  <candidate-font size="12" face="helvetica" style="roman"/>
  <office-font size="9" face="helvetica" style="roman"/>
  ...
</ballot-style>
+------------------------------------------------------------------------

          Those look like what the sample has, but I'm guessing...
          you'll have to match up the exact details. But we will not
          attempt to create any alternate ballot style file for the
          demo. Defining and using such named values assures
          consistency across ballot elements.

    [[b]] The ballot placement will indicate where on the page each race
          appears. The rules about where columns may break and the like
          is complicated, and depends on jurisdiction (e.g. when can a
          candidate list go to next column). However, for our purposes,
          we should be able to manually set the positions to match our
          known-OK sample. Perhaps post-demo, we can automatically
          generate ballot-placement.xml based on ballot-election.xml and
          a set of election rules. The data file might look like:

+------------------------------------------------------------------------
<ballot-placement> <!-- measured from top/left -->
  <summary x="165" y="20"/> <!-- General election ... -->
  <usage x="80" y="65"/> <!-- To vote ... -->
  <instructions x="60" y="88"/>
  <slot x="60" y="430"/> <!-- president race -->
  <slot x=... y=.../> <!-- congressional -->
  ...
</ballot-placement>
+------------------------------------------------------------------------

          Again, we're only looking to determine one set of values for
          the demo, but in principle, this is how a different ballot
          layout could be defined. We can demonstrate this
          configuration technique to election officials or to others.

    [[c]] The actual election information. My prior suggested code
          snippet referred to slots where the various elections/races
          will go. Those absolute page positions would be taken from
          the ballot-placement.xml file; but it will be easier in
          programming it to simply refer to "slot 1", "slot 2", and so
          on.

          The actual election information can be an improved version of
          the XML I demonstrated in:

          {{http://gnosis.python-hosting.com/voting-project/August.2003/0063.html}}

          Again, we can show an election official how this file is
          utilized for ballot configuration.

 [[5]] I think we should approach validation of these XML data files in
       the manner I suggested earlier. I.e. during development, we can
       manually validate sample files as samples and DTDs are modified.
       By the time the demo goes out, gnosis.xml.objectify will grow a
       new switch to add validation (a one line change to the code).

 [[6]] We will presumably need an additional ballot-election-lang.xml
       file for each additional language provided. For the large type
       option, we will need to define a new set of all the data files.

 [[7]] Despite what Alan proposed in the referenced post, I believe that
       non-selected items SHOULD NOT be modified at all after a voter
       selection is made in a race. That is bad interface design.
       Rather, only the SELECTED item(s) (one or several, depending on
       the type of contest) should be highlighted. However, I agree
       that this highlight should be prominent, probably combining a
       larger font, surrounding box, and a color change.

 [[8]] In fact, contrary to Alan's referenced post, any web version of a
       voting system CANNOT be identical to the polling place version.
      Not all users will have a screen that displays exactly 1280x1024.
      Moreover, it is awfully hard to assure users do not override
      colors, fonts, etc. in some manner (the issues depend on the
      delivery strategy, i.e. DHTML vs. Flash vs PDF forms). But in
      all cases, users have some control of the presentation. Most
      likely, very little other than the XML data formats can be shared
      between a local and web based version (i.e. not much source code).

 []

========================================================================
The Blind-Accessible Ballot System

  What goes here?

========================================================================
The Ballot Printing System

* The barcode system/font

  What goes here?

* The encoding of cast votes

  What goes here?

* The human-readable ballot

  What goes here?

========================================================================
The Barcode Vocalization System

  What goes here?

==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Tue Sep 30 23:17:03 2003