RFC: Integrating project links into the Classifier component #2165
Replies: 6 comments 36 replies
-
|
Going home could be done by: |
Beta Was this translation helpful? Give feedback.
-
|
The problem with the full page refresh is you run I guess there's still the overhead of authenticating again, which you wouldn't have with a client-side transition. I haven't thought too much about it, but there might be other client-side state that's lost when the store is rebuilt. |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about it a bit more, |
Beta Was this translation helpful? Give feedback.
-
|
We've discussed stashing snapshots of the store into session storage / local storage / indexedDB and rehydrating the store as needed for future features, primarily when navigating between Talk and the classify page, so I think that'd be a viable solution here too. We could think about doing this in memory server side too? Not sure what the mechanisms would be for that exactly. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, we can reconstruct that since the Project resource is stored which includes its slug, |
Beta Was this translation helpful? Give feedback.
-
|
front-end-monorepo/packages/app-project/pages/_app.js Lines 36 to 37 in 582e6e4 |
Beta Was this translation helpful? Give feedback.
-
|
Another possible pain point is the 'Subject Selection Modal' link, which relates to #2166
You can open subject set selection by linking directly to a workflow eg. https://www.zooniverse.org/projects/msalmon/hms-nhs-the-nautical-health-service/classify/workflow/18109 You can also open it by setting state in the Classify page component (or the Project Home component.) Subject selection can similarly be triggered by URLs or by setting state within the project app. Ideally, the Classifier doesn't know anything about the page that it's embedded in, but here we've got a control for a feature of the project app. |
Beta Was this translation helpful? Give feedback.
-
|
A callback is probably the cleanest solution. The accessible version would look something like: function onClick(event) {
const isCmdClick = event.metaKey
if (!isCmdClick) {
event.preventDefault()
props.onSelectSubject(event)
}
}
<a onClick={onClick} href={`/projects/${project.slug}/classify/workflow/${workflow.id}/subject-set/${subjectSet.id}`} >
Subject Selection Modal
</a>The link would be accessible in any assistive tech (screen readers, switches, Dragon etc.) The downside is that the subject set page URL is embedded in the classifier. |
Beta Was this translation helpful? Give feedback.
-
|
That link could also be a button, and still be accessible. We should be careful to distinguish between links and buttons in the visual design. At the moment, it looks like a link (to me.) |
Beta Was this translation helpful? Give feedback.
-
|
Could the callback just call a function in the project app that would open the modal and keep the project app responsible for updating the URL if something new is selected? I don't think this should directly be a link because someone may change their mind and want to cancel. |
Beta Was this translation helpful? Give feedback.
-
|
That's a good point. The workflow/subject set selection modal is deliberately designed so that it can't be closed once opened. I guess if it was a link, then you could use the Back button to cancel the action but I'm not sure about controlling modals with URLs either. The login and register forms open via URLs, which means they can be opened even if you're logged in. |
Beta Was this translation helpful? Give feedback.
-
|
That modal design makes sense if the only way to reach those is upon first page load, but now they're not, so they need to be cancelable I think now. |
Beta Was this translation helpful? Give feedback.
-
|
Now that #2132 has merged, you can try out subject selection at https://fe-project.preview.zooniverse.org/projects/bogden/scarlets-and-blues/classify/workflow/17077 The Minutes workflow has subject sets that are indexed in Datasette. The classifier hasn't been updated to use indexed selection yet, so it will crash after you select a subject. |
Beta Was this translation helpful? Give feedback.
-
|
Somewhere along the line, I've accidentally broken that URL. It's fixed in #2169. |
Beta Was this translation helpful? Give feedback.
-
|
If we pass in the router as an external dependency, then accessible routing might look something like this (without having a direct dependency on /*
The router could also be injected into the store, like the API client is.
*/
const { router } = props
function onClick(event) {
if (!event.metaKey) {
event.preventDefault()
const { href } = event.target
router.push(href)
}
}
<a href="/some/url">Client-side link in the parent app</a>Marcy Sutton did a bunch of user-testing of accessible client-side routing, for Gatsby, in 2019. That's worth reading because any solution we adopt will have to work with assistive technology. Gatsby published details of their React implementation in February last year. |
Beta Was this translation helpful? Give feedback.
-
|
Taking a step back, why are we directing users back to the home page to begin with? Workflow selection can be done on the classify page. |
Beta Was this translation helpful? Give feedback.
-
|
Changing |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it's hard to keep track of what you're taking about here. Anchor link for project home page is fine with props to instruct how to build the link (though my question stands about why are we linking to the home page). Opening a modal is something I'm saying to do by callback. |
Beta Was this translation helpful? Give feedback.
-
That's a really good question. My ideal solution to handling links inside the classifier would be: don't have links to other pages inside the classifier. I'm not sure this dialog box needs a link to the home page either. All the other actions that it initiates could be handled by buttons, which change either the classifier state or the state of the parent page. Changing the state of the parent page could easily be done with either a callback from the classifier or the classifier sending a notification (or event) to its container. |
Beta Was this translation helpful? Give feedback.
-
|
@snblickhan do you have any insight why the design for the modal for when a subject has been retired has a link to the home page? If I had to guess, it would be because Becky was thinking that this is where workflow selection happens, but we now support this happening on the classify page directly, so navigating back to the home page is not necessary. Selecting a new workflow from on the classify page context has been a long requested feature, especially for Gravity Spy just for context, so staying on the page for this interaction I think is generally preferable. If there's another reason to go to the home page, that would be helpful for this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Having a decision about this soon would be beneficial to me as well. I'm getting closer to the point that I need to wire up #2143. There are two ways I'm thinking of doing this:
Users will always be able to cancel the prompt and have no routing or load of new workflow take place. |
Beta Was this translation helpful? Give feedback.
-
|
I think you'd get a clean separation of concerns with a system where the classifier handles the business logic of workflow assignment, but has no opinion about the mechanism by which a volunteer chooses a new workflow. When a new workflow becomes available, the classifier could notify its container through a callback, or by sending a notification message, with a payload containing the new workflow ID. In the project app, the Classify page could respond to that notification by showing a link to the new workflow in a popup (this is more or less how workflow selection works for Engaging Crowds.) Volunteers can either click on the workflow link, to go to the new workflow page, or cancel the popup, to continue as they were. When the workflow ID in the window location changes, client-side, the classifier's A second option would be to have the popup in the classifier itself, with the classifier notifying the project after workflow state updates in the classifier store. The window location could then update to reflect the new classifier state. In that case, the classifier is now deciding how you choose a new workflow (via a dialog box), which makes it less reusable as a component in my opinion. In that case, I think it would be difficult to communicate the change of window location to anyone using assistive technology (see the discussion of accessible client-side routing that Gatsby tested with people who had a variety of impairments.) |
Beta Was this translation helpful? Give feedback.
-
|
The project app loads UPP when you log in. It's been at the back of my mind to add that to the project store, as front-end-monorepo/packages/app-project/stores/YourStats.js Lines 111 to 112 in 03b0c9a
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, I understand what I think the options are. What I was missing was that the project app is already loading up the UPP. I had forgotten that. I think we're at the point that a summary of the discussion here can be written up? |
Beta Was this translation helpful? Give feedback.
-
|
Ok, here's a summarization of where I think we are in this discussion Let me know if this is agreeable to everyone. Prompting a volunteer to work on something elseThe context is we have persistently had problems with volunteers continuing to work on workflows where classifications are no longer needed. We have an improved design of the banners that appear with subjects, however, there is still a need to more specifically prompt to do something else. Possible prompt triggersAll projectsThe project or workflow is entirely finished. Projects using ordered subject set selection (like Engaging Crowds)For humanities projects that follow the Engaging Crowds model subjects are ordered and can be loaded in the classifier regardless of retirement or already seen status. A subject can be loaded by way of a selection process provided in modal form on page load or by direct URL link. Workflow assignment (like Gravity Spy)There are projects who wish to assign workflows. Some wish to do it like Gravity Spy where user weighing is analyzed by previously submitted classification quality and access to more complex workflows are blocked by this analysis. Others may have some other determining mechanism. The assigned workflow is received by a workflow id set in the user project preferences. If a volunteer gets directly linked to a workflow they do not have permission to access yet, then this will prompt the workflow selection modal to open instead with a message saying it's not available to them yet. Proposed solutionsA variety of scenarios exist where different prompts should load:
All prompts should be cancelable to allow the project, workflow, and subject to continue to load for education, demonstration, and citation purposes. We might consider a future session demo and/or education mode for the classifier that toggles these various modals off for the session. General project applicationThis applies to all projects where the project or workflow may be finished. This check pauses the classifier from fully loading and waits for the volunteer selection on what to do? Ordered subject set applicationThere is a provided design for prompting when the subject is retired and already seen, but needs several modifications:
Workflow selection applicationCurrently the user project preferences is being loaded twice. Once by the project app and once by the classifier. This is unnecessary. We should refactor these so that it is only loaded by the project and a callback is passed by prop to the classifier to make updates to the UPP as needed for tracking seen states for tutorials and mini-courses. The workflow assignment modal prompt will move to the project app and handle routing. The triggering of this prompt is still TBD and we may implement web sockets or a polling mechanism. There is already a callback for the project app to keep track of classification counts for the session so if we use polling, this can be easily implemented. For websockets, we need to add this anyway at some point to wire up talk notifications for the header in the project app, so could leverage this if Sugar is updated for this functionality. |
Beta Was this translation helpful? Give feedback.
-
For projects with indexed subject sets, we'll know the subject's classification status before the classifier loads. When you pick a subject to work on, the classification status is displayed alongside the link to the subject. See #1955. |
Beta Was this translation helpful? Give feedback.
-
|
@snblickhan That's a good point about completed subject sets. At the moment, we can tell when a set is retired. In fact, I think we don't list retired sets because Cellect only sends back sets that are incomplete. For incomplete sets, I don't think we have a good way of detecting that a volunteer has completed that set (but not retired it), short of paging through the entire set and checking the user-seen status for each individual page. |
Beta Was this translation helpful? Give feedback.
-
|
If the subject is finished, do we want to assume they want to continue in the same workflow if there's more than one available unfinished? Depending on availability, we may want specific options to be displayed, i.e. "Select a new workflow", "Select a new subject set", etc. So I don't see a whole lot of difference in the UI presentation that we would have if it's just the subject that is finished vs the subject set, the variable will be in what is still available. |
Beta Was this translation helpful? Give feedback.
-
@snblickhan can confirm, but my understanding is that we agreed it's a separate feature and would be implemented somewhere else around the classifier and specifically not in the task area. Getting a new subject is something that is independent from the retirement or already seen status, so shouldn't be coupled to this. |
Beta Was this translation helpful? Give feedback.
-
|
To clarify:
|
Beta Was this translation helpful? Give feedback.
-
For Engaging Crowds, we want to block the task area when you load a subject that' you've already classified, or which has been retired. Instead of classifying the subject, you'll be given the option to return to the project home page, navigate to the next (or previous) subject, or choose a new subject to view (or classify.) See #2027 and the designs in the comments.
The classifier could import
next/link, then write each of the links in that popup as something like:That would make the Classifier component implicitly part of the project app, so it couldn't really be published and used as a self-contained component.
The router could be passed to the Classifier as a prop, like the client is now. Routes could then be handled by the store but this still ties the Classifier component to the specific routing of the NextJS project app.
I'm looking for a way to embed that popup in the Classifier component, without explicitly adding the project app routes to the Classifier. I wondered if anyone has any suggestions?
Beta Was this translation helpful? Give feedback.
All reactions