[OVC-demo-team] GUI status

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Thu Jan 29 2004 - 23:04:59 CST

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