ADR-18 - Workflow routing

[rogerhutchings]

Following chat in #1077 (comment), this adds an ADR for how we handle workflow routing. This was done in a bit of a rush, so comments welcome

cc #806

[eatyourgreens]

When not logged in, /classify should take you back to the current workflow in the MST store eg. when using the project navigation to navigate between Talk and the classifier.

[rogerhutchings]

So with the caveat that there's going to be an unavoidable full-page refresh in navigating between Talk and Classify, we're going to need to start storing some MST data on the browser. I'll add an edit to reflect this, but with PHT being a single workflow project it wouldn't need to be done at the same time as the PR that implements this change - sound okay?

[srallen]

I agree, that's a separate issue. One where we would leverage stashing a snapshot of the store in the browser's local storage or indexedDB and load it back up when users navigate between Talk and the classify page.

[eatyourgreens]

The store could be used to get the current workflow for all classifiers, with user prefs to persist settings across login sessions. That would greatly simplify the logic.

[srallen]

I have a few more inline comments.

[shaunanoordin]

🎏 Just to flag a quirk about the WildCam Lab Assignments:

• WildCam Lab Assignments have URLs that look like... https://www.zooniverse.org/projects/zooniverse/wildcam-gorongosa/classify?workflow=8074&classroom=1
• The classroom=true flag exists to override the standard "can a user select this workflow?" rules.
  • For example, WildCam Gorongosa (the project) doesn't actually allow workflow workflows to be selected by the user. (Presumably because if it did, it might end up auto-listing a few hundred potential workflows/classrooms on the WildCam Gorongosa Zooniverse.org project page.)
  • Going to https://www.zooniverse.org/projects/zooniverse/wildcam-gorongosa/classify?workflow=8074, without the classroom flag, would instead silently load the default workflow 338 instead. (The URL still shows 8074, which is confusing AF.)

Whatever the shape of the new workflow routing looks like, WildCam Labs can be modified to adopt it. However, this WildCam Labs scenario does show an edge case where an "I know what I'm doing, I really want to select this workflow, for reals" flag might be needed.

[shaunanoordin]

Query: does this ADR plan to address what happens when a user types in an invalid workflow choice?

What I'm reading:

• this ADR explains what happens what to do when a user visits the Classifier with no specific workflow set, e.g. zooniverse.org/projects/marvel/avengers/classify
• i.e. they should be redirected to/the browser history rewritten to a specific workflow (usually the default, or a workflow stored in the proj pref): e.g. zooniverse.org/projects/marvel/avengers/classify/workflow/101

My assumption:

• since we're talking about how we're allowing users to bookmark by workflow, we're also saying that a user can just type in a specific workflow into the Classifier, e.g. zooniverse.org/projects/marvel/avengers/classify/workflow/103, and the Classifier will select workflow 103. (Assuming it's a valid workflow.)

My question:

• what are our actions when the user specifies an invalid workflow? e.g. if zooniverse.org/projects/marvel/avengers/classify/workflow/404 doesn't exist?
• will the user be sent to the default workflow?
  • (As stated in comments above , this comes up as a bit of a problem if the default workflow is quietly selected instead of the specified workflow.)
• or will the user see an error message "Sorry, that workflow does not exist and/or you're not allowed to see that workflow, pls go to the project home page and try again" ?
  • I'm very much in preference for this latter option.

[rogerhutchings]

Yeah, I don't want any magic happening either. We should treat it like any other web resource; if you don't have access to a workflow due to permissions, you get a 401 / 403 error (depending on login status) for example. We can do some nice stuff with the error page depending on the error code though.

[srallen]

I'm supportive of an error message if you do not have permission to load that workflow with UI asking what you'd like to do. I think noting that is within scope of this ADR.

[srallen]

Re the classroom experience:

The classroom=true flag exists to override the standard "can a user select this workflow?" rules.

We will likely have to continue doing something like this, but I'd like to consider that when we fully begin implementing workflow selection strategies and note in an ADR for that specifically.

[eatyourgreens]

A lot of the conversation here is about how a workflow should be selected when the classify page first loads, if one isn't specified in the URL. At the moment, the classifier component handles selecting and loading a workflow. Are we proposing that the classifier component should be able to redirect the URL of the parent page, which requires it to have some knowledge of its parent and the window location? Or are we proposing that the responsibility for workflow selection should be moved out of the classifier component, so that the parent loads a workflow then passes it into the classifier?

[rogerhutchings]

Good point. I'm strongly in favour of passing in a workflow_id prop. If we're trying to create a reusable classifier, then we shouldn't be adding in a load of features that are only used on zooniverse.org.

[eatyourgreens]

The model I've been leaning towards with PFE is something like:

<WorkflowSelector>
  <Classifier/>
</WorkflowSelector>

or withWorkflow(Classifier).

See zooniverse/Panoptes-Front-End#5318 for an example.

EDIT: withUser(withWorkflow(Classifier)) might be better, since we can't load a workflow until we know whether or not there's a user session. So moving responsibility for the workflow out of the Classifier component would also imply moving responsibility for the user too?

[srallen]

I don't think workflow selection strategy should be in a component at all, classifier, HOC, or a parent. I think it should be a set of functions called by the workflow store. We could support a workflow id prop too like we do for projects.

[rogerhutchings]

@srallen and I also chatted briefly about spinning up a small API to handle workflow selection.

[rogerhutchings]

I think everything's been covered that needs to be in the ADR, with a future ADR to cover exactly how we do workflow selection. Is this now good to merge?

[eatyourgreens]

Looks good to me.

[srallen]

Yep feel free to change this to be accepted status in the ADR. I don't want to lose the comments and concerns about workflow selection functionality here, so let's open a discussion issue for it as a basis to write an ADR for that. #642 can be incorporated into an ADR for workflow selection. And I think #806 can close since we agree on architecture and can open specific issues on implementation.

[rogerhutchings]

closes #806