Re: [OVC-demo-team] Questioning the requirements/architecture documents

From: Eron Lloyd <elloyd_at_lancaster_dot_lib_dot_pa_dot_us>
Date: Tue Feb 03 2004 - 19:24:40 CST

Hi all,

On Saturday 31 January 2004 9:13 pm, you wrote:
> Greg Stern wrote:
> > That is, it is basically a paper ballet layout (and
> > confusion) and doesn't take advantage of a better UI that a computer
> > can bring. For example, why isn't it a wizard interface with one page
> > per vote, with a summary page at the end when the voting is complete?
> Such a "wizard" approach would both be illegal according to most
> election law, and would be hugely confusing to voters who do not use
> computers on a day-to-day basis. Actually, I wouldn't like it as an
> experienced computer user either, but that's neither here nor there.

Are we going by local election laws, most of which are ridiculously out-dated
and ambigous (especially related to ballot design), or are we attempting to
follow the guidelines documented in the VSS? If we are following the VSS,
then I don't see how a multi-step ballot would be discouraged. Of course, we
want to reduce the amount of steps and complexity for sure, but this one page
restriction is an impossible limitation. I have just about a working example
of the ballot sample that Alan produced, which is very tight given the layout
in the GIF file. It works right now, but the minute I change the font size or
alter the language, everything is out of whack. I just don't see this
working. How on earth would you use such a ballot, for example, if we had a
wonderfully democratic election system where 8 or more parties ran candidates
for every seat? How would we manage the California run-off ballot? It's just
not possible.

> In short, an excessively "computerized" interface is a non-starter.
> > I agree with xml describing the data, by why also the view.
> XML is widely used for lots of data descriptions. It just makes more
> sense to use XML than to invent yet another custom description language
> for purposes of the View document.

Has anyone taken a look at OASIS' EML schemas?

> > And finally I'm curious about the choice of Python. The majority of
> > open-source developers I've seen are either program for KDE or Gnome.
> I don't really see the connection here. Both PyQt and PyGtk are
> available (as is wxPython). The GUI library used is quite independent
> of the programming language used. If the argument here is actually
> about using C++ rather than Python... well, it takes at least twice as
> much development time (and many times the number of lines; therefore,
> proportionally more error-prone).

It's very easy (and fast) to code in Python and Qt. We can test, run, and
modify the code very quickly without worrying about low-level logic details.
If necessary down the road, we could move our code to C++ very easily. We
also still have complete access to all the Qt benefits, such as Designer and
Linguist. Python is an excellent choice for even a finished project, but even
more sense for a prototype. Plus many developers *here* are versed in it
(which matters).

> > I'm very tempted to implement a more logical based wizard UI based on
> > the XML format defined for the data using Qt. If I did, would you be
> > interested in what I develop? How set are you on the existing
> > requirements and architecture documents?
> The use of Alan's demo screen is FIXED IN STONE for the demo.
> Conceivably, WAY down the line, we could consider other interface
> designs. But any such design has to be IMMEDIATELY obvious to someone
> who has never seen a computer before, or it's entirely unsuitable for
> voting purposes.

I still am having trouble understanding why. There is no empirical study on
electronic ballot design, especially done in an academic environment where it
is shared and furthered by the work of others and field research. The closest
thing I have found was this:

which still leaves many questions unanswered. How many here have had the
priveledge to use several types of computer voting machines to test and
evaluate their interfaces? Not me. All the images of the machines from
Diebold, ES&S, Sequoia, et. al. reveal primative, poorly done interfaces.
Diebold's unit seriously looks like nothing more than an embedded Web
browser. Do users benefit more from a single tabular design, or would it be
better to break each race out separately? Does displaying photos of the
candidates help to connect a name to the face? For races with many seats, can
we benefit from something such as Robsons Ballot Rotation:

def rotate(sequence):
    sequence.insert(0, sequence.pop())

which reduces the unfair advantage of fixed candidate listing? These are the
kind of questions I'm interested in researching and answering, and a large
reason why I joined this project. If we are just racing to get funding, I
understand, but the constraints of the demo requirements seem like a burden,
if we are demonstrating a *concept* not a design.

> The rest is somewhat more movable. But the tabulation software and
> other parts have been developed around the assumptions documented.
> Still, if Greg checks in a amazing implementation that just happens to
> be written in C++ (or uses some custom View Description Language, or
> whatever), I have nothing against using it (for the demo).
> > P.S. I would expect it wouldn't take more than a weekend to implement
> > that part.
> You're at least the 20th person to make this claim (of the triviality
> of writing the interface). So far, the prior 20 have not delivered
> working code (even given more than a weekend). But if you want to
> check in something you think is useful, please feel encouraged to do
> so. No harm can come of having another interface in sourceforge, even
> if it's not used in the demo).

I will say that it is trivial to write *an* interface (which I have already),
but difficult to satisfy the requirements of this particular demo. To me this
is why one hasn't been checked in yet, despite so many attempts. It seems
much too rigid of a demand for something that is supposed to be considered
throw-away code.

That aside, have we any new code from Gene?



[This E-mail scanned for viruses by Declude Virus]
= 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:15 2004

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