Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: Notes field is unused #934

Open
sallain opened this issue May 6, 2024 · 4 comments
Open

Problem: Notes field is unused #934

sallain opened this issue May 6, 2024 · 4 comments

Comments

@sallain
Copy link
Collaborator

sallain commented May 6, 2024

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Contributor

@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:

  • using an expandable section below each row (that only displays if there is something in it)
  • configuring enduro to always include the STDERR in this notes field if there is a problem / error

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
Copy link
Collaborator Author

sallain commented May 8, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants