I guess that a refactoring in the admin UI and a new concept would be
quite helpful.
I have over 500 Matterhorn recordings now and with the current concept
it is quite hard to keep the overview with the current table approach.
An example:
A lecturer calls me and asks why the recording from June 5th is missing.
So I know the lecturer, probably the course and the date.
Now we have October and the recordings started in April. So this is
probably just in the middle of the semester. I would have to click
through 20 of 40 pages of recordings probably to find the recording. If
I sort the table I might still have the paging problem if the course
title or lecturer name are starting with letters in the middle of the
alphabet.
So I filter with keywords. This works still fine. But what will happen
in 2 or 3 semesters when I have more than 100 recordings for the a
certain lecturer or there are several courses with the significant keyword?
I would prefer a tree stucture of the (finished) recordings, where I
have semesters/years followed by the courses (aka series) in this term
and the episodes attached to the series. For episodes without a series
we could use a default node to show these.
So I would not separate between episodes and series on different tabs in
the admin UI, as they are connected like I described. I like the idea of
the processing tab, where I see what's in production and what is
upcoming. If there would be a "recently finished" tab with the finished
results of the last week it would be nice but I guess it would not be
important.
If we create a more useful "more info" page for an episode (preview
images, download links for all media and probably editing the metadata),
I guess it would be no problem to add the "play" button here, or an
other kind of preview.
Just my 2 cents
Rüdiger
P.S.: An open problem in my scenario by the way is, how I find the
reason why an recording is missing... There need to be placeholders for
these recordings with comments ("removed because of copyright issues",
"audio was missing", ...).
Am 12.09.2011 20:56, schrieb Judy Stern:
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]
_______________________________________________
--
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: [email protected]
Internet: www.virtuos.uni-osnabrueck.de
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
