Stage-Specific Classes

Stage-specific classes support complicated annotations and multi-step processes by allowing you to select specific classes, as well as specific annotators, for each annotation stage.

Breaking down complex annotation tasks into smaller constituent elements helps drive increased annotation speed and accuracy. Annotators can focus on their specific stage without being overwhelmed with irrelevant classes, leading to faster and more accurate annotations.

Within a workflow, you can select different classes for each annotation stage like this:

The worker will then only see the selected classes, and the relevant tools for the selected classes, saving them the time and effort of filtering through a longer list of possible annotations and irrelevant tools.

The end result looks something like this - as you can see below, each annotation stage has both a specified class and a specified annotator.

Our tooling is reduced so that only the relevant annotation tools are visible. As you can see below, since only the Bone class (a polygon) has been added to this stage, other tools such as the bounding box tool are hidden from the left-hand toolbar.

If annotators are responsible for numerous classes and stages of annotation, they will see helpful pop-ups with new annotation instructions for different classes as they enter a new stage.

Possible use cases include

1. Large-scale annotation projects: In complex workflows with multiple annotation stages, stage-specific classes help segment these into smaller, more efficient stages and enhance overall project management.
2. Complex annotation tasks: For tasks that require different sets of instructions or classes at different stages, stage-specific classes can help ensure that annotators have access to the correct information at the right time.
3. Collaborative projects: When multiple teams or organizations are working together on a project, stage-specific classes can help facilitate communication and collaboration by providing clear and organized instructions for each stage.

📘

"Lock" annotations

For any projects where a worker should not have the ability to edit an annotation class (for instance, when annotations are imported), removing the class from their assigned workflow stage will have the effect of making annotations read-only.

In conclusion, stage-specific classes are a valuable feature for managing complex annotation tasks and improving the efficiency and organization of the annotation process.

FAQs:

Can users see past annotations?

• If the user is on a class filtered stage they can see past annotations, but they are read-only. This means the user can see past annotations but can’t edit or delete them. If the user is on an unfiltered stage, they can see and act upon all past annotations.
• Watch this for an explainer: https://www.loom.com/share/6db22bfa79804f489b3efcecc4033b56
• In future milestones, we hope to add a toggle on an annotate stage that lets users turn on/off this behaviour.

Can users act upon past annotations?

• Only if they match the class filter on the stage (e.g. the past annotation is coke_can, and that is a class applied to the Annotate stage you are on).
• For classes that do not match, while workers can see these past annotations, they are not able to act upon them. This means they can’t edit or delete them.