Re: [OVC-demo-team] GUI status

From: Anand Pillai <anand_pillai_at_fastmail_dot_fm>
Date: Fri Jan 30 2004 - 01:35:32 CST

Though I could not produce a GUI, I have the code with
me (posted to sourceforge also I believe) which parses the
two XML files and creates a basic frame with some elements,
using the gnosis xml parser.

I found out that this approach is a bit error prone, since
we have two objects to keep track of, one for the style
and other for the placements. We need to keep track of
the names of the elements in both the objects (xml) to make
sure that we are adding the style to the same object which
we placed. This will need some kind of nomenclature rules
between the two xml files so that there is no ambiguity
in the naming of elements. And this is what exactly which
makes it error prone.

For the demo it might be fine, but thinking of the larger
picture, I would drop that approach though it feels more
modular than using a single UI xml file. But perhaps a bit
more modular than what we actually want...

The current xml files does not fit this model since the
elements dont have any nomenclature rules and only the
persom who developed the xml will know which style to
apply to an element which he has placed correcly. Instead
of trying to develop these naming rules, I suggested to
go for a single xml, embedding both placement and style
data in it as attributes of the elements, which would mostly
be the gui widgets (or other elements like text, lines,
seperators etc).

The unified xml file which I created *is* an exact replica
of Alan's ballot sample since I actually did the measurements
on screen for each widget and entered that data inside the xml.
In fact it unifies the placement and style xml files rather
neatly, I would say.

My opinion is to use a single "grand" xml file which would
make maintanence of schemas and also coding, easier.


----- Original message -----
From: "David Mertz" <>
Date: Fri, 30 Jan 2004 00:04:59 -0500
Subject: [OVC-demo-team] GUI status

Fred McLain wrote:
> I've not heard from the person doing the UI design on this list over
> the
> last week. It's possible that it's still being worked on. I don't
> want
> to step on any toes here, but if it is being worked on it would be
> great
> to get the requirements committed to the repository.
> David, could you fill us in on the GUI developer situation?

Unfortunately, Anand Pillai who started work on the wxPython version of
the GUI proved unable to finish it (or worse, check in a partial
version). Gene Mosher had also promised to create a version that used
his own GUI library, but that hasn't shown up either.

The requirements, however, have been published for quite a while, and
have not really changed. See:

Eron Lloyd wrote:
> Regarding the UI, I thought that there was someone doing some work on
> that, in
> wxPython I believe. Was it all scrapped? I'd be more than happy to
> develop a
> UI, but I am a committed PyQt developer, as I was never satisfied by
> wxPython.

In all honesty, I have almost no opinion on the merits of wxPython
versus PyQt. Either would be completely acceptable as long as it can
duplicate the appearance of Alan's Ballot sample.

However, I really still want to push the MVC architecture documented in
the Architecture documented at the above URL. The contests should be
stored (in XML) in a separate document from the ballot presentation
configuration (also in XML). Anand recently posted some thoughts on
combining the placement and style documents; I sort of don't have much
opinon there either. I probably think this separation is still better
modularization, but I will happily defer to anyone doing actual
programming work for it. However, the contests should ABSOLUTELY be
stored independently... they can be used for the blind interface or
another interface. The content is independent of the presentation.

> Looking at Alan's ballot mockup, that's one heck of a lot of work to
> produce
> flexibly (and quickly), unless I would hard-code the positioning of
> each
> element. I'm trying to limit myself to thinking about the demo, so
> this would
> be possible, but I'm really against that for the long run.

We should be clear on the point that the ballot mockup is definitive
for the demo. We DO NOT want flexibility at this point, we need the
ballot to look EXACTLY like in the picture. Moreover, the demo isn't
the production system... we're likely to throw a lot of the demo code
away (maybe not ALL of it, but this is a proof-of-concept for the
voting system, NOT for the software design... it's easy for us
programmers to forget the difference).

In addition--this has come up on the list before, but newcomers are
likely to have missed archived discussions--the flexibility we might
eventually have in production is subject to very different criteria
than those in a traditional GUI interface. It's not enough for widgets
to flow in a nice looking way... they have to flow in a way that
follows jurisdiction-specific voting regulations, and is specifically
approved by elections officers. Standard auto-resizing windows
ENTIRELY miss the goal. For example, introducing subtle psychological
bias towards one selection over another might be undesirable for a data
entry screen--the same thing on a ballot is ELECTION FRAUD. Things
like position of a candidate on a page, column breaks, order of items,
etc. are major legal issues, not reducible to technical ones.

FWIW, my suggestion for XML documents configuring ballot-placement is a
good approach. We MIGHT have some application to automatically
generate these positions, but it is also potentially manually tweakable
(or perhaps some drag-and-drop configuration application could be used
later). But for now... just make it look like Alan's sample picture.

Yours, David...

  Anand Pillai
-- - Sent 0.000002 seconds ago
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Thu Apr 1 02:40:14 2004

This archive was generated by hypermail 2.1.8 : Thu Apr 01 2004 - 02:40:36 CST