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]
_______________________________________________
