Re: [OVC-demo-team] New tester

From: Fred McLain <mclain_at_zipcon_dot_net>
Date: Thu Jan 29 2004 - 10:34:26 CST

Hi Anand & all,

It might be better to define this as an XSD or XDR. It so happens that
I work for a company that produces a schema management tool,
http://www.schemalogic.com. It's a SOAP service that allows for change
notifications, XSD/XDR exports, voting on changes and GUI based schema
building. I have sent in a request about making a server available for
us to collaborate on putting our schema together.

        -Fred-

On Wed, 2004-01-28 at 23:29, Anand Pillai wrote:
> 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.
>
> -Anand
>
>
> ----- Original message -----
> From: "Anand Pillai" <anand_pillai@fastmail.fm>
> To: OVC-demo-team@lists.sonic.net
> 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
>
> ...
> <fonts>
> ...<ballot_print_box_font size="26" weight="bold" />
> </fonts>
>
> 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" />
> </ballot_print_widget>
>
> 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.
>
>
> -Anand
>
>
>
> ----- Original message -----
> From: "Fred McLain" <mclain@zipcon.net>
> To: OVC-demo-team@lists.sonic.net
> 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
> ...
>
> Exceptions:
> at 9: User hits enter
> 10. System says canceling selection
> 11. go to step 4
> ----
>
> One reference I found via a google search:
> http://www.objectmentor.com/publications/usecases.pdf
>
> Though I prefer the outline approach, you can also do this as a diagram:
> http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
>
> No matter which approach we take, we need requirements in order to test,
> otherwise it's just opinion or saying "runs as coded".
>
> -Fred-
>
> On Wed, 28 Jan 2004 14:02:15 -0800, Alan Dechert
> <alan@openvotingconsortium.org> 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: http://www.opera.com/m2/
> --
> Anand Pillai
> anand_pillai@fastmail.fm
>
> --
> http://www.fastmail.fm - IMAP accessible web-mail
> --
> Anand Pillai
> anand_pillai@fastmail.fm
==================================================================
= 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