[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 that may have holes in its logic. Due to time constraints, I have not been able to 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 presentation issues. I disagreed with that perspective but wanted to see if any further discussion of the issue would take place on the mailing list, so I did not speak 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 allow for dynamic, two-way interaction. ------------------------------------------ Generic vs. Election-Specific ------------------------------------------ As is commonly known, there are already standardized ways to present data stored in an XML format. Cascading Style Sheets (CSS) is the most common method. Extensible Stylesheet Language (XSL) - made up of XSLT, XPath, and XSL/FO - is the up-and-coming method. Document Style Semantics and Specification Language (DSSSL) was created to format Standard Generalized Markup Language (SGML) and XML, however it's rather complex and is not widely used. Formatting Output Specification Instances (FOSI) has been used to 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 creating an 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 creating an election-specific way to define user-interfaces for voting systems. This is 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 to define 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 - poorly designed ballot layouts, confusing ballot instructions, and no ballot validation feedback for voters. A post-mortem analysis by USA Today and several other news organizations (http://recount.usatoday.com) revealed that these problems (not including the many other problems that occurred) likely 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 to define ballot presentation and voting system user-interfaces. This would allow very detailed guidelines and/or templates to be defined, published, widely 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 participate in forming them. However, without a common method of defining ballot presentation and user-interfaces, this type of open discussion and analysis is 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 recount was the use of a standardized ballot for all national elections. In theory, at 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 ballot standardization 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 for each election -- this could provide the benefits of a standardized ballot without 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 analyzing ballot 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, cost and time constraints would likely prevent national-level citizen watchdog groups from analyzing all of the ballot definitions if manual analysis is the only option available. A standardized method for ballot presentation and user-interface definition would allow automated and semi-automated analysis of ballot definitions. Legislators, policy makers, and voting standards creators could create one or more guideline schemas that would have jurisdiction-specific ballot definition requirements encoded into an XML document model. These guideline schemas 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 according to 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 be passed 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 through a validating parser at the end of the process, to help insure that ballot presentation 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 desirable extent, then commonly available scripting languages could be used to create automated 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 definitions would 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 systems and 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. However, 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, legislators can begin to think in terms of creating 50 state centralized computerized registration systems that could easily network permitting the accessibility 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 that is 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 of Compaq 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 that we should be unconcerned with them. The US Department of Defense recently built a small-scale prototype that was, in essence, a vote-from-any-polling-place type of voting system. It was created as part of the Federal Voter Assistance Program, which is targeted at assisting US military personnel with participating in elections while they are stationed overseas. Dr. Jefferson recently commented on this effort during his participation in a 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] that at any one location you have military personnel from 500 different jurisdictions with 3,000 different ballot types all trying to vote in one location. That is an enormous problem; they have a huge, enormous problem. For a first shot at tackling the problem, it was time to try it. I assume they 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_p4.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 of defining ballot presentation and user-interface. (6.) Increase the probability of EML acceptance and adoption by election administrators, legislators, voting standards creators, and voting system creators. With any type of standard, the less benefit it offers, the less incentive there is to adopt it. With EML my concern is that if its capability becomes too tightly focused, then those who run public elections will simply ignore it. 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 this happen. If it is going to be built, I tend to think it should be built to be widely useable. This is the reason I believe it would be wise for the committee to work off of 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 and effort into creating. This approach would allow a broad field of options to be considered. Then the options would be narrowed down based on the potential value committee members see in each option. The options for which there is not sufficient support 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 be seriously considered for wide-spread adoption. ----------------------------- Presentation Issues ----------------------------- Concerning election-specific presentation capability, after looking at what is needed and what is currently possible, my perspective has changed. I no longer see benefit in creating election-specific presentation capability. My current thinking is that CSS and XSL should work well for this. I do, however, see benefit in creating several types of examples that show how EML could effectively be used. One type is examples showing how CSS and XSL could be used in conjunction with 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 government into 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 be validated against one or more published guideline schemas. And a fifth type is an example of how vote-from-any-polling-place could be facilitated 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 may not derive significant benefit from building-in support for CSS and/or XSL. However, those creating voting systems intended for use in public elections may 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, however 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 feasible to do with XML. If the EML committee addresses this at all, I tend to think it 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 any of this, so everyone's comments are welcome. Best Regards, Thom
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC