-----Original Message----- From: Thom Wysong [mailto:wys...@technodemocracy.org] Sent: Tuesday, 12 June 2001 17:35 To: elec...@lists.oasis-open.org Subject: Election Presentation & User-Interface Issues

I apologize for sending this out only a few hours before our next meeting.I had intended to send this out earlier, but it has taken substantially longer to write-out than I had anticipated. I consider this as a draft thatm ay have holes in its logic. Due to time constraints, I have not been ablet o seek-out feedback on this before sending it out. I welcome everyone's comments.

------------------------------------------------------------------ Election Presentation & User-Interface Issues

------------------------------------------------------------------

In our last meeting a few weeks ago, the issue was raised of whether the EML committee should address presentation issues. A couple people stated that they thought Election Markup Language should not address presentationi ssues. I disagreed with that perspective but wanted to see if any furtherd iscussion of the issue would take place on the mailing list, so I did nots peak up.

Following are my thoughts on both presentation and user-interface issues. From my perspective, these are related topics. Presentation deals with tatic, one-way communication. User-interfaces extend presentation to allowf or dynamic, two-way interaction.

------------------------------------------ Generic vs. Election-Specific

------------------------------------------

As is commonly known, there are already standardized ways to present datas tored in an XML format. Cascading Style Sheets (CSS) is the most common method. Extensible Stylesheet Language (XSL) - made up of XSLT, XPath, andX SL/FO - is the up-and-coming method. Document Style Semantics and Specification Language (DSSSL) was created to format Standard GeneralizedM arkup Language (SGML) and XML, however it's rather complex and is not widely used. Formatting Output Specification Instances (FOSI) has been usedt o format SGML and XML, however it's also not widely used.

As I mentioned in a previous email, there is also a way to define user-interfaces in XML using Extensible User-interface Language (XUL). While XUL is not a standard, it is the only way I'm aware of to define user-interfaces using XML that is actively used.

One issue I've been looking into is whether there's a benefit in creatinga n election-specific way to define how XML ballot data is presented to voters. This is in contrast to using the generic methods for XML presentation (CSS & XSL).

Another issue I've been looking at is whether there is benefit in creatinga n election-specific way to define user-interfaces for voting systems. Thisi s in contrast to there being no standard way to define election-related user-interfaces.

For awhile now I have held the view that creating election-specific ways tod efine both presentation and user-interfaces would be beneficial to the elections community.

-------------- Rationale

--------------

There are several reasons why I believe having a standardized way of defining presentation and user-interfaces for elections is necessary.

Standardized presentation and user-interface definitions for elections would ...

(1.) Provide a common way to address election presentation and user-interface issues.

Some of the largest problems that occurred in the 2000 US Presidential Election in Florida had to do with presentation and user-interface issues -p oorly designed ballot layouts, confusing ballot instructions, and no ballot validation feedback for voters. A post-mortem analysis by USA Todaya nd several other news organizations (http://recount.usatoday.com) revealedt hat these problems (not including the many other problems that occurred)l ikely changed the outcome of that election.

There aren't many feasible solutions to these problems. However, the one that seems to offer the most promise is to enable legislators, policy-makers, and any other interested parties to use a common method tod efine ballot presentation and voting system user-interfaces. This would allow very detailed guidelines and/or templates to be defined, published,w idely analyzed, conversed about using a common vocabulary, and finalized.

This process could bring ballot layout and user-interface decisions out into the light of day, where all affected by the decisions can participatei n forming them. However, without a common method of defining ballot presentation and user-interfaces, this type of open discussion and analysisi s only likely to happen in a localized, limited way at best.

(2.) Enable voluntary ballot standardization without heavy-handed legislation or policy.

One partial solution that was discussed as a result of the Florida recountw as the use of a standardized ballot for all national elections. In theory,a t least, this would ensure that no voter or voter group would be disenfranchised because of poor ballot layout or unclear voting instructions.

However, in the US at least, federally mandated solutions for election problems generally aren't well received. This means that any type of ballots tandardization that occurs would likely need to be adopted on a jurisdiction-by-jurisdiction basis.

If every jurisdiction adopts a common, standard way of defining ballot data, presentation, and user-interfaces -- and adopts a common template fore ach election -- this could provide the benefits of a standardized ballotw ithout the legal and political battles that would be triggered by mandating a standard ballot.

Voluntary ballot standardization is unlikely to happen without a standardized way of defining ballot presentation and user-interfaces.

(3.) Enable large-scale, automated and semi-automated methods of analyzingb allot content, layout, and user-interfaces.

As mentioned above, publishing ballot definitions online would be useful for uncovering problematic ballot designs. However, due to there being thousands of ballot layouts used in any given national-scale election, costa nd time constraints would likely prevent national-level citizen watchdogg roups from analyzing all of the ballot definitions if manual analysis ist he only option available.

A standardized method for ballot presentation and user-interface definitionw ould allow automated and semi-automated analysis of ballot definitions.

Legislators, policy makers, and voting standards creators could create oneo r more guideline schemas that would have jurisdiction-specific ballot definition requirements encoded into an XML document model. These guidelines chemas could be fed into an XML validating parser along with all the ballot definitions they are intended to apply to. The validating parser would automatically flag any ballot definitions that are invalid accordingt o the parameters encoded into the guideline schemas. The ballot definitions that are deemed as valid by the validating parser would not need further attention. The ballot definitions flagged as invalid could bep assed off to human analysts for follow-up analysis or action.

Templates could be created which would be used to construct ballot definitions, customized for local precincts, that combine national, state/provincial, and local contests and issues. The ballot construction process could automatically pass all newly built ballot definitions througha validating parser at the end of the process, to help insure that ballotp resentation and user-interface guidelines are being met for each ballot.

If for some reason the capability of XML schemas and validating parsers isn't sufficient to analyze and validate ballot definitions to a desirablee xtent, then commonly available scripting languages could be used to createa utomated validation robots (a.k.a. "bots"). Automated validation bots would be feasible as long as standardized definitions for ballot presentation and user-interfaces are used.

This solution would be beneficial, but is unlikely to happen without a standard way to define ballot presentation and voting system user-interfaces.

(4.) Increase interoperability of voting systems and election management software.

Without standardization, ballot presentation and user-interface definitionsw ould need to be customized for each voting system and each suite of election management software. However, with standardization, ballot definitions could be created once and used with any standards-compatible voting or election management system.

Currently the practice seems to be that election administrators use election management software supplied by the same vendor that supplies their voting system. Standardization - including ballot presentation and user-interface definitions - would allow election management system software to be de-linked from voting systems. Election management systemsa nd voting systems could be chosen independently of each other.

Definition of ballot presentation and ballot user-interface could be defined in a non-proprietary manner that would work with any standards-compliant voting system or election management system.

Data interoperability among voting systems will be a positive step forward.H owever, presentation and user-interface interoperability would provide even greater benefit and flexibility to election administrators.

(5.) Enable advancement in election technology, procedures, and solutions.

In her email sent to this committee on 24 May 2001, Deborah Phillips stated ...

" ... we would like EML to be available (and constructed) for the widest possible application and use, so that the states, vendors, administrators,l egislators can begin to think in terms of creating 50 state centralized computerized registration systems that could easily network permitting thea ccessibility of one's local ballot from any secure polling station and also the instantaneous verification of registration nationwide ..."

I refer to that last part about "permitting the accessibility of one's local ballot from any secure polling station and also the instantaneous verification of registration nationwide" as vote-from-any-polling-place. This concept has previously been referred to as vote-anywhere, a term thati s misleading to the degree that it implies it encompasses voting from locations other than officially-controlled polling places.

I have heard David Jefferson present this concept several times over the last couple years. For those unfamiliar with him, David is an employee ofC ompaq Computer Corporation and was the Chair of the Technical Committee for the California Internet Voting Task Force.

Vote-from-any-polling-place systems are not so far off into the future thatw e should be unconcerned with them. The US Department of Defense recentlyb uilt a small-scale prototype that was, in essence, a vote-from-any-polling-place type of voting system. It was created as parto f the Federal Voter Assistance Program, which is targeted at assisting USm ilitary personnel with participating in elections while they are stationedo verseas.

Dr. Jefferson recently commented on this effort during his participation ina panel discussion hosted by the National Commission on Federal Election Reform. He stated ...

"... [this is] a first shot at a project, at a very important problem. There are many barriers to overseas military voting, not the least of which [is]t hat at any one location you have military personnel from 500 different jurisdictions with 3,000 different ballot types all trying to vote in onel ocation. That is an enormous problem; they have a huge, enormous problem.F or a first shot at tackling the problem, it was time to try it. I assumet hey will learn from this experience and try again on a larger scale with[ a] somewhat different architecture."

(http://www.reformelections.org/data/transcripts/h2/hearing2_p 4.php?d=April+ 12%2C+2001)

It seems likely that this type of voting will, sooner or later, be available in non-military settings. However, one of the many issues that need to be addressed before this can happen on a wide-scale is that of enabling a consistent way to present tens of thousands of ballot types, which originate from thousands of different jurisdictions, with a single voting system.

The only way I'm aware of to do this, in a way which allows every jurisdiction to maintain control of how their ballots are presented to their voters, is to use a common method for defining ballot presentation and user-interface.

Vote-from-any-polling-place is unlikely to happen without a standard way ofd efining ballot presentation and user-interface.

(6.) Increase the probability of EML acceptance and adoption by election administrators, legislators, voting standards creators, and voting systemc reators.

With any type of standard, the less benefit it offers, the less incentivet here is to adopt it. With EML my concern is that if its capability becomest oo tightly focused, then those who run public elections will simply ignorei t. If EML only provides partial solutions for public election problems, then there may not be sufficient incentive to adopt it.

If this were to happen, then EML could end up as a niche technology used only for small-scale or private elections. I would prefer not to see thish appen. If it is going to be built, I tend to think it should be built tob e widely useable.

This is the reason I believe it would be wise for the committee to work offo f a broadly defined purpose statement that encompasses using XML in any way that would improve elections, and not solely focusing on data interchange. What capability is actually added to EML would then be determined by whatever capability people feel is worth investing time ande ffort into creating.

This approach would allow a broad field of options to be considered. Thent he options would be narrowed down based on the potential value committeem embers see in each option. The options for which there is not sufficients upport would simply go unimplemented.

With this being said, I do believe that any XML specification which is intended for use in public elections needs to have a standard way of defining ballot presentation and voting system user-interfaces for it to bes eriously considered for wide-spread adoption.

----------------------------- Presentation Issues

-----------------------------

Concerning election-specific presentation capability, after looking at whati s needed and what is currently possible, my perspective has changed. I nol onger see benefit in creating election-specific presentation capability.M y current thinking is that CSS and XSL should work well for this.

I do, however, see benefit in creating several types of examples that showh ow EML could effectively be used.

One type is examples showing how CSS and XSL could be used in conjunctionw ith EML for creating common types of ballot layouts - using paper, electronic/visual, electronic/audio, electronic/tactile, and wireless/visual ballots.

A second type is an example to show how EML "templates" could be used to automatically combine ballot definitions from multiple levels of governmenti nto a single ballot with a consistent and unified ballot layout.

A third type is an example procedure for packaging and publishing ballot definitions, including presentation and user-interface elements, on the Internet for all to access and analyze.

A fourth type is examples showing how published ballot definitions could bev alidated against one or more published guideline schemas.

And a fifth type is an example of how vote-from-any-polling-place could bef acilitated using EML/CSS or EML/XSL.

These examples would not necessarily need to be created by the EML committee. I do, however, think they would be beneficial to create. If these examples are created, they could be used as initial prototypes for developing the solutions mentioned in the "Rationale" section above.

Voting systems that are used on a small scale or for private elections mayn ot derive significant benefit from building-in support for CSS and/or XSL.H owever, those creating voting systems intended for use in public electionsm ay have a greater incentive to build this support into their systems.

------------------------------- User-Interface Issues

-------------------------------

I had intended to write out thoughts on user-interface definition as well,h owever I've run out of time to get this email out before our meeting. I will look into this further and get something written up on it when time permits. At this time, however, I'm not even sure this is something that could realistically be defined with XML since it would involve both user-interface and elections-programming definitions. I'll have to look into this further to see what it would involve and if it would be feasiblet o do with XML. If the EML committee addresses this at all, I tend to thinki t would not be worked on until Phase 2, Phase 3, or beyond.

----------

As I mentioned above, I have not yet had time to seek out feedback on anyo f this, so everyone's comments are welcome.

Best Regards, Thom

This footnote confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.