Classification started_at can be off by hours or days

[eatyourgreens]

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.

Panoptes-Front-End/app/redux/ducks/classify.js

Lines 48 to 75 in 131d101

	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]

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”.

[eatyourgreens]

This bug was mentioned on Talk, by a Year 10 student recording time for their Duke of Edinburgh award.
https://www.zooniverse.org/talk/17/3549090?comment=5827377&page=1