You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I most frequently enter judgments on a single query at a time. If multiple wells are open at once it's very easy to lose track of which query is being worked with so I close each query well once I'm done rating.
In order to close a query well, I need to scroll all the way back up to the query header (often 2-3 swipes), stop exactly on the header, and then click the collapse trigger (glyphicon-chevron-up)
Describe the solution you'd like
Currently the collapse trigger lives in the header (up top), but I tend to work my way down the results and then want to collapse the query once I've finished rating all the unrated. A second trigger (glyphicon-chevron-up) at the bottom of results (in the right side of the "Peek at..." div) would remove most of the excess scrolling from this task.
Describe alternatives you've considered (not exclusive) Alternative 1: If the query header for the query-results in view scrolls up out of the frame, freeze and stack that div under the quepid-header-div allowing the results for the query in focus to scroll underneath it. This way the existing collapse trigger is always in view. (Actually probably a more usable solution... just requires more work)
Alternative 2: Automatically collapse once no "unrated" results remain.
Bonus 3: Keyboard shortcuts (right-arrow open well, left-arrow close well, up/down focus on next result-or-query which is visible above focus (last action).
Additional context
Accelerating judgment entry in Quepid reduces the overall time needed to build judgments. Since the OSC engagement model pushes judgments as a prerequisite, the effort of building judgment lists is likely a major brake on engagement with OSC. Faster human automatons == more work for OSC :-)
The text was updated successfully, but these errors were encountered:
This makes a lot of sense, and does highlight that maybe we need a view to Quepid that is optimized for the rater experience ;-) But that is a whole nother thing! I'm hoping someone picks this issue up, or that i can get to it.
Is your feature request related to a problem? Please describe.
I most frequently enter judgments on a single query at a time. If multiple wells are open at once it's very easy to lose track of which query is being worked with so I close each query well once I'm done rating.
In order to close a query well, I need to scroll all the way back up to the query header (often 2-3 swipes), stop exactly on the header, and then click the collapse trigger (glyphicon-chevron-up)
Describe the solution you'd like
Currently the collapse trigger lives in the header (up top), but I tend to work my way down the results and then want to collapse the query once I've finished rating all the unrated. A second trigger (glyphicon-chevron-up) at the bottom of results (in the right side of the "Peek at..." div) would remove most of the excess scrolling from this task.
Describe alternatives you've considered (not exclusive)
Alternative 1: If the query header for the query-results in view scrolls up out of the frame, freeze and stack that div under the quepid-header-div allowing the results for the query in focus to scroll underneath it. This way the existing collapse trigger is always in view. (Actually probably a more usable solution... just requires more work)
Alternative 2: Automatically collapse once no "unrated" results remain.
Bonus 3: Keyboard shortcuts (right-arrow open well, left-arrow close well, up/down focus on next result-or-query which is visible above focus (last action).
Additional context
Accelerating judgment entry in Quepid reduces the overall time needed to build judgments. Since the OSC engagement model pushes judgments as a prerequisite, the effort of building judgment lists is likely a major brake on engagement with OSC. Faster human automatons == more work for OSC :-)
The text was updated successfully, but these errors were encountered: