Re: [OVC-demo-team] BRP Mockups

From: Eron Lloyd <elloyd_at_lancaster_dot_lib_dot_pa_dot_us>
Date: Thu Feb 26 2004 - 21:39:09 CST

Hi David,

On Thursday 26 February 2004 8:56 pm, David Mertz wrote:
> On Thursday, February 26, 2004, at 08:20 PM, Eron Lloyd wrote:
> > The Ballot Reconciliation Process UI mockups are complete, and can be
> > reviewed
> > here: http://www.lcgp.info/tmp/evm/brp/
> > *Please* give me feedback on layout, wording, workflow, etc. I want to
> > have
> > this coded and done by the end of the weekend.
>
> Alan or Fred can chime in with more detail on the specific workflow. I
> just wanted to comment, Eron, on how nice these Qt dialogs look from a
> visual perspective. It is a nicely refined, but clean, widget set--and
> you have done a great job with the layout. Actually, I also thought
> your Qt version of the ballot GUI had a nice look, even though I think
> Fred is right about the fastest approach to the demo being to use a
> literal background image of the whole ballot.

I really appreciate the compliments. Regarding the ballot UI that I'm working
on, I agree that it may be a bit premature to roll it out... it works, but
the code is *far* from finished. In time, I hope to add much more tightening
and polish to it, but I think we have at least a solid object model to build
on there. I'm really excited about some of the interaction features I've been
working on since that release; I think I've come up with a way to allow for
single-selection, multi-selection, ranked selection, and limited selection
voting all with the push of the one button. You'll see more once I check the
code in. Do we want me to factor out the on-screen keyboard still?

> Couple smaller questions. Did you (or will you) use PyQt or PyKDE for
> the coding? I guess the latter is higher level, right? But I haven't
> used either enough to have any opinion... I'm just curious. Related to
> that, do you know if there are KDE interface guidelines about the order
> of the buttons in a "wizard" application? I'm wondering whether the
> Cancel should be to the right of the Back/Next, or possibly to the left
> of them. I guess I should go play with a few other KDE apps to see
> what they do.

Right now the mock-ups are purely Qt Designer XML-based; I'll end up either
sub-classing or re-writing the UI from scratch once I get a good solid
design. I will definitely use PyQt; PyKDE is nice, but creates too many more
dependancy requirements. Based on the research and architecture design I've
been working on for the past year, I'm convinced that Python and Qt are the
best tools for this project. 90% of the code we write will be able to be
Python-based, and all low-level stuff (hardware) can be written in Qt/C++ and
wrapped with SIP to expose an API to Python and PyQt.

Regarding the setup of the procession buttons, I'm simply sub-classing the
QWizard component, which manages the button arrangement automatically. One
thing the final version will do is take advantage of QWidget.enable() to
block or protect access to the interface to prevent mistakes or changes to
existing entries that are already completed. I could disable the Cancel
button if necessary. As far as I can tell, KDE also uses QWizard as a base
class, like in kpersonalizer.

> On Ballot Verification Witnesses: Not essential, but if it is easy to
> eliminate the choice of Witness One from the pick list for Witness Two,
> that would prevent one type of user error. If it's hard to be dynamic
> at that level, I wouldn't worry about it though.

Will add that, no sweat.

> I assume the several forms with lists of items that may be added will
> grow scroll bars when needed? Would it be better to have the scroll
> bars visible always? I don't have an opinion, just something that
> strikes me.

Yes, most container widgets inherit QScrollView, that automatically displays
scrollbars as necessary. When not needed, it frees up screen real-estate. I
can also change the sort order to display the newest entries on top,
preventing the need to scroll down to verify input.

> On Compare Ballots: I'm thinking that reconciliation of a couple
> hundred ballots won't take more than a couple seconds, even on a three
> year old machine. The progress bar might be unnecessary--if you
> eliminated it, you could fit the hidden line of the generated report on
> screen without needing to scroll. Depending on what was in the Errors
> tab, that might still need to scroll, but the Summary is more basic.

You're probably right. At the same time, though, it's good UI practice to
provide progress activity to visually indicate that a process is complete,
and there may be instances where it does take some time. One thing to keep in
mind with Qt is that it has fantastic layout support, so you almost never
want to use absolute sizes for the UI; let Qt determine it based on the rules
you set. Therefore, the window can easily stretch, displaying all list items.
I made it compact to begin with, but it can certainly take up the full
screen.

Again, thanks for the great feedback. Think I'm going to get some sleep
now :-)

Eron

---
[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:23 2004

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