artefactual-sdps / enduro

A tool to support ingest and automation in digital preservation workflows
https://enduro.readthedocs.io/
Apache License 2.0
4 stars 3 forks source link

Problem: Notes field is unused #934

Open sallain opened 4 months ago

sallain commented 4 months ago

Is your feature request related to a problem? Please describe.

The Enduro UI contains a Notes field that is unused in the integration with Archivematica (it was minimally used in the integration with a3m). The field is located in the Preservation Actions section.

image

This field is intended to contain any useful output from the task, such as detailed results or error messages. However, when Start/End times are added via #832, there will be very little space for a note. This will especially be a problem in narrower views.

Describe the solution you'd like

Add detailed information to the Notes field. This may require that the Notes field is redesigned to allow for enough space. While some notes may be short, I think there are plenty of cases where they will contain long strings (e.g. UUIDs) or multi-line content/paragraph breaks. It would be good to allocate enough space for that content so that it's easy to read.

Describe alternatives you've considered

Remove the Notes field for now to simplify the interface.

Additional context

mcantelon commented 4 months ago

Maybe we could have it display in a modal when a button is clicked? Each task should have standard output (and sometimes standard error output) that could be stored in the notes column in the DB (although maybe separate DB columns might make more sense).

jraddaoui commented 4 months ago

We may only want to capture stderr here(?), if not, using two columns makes sense to me. And I was thinking on an expandable section below each row, but I don't know how easy/accessible would that be to implement. Thoughts @fiver-watson and @sallain?

fiver-watson commented 4 months ago

@mcantelon using STDOUT all the time is what AM did with the gears, right? As Sara noted in our meeting, that's both a plus and a minus of the AM user interface - much of the time that's too much information and confuses end users with more details than they need. I would prefer for us to be more curated and selected with the types of messages we add here, and the language we use in delivering them, so they are not just system messages, but actually crafted information intended for an operator. System adminsitrators maintaining the site should be able to see standard out messages in other ways if needed.

@jraddaoui I agree that STDERR messages will be important. As a first increment, I am fine with:

Long-term, I'd like to do more work to make the error messages as user-friendly as possible for the actual operators, and curate more general notes about task progression etc. I'd also like to think about accessibility, usability, etc. more - but that will take time and I like your suggestion as a first pass.

@sallain your thoughts?

sallain commented 4 months ago

@fiver-watson @mcantelon @jraddaoui I think that including the STDERR as a first iteration is a great idea. That should give us a good baseline to measure both the usefulness of the messages and the design.