Classification started_at is off by hours (or days) for continuous sessions in the same tab.

[eatyourgreens]

I looked back through my classifications on my admin page (https://local.zooniverse.org:3735/admin/users/149?env=production) and classification 596255757 was started at 12:46:12 but finished at 17:32:48, which is the time that the classification was saved to Panoptes. There's a bunch of classifications that were submitted in between, around about 13:30, each taking roughly 30 seconds or so.

Originally posted by @eatyourgreens in #6441 (comment)

Classification 596255757, shown above was started at about 17:32:00 and submitted at 17:32:48. The timestamp recorded on the classification has it starting at 12:46:12.

To reproduce this:

1. Classify a few subjects.
2. Leave the tab for a while.
3. Return to the tab and classify the subject that's already loaded.

In the case of the classification that's shown in the screenshot, I triggered this bug by doing some classifications on Squirrel Mapper in the morning, then returning and continuing to classify in the afternoon, creating one classification that's recorded as being ~5 hours long.

Classifications start when the subject loads, which will be the end of your previous classification session in this case. It would be more accurate to record the time that the first annotation is created or updated. You can detect when a volunteer begins to interact with an annotation by tracking when annotation._inProgress changes from false to true.

front-end-monorepo/packages/lib-classifier/src/plugins/tasks/models/Annotation.js

Lines 33 to 39 in b7b228d

	.actions(self => ({
	update (value) {
	self.value = value
	self._inProgress = true
	const { authClient } = getRoot(self)
	authClient?.checkBearerToken()
	}

Talk discussion here:
https://www.zooniverse.org/talk/17/3490049?comment=5742039

[eatyourgreens]

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.

[eatyourgreens]

PFE also sets started_at when the subject first loads, so it should be possible to reproduce this bug there too. That probably accounts for the majority of the bad data that Peter is dealing with.

[eatyourgreens]

Here's the equivalent issue and PR for PFE:

• Classification started_at can be off by hours or days Panoptes-Front-End#7215
• fix(classifier): set started_at timestamp when annotation starts Panoptes-Front-End#7216

[goplayoutside3]

Thank you for documenting your findings and proposing the code changes in #6449. You noted some of the website’s user stats behavior already, but I’m going to write it out here for clarity so we’re on the same page.

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

Where to go from here:
We cannot prevent volunteers from leaving tabs open or beginning a classification, walking away, and coming back to complete it later. However, in FEM specifically there could be improvement to the Done & Talk button to guarantee classification submission to Panoptes immediately upon clicking that button. I do want to implement the ability to right-click Done & Talk and open the subject’s Talk page in a new browser tab. This is how PFE’s classifier works and it should have been the default behavior of FEM’s classifier too. If you’d like to subscribe to Issue #3024 or contribute code to be able to right-click, it is on the docket to be implemented soon.

[eatyourgreens]

I do want to implement the ability to right-click Done & Talk and open the subject’s Talk page in a new browser tab. This is how PFE’s classifier works and it should have been the default behavior of FEM’s classifier too.

Sadly, it doesn't work in PFE either. Right-clicking on a link and choosing an option from the context menu won't fire an event that you can handle in React, or at least it didn't when I opened zooniverse/Panoptes-Front-End#6129. This means that classification.metadata.finished_at works fine in the monorepo, but isn't recorded if you right click and open in a new tab in PFE. It's a shame because you're right that Done & Talk absolutely should be a link, if only so that it works properly for visually impaired volunteers, and that was how I originally implemented it in PFE.

Here's some context for the button:
https://github.com/zooniverse/front-end-monorepo/pull/516/files#r266525303

If you’d like to subscribe to Issue #3024 or contribute code to be able to right-click, it is on the docket to be implemented soon.

Maybe. Thanks for the invite, but I'm pretty much fully booked with Caribbean disaster mapping through early 2025. Since Guillermo Rauch's enthusiastic endorsment of the US election results, I'm also making a conscious effort to avoid Next.js work. I think Lea Verou's right here, that this will be a tipping point for the relationship between small organisations (and indie developers) and Vercel/Next.js.
https://twitter.com/LeaVerou/status/1854416736302268789

I'm automatically subscribed to #3024 as the original author/owner of that issue.