Platform(s): all
URLs (aka web addresses) of any pages, if relevant:
Description of need:
People who do a lot of identification, and in particular those of us who do this in a systematic fashion for a particular region/taxon, often maintain a “queue” of observations that they are trying to work through. It can often be difficult to keep track of which observations we have successfully delt with, which observations we need to revisit (because we are trying to get additional information), and which ones we want to ignore completely. The “reviewed” checkbox is very helpful for this, as it can be set/unset on the thumbnail view, there is a “mark all as reviewed” button, and because observations can be EASILY filtered based on reviewed = yes/no/any. However, identifiers often need finer granularity to manage their queues, and often have to resort to additional “hacks” to obtain it (eg. creating special projects, adding fields that only have meaning to them, or using “favourites” for observations to be revisited). Because these workarounds are not as easily accessed as the Reviewed checkbox, it makes for an awkward and inefficient workflow.
Feature request details:
Currently, the Reviewed checkbox is binary, where Reviewed = yes or no
It would be extremely helpful to identifiers if Reviewed could be transformed into a multi-state Status. For a start, I suggest this status have 4 states of the form:
Status = Reviewed, Queue1, Queue2, None (ie. unreviewed)
(NOTE: my original suggestion was for the states to be “Reviewed, Watch, Ignore, None”. I’ve replaced Watch and Ignore with “Queue1” and “Queue2” to cover a more general use case)
All existing observations that have Reviewed = Yes (for a particular user) could be mapped to Status = Reviewed. Those with Reviewed = No could be mapped to Status = None. In this way, the feature has no (functional) effect on existing observations. To all intents and purposes, it will look as though no change was made.
The Status on individual observations could be set either via a drop-down (replacing the current checkbox), or by adding additional checkboxes (which would be mutually exclusive). The current checkbox can be set very quickly - whatever new mechanism is chosen should have equivalent functionality (if possible). On the thumbnail page, the “Mark all as reviewed/unreviewed” button would need to be changed into something new that gives access to the multiple status options (add buttons for “Move all to Queue1” and “Move all to Queue2”?) For filtering purposes, the current “any/ yes/no” options could be changed to “any/reviewed/queue1/queue2/none”. In this way, identifiers could easily manage separate queues of observations that they have identified, those they need to revisit as one part of their workflow, and those they need to revisit as another part of their workflow (or ignore completely).
Currently, when observations with Reviewed=yes are displayed on a thumbnail page, the images are grayed out. This can be problematic when one is trying to see the images, and would pose a problem if the status is no longer binary. In other words, how do we differentiate the Reviewed from Queue 1 and Queue 2 observations when the “any” option is selected for filtering. One option might be to associate a distinct colour with each state:
Reviewed: Green Queue1: Yellow Queue2: Red None: no colour
Perhaps the colour could be displayed as a border around each thumbnail image, or a coloured shape superimposed on one corner of the image. If there are concerns about users with CVD, the status could be indicated using a method that does not involve colour (eg. distinct border patterns on thumbnail, or distinct shape icon superimposed in corner of thumbnail image).
One option might be to simply use the colours as the status (ie. Status = green, yellow, red, none). This might be preferable as it allows individual users to associate their own meanings with each colour. But given that there are currently users who associate “watch/revisit” with the favourites function, users are clearly able to adapt different meanings as needed.
If there is reluctance to “tamper” with the existing REVIEWED function because it works, and is widely used, and any change would require extensive regression testing, perhaps there may be some way to augment it with an auxiliary status checkbox to provide the additional functionality. This will necessarily be less elegant, and there may be issues with interactions between the auxiliary status and the reviewed checkbox that could be tricky to resolve. One simplification might be to link the auxiliary status with REVIEWED such that setting either Queue1 or Queue2 automatically sets REVIEWED at the same time (similar to how adding an ID automatically sets reviewed to YES). This is intuitively satisfying - if you decide to move an observation to one of your queues, it implies that you have reviewed it (at least to some extent). Again, if implemented as something separate from the current Reviewed checkbox, colors could be used in addition to or in place of the named states of Queue1 and Queue2.
If the only viable option is to add a single binary auxiliary status (ie. simply mirroring the existing “Reviewed” checkbox), I would recommend that it have a generic name that does not imply any particular function (just call it “Queued”?). Giving the new checkbox a generic name would allow each user to associate their own meaning/function with the checkbox.
In summary, I would suggest the following 3 options for the feature in order of preference:
- convert the existing Reviewed checkbox into a multi-state status (reviewed/queue1/queue2/none)
- leave reviewed checkbox as is, but augment it with an auxiliary multi-state status (queue1/queue2/none)
- leave reviewed checkbox as is, but augment it with an auxiliary binary checkbox (queued)
