Re: Demo Architecture

From: Anand Pillai <abpillai_at_nospammail_dot_net>
Date: Mon Aug 11 2003 - 09:21:35 CDT

My thoughts/suggestions right below.

On Sun, 10 Aug 2003 22:50:45 -0400, "David Mertz"
<> said:
> 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:
> 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:
> 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.
A: So this much is very clear. We need to design the UI to mimic
         the layout of the given ballot sample. This has to be our first

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

A: My machine has a higher resolution in fact. So I have no problem

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

A: Yes, you can do this very well with wxPython. It supports a method
       called "ShowFullScreen" in its 'wxFrame' object which we shall be
       to layout other GUI elements. The GUI elements will be laid out on
       "wxPanel" which will be added to the basic frame object (an
       of "wxFrame").
       The good part of the wx API is that to unset the full screen mode,
       you just
       pass "FALSE" as the argument to the same method, which resets the
       frame to the state it was, prior to being set to full screen.

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

A: I think it can be safely said that this xml file (ballot-style.xml)
       behave as the "style sheet" for our GUI, making an analogy with
       stylesheets of HTML/XML pages.

       I shall see if I can come up with a basic DTD for this. I am not
       good in XML schemas though. (Anyway nobody really understands XML
       schemas well). I also think that most browsers support XML parsers
       that support DTDs rather than Schemas. This is important since
       Alan had mentioned that a Web UI for the program is a future goal.
> (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>

         We can use this xml for passing the data to the wxPython
         coordinates for each GUI element. I agree with David. It makes
         sense to split the style xml from the layout xml. My initial
         was a unified one, but this is much more sensible, and helps
         the application to scale, in terms of UI capabilities.

> 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:

A: This is what I meant by the "input" xml, the one which contains
data on the
        candidates and other information needed by the program. We can
        the analogy using the MVC paradigm (Model-View-Controller) that
        the first two
        XML formats defines the "View" and this one defines the "Model".

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

A: I have a question here. Does gnosis.xml support validation

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

A: Anyway, a web UI is not needed in the alpha code at least.
        That is my understanding, from discussions with Alan.

       I would like to highlight a new topic. Since I mentioned MVC
       in the beginning (It is a paradigm that ideally fits most UI
       especially the ones which have extensive data structures also,
       like our
       voting program), the "C" (Controller") bit here will be taken by
       on screen electronic keyboard, which Alan rightly suggested.

       It does not take much to define an onscreen keyboard using
       In that case we can have an xml, say "ballot-controller.xml" for
       layout which will define the number of keys, their placements on
       keyboard etc.

       Adding an xml for this bit will probably add too much complexity
       for our
       program, so I suggest to go with a default keyboard layout, i.e a
       one. This can be part of the voting application, but in a separate
       frame, which
       will make communication between the keyboard and the voting
       program easy,
       by posting specific wxWindows (wxPython) events. We really dont
       need any
       kind of encryption here.

       There might be some onscreen keyboard widgets already available in
        written by 3rd party. We can modify it to fit our requirement. I
        think that
       a U.S 105-key QWERTY keyboard (without dead keys) will be all

       If we need to support generic keyboard layouts, we need to think
       in terms of
       a keyboard xml format also.

> 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 <> ]--------------------------



  Anand Pillai
-- - One of many happy users:
= 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:07 2003

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