A huge +1 to Judy
2011/9/12 Judy Stern <[email protected]>
> 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]
> _______________________________________________
>
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
