Export Feedback Interface

Hi, I have been using some of the digital scholar projects for few years now (at least try to use it in daily basis in a humanities research environment).

Knowing Tropy and Omeka can work together is a great burden eradicator.
I have some Exporting plugin requests from Tropy to other tools like DSpace and other Archival Repositories that are using in GLAM institutions.

However, my main concern in recent times is that, while exporting Tropy Items to Omeka, there is a lack of UX feedback like :

  1. No. of items, and the total no. of media is enlisted for upload.
  2. How much have been uploaded and synced so far in Omeka
  3. Options for pausing, Resuming
  4. Feedback for errors in file access, network etc…

Today i have been trying to test the tropy omeka-s plugin by comparing the logs during (1) exporting to local omeka-s instance in the same machine (2) exporting to online instance of omeka-s. The logs were really helpful and with help of my FOSS peers, i can able to understand whats happening at code level - as the logs refer back to the code where the error occured.

This is where i thought the same information if available to the user of Tropy it will be of great use for Tropy broadly.

I am requesting this, because in my experience, the scholars who work with material sources (manuscript, inscripts, archaeological artefacts, museum objects, herbariums, etc…) can do most of the curation, batch processing, metadata curation using Digikam and Tropy combination. This workflow model essentially decouples the dependency of the work on the Archival and Exhibiting - FOSS services, easing the continuous works of scholars who add descriptive, scholarly metadata continuously. Whenever the team decides OK after review or the individual scholar finds it better to upload, then it can be synced. This means the reliability, consistency through UX feedback mechanism plays a very important role.

Thanks for these suggestions, they’re all good points!

I think improving the error reporting is mostly something that we can do in plugins themselves. Giving better feedback about the progress is something that we need to find a good way to expose to the plugins (it’s something we’ve already been deliberating).

Pause/resume is not something we were planning to add; however, cancelling the plugin from the UI would be a first step in that direction.

1 Like