Overview
This demo prototype app is part of the TrustTheVote Project‘s highly accessible remote ballot client (ABC Mobile App) wherein such a mobile “client” provides the services of ballot access, preparation, and production of necessary ancillary documentation to complete a ballot transaction (i.e., casting of a ballot).
The ABC Mobile App is intended primarily for the needs of ~30 million Americans who have accessibility and disability support requirements to vote from home. However, the app may be suitable for a range of remote voting application settings. The ABC mobile App will also be part of the Tusk Charitable Foundation’s “Mobile Voting Project.”
This software is part of the OSET Institute‘s architecture and design phase of the ABC Mobile App and is pursuant to specific work as part of this phase described below.
Additional Engineering Risk-Reduction Deliverables
There are four (4) additional important elements of the Engineering effort for the ABC mobile app as part of the Tusk MVP.
Originally, it was planned for these to be accomplished in the initial stages of the Development Phase. However, deferring these two important exercises introduces unnecessary risk to the Development Stage given the potential for other providers of software to be integrated with this work to run into unforeseen technical issues.
Performing this work contemporaneous to the balance of the Engineering stage alleviates that risk and allows for early detection and resolution of potential issues during the engineering stage and not the Development Phase. Here are the two specific tasks accomplished by this demo prototype app:
- PDF manipulation software verification. A “port” to an Android® environment and to iOS® of existing PDF manipulation functionality OSET Institute currently has on a server-side service to prepare ballot PDFs using open source PDF manipulation software to manage that capability. The purpose of this effort in the Engineering stage is to determine whether and to what extent open source (royalty-free licensed) postscript manipulation software can provide the level of professional-grade PDF rendering (i.e., preparing a marked ballot image), and if not what the options are, including developing such open source capabilities alternative to having to address incorporating fee-based licensed software components to an otherwise public technology solution.
- For assessing this PDF manipulation capability: the work is to develop simple Android and iOS apps that will enable developers to use Android’s and Apple’s corresponding PDF file handling libraries, and test functional compatibility of the PDF ballot file format, and the library’s ability to form-fill a PDF to represent voter choices. If necessary, this will further include experimenting with 3rd-party libraries as possible alternatives to Apple’s PDF library or alternatives for Android. Implementation of a ballot printing option will also be included, to ensure that iOS and Android printing functions are properly integrated on each platform, and to provide a method of reviewing the generated PDF for correct printed formatting after form-fill. By the conclusion of this stage of work, the OSET Institute will have a tested and proven a method of iOS and Android app ballot PDF preparation, and a software design for the Development stage of the app’s full functionality for PDF preparation for both targeted operating systems/environments.
- Android® and iOS® Skeleton App Development Validation. This second aspect is a prototyping exercise to provide a working example of an app (for each mobile OS platform) that any developer could use to add additional ballot return capability in addition to the base app’s ballot and affidavit printing functions. The app’s front-end functionality will be limited to support the print function and provide a point for additional ballot return functionality. To be clear, this development of what we loosely refer to as “crash test dummies” was earmarked to be part of the Development Phase-2 before the OSET Institute research engineering (CoreTeam) realized that deferring this work could wreak havoc on the actual development cycle. In other words, this item needs to be addressed first, in advance of the actual ABC mobile client development effort or there is a substantial risk of failing to make a December system complete target date.
- For the “crash test dummies:” the work is to build both Android and iOS “skeleton” apps using the development environment chosen for Phase-2, built for each of Android and iOS, containing internal programming interfaces, and sample artifacts to pass from the main app through the internal programming interface, to a placeholder for a client library that could be developed to perform further processing on the PDFs and cast vote records created by the app. While hard-coding or “stubbing” most of the Phase 2 app’s functionality, the Phase 1 skeleton apps (Android and iOS versions) will be sufficient for any other party to re-build, and experiment with implementation techniques within the internal programming interface, using realistic static data artifacts formatted exactly as will be the dynamically created data artifacts of the Phase-2 app.
