Christoph, Judy et al., It's exciting we are having this discussion. I strongly believe this is a better approach to managing the video contents than the current one. I've got just a couple remarks (I want to clarify that I am explaining my point of view here, which may not be the same as the "official" point of view, corresponding to the episode service developers):
*Christoph said:* > *adding a media package to the episode service is just a regular workflow > operation* I strongly disagree with that. If we want to have a "real" repository, then including a certain media in it shouldn't be a matter of processing it. If "mediapackage" = "episode", then using workflow operations to include the mediapackage in the service is absurd (because unprocessed mediapackage are *also* episodes --or are they not? please share your thoughts). The way I see it, a mediapackage goes into the episode service in the very moment it enters the system. I understand it as a catalogue of every media existing in the system (processed or not). After we have our mediapackage/episode cataloged, we can apply whichever workflow we want, and obtain different results (such as re-encoding it, publishing it... --just like we do now). Think about a normal ingestion: you receive the mediapackage, then you apply a workflow to it. In the new scenario, you receive the mediapackage, you put it into the episode service AND apply a workflow subsequently. Should this workflow fail, it is trivial to go to the episode service, see what went wrong and re-apply the workflow (perhaps changing some options to make it work this time). *Christoph said:* > *Adam said: Can you have multiple workflows simultaneously running against > the same episode? * This depends on the actual workflows. Take for example metadata changes > happening concurrently in both workflows. That leads to lost updates of > metadata. If this depended on me, I wouldn't allow for multiple workflows to be applied simultaneously to the same episode. Workflows are expected to be fairly complex (they are already, and I expect they will become more complex as we want to apply more convoluted operations to the videos --cropping, virtual panning, sound processing--), and thus we have to guarantee the consistency of data during the whole workflow. I don't think it's a loss at all: right now, I believe only one workflow can be applied to the same mediapackage. *Christoph said:* > *Adam said: my understanding is that the episode list in the UI mockup > represents recordings not workflow instances. If so, workflow info like the > "process column" should be removed in light of this, as there is already a > place to review workflow instances. This makes sense especially if > simultaneous workflow instances are running against the same recording. > * **It represents media packages aka episodes in their most recent state. As > the term recordings is currently used in the UI it is a synonym for workflow > instance, isn't it? > In this scenario the "process column" makes sense since it gives the user > direct visual feedback about what he has done after starting a workflow with > some episodes. Please see also http://opencast.jira.com/browse/MH-8124 I agree with this idea. Episodes can be "idle" (not the best term, I know), as in "not currently being processed" or they can currently be being applied a workflow (does this sentence even make sense in English?). This info is interesting to the user, primarily, because episode cannot be modified until the workflow has finished (for consistency, as I said before), but also, because you can see at a glance if some workflow is being applied to a certain episode, and you can then click to see the details, etc. *Christoph said:* > A*dam said: aside from referring to the workflow instance filters, it > might be helpful to know which workflows were formally run against each > recording and what their status was (failed, finished, etc) within the > episode UI. Otherwise users will need to refer to the Finished and Failed > tab as the source of authority for formally ran workflows when determining > which workflows to run in the episode context. Not a big deal but a nice to > have.* These information will be visible when clicking on a certain episode to get > the detail view. I will improve the mockup to clarify this more. Not saying that a tab showing all the workflow instances is not useful anymore, but I believe that being able to see the workflows applied to *each * episode is better. Both views are complementary, though. We could have an "Episodes" tab, and by opening a certain episode details, we'd see a list of the workflow instances applied to that episode, perhaps with the possibility of filtering them by state -failed, finished...-. Then we could have a "Workflow Instances" tab, where we'd see all the instances together, and we would be able to filter them. So the "Failed", "Processing", etc filters would be part of the same "Workflow instances" tab. *Adam said:* > *it's unclear why actions are displayed in this context if the list > represents recordings. I see no harm in a view page per recording, but > actions should be dependent on the chosen workflow. * Actions should be dependent on the chose *episode:* is it published?; where?; is a workflow currently being run on it? In other words, they depend on the current state of the episode. Of course, the current state depends on the workflows applied in the past, but the important thing is the outcome of those workflows, the results, and not the workflows themselves. *Adam said:* > *If edit were available for a recording without choosing a workflow, how > would changes to its metadata impact associated "running" workflow > instances? Would edit be turned off in this scenario?* In the way I see it, yes. *Adam said:* > *Even if no workflow instances were currently running, it seems like the > edit action should prompt other actions like redistributing the recording. > Aside from view and edit, I'd think other actions would derive from hold > states, and would make most sense within the context of the workflow > instance filters.* The way I see it, the workflow instances should appear listed under the episode they are applied to. Therefore, one of the states associated with an Episode (apart from "under processing") could be "On hold". I see an episode state as "the state of a workflow being applied to that episode, should there be one". So the user would see a certain episode "on hold", which means a certain workflow is being applied to the episode and it's waiting for user action. They would see the episode details and take the appropiate measures. I find also very natural that the users can edit metadata directly, and then, by clicking "Submit", a workflow instance to update that metadata in the distributed copies would be launched. This is pretty straightforward if we could inspect each episode and it's associated metadata. I can imagine a different set of options specific to certain distribution channels where the recording is distributed. *Christoph said:* > The only use case in mind at the time I created the mockup was the "play" > action. Since this one moves to the details page the column will be dropped > entirely. This "play" option could be one of those specific options that are tied to a certain distribution channels. So, we could have an episode distributed to iTunes and to the Engage part, and we could see a different "Play" option for each channel, so that we can "play" the iTunes copy OR the Engage copy independently. *Christoph said:* > *Adam said: If a workflow is chosen and it needs options set prior to > initiation (i.e. flavor identification) will the user be presented with > required options prior to worfklow initiation? I could see a scenario where > the user originally ran the default workflow with a subset of avail options > and later they want to run the same workflow with other options chosen. In > the context of the episode UI, it might make sense to have granular > workflows in place that don't rely on options.* Good point. We need to think about this. One of the actions that the user could do (perhaps instead of the "play" action that is going to dissappear) is "Apply workflow". That will led the user to a list with all the available workflow definitions, and they could choose the options needed by clicking on one of them. Them a button "Run!" will start the workflow on that episode/mediapackage. In certain cases, I see normal a workflow can be applied with default options. For instance, my previous example about ingestion: the ingestion service receives a mediapackage, puts it in the episode service and runs the default workflow with the default options. Then, the user can see that workflow listed in the episode details, and maybe they will have an "Run again" option which will allow them to set the workflow parameters previously. *Christoph said:* > *Adam said: which date is represented in the date column? upload date? > creation date?* > Currently this is the start time, which is the creation date. I think all of them can be interesting: upload date, start time and perhaps even the date when it was scheduled. We've got records of all that times, including them in the UI in a visual way shouldn't be overkill. *Christoph said:* > One thing I like to get clear is the definition of "recording", "workflow > instance", "episode", "media package". As far as I understand it "recording" > equals "workflow instance" and "episode" equals "media package". Thoughts? Yes, I agree that's the status now. However I do not like so much the "recording"-"workflow instance" equivalence, because I believe it brings confusion. "Recording" = "Episode" = "Media Package" sounds more natural to me. My two dollars :P Rubén
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
