Sketching out the platform architecture and experience

[markwhiting]

We aim to build a platform to measure common sense from open participation on the internet. For now we will assume that the instrument and basic flow of the experiment is consistent with our prior common sense work — 2 main questions (I agree, I think most others agree) with some supporting ones (why do you agree, etc.) for each of a number of statements, potentially followed by other individual property questions (demographics). After completing this, participants will be given the option to see and share their results.

Statement selection

To compute PQ-commonsense, we will aim to have a portion of the corpus that is collected for every participant. We will use a sampling approach to determine which other statements a participant should respond to. We have not yet determined the selection of the PQ-commonsense statements or the sampling approach but are designing the system under the assumption that those pieces will be required and will be finalized during testing.

• Determine total number of statements to require
• Select statements everyone will answer
• Statement sampling algorithm #25
• Determine protocol for statements beyond the required ones, e.g., half are preferred and half are sampled

Experience

Here's is a visual flow of a user's experience on when joining the platform, and the basic application functions that support user interaction:

Here is a figure showing the visual layout of the survey page at this time:

Architecture

We are developing this as an application that can be easily deployed to EC2 or other bare metal, or container compatible server platforms — hopefully avoiding some of the issues we face in Empirica deployment. We are using Typescript with React as the front end library and Express as the server, and a relational database design.

Views

The main views are:

• Landing page #20
• Consent page #19
• Statement survey
• View for results and sharing #21
• Finalize account management #22
• Page for adding statements #23

We are designing these to allow for localization based on user language preferences.

Authentication

To avoid loosing users early on we will not ask them for login until after collecting some data, and we will not require login at any point. Instead, (as shown above) we will establish a session ID once they start the experiment and use this as a consistent identifier. If they later decide to establish an account, we will bind these together and allow them to return to answer more questions and upload statements.

• Session ID pre-login #26
• Login

Data model

Because we have a large number of users, a large number of statements, and are potentially a large number of languages, we are designing basic tables around the following concepts:

1. users — users and associated individual data
2. statement prototypes — statements and their properties
3. statement-language instances — versions of statements in particular languages
4. statement-user responses — users' responses to statements

Because these are long tables with relatively consistent formats, we will design for a relational, SQL based database for integration with platforms like AWS RDS.

Operations

We will use Github Actions for testing and deployment to AWS tooling. We will aim to test on commit and have near continuous uptime — so that the experiment can take participants at any point.

[markwhiting]

April 26 Update

Session ID is now functioning (#26), and we are aiming to have a testable platform by a May 10 milestone. We will use that to test our assumptions and answer questions (#31), and then push for a secondary milestone for launch.