Realtime commands

realtime_commands.md

Realtime commands for Zooniverse

1. Retire Subjects (individual/batches)
2. Assign Subjects to Users
3. A/B flights on subsets of Users
4. Interventions in user interface
5. Subject prioritization
6. Incentives/achievements (perhaps not realtime)
7. Responsive User training. Custom tutorial experience/feedback. When to end training?

See API request examples here.

1. Retire Subjects

The goal here is to be able to support CrowdSynth-like requirements - i.e. to dynamically request the retirement of a Subject or number of Subjects.

2. Assign Subjects to Users

We'd like to be able to say that a particular User should see the following XXX subjects next. Use case being - this person is the best individual to classify this Subject right now.

3. A/B flights on subsets of Users

Ideally we'd like to be able to dynamically create a A/B flights that might include changes in messaging, popup dialogues, interface changes, interventions (see #4).

4. Interventions in user interface

This seems like an extension of #3. Interventions might include:

• Interface changes
• Messaging
• Cutting off the User (!)
• Displaying personalised messages
• Emailing a person (opt in) to encourage them to return

5. Subject prioritization

Currently difficult to support - perhaps as simple as a dynamic group of Subjects thay should be considered a priority over others in the system. Note, an approximation to this could be to assign a group of Subjects to a large number of regular volunteers (see #2).

6. Incentives/achievements

Badges/recognition. Perhaps not something that needs to happen in realtime.

7. Responsive User training. Custom tutorial experience/feedback. When to end training?

The ability to respond to a User's behaviour (perhaps during a tutorial) and work out if they need more training or the tutorial can be ended. Also, the ability to respond to dramatic changes in User performance e.g. Simpson et al.

Outstanding questions

1. Will there be a single Redshift table per project or will we be trying to denormalize many projects to the same table?
2. What will the partitioning be of the message stream at the Kafka level? (should there be multiple client-specific streams)
3. What message stream will the general Zooniverse events appear in (such as login events, browser closing etc.)
4. Will Research Subscribers have to subscribe to multiple Kafka message streams? (i.e. will they have to listen into the Zooniverse events & a project stream)
5. How are users assigned to different experiments? For how long might a client have permission to a particular user? Would it matter if there were multiple A/B flights in action?

• Need to be able to register a 'flight' and request a number or fraction of users. Given some kind of access key.
• Then notify API when flight is ready to start.
• Zooniverse then starts assigning users to a particular flight (perhaps these messages come out in a general Zooniverse topic stream)