[RFC] How to handle workflow selection?

[rogerhutchings]

In #228, I wrote an ADR on how to handle workflow routing, but a lot of the conversation revolved around how we choose a workflow for a given user; this issue is to continue that conversation.

It should lead to an ADR on how to handle workflow selection.

[srallen]

PFE's current order of workflow selection preference:

1. Load a workflow by query param if param is present and the project has Allow workflow query enabled and the workflow is active. Notes from Nature uses this.
2. Load a workflow by query param from the project builder using the view workflow button if you are the owner, collaborator, tester or an admin. This removes the active: true from the API call.
3. Load the workflow in the user's project preferences { preferences: { selected_workflow: '1234' } } and if it is active. This is set when a user selects the workflow to classify on (if the project has enabled this) or if the user is promoted and the select to classify on the new workflow offered to them. This ensures the same workflow is loaded on subsequent sessions.
4. Load the workflow in the user's project preferences { settings: { workflow_id: '1234' } } property and if it is active. This is how Gravity Spy pushes user workflow level promotion
5. Load the workflow in the project's default configuration and if it is active
6. Load a random active workflow linked to the project

We should define how this will change with the routing ADR in mind, but generally we will likely still have an order of preference.

[srallen]

This impacts home page design because with current project builder/PFE configuration it is possible to have a scenario where a project has multiple active workflows, does not have a default, and does not allow a volunteer to choose which workflow to work on. This is effectively the project setting its preference to the last fallback option of random selection for the initial visit.

[beckyrother]

Why and how does this happen? Is it possible to force a project to chose a default workflow?

[srallen]

@beckyrother, We have a list of project now where we can investigate why they might be using this configuration:

• Parochial Archive Project in Rome
• Galaxy Zoo Mobile - Might be a workaround for mobile use
• Anti-Slavery Manuscripts - CFE, so workflow selection does not apply

I think this list might have been greater in the past because when the new project builder launched, only two kinds of workflow selection was supported: Allow volunteer to choose or random selection.

With the addition of several new features, we had to start keeping track of which workflow a user worked on last, which the project wants them to use, setting a default, etc. This greatly has complicated workflow selection and has meant over time that very few use random selection at all anymore.

It should be noted, that forcing volunteers to get a random workflow was a feature requested really early on in the development in PFE: zooniverse/Panoptes-Front-End#189

Question 2: Can we have a single button on the project landing page that goes to 'classify' without specifying workflow (and so get a random workflow)?

Right now there's a button for each workflow on the project landing page. But I don't want users to have the option of choosing different workflows.

This request didn't really explain why the project wanted this, but there may be a valid research reason why this might be wanted, although, with the current rarity, we may want to decide against supporting it. We need more information about potential use of random selection.

[beckyrother]

Thanks @srallen. I'm receptive to the idea of random selection IF there's a good reason for it.

In general randomization isn't a great user pattern as it makes it difficult for the user to get back to a specific workflow. Additionally, if someone really enjoyed one task on a project and wanted to see what else they could help with, they wouldn't be able to see other available workflows or dive deeper into the project in the way they might if they were able to see and participate in multiple workflows.

[srallen]

@beckyrother based on the discussion on slack, the A/B split use case is one I think we might have to support. There have been two projects that have run splits that had to do with assigning a workflow to a volunteer to work on and Lucy says that there's interest to do an experiment like this again in the future. I realized thinking this through that if we listed the available workflows on the homepage, then that might break the experiment and/or causing a confusing UX where the volunteer tries to select to work on workflow A, but they've been assigned to workflow B and workflow B loads with the classifier.

In general I would agree that randomness is bad UX, however, it doesn't seem like many projects are picking a configuration scenario that I described above. The projects we know about (which have been revised down to 3 and only 2 are relevant) aren't in the A/B split use case scenario and we could choose not to support randomness for those reasons, but I think we'll have to for splits.

[beckyrother]

Ok, thanks Sarah. Maybe there's a way to allow only those projects to continue with random workflow selection while preventing that from being an option in the future? Unless the research team has a Very Good Reason

[srallen]

Ok, so let's say we switch to a design that does the following on the homepage:

If there are multiple active workflows, give volunteers the options to choose displaying each workflow by display name.
If there is only one active workflow, only show the single workflow by display name
If there are multiple active workflows for splits, only show a single button that says get started

Does only showing 'get started' for splits give away that an experiment is running? What effect would this have?

The above design would basically switch the configuration to be that all projects default to allow volunteers choose which workflow to work on, and then we only disable this if there's a workflow assignment split running if we decide to go this direction.

[beckyrother]

What would be the ramifications for showing the workflow name even if there is randomization?

[srallen]

Ah, so only show the workflow button with display name of the one they're assigned to via the split (after we know if there is a split)? I'm not sure if there would be any, but to guarantee this, we'd have to request for splits and wait for the response before showing any workflow buttons to choose from, which we'd have to do anyway. I like this idea 👍

[srallen]

At some point in the near future, we should make a flow chart, lol

[beckyrother]

Yeah, and I like the loader! This way it's always consistent

[eatyourgreens]

Should we move workflow selection and loading out of the Classifier component itself? At the moment I think we have code that reacts to changes in the workflow and resets the classifier accordingly, but it occurs to me that a change of workflow is not something that generally happens during classification. If I change workflow, I'm probably going to reload/remount the Classifier component anyway, so observing workflow changes is pointless.

I'm thinking maybe use a provider to select and load the workflow, then pass it down to the classifier as a prop maybe:

<WorkflowProvider>
  <Classifier/>
</WorkflowProvider>

then we can export the decorated and undecorated Classifier, where the decorated Classifier is essentially the same component that we're loading into the project app at the moment.

export default withWorkflow(Classifier)
export { Classifier }

My thinking is that the undecorated Classifier would be much simpler to mock and test, and is only responsible for annotating a queue of subjects for a single workflow's tasks.

[srallen]

We think we should deprecate random workflow selection as a strategy as there hasn't been a clear use case presented to continue to support it.

[srallen]

Implementing the strategies we will use and moving the UPP request to the project app time estimate: 4 weeks

[eatyourgreens]

#1793 adds an optional workflowID prop to the classifier, so that we can specify which workflow to load. We could make that prop required, in which case it's the responsibility of the project to choose a workflow and pass the ID into the classifier. The classifier itself would have no opinion about how to select a workflow (from the URL, from saved preferences, by assignment etc.)

[beckyrother]

Not sure if this is the right place for this, but adding this InVision link showing workflow selection options.
Workflows that allow for subject or subject set selection are separated from random workflows. These categories are only shown in a workflow applies to that category

https://projects.invisionapp.com/d/main#/console/12924056/432001828/preview

[srallen]

Related ADR need a superseding ADR: https://github.com/zooniverse/front-end-monorepo/blob/master/docs/arch/adr-18.md

We're dropping random selection.

[srallen]

I've documented the final discussion on how this works and opened up ADR 34