Milestone #2 and beyond plan as of 2024/03/01

[windoverwater]

@stratofax @ion-oset

Current status: I decided to punt giving a UI/UX preliminary demo yesterday as it was not the correct forum for that and because being early in the milestone, there is still more to do. Per the project and design pages, this is what I think the current state of milestone 2 and beyond is.

Thoughts/comments? Neil - do you want to zoom to coordinate/discuss?

milestone 2 - complete by 3/21 (2.5 weeks)

Goal: stub out initial user story 2 workflow in both UI and UX
ToDo:
2) add the voter's selection to the JSON
3) add a checkout page that prints the contests, asks the question, and prints the castBallot.json to the console
4) add backward and random contest navigation

• add a previous contest button
• the progress bar will need an upgrade to handle colors and borders
  • let the active contest (progress bar) be white
  • let the vertical separators be black
  • let the horizontal borders be a darker gray
  • voted contests green
  • under voted contests yellow (thus yellow and gray are under votes)

The above should complete the UI/UX experiment. If ok, maybe do a UI/UX cleanup/debug pass to complete milestone 2 if there is enough time and if any UX/UI issue is significant or has significant risk.

Start milestone 3 on 3/21 and complete on 4/17 (4 weeks)

Note - maybe tweak the overall endpoint design - TBD!:

• the landing page is just a simple index.html
• voting.html has no git workspace behind it - just a html, css, JS page like the landing page
• the JS casting of a ballot on the backend is the only endpoint that does real work:
  • creates the guid git workspace
  • calls the VTP code to cast the ballot
  • returns a html page with the embedded JS object from the json object literal with additional html status/error messages

Start milestone 4 on 4/17 and complete on 5/1 (2 weeks)

Complete user stories 3, 4, and 5:

• user story 3: support endpoint for displaying git hashes (readonly git workspace)
• user story 4: support endpoint for console.log output of the ballot-check function (readonly git workspace)
• user story 5: support endpoint for console.log output of the tally-election function (readonly git workspace)

Start end-to-end testing and demo hardware construction/debugging on 5/1 and complete on 5/22 (3 weeks)

[stratofax]

@windoverwater This is an impressive plan but hard to evaluate because I'm not sure what the overall goal of this project is, or if you have a Minimum Viable Product in mind, or any other high-level strategic target or goal. Without that, I just can't make any kind of evaluation of these detailed plans.

In lieu of a clear target, I'd like to focus on getting some kind of CI/CD pipeline up and running, using GitHub Pages, so we can all look at the current state of the developed code, at any stage in the project.

I know that articulating overall goals and milestones is difficult, so I'm hoping that we can discuss them here and, as a result of that process, have both a better understanding of what we're working on, and why it's important.

[windoverwater]

@stratofax Appreciate the feedback! The immediate goal is to more or less complete the original democracy festival project goal(s) of last spring. The MVP is along the same lines as that plan as well - for a participant in the fair to demo the VTP technology on their personal phone by executing the five user stories described in the design notes. Basically, they need to be able to vote, inspect their receipt, and tally the election on their phones.

Strategic disclosure - I don't know if it is worth it at this point, so please proceed with caution. FWIIW I have other reasons that help make it worth it for me.

Regardless, getting some kind of CI/CD pipeline up and running would be great! That seems like a great idea 👍 if you want to work on that.

[stratofax]

@windoverwater I created an Issue, #4, so we can track the status of the CI/CD pipeline. I added the Issue to your existing Project as well.

In addition, I opened a new discussion, #3, so we can work on a concise mission statement for the README file.

[windoverwater]

@stratofax Here is my current thoughts on the target goals for milestone3 (milestone2 finished 8 days late - didn't take into account a week of vacation and the 'state' of the backend). NOTE - disclaimer - I have never done this before so this is a SWAG as to how to best stitch together client html/css/javascript, a FastAPI uvicorn middle layer, and a python backend. Would like to talk about it when we meet this week.

1. user lands on welcome page: http://127.0.0.1/index.html

• served as a static uvicorn page
• clicks a button which:
  • optionally passes the address as a parameter (if there is enough time at end to add address handling to the demo)
  • goes to http://127.0.0.1/voting.html (in the existing tab)

2. user lands on http://127.0.0.1/voting.html

• served as a static uvicorn page
• reads an optional address parameter
• will fetch a (possibly address specific) blank ballot via http://127.0.0.1/get\_blank_ballot endpoint
  • this endpoint is altered so to not require a vote_store_id GUID (note - the GUID workspace is not created until the ballot is cast)
• completely handles the voting process by changing the DOM, not by loading/reloading a new page per contest
• if voter spoils ballot, voter returns to index.html (in same tab)
• if voter casts ballot, calls the http://127.0.0.1/cast-ballot endpoint supplying cast_ballot json
  • this (existing) endpoint is altered so that it:
    • creates the vote_store_id GUID first
    • then calls the backend to cast the ballot
    • if successful returns the GUID and the receipt
• note - the existing http://127.0.0.1/receipt.html (static) page is deleted and the javascript moved to the voting.js page so that voting.js also handles displaying the receipt by re-writing the DOM (the same document layout is already used by receipt.html. In fact, every page employs the exact same html stubbed out DOM).

3. while viewing the receipt contest, user can click links/buttons to create new tabs for the contest-cvr, verify, and tally pages
4. contest-cvr - http://127.0.0.1/contest-cvr.index?GUID (with endpoints having the GUID embedded in the path)
5. verify-ballot - http://127.0.0.1/verify-ballot.html?GUID (ditto)
6. tally-contest - http://127.0.0.1/tally-contest.html?GUID (ditto)

[stratofax]

@windoverwater I'm looking forward to working with you on Milestone 3 with you later this week! I can post a more detailed response over the next few days.

[windoverwater]

@stratofax Just a few FYI's. I tweaked some of the readme's prior to a ad-hock demo I gave on Thursday (2 days ago) - just a small step at making everything more welcoming and not outright mistruths. We probably should have GH to discuss. Also tried to address the issues (that I wrote down) from your test run a few days ago. A significant 'bug' discovered regarding prep for the Thursday demo is that on a touchscreen device, the 'touch' events are all different from that of mouse/trackpad 'clicks'. Ugh. Ended up adding https://github.com/Bernardo-Castilho/dragdroptouch as a solution which caused a negative UX artifact on the ballot receipt page. Hacked a solution to that which seems to work. However, if the 'new' vs 'not new tab' UX question gets answered differently than how it works now, the hacked solution may be able to be deleted. Regardless, the hack may not be sufficient - TBD.