RE: Election Presentation & User-Interface Issues

[Michael Zolotarev <michael.zolotarev@baltimore.com>]

Dear all,

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.

Regards
Michael

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:wysong@technodemocracy.org]
> Sent: Tuesday, 12 June 2001 17:35
> To: election-services@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.
> 


-----------------------------------------------------------------------------------------------------------------
"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.