Rework the workflow tab in the event details in the admin interface

[Arnei]

Hello everyone,

It has come to my attention that many of our admin interface users are discontent with the workflow tab and its subpages:

To improve the experience I would like to inquire on how everyone uses the workflow tab. Feel free to answer even if are content with the way things are, so that we can consider everyones opinions. Consider the following questions.

• What tasks are you looking to solve when opening the workflow tab for an event? Which of these tasks is the most common, maybe by far? What specific information helps you in solving your tasks?
• Are there any tasks you thought this tab would help you solve, but it did not? What information or features are missing that you would need to carry out your task?

[mtneug]

First of all, as an Opencast admin, I use this page very often. This is basically the first step when checking the status of some processing. I also like the details this tab provides, which helps to pinpoint problems, etc. As an Opencast/workflow developer, I often use this page to check on the execution of a workflow. Basically, having the subpage with the workflow operations open.

What I don't like:

• It's cumbersome to navigate to the list of operations. The new admin UI allows navigating directly to the newest workflow operation list by clicking on the status cell, but this removes the ability to quickly filter by that status.
• The new Admin UI sorts the list of workflows in the opposite direction compared to the old one (new workflows at the bottom of the list). I usually want to navigate to the newest workflows. I therefore liked the other sorting direction better.
• Most often, I use the workflow tab to check on failed workflows. I start by checking which operation failed. I then want to see the error message and have to navigate back to the higher-level workflow overview page to click on the error and warnings subpage. This navigation is cumbersome and involves too many clicks.
• The error message can, at times, be very generic. This is mostly the case when multiple subjobs are spawned from one operation, possibly running on non-admin nodes. Although I don't really have an example for such an error off-hand right now.
• I often also want to know which Opencast node produced the error. Navigating to the operation details will show the "Execution Host", but this is always (?) the admin node as the workflow operation job is executed on the admin node. Basically, I want to know where subjobs failed to check on that node. You have to go to the Opencast log to find that out.
• The list of workflow configuration is very prominent as the second section. I would move it down to the bottom of the page.

[LukasKalbertodt]

I mostly agree with your comment, but:

The new admin UI allows navigating directly to the newest workflow operation list by clicking on the status cell, but this removes the ability to quickly filter by that status.

You can still use the big "stats" buttons in the header (i.e. "3 running") to quickly filter by status. I much prefer the new behavior, as this is intuitively what I expect it to do.

[mtneug]

I'm not too opposed to the new behaviour. For me, it's just a matter of getting used to the new way. BTW, we have more states than would comfortably fit in the header. IMO, no change is necessarily needed in the link of the status cell. But maybe another flow could improve things even more?

[LukasKalbertodt]

Good idea, the workflows tab is really bad UX-wise.

What tasks are you looking to solve when opening the workflow tab for an event?

Main use case: how far is processing and how long does it still take? Second use case: check out errors. Both use cases are terribly served, as Matthias already said.

For the most part, I think the details pages are ok. They can mostly stay as they are. But the "dashboard", i.e. the first page for a workflow should be drastically improved. Ideas:

• If a (fatal) error occurred, show the failed step and the full error message there. It shouldn't be necessary to dig through multiple menus to get to that.
• Show a graphical overview of workflow steps. Maybe a horizontal line with small circles/nodes for each step. Nodes can have different colors/shapes/patterns/icons depending on their state (done, skipped, error, queued, ...). Hovering over a node should show a tooltip with the most important information about it (title, description, state, duration). Clicking a node should link to the workflow step details. I know that due to "include" operations, the number of steps can dynamically change. Maybe mark upcoming "include" operations with a special symbol so people know that this will resolve to a number of steps.
• Show when the workflow was started and/or for how long it has (already) been running.
• The current "workflow details" and "workflow configuration" are not as important and should move down.

Non "dashboard" related:

• The "stop workflow" button does not have a "confirm" dialog, meaning you can accidentally press it. It never happened to me, but still. Cancelling a workflow accidentally usually does not have catastrophic consequences, but it's more than an inconvenience, as it can cost quite a bit of time, for example.
• Most events only have one workflow, so maybe special case that to immediately show that workflows dashboard? Saves a click each time.

Finally, I think it would be amazing to have a time estimate. Yes yes, workflows are Turing complete, but I think lots could be done to get decently accurate estimates. At least when only one event is processing at a time. It would also be nice if some operations (long running ones) could have an internal progress. Like encode or speechtotext. It's possible to get the encoding progress from ffmpeg output, likely also from whisper. But sure, that's more work. But would be really really useful IMO.

[mtneug]

Most events only have one workflow, so maybe special case that to immediately show that workflows dashboard? Saves a click each time.

I disagree with this assumption. Depending on how you do lecture recordings, there is an ingest + edit workflow. I would find it confusing if different pages are presented depending on the number of workflows that ran.

[snoesberger]

Yes, there is room for improvement for the workflow tab. And I mostly agree with what Lukas and Matthias already mentioned.

My use cases are mainly:

1. Checking why a workflow failed.
2. What is the workflow doing at the moment? Which step is being executed?
3. Check the workflow configuration parameters.

Possible Improvements:

• I generally need too many clicks to access the information.
• If a workflow fails, display the failing step and the error message directly on the first page.
• If an error occurs, display the error message in the operation details of the corresponding workflow step.
• State the correct execution host for each workflow step, e.g. the execution host for encoding steps is currently always the admin node, even though encoding is done on a worker node.
• For the overview of the workflow config: visually differentiate between user-set parameters (e.g. straightToPublishing) and workflow-generated parameters (e.g., presentation_work_video). Most of the time I'm interested in the parameters set by the user.
• The "time in queue" for a workflow step is apparently always 0 ms. It would be helpful to know how long we had to wait for free resources to become available to pick up the task.
• Currently, it is difficult to determine which step belongs to which sub-workflow. It would be helpful to have a visual indicator showing which partial workflow each step belongs to. One option could be a colored frame starting at the "Include" step containing all steps of the partial workflow.
• It would be helpful if skipped steps were more clearly distinguished visually, such as by a different color or being grayed out.

Features I'd like to have:

• We can already stop a workflow. It would be nice if we could also pause a workflow and resume it later, e.g. to give precedence to another workflow. An other option would be to give a workflow high priority so that it is executed before all others. Use case: we have a lot of video uploads and encodings at the same time, but one of the videos should be published as soon as possible.
• I also like Lukas's idea of providing a time estimate. This value should be made available to other applications too, such as LMS and Tobira. I know it's difficult to estimate the time required for partial workflows that may or may not be included, or for lengthy operations such as encoding or speech-to-text conversion. One idea could be to take the duration values from workflow steps that have already been executed and calculate an average value (e.g. per minute of video for encoding steps). These values could then be used as a basis for the estimates.

[stefanosgeo]

I agree with all the points Sascha made.

If a workflow fails, it would be helpful to display both the error details and the specific host where the issue occurred. Additionally, when a service fails—like the composer, for example—I see a notification at the top right of the page. I usually click it to restart the service, although I’m not entirely sure if that’s necessary; I just do it because makes me feel better :).

A more prominent red notification in the top-right corner could include a direct link to the failed event’s workflow details tab. In general, making the notifications more informative and visually distinct could help draw attention to critical issues.

Lastly, about the estimated time feature: in our portal, I implemented a simpler version by calculating progress based on workflow steps—for example, if the workflow is on step 7 out of 10, it displays 70% complete. This is much easier to implement, though admittedly not as polished as showing an actual estimated time.

[grexca]

We see the same improvement needs mentioned so far.

In my opinion, it would also be useful to be able to see if a single node is accumulating the most errors or too much errors, these will help us to known that there could be a problem on that node.

Regarding time estimation, an estimate based only on workflow steps will provide information that is too inaccurate and therefore, in my opinion, could be not very useful.

[KatrinIhler]

For this also see opencast/admin-interface#1292