|Thom Wysong||Jun 12, 2001 12:40 am|
|Michael Zolotarev||Jun 12, 2001 1:54 am|
|Jason Kitcat||Jun 12, 2001 3:29 am|
|Michael Zolotarev||Jun 12, 2001 3:36 am|
|Thom Wysong||Jun 12, 2001 7:03 am|
|Krishna Sankar||Jun 12, 2001 12:51 pm|
|Krishna Sankar||Jun 12, 2001 1:14 pm|
|Krishna Sankar||Jun 12, 2001 1:18 pm|
|Krishna Sankar||Jun 12, 2001 6:38 pm|
|Michael Zolotarev||Jun 12, 2001 10:37 pm|
|Krishna Sankar||Jun 13, 2001 10:32 am|
|Michael Zolotarev||Jun 13, 2001 6:58 pm|
|Michael Zolotarev||Jun 13, 2001 7:07 pm|
|Krishna Sankar||Jun 13, 2001 8:11 pm|
|Krishna Sankar||Jun 13, 2001 11:24 pm|
|Krishna Sankar||Jun 15, 2001 12:47 am|
|Subject:||RE: Election Presentation & User-Interface Issues|
|From:||Michael Zolotarev (mich...@baltimore.com)|
|Date:||Jun 12, 2001 1:54:30 am|
I'm afraid we may be drifting away from the original goal of the TC. And I see that drift as a dangerous one.
Before anything else, let me remind you the charter (ignore it if you think that you are familiar with it :): to facilitate "...structured interchange of data among hardware, software, and service providers who engage in any aspect of providing election or voter services to public or private organizations. The services performed for such elections include but are not limited to voter role/membership maintenance (new voter registration, membership and dues collection, change of address tracking, etc.), citizen/membership credentialing, redistricting, requests for absentee/expatriate ballots, election calendaring, logistics management (polling place management), election notification, ballot delivery and tabulation, election results reporting and demographics".
Sorry for preaching, but the only situation when we need a *standard* token is when there are two or more vendords involved, and interoperating. Why bother otherwise? Now, where do you think would different "election services vendors" be interoperating? I'm inclined to think that the most of interactions will be around the backbone of the election services, dealing with already collected ballots, specifically. Very unlikely at the front-end. The actual ballot presentation will be, most likely, a battlefield where different vendors will be kicking each other's arses (sorry), trying to do different "presentation layer" things.
I agree that we do need some sort of regulation here, for the user interactions layer. But it shoud come from the govs, psychologists etc. Not from a standards body trying to work out a structure of a token(s), which is essentially a collection of bits on the wire/storage device.
I'm sure that once we have a backbone which can be used by a number of vendors, AND a number of voting terminals (including MS IE 5.5 :) which can be successfully plugged into that backbone, the issue of standard presentation will be sorted out. But not before, and not together with.
Sorry for being humbled a bit - I'm in Sydney, and it's late. Pity the time difference makes it impossible for me to attend the chat.
-----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.
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.
----------------------------------------------------------------------------------------------------------------- "How can I make sure the right people get access to the right resources and business applications, with a user base that's constantly growing and changing?" The answer... Baltimore SelectAccess Next Generation Authorisation Management http://www.baltimore.com/selectaccess/index.html
----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on.
In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.