Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Classification started_at can be off by hours or days #7215

Closed
eatyourgreens opened this issue Nov 8, 2024 · 1 comment
Closed

Classification started_at can be off by hours or days #7215

eatyourgreens opened this issue Nov 8, 2024 · 1 comment

Comments

@eatyourgreens
Copy link
Contributor

eatyourgreens commented Nov 8, 2024

Expected behavior

Classification started_at times should record when a volunteer starts the first workflow task.

Current behavior

From Peter Mason on Talk:

I have seen differences in the start time (started classifying by the volunteer) and finished times (completed classification received by zooniverse) of many hours, even days.

Steps to replicate

This is pretty easy to replicate if you classify regularly on the same workflow over several days. Do some classifications on a workflow, leave the page for a few hours or days, then return to the same tab and continue classifying. Your first classification in the new session will start when your previous session ended (several hours or days ago.)

Additional information

Classification start times are set when a subject first loads in the browser. If you leave the classify page and return, the started_at time will be off by however much time elapsed between loading the subject and returning to classify it.

function createNewClassification(project, workflow, subject, goldStandardMode, lastInterventionUUID) {
// Record whether this subject was received from Sugar or from the Panoptes API.
const source = subject.metadata.intervention ? 'sugar' : 'api';
// Delete the metadata key because we don't want volunteers to see it.
subject.update({ 'metadata.intervention': undefined });
const newMetadata = {
workflow_version: workflow.version,
started_at: (new Date()).toISOString(),
user_agent: navigator.userAgent,
user_language: counterpart.getLocale(),
utc_offset: ((new Date()).getTimezoneOffset() * 60).toString(), // In seconds
subject_dimensions: (subject.locations.map(() => null)),
source
};
// record if this classification had an intervention payload directly before it
if (lastInterventionUUID) {
newMetadata.interventions = newMetadata.interventions || {};
newMetadata.interventions.uuid = lastInterventionUUID;
}
const classification = apiClient.type('classifications').create({
annotations: [],
metadata: newMetadata,
links: {
project: project.id,
workflow: workflow.id,
subjects: [subject.id]
}
});

This issue is the same issue as zooniverse/front-end-monorepo#6447. I've tried to fix it in zooniverse/front-end-monorepo#6449 by updating started_at when a volunteer starts to annotate a subject eg. by selecting a radio button for a question task or clicking a choice button for a survey task.

An alternative strategy might be to reload the subject queue, or reset the started_at time, if the queue is stale after a visibilityChange event..

@goplayoutside3
Copy link
Contributor

I also commented on the linked FEM Issue, but copying here for clarity:

The frontend components that display hours a volunteer spent classifying use session_time from ERAS. If the classification is stored in Panoptes, session_time is calculated by the classification’s finished_at - started_at metadata. When Ouroboros classifications were ported over to Panoptes, steps were taken by the backend team to account for the lack of finished_at in the metadata.

session_time is where a time-limit cap is applied if the two properties were recorded several hours apart or even days apart. The time-limit cap was decided specifically with the new user stats website features in mind. We decided it was better to overestimate from a place of trust than underestimate time spent classifying in the cases where finished_at - started_at is large.

Decision:
started_at will continue to be recorded on subject load. Changing started_at to the time of first annotation misses the volunteer's time spent analyzing the subject before making an annotation, referencing the tutorial, and watching the flipbook or video subjects. For some projects annotation begins with interaction with the subject through drawing while for others it begins only once a simple choice task is completed. started_at recorded on subject load is in line with “better to overestimate from a place of trust than underestimate”.

@goplayoutside3 goplayoutside3 closed this as not planned Won't fix, can't repro, duplicate, stale Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants