Re: [OVC-demo-team] New tester

From: Anand Pillai <anand_pillai_at_fastmail_dot_fm>
Date: Thu Jan 29 2004 - 01:29:09 CST

I have combined the style, placment XML files
and produced a single UI xml file which is more
comprehensive than the existing two.

It does not have a DTD right now. I am in the process
of defining a schema for this.

Please note that the XML files model Alan's original
ballot demo sample.

The XML elements are kind of self-explanatory though
I have used some grouping for the font styles using numbers
instead of text strings (1 for regular, 2 for bold, 3 for italic
etc). The code can take care of converting the numbers to
actual styles.


----- Original message -----
From: "Anand Pillai" <>
Date: Thu, 29 Jan 2004 12:01:03 +0530
Subject: Re: [OVC-demo-team] New tester

Yes. This is what I also think. We need to chart
a model for the voting UI instead of blindly going
ahead and producing something that "just works".

The existing xml model detailing the UI elements
is not of very good quality. At best the code it
produces will be of beta quality and cannot go further.
Since we developed the XML specifications ourselves,
which is one of the reasons for it.

There are existing XML specifications allowing one
to do this. Mozilla's XUL is one of them though it
is too extensive to be considered a candidate.

As you might know the current idea is to parse two
XML files which correspond to the style and placement
of the UI elements and build the UI. There will be
two processes here, one that parses the XML and other
that creates the UI by using the parsed data.

I consider this process flawed. I did not say this at
the beginning of the project since it was proposed by
David Mertz, but instead of using two XML files we
should put all coding information in one, creating
the UI XML as a single data repository. We should define
the elements of the UI as XML elements, and each element
can have its own style and placment defined as attributes.

I wrote the minimalistic GUI by parsing the style and
placement files but the process is very clumsy. Here is why.

For coding information on the ballot print button, two pieces
of information need to be defined.

1. ballot-style.xml

...<ballot_print_box_font size="26" weight="bold" />

2. ballot-placements.xml

...<ballot_print_button x="945" y="860" width="257" height="82" id="25"
/> <!-- Print button -->

Instead of this the following one xml would suffice.

<ballot_print_widget posn="945 860" width="257" height="82" id="25">
  <font size="26" weight="bold" />

This is much more neat and concise and avoids the overhead of
maintaining two xml files with different naming schemes for the
element. As you know schemas are difficult to write and maintain
and maintaining one schema is definitely easier than maintaining
two disparate ones working on the same code.

I suggest the formation of a UI design team, which need to come
up with the XML schema for this unified XML. We need to jump to
coding only after that.

The existing ballot-placment and ballot-style xml are attached
with this mail.


----- Original message -----
From: "Fred McLain" <>
Date: Wed, 28 Jan 2004 15:09:31 -0800
Subject: Re: [OVC-demo-team] New tester

Sure. What I am looking for is a list of steps that the user is expected
to perform and the responses the system is expected to give. In short,
requirements. Use cases are a simple way to describe these:

1. User hits any key
2. System says instructions on use
3. User hits down arrow
4. System says ballot title
5. User hits down arrow
6. System says first canidate name
7. User hits enter
8. System restates selection and asks for down arrow to confirm
9. User hits down arrow
10. System says "confirmed"
11. System says next ballot title
at 9: User hits enter
10. System says canceling selection
11. go to step 4
One reference I found via a google search:
Though I prefer the outline approach, you can also do this as a diagram:
No matter which approach we take, we need requirements in order to test, 
otherwise it's just opinion or saying "runs as coded".
On Wed, 28 Jan 2004 14:02:15 -0800, Alan Dechert 
<> wrote:
> Fred,
>> Last time I talked to Al he was requesting more effort on the vision
>> impaired (audio) interface.  I have done some testing on it and found 
>> that
>> Jan's code didn't crash but I am confused about the work flow.
>> Does anyone know if we have use cases for the audio interface?
> Can you elaborate on this?
> Thanks.
> Alan (not Al, btw) D.
Using M2, Opera's revolutionary e-mail client:
  Anand Pillai
-- - IMAP accessible web-mail
  Anand Pillai
-- - IMAP accessible web-mail

= 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:12 2004

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