Re: Demo Architecture (Call for meeting)

From: Anand Pillai <abpillai_at_nospammail_dot_net>
Date: Mon Aug 11 2003 - 00:43:25 CDT

Thanks a lot David for clarifying some of the initial doubts
I think most of the developers had on the requirements. I myself had
vague ideas on the UI bit of the application and thought that
it was not very important to get it right for the first demo.
But now it looks like we need to get the UI bit right to Alan's
specifications, though the data part may not be very secure
and stringent. It is something like how Microsoft designs their
products, but if that is the way to go, I have no problems
there at all.

I think that the current situation calls for a developer meeting
with David as the chair as soon as we can arrange it. This meeting
would discuss David's proposals and other developers can give their
suggestions also. Alan should also be present as the project
coordinator, so that we can all get information first hand from him.

I request the following developers also to attend the meeting apart
from Matt Shomphe and myself.


A rough draft of the topics of discussion.

1. UI layout and design/ Developer's inputs on
    UI toolkits.
2. XML data format/Developer's inputs on XML APIs
    /Discussion on possible alternatives.
3. Alan's clarification on his requirements so that
    developers can be in sync with his thoughts. I
    dont want to have the initial demo *thrown away*
    because there was a mismatch between requirements
    and the actual delivered code.

I call for this meeting on Tuesday August 12 2003. The
venue can be Yahoo conference on the Y! messenger.
The convenient time for me is 21:00 pm to 01:00 am IST (next day)
(15:30 to 19:30 hrs GMT).

I request other developer's opinions on this suggestion.
Do let me know if the timing is suitable also.



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

  Anand Pillai
-- - Choose from over 50 domains or use your own
= 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