@fiver-watson are you expecting the icon to show on cards even when all the output fits on a single line?

Have you considered replacing the "Started" and "Completed" times with a single task duration indicator. This could show the total duration for completed tasks or a dynamic counter for ongoing tasks, while detailed timestamps could be displayed only when the task is expanded.

@djjuhasz admittedly, i hadn't fully considered - I assumed that all tasks would have SOME kind of STDOUT that we could display... though perhaps that is not the case.

2 initial thoughts on how we could proceed:

1. only show if there is in fact further content to display
2. implement @sevein's suggestion - show only duration on the initial card view, and include start and end timestamps in the pulldown. That way there should always be something to show...

@sevein @fiver-watson I think what we show on the UI should be determined by what data is most relevant to the operator in the current context, and I think that in most cases task duration will be less relevant than the task start (for running tasks) or completion (for completed tasks) times in the preservation task list view.

I would imagine that in most cases where SIP processing completes successfully the operator won't be looking at the preservation tasks at all. The preservation tasks interface mostly seems relevant when one or more of the tasks failed, and the operator wants to know which ones and why. The second scenario I can imagine where the preservation tasks are relevant is when a SIP is taking a long time to process and the operator is trying to find out why.

For the first scenario (task failed) the time that the task failed could be relevant to correlate it with other activities in the environment (e.g. high network usage, disk issues, concurrent processing). In this scenario duration seems less relevant, but it might be informative if the task timed out.

For the second scenario (long running task) the duration of a long running task seems highly relevant, and the time the task started would be slightly less relevant, but may also be helpful for correlating other events.

In either of the above scenarios clicking on a task to get more details such as start and end time and task duration seems reasonable, and would also be necessary to see detailed error output. If the operator can get all the data they need by clicking the task, then I think the default, collapsed card view should show the start time for any pending or currently running task, or a completed time for any tasks that have completed or failed. I think the timestamps are useful on the list view because the list is ordered in reverse chronological order, and the timestamps reinforce this ordering. I also think that scanning a list of timestamps provides more information than a duration, and you can infer the duration of any particular task based on the timestamps of the preceding and subsequent tasks. Providing a duration is also more computationally expensive (it is a calculated value) and requires more frequent updates of the UI (it changes frequently for a running task).

All good points!

For the work to date, this is looking good to me! Let's pass it on to the client and see how they feel.

I'm working on making the task cards expandable when there is more than one line of output.