I don't see nothing against making (not right now, but when the Episode
Service is "established") "Recordings" = "Episodes", thus leaving the tab
name unchanged. It's a very straightforward change and we avoid changing our
UI naming convention.
I guess that (speaking in UI terms only) we could distinguish between
"normal" workflows, i.e. those which are consciously started by the user
("let's include some subtitles here") and "hidden" workflows, i.e. those
which perform typical operations which are consequence of certain user
actions and which they are not aware of (i.e. "I'm changing my recording
title" triggers a workflow to update the published media). I don't think
that both kind of workflows need to be different in the backend, though.
Is it needed a tab with the workflow instances only? Well, I think so. An
administrator may want to know how many "operations" (so to speak) are
currently running in the system, if some of them have failed, are on hold,
etc. There should be a primary filter (perhaps a drop-down menu with all the
workflow definition names and "all") to get only the instances of a certain
definition, or all of them, and then other secondary filters as state (just
as we have now). This is more useful as the number of "episodes" grow,
because we may have a system where no episode is ever deleted, thus the list
may contain thousands of episodes, most of which won't have been modified
for a long time (they're just stored there, but they don't need to be
changed, published somewhere, retracted from somewhere... any longer). The
daily chores are more focused in managing the recent incorporations, the
episodes that are being processed, published or modified. Then you just need
to see a list of the active workflows AND to which episodes they are being
applied, and you can navigate forth and back.
And I totally agree that we should difference the "details" of an episode
(basically its metadata) with the workflows applied to it. We could use
"workflows" or whatever UI convention we want instead ("processing",
"operations"?). But they should be, from my point of view, in a different
category.
Sorry about the long rant. It's almost 22:00 and my ideas aren't now as
clear as I would like.
Best regards
Rubén
2011/9/14 Judy Stern <[email protected]>
> And thanks, Ruben.
> As I reread this, it's all getting clearer. In particular, there's an
> important notion in this statement: "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." Leads to one big
> question at the moment: What are the needs (use cases, user stories, etc.)
> that require a sortable view of all workflow instances? If we have an
> Episodes UI, why not call it "Recordings" (replacing what's in Recordings
> now)? If we could add the display of a bit more data (e.g. "Recording
> Date/Time") to the UI Christoph is proposing and provide a way to filter
> the episodes by status (e.g. to only those actively running a workflow, with
> further filtering based on which phase it's in), we'd have close to all of
> the information in the current Recordings UI. What am I missing? More
> importantly, what would users be missing if they don't have a table of all
> workflow instances? (I guess part of the answer is dependent on whether we
> need to simultaneous workflows running on the same episode...)
>
> Judy
>
> p.s. I've been trying to come up with ideas for merging the current
> Recordings UI with the Episodes UI (now at <
> http://opencast.jira.com/wiki/display/MH/Combining+Episodes+and+Workflow+Instances>
> ...still very incomplete so don't focus on any details). Though I still
> have an intuitive sense (in other words, not backed by analysis or data)
> that it would be nice to be able to see it all in one UI, it's starting to
> seem that if we treat workflow instances as "details" of each episode, then
> users could still get that info when they need it (and might not need to see
> all the workflow instances at the same time). Thoughts anybody?
>
> On Sep 14, 2011, at 4:15 AM, Rubén Pérez wrote:
>
> 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]
> _______________________________________________
>
>
> Judy Stern
> Educational Technology Services, UC Berkeley
> [email protected]
>
>
>
>
> _______________________________________________
> Matterhorn mailing list
> [email protected]
> http://lists.opencastproject.org/mailman/listinfo/matterhorn
>
>
> To unsubscribe please email
> [email protected]
> _______________________________________________
>
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
