Quick-publish on save (Metadata, Thumbnails, Subtitles, …)

[lkiesow]

It is pretty confusing for end-users that they have to start another publication process if a video is already published and they just™ want to update the metadata (e.g. fix a typo in a title) or replace the thumbnail. Worse even, people expect that if they hit “Save” this is already published. They don't know anything about asset managers or two-step publication processes.

But even if you managed to educate users that they have to “Save and process changes”, the problems do not end there. By default, hitting the processing will launch a full publication process, including a re-encode of the video files. This can take quite some time, in which the user also can no longer interact with the video.

You can mitigate that, of course, by providing several different workflows to users. But while this will open up the option to speed up the process, it also makes the whole tool more complex. Users need to know what's happening and which workflow they have to select for what action. That's again bad for usability and therefor bad for your support.

Auto-update when saving

We actually know what has been modified in the editor. Since we know that, we could actually launch a quick workflow automatically if the event is already published. A workflow which just published the updated data and nothing more.

Publish directly:

• If the metadata has changed, launch a workflow updating the metadata
• If subtitles have changed, launch a workflow to publish the updated subtitles
• If thumbnails have changed, launch a workflow to publish the updated thumbnail(s)

Needs re-processing:

• If the cutting information has changed, save the cutting information and display a hint that the changes will be saved, but the video will not be re-processed.
• If the track selection has changed, display a hint when you change that the cut marks will be saved, but the video will not be re-processed.

If these data was changed, on the “Save” page, show a hint that publishing this needs reprocessing.
Also, if a video has not yet been published, add a hint that saving will not publish the video automatically.

ℹ️ Note: This is related to the general discussion about auto-publishing and the publication data structure which is kind of stuck before re-moddeling the internal data structures. This is mean't as a quick improvement only. It doesn't try to solve the entire system. Also, we can make this configurable if necessary 😉

[Arnei]

Generally seems like a good idea to me. Below some thoughts and questions that crossed my mind while thinking about this:

Does Opencast actually support workflows that only update the existing publication with metadata/subtitles/thumbnails? There is a republish-metadata workflow, so I suppose for metadata it should work at least, but I also vaguely remember hearing about issues with the strategy: merge configuration key.

What about other publications channels than engage? Would they support these kind of workflows? What should we do in the editor if they don't?

What if multiple "publish directly" things get saved at the same time, e.g. metadata and subtitles? That would be two workflows and afaik we cannot queue workflows, nor do we necessarily want to be able to. So we would need a separate workflow for the combination of metadata and subtitles. That's getting to be a lot of workflows, although maybe the include WOH makes this easy?

What if multiple "publish directly" and "needs re-processing" things get processed at the same time. Can we still reasonably assume, like we do currently, that the user selected workflow will also take of our "publish directly" things?

Is there ever a case where the user wants to save metadata/subtitles/thumbnails and NOT have them be auto-published (if the event has already been published)? I would assume not, but I'm not a user.

Taking this a step further, could we merge the "Save" and "Save & Process" buttons into one button? Remove the workflow selection all-together and just start a pre-configured workflow based on the changes made, no thinking necessary. Maybe this would help users more than hints about "publishing" and "reprocessing", which they can't be expected to know about (and who reads signs anyway)?
This begs the question if the user ever needs to be able to save cut-marks/track-selection without publishing. Again, I am not a user so I would not know.

[lkiesow]

Here is a quick recap from @Arnei's and my discussion about this on the way to the Opencast DACH:

workflows: ETH already has such a workflow in production that does a quickish-publiction of metadata, subtitles and thumbnails. We can use that. It should be contributed anyway.

Publications: We can ignore internal and can start with looking at the engage publication only. If this comes up later, we could make this configurable. But it's only for the trigger anyway. For publishing to different channels, adopters can customize the workflows.

Multiple publications: We need to lock the editor in the same way we lock it after “Save and publish” if we start a workflow.

Make “Save” and “Save and publish” one:

That's a good idea. We Here is a concept:

On the “Finish” page, auto-select what to do:

• If there is no publication, start the publication workflow
• else
  • if the cut marks have been modified → start publication workflow
  • else if subtitles have been modified, start a quick-publication workflow to cut and publish subtitles (we can also start the regular publish for now to make things simpler)
  • else if metadata, thumbnail, chapters, … have been modified → start the republish metadata workflow

For special cases, we can also include an “Advanced mode” where we can show infrequently used additional workflows or offer functionality like save without publication. For the latter, we also want to ask a few end-user if it's okay to not have this by default.

[mtneug]

So basically have multiple workflows that are conditionally selected by the editor? Everything remains configurable through workflow definitions and editor configuration? IMO that's exactly how it should be designed in Opencast. So +1.