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

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Sun Feb 01 2004 - 23:44:40 CST

> Why? Can you point me to such a law (for my own engineering and
> curiousity purposes).

Alan or Doug could do a better job with legislative specifics. But the
way to think about this is almost the reverse of what you might in most
design projects. You should basically assume that anything not
EXPLICITLY known to be allowable is prohibited (the interface aspect,
that is). Alan did some real work in researching and creating a demo
screen that matched existing, approved ballots... not in precise
content, but in form.

> I disagree. Making the user make one real choice per page versus
> making 20 choices is much easier to use.

Think of the target as people who have used paper ballots many times
before, but have literally never seen a computer. That might not be
-average- for voters, but we cannot disenfranchise that group.

> Again, having one "vote" per page makes so much more sense than
> overloading the screen with so many votes. I also don't find radio
> boxes to be intuititive to non-computer users. That UI especially
> won't work with a touch screen mouse.

There's not reason radio buttons won't work with touch screens. We
have several programmers experienced with touch screen development who
have chimed in on this (that it is fine). There probably -are- some
problems with where radio buttons versus checkboxes are used... that
might be able to be adjusted.

>> more sense to use XML than to invent yet another custom description
>> language for purposes of the View document.
> Help me make the connection here? What is the requirement to have such
> a dynamic view. It will be much faster and potentially more precise
> to use some sort of GUI tool, such as Qt Designer, to come up with
> the different GUI's.

First thing, the positions ARE data. I'm not sure how Qt Designer
specifically stores its positions, but I know some such tools do
actually use XML underneath. But Qt Designer itself is quite unlikely
to be usable for this purpose... we'll probably need something
customized (but maybe starting from some prior project). There's
nothing odd about dragging widgets as a way of producing corresponding
XML.

The view isn't dynamic as in runtime. But different elections will
have different ballots, which will all require their own design.... and
their own review and approval by elections officials. That's not for
the demo, it's just my attempt to look forward in the design. If for
some reason it was easier to scrap any dynamism in the view for the
demo, that would be fine. However, I understand that Anand has
actually measured the positions of all the boxes for the demo, and put
those into his XML document... there's really no reason not to use that.

> We can go and forth about this, but I would offer that the thousands
> of KDE programs, which is arguablely the most successful open-source
> project in the world, backs up the the C++/Qt data point. But I think
> this is more religion than reason.

I don't have numbers of source lines, but I know quite a few KDE
programs are written in Python (presumably using PyKDE and/or PyQt
libraries). In terms of various languages, this well known empirical
study is worth looking at:

http://216.239.37.104/search?q=cache:kU1N6jwJdtgJ:www.ipd.uka.de/EIR/
otherwork/
jccpprt_computer2000.pdf+lutz+prechelt+empirical+python&hl=en&ie=UTF-8

> My sourceforge id is gregdstern.

It looks like you're listed as a developer on EVM2003. Maybe someone
else added you before I checked. Do you not have the right privileges?
I don't really know Sourceforge very well, but I'll figure out how to
change your privileges if that needs doing.

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

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