Re: about the Python code

From: Edward Cherlin <edward_dot_cherlin_at_etssg_dot_com>
Date: Thu Jul 24 2003 - 18:51:33 CDT

Actually, in the space common to both US Letter and world A4
paper. A4 is a bit taller and narrower.

> > The web & pc components
> > have two general functions: (1) print & (2) larger type.
> > ...
>
> The first button in the Instructions tile is to switch
> languages. This is worth mentioning because there are some
> formatting issues to consider. For example, I think on the
> printout we have to organize the text so that if the voter is
> using non-English, we print the information in their language
> but put in the English equivalent.

That raises thorny formatting issues. It might be better to print
the two languages on separate pages.

> Eventually, there are
> other localization issues but we probably don't need to worry
> about this for the demo.

Unicode, for a start.

> > "Larger type" will result in a multipage ballot (with, I
> > assume, a "Next"
>
> function). ...
>
> Yes. The LARGER TYPE button will change to say NORMAL TYPE
> and will have Previous and Next arrows appended.

UI issue: The button should says clearly what it will do.
Otherwise many users will assume that it is showing the current
state. INCREASE TYPE SIZE and RETURN TO NORMAL TYPE SIZE will
work, but we should be able to improve on that. Maybe just
DECREASE TYPE SIZE for the second message.

> > The PC version will be implemented in Python. The web
> > version will be implemented in something -- maybe Python,
> > maybe PHP.
>
> Sounds about right. We're working on all that.
>
> > Anything I'm missing?
>
> Probably.
>
> --Alan
>
> > There's a lot of discussion about (what appears to me to be)
> > esoterica: e.g., codes assigned to the ballots. From the
> > code development point of view, I'm not seeing this as a
> > huge issue. Whatever implementation is decided on can
> > (probably) just be plugged-in to the code. From the design
> > point-of-view, I want to make this as robust and extensible
> > as possible. Matteo's idea of separating out the "interface
> > data" from the interface itself will make this a very
> > flexible system.

Vital for multilingual applications. Don't forget to allow for
right-to-left reading order for Arabic, Hebrew, and some other
languages.

> Just tell us what's needed and we'll try
> > to build it ;-)
> >
> > FWIW, for generating random numbers, this is what Python's
> > new (2.3) "random" module says:
> > ============================================================
> >========== General notes on the underlying Mersenne Twister
> > core generator:
> >
> > * The period is 2**19937-1.
> > * It is one of the most extensively tested generators in
> > existence * Without a direct way to compute N steps forward,
> > the semantics of jumpahead(n) are weakened to simply jump to
> > another distant state and rely on the large period to avoid
> > overlapping sequences.
> > * The random() method is implemented in C, executes in
> > a single Python step, and is, therefore, threadsafe.
> > ============================================================

Quite adequate for a demo. It's nice to see somebody take these
issues seriously in a language design.
- --
Edward Cherlin, Simputer Evangelist
Encore Technologies (S) Pte. Ltd.
Computers for all of us
http://www.simputerland.com, http://cherlin.blogspot.com
Received on Thu, 24 Jul 2003 16:51:33 -0700

This archive was generated by hypermail 2.1.8 : Wed Aug 06 2003 - 12:50:26 CDT