Tobias, Christoph: Some questions about the Episode Service: When does an episode become available on the Episodes tab? Must the (first) workflow have finished or merely have been started? From what it says on [1] (e.g. "...a place where all media packages will be kept after they have been processed", "..will be called the archive"), it seems like it would be the former. Can you clarify? Can you have multiple workflows simultaneously running against the same episode?
Additionally, can you answer the questions Adam previously asked? > -does the episode service incorporate authorization? > -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. > -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. > -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. 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? 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. > -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. > -which date is represented in the date column? upload date? creation date? thanks in advance, Judy [1] http://opencast.jira.com/wiki/display/MH/The+Episode+Service On Sep 13, 2011, at 10:10 AM, Judy Stern wrote: > > On Sep 12, 2011, at 10:31 PM, Tobias Wunden wrote: >> You'd like to stick with "Recordings", but you don't mention how the episode >> view should be integrated in your mind. Would you like to merge the two >> views into one? > Yes, I believe they should be merged. Although they are not the same thing, > they are related enough that it will only be confusing to keep them separate > in the UI. > >> If so, is it fine to take an iterative approach and show the "Episodes" tab >> now in addition to "Recordings" and start merging the two views in the next >> step? >> > Depends on *when* the "next step" is. For usability reasons, I strongly > recommend against any kind of public release with a separate Episodes tab. > > I do not, off the top of my head, have a good solution for how to integrate > them. I am not even 100% positive there is a feasible solution. But give me a > couple of days to try to come up with something, taking into account what > Rudiger, Ruben, and others have conveyed. (Or will convey: As usual, if > anybody on this list has needs and/or ideas, please speak up.) > > Judy > >> Tobias >> >> On 12.09.2011, at 20:56, Judy Stern wrote: >> >>> I've got some fairly strong opinions about this, which perhaps may be >>> allayed with further discussion. (Thus, I am not giving a "-1" just yet.) >>> >>> No disagreement with the the statement that "we need to start separating >>> our thinking and terminology with respect to what a workflow is and what a >>> recording is." Where I am unsure is whether or how this should translate to >>> the Admin Tools UI. >>> >>> My primary concerns with the term "workflow": >>> 1) It's ambiguous. Aren't we really talking about "workflow instances" >>> here? (A table of "workflows" should show the available workflows, e.g. >>> "Encode, Analyze, and Distribute", "Encode for DVD", etc.) >>> 2) (More controversial) The term "workflow" is too "loaded" for many >>> potential users of the Matterhorn Admin tools (e.g. "program >>> administrators", those who are not programmers or system administrators, >>> and can't always be expected to have a deep understanding of how Matterhorn >>> works). >>> >>> My primary concerns with the term "Processing": >>> 1) We'd introduce further complications, since we have a Recordings filter >>> called "Processing". Many of the items we currently call Recordings are >>> only "processing" (as we've used the term before) at certain times. >>> 2) The tabs are meant to represent the conceptual objects in the system >>> ("Recordings", "Series", "Capture Agents", soon "Users") that one can get >>> information about and act upon. ("Statistics" is an oddball here, but it's >>> at least a noun.) >>> >>> When the current admin UI was designed with the term "Recordings", it was >>> with the intention of "Recordings" being a reference to something more >>> conceptual than a single workflow instance. It was meant to represent the >>> conceptual entity that non-Matterhorn technical experts might think of (and >>> care about) when they're asking questions, e.g. "When will I be able to >>> view [the recording of today's class]?", "What has to be done to make the >>> [the recording of yesterday's class] available?". To be sure, it was also >>> recognized that there were serious design problems that needed to be >>> solved in order to represent some of the power that the underlying >>> architecture provides (that is now starting to be surfaced): How can can we >>> represent partial failures (e.g. distribution to one distribution channel >>> but not another)? How can we represent any multiple attempts to process a >>> recording (e.g. retries)? Etc. >>> >>> I am wondering if we could consider continuing to call the tab "Recordings" >>> but move towards starting to solve those design problems: Can we come up >>> with a way to expose the application of multiple workflows to those >>> recordings (i.e. show all the workflow instances)? This would mean such >>> characteristics as: >>> -- clearly exposing when a particular recording has multiple workflow >>> instances (and query what settings have been applied to each instance) >>> -- providing the ability to take certain actions on specific workflow >>> instances (think about some of the hold state actions) and other actions on >>> the recording as a whole (think about editing metadata) >>> --being able to apply new workflows to existing recordings. >>> We'd also need to think thru some of the questions Adam has asked in the >>> thread "Release 1.3 Scope and Criteria <IMPORTANT> #proposal". >>> I am happy to try to tackle some of these design problems if there is not >>> huge disagreement to the approach. >>> >>> Judy >>> >>> >>> On Sep 12, 2011, at 3:53 AM, Tobias Wunden wrote: >>> >>>> As part of the work on [1] and with the ongoing activities around the >>>> episode service, it is becoming clear that we need to start separating our >>>> thinking and terminology with respect to what a workflow is and what a >>>> recording is. >>>> >>>> The current admin uis refer to "recordings" where really "workflows" are >>>> meant. With the episode service in place (currently displaying an >>>> "Episodes" tab next to "Series" and listing the media packages that have >>>> so far been processed by he system), I suggest to rename the current >>>> "Recordings" tab to "Processing" or "Workflows". >>>> >>>> Does anybody have strong opinions about this? >>>> >>>> Tobias >>>> >>>> [1] MH-8084 As an administrator, I want to be able to retract media >>>> packages from their distribution channels >> >> _______________________________________________ >> 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] > _______________________________________________ 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] _______________________________________________
