Thanks for your thoughts. The feature you describe, what we call ‘batch editing’, has been regularly requested by Specify users and we have had numerous team discussions about how to approach it. As you point out we have had it on our new features list for some time, and we’re definitely aware of the impracticality of updating large numbers of records, one-at-a-time. There are a couple of difficult design challenges, centered around how the user will know which records they are actually updating and the impact of those updates as they cascade across the numerous table relationships associated with (e.g.) collection objects or collection events. We had batch editing as a feature in Specify 5 and it was a powerful tool, but we regularly received distress calls from users who had made batch changes and not realized the impact they had on other records they had not intended to change–as a result of the logical relationships among multiple data tables. For that user experience reason, batch editing will probably require additional functions like a system to do complete roll-back of updates that have unanticipated consequences. A batch change facility will probably need to be incorporated into the WorkBench module, where we would flatten out all those hidden logical relationships, enable spreadsheet-like batch operations, and then re-import the records in the dataset back into the Specify relational schema with the required validity checking. We’re also looking at the possibility of using the query results screen as a starting point for batch updates, some of the same engineering challenges apply, but by limiting updates to one data table at a time we may reduce the risk of unintended cascading changes. In summary, we know of the need, we’re still trying to scope the capability and to find a way to minimize collateral damage, and then fit the capability into our development priorities. Significant design, business logic and UI challenges like this unfortunately get pushed back as we resolve problems and add features that are smaller and have more discreet boundaries. That’s not optimal.
With a more open, collaborative consortium organizational model and more resources, we would be more responsive to significant engineering challenges that capabilities like this represent. It’s still on the list. Thanks again.