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