Demo Architecture

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Sun Aug 10 2003 - 21:50:45 CDT

This especially for Anand, Matt & Van. Let me know if this makes sense,
and also whether you agree with the parts I propose for technological
decisions (1 & 2 are fixed requirements, the rest are my
recommendations).

I spoke with Alan, and I think it is worth clarifying a bit for Matt,
Anand, Van, and any other developers, exactly what should be included in
the demo. I do not think this matter is sufficiently documented in any
one place. Alan's post at:

    http://gnosis.python-hosting.com/voting-project/initial-digests/0081.html

kinda hints at the matter; and there are probably all sorts of other
documents scattered around from his several years of investigation of
the matter, and from consultation with experts like Doug Jones.

Of course, I also incorporate my own notion of the proper development
and technological approaches to move things forward.

(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).

Yours, David...

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <mertz@gnosis.cx> ]--------------------------
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Sun Aug 31 23:17:06 2003

This archive was generated by hypermail 2.1.8 : Sun Aug 31 2003 - 23:17:17 CDT