Re: [OVC-demo-team] Focus on ballot GUI

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Thu Feb 05 2004 - 11:25:13 CST

Eron Lloyd wrote:
> David, I'm sorry if I've been a bit too vocal for your or anyone
> else's liking over the whole UI issue.

It's not that. All the issues you have thought about are indeed
interesting ones, and ones that merit serious consideration or studies.
  But the studies need to come after the demo (or at least in parallel
with it, but not as part of this list). The layout Alan designed is
one designed not to raise any outright red flags among the demos target
audience (elections officials, journalists, etc)... which is a quite
different matter than being the optimal design for production.

For the demo, we don't need to worry about races with more contests.
The sample is realistic for a typical ballot... obviously something
like the California recall presents special issues. I'm not convinced
that page turns -would- turn out better after actual studies. A real
concern beyond familiarity to non-computer-literate voters is the
likelihood of voter abandonment of partially completed ballots: It's
easy to imagine a voter tiring of page turns, and to leave (either
thinking they had already voted on the contests they cared about, or
simply because the process felt too lengthy... even if it -actually-
took less time, the -perception- of time would probably be longer with
page turns). But again, that's post-demo; I'd be happy to be shown
wrong in my intuitions by studies involving actual test uses and
stopwatches, post-ballot interviews, etc.

> we should structure the Dev. team a bit more and all be on the same
> page
> as far as our design goals and objectives (a timeline would help, too).

I think now that Fred has agreed to be Dev Lead, he'll do a better job
with following up on these needs than I did.

> The basic architecture document summarizes the ballot mockup, XML
> schemas, and
> requirements for a MVC design. Besides that, there are a few items
> that don't
> seem to be mentioned (I can't think of them all, heres a start):

I know. I did all the documentation there is so far, but recognize it
is quite incomplete (and outdated in a few places, i.e. barcode
obfuscation is now ROT10 rather than XOR). If Eron or someone else
would like to take over updating and expanding the Architecture
document, that would be wonderful (I guess Fred should decide on this
responsibility, but I imagine he wouldn't turn away volunteers).

> 1. There is a button for language switching. Is the entire application
> supposed to support l10n strings? What languages? Is this just a
> placebo?

The languages needed for a specific jurisdiction will vary. So
French/Spanish are indeed placeholders in a way. But ideally, we'll
find translators to create ballots in those languages, for the demo
(but maybe that's M2 or more, not M1). Btw: I think 'placebo' isn't
quite the word you want... probably 'placeholder'.

> 2. Are we to provide for font enlargement, too? Doing so immediately
> breaks
> Alan's pixel-precise positioning, obviously breaking the resolution
> boundaries. In my design, I allow for scrolling (horizontally) since I
> develop in 1024X768 and wanted to accommodate for this adjustment.

Yeah... we need to do the font enlargement somehow. But exactly how it
works is kinda unspecified. The default UI, however, should be
-exactly- 1280x1024 with NO scrollbars or other window widgets visible.

On my Mac, I recently noticed that I can enable screen zooming which
lets me enlarge any screen region by as much or little as I like. (the
Mac version is really slick because its Display PDF interface avoids
any pixelation of widgets when zoomed). I wonder if that would be a
suitable interface. Or would it be to computer-oriented, and
unfamiliar to many users? But requiring an extra couple minutes of
training for visually impaired voters might not be unreasonable.

> 3. There still hasn't been any discussion on how to factor out the
> audio code
> to remove it's curses dependancy. Is Jan still working on this?

I don't know anything about this issue.

> 4. It's going to take some time to get the look and feel exactly
> right. Even
> in Python, I'm having to resort to low-level drawables and custom
> widgets in
> Qt to piece things together.

Let's aim for "close" for M1, and we can tweak the widgets later. But
yeah, we'll probably need bitmap buttons for the controls (the bitmaps
can be captured by cutting them out of Alan's pictures)

> 5. How should we handle write-in entries? There is mention of an
> on-screen
> keyboard; is this the route we're taking? Do we need to accommodate any
> accessibility issues? What about error handling and input validation?

Dunno... this would be a good addition to the Architecture spec.

> 6. Where is all the other code? CVS is quite bare besides BVA, RII,
> and the
> printing module. Will there be tabulation and ballot verification code?

Yep... there's not enough there yet.

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

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