Once we decided to treat annotations as a database, I considered different ways to surface annotations and associated metadata to users. Users could already see annotations labeled directly on the DNA sequence. They had to open the expanded annotations panel to see the metadata attached to an annotation.
Some options, such as using cards for each annotation, were initially attractive because they were more visually clean. However, based on stakeholder interviews, I discovered that the top two reasons users arrived at the annotations view was 1) to make bulk edits to several annotations at once, and 2) to compare metadata between two or more annotations. Recognizing that bulk actions were the workhorse of this view, I decided to use a toolbar as a space to for users to initiate bulk actions. This brought bulk functionality to the forefront of the view and made many hidden functions much more discoverable to users.
Creating custom fields was a new functionality that wasn't previously available for annotations. My hypothesis was that creating a flow with high familiarity would be easiest for users to discover and learn, so I considered borrowing from existing patterns of interaction seen in many other table-based softwares and using a new column that could be edited in place
However, there were several scenarios where a user might want to add metadata to an annotation, but not necessarily have all the information available to fill out an edit-in-place column.
The trade-off of data quality for ease of custom field creation was not favorable, especially when a key use of capturing this metadata is for clean data exports for downstream use in the R&D workflow. I iterated through a few other possibilities to add custom flows, and eventually landed on one with an automated search for existing columns with the same column name. This safeguarded against data quality loss and removed reliance on recall.