Judy,
What about the poor person that has to manually enter the same series
and recording requests data semester after semester after semester
(until the course gets dropped or its syllabus radically changes)
through the Matterhorn UI? Is it really fair to call that poor student
aid worker a "metadata fanatic"?
Here is 2¢, if someone has time to make the page...
1) The page harvests series data (in a date range, or from the beginning
of time?)
..../series/series.xml?...
2) The page transform the series list xml into pretty HTML for
click-able selection.
3) User selects one of the series from the list. Now page show series
metadata in an editable form.
3.1) The page retrieves episode metadata to facilitate bulk Recording
scheduling.
... /episode.xml?series=[selected seriesID]
... Page also show list of series episodes.
... Page allows user to add and delete from the potential events and
expand episode meta data into editable form.
4) Administrator edits series and/or episode metadata.
... insert new series ID (or let Matterhorn create)
... add new recording dates, change titles...
5) After making edits, administrator clicks [create new series &
schedule recordings] button.
...Browser runs client side data validation before formatting data for
POST and MAKES SURE that user is not using an existing series ID(!!).
- Karen
On 7/31/2012 7:29 PM, Judy Stern (Commented) (JIRA) wrote:
[
http://opencast.jira.com/browse/MH-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31357#comment-31357
]
Judy Stern commented on MH-6910:
--------------------------------
@Ruben: I think we basically agree. We can't design for everybody: "Common sense tells us that we need
to create products that can accommodate the needs of as many people as possible. That means more people will
be able to and want to use our product, right? No! In reality, designing a product that works for everyone,
means it likely will not work for anyone. Since everything on a webpage or in a web application competes for
users' attention, all the pieces that are not relevant to a particular user increase their cognitive load,
and information overload and overhead. By designing for everyone, everyone ends up paying this high
price." (from http://wiki.fluidproject.org/display/fluid/Designing+with+Personas ) But this means we
have to decide who we *are* designing for. Olaf is "designing" for somebody different than you are.
The only way to decide who is "right" (whether this is described in too low level terms or not) is
to figure out who we should be designing for. Now, *IF
* the primary users could *all* be described as "deeply immersed" and maybe even "metadata
fanatics" or "file manipulators" then there's nothing wrong with surfacing in the UI what they
want to see, in the terminology that makes the most sense to them. When you have 2 very different types of
users, you really need to create 2 different UI's, and fortunately, that appears to be what's happening (if I
read Olaf's comment correctly). Unfortunately, I'm sure this kind of thing will continue to happen. p.s. 2
cents is probably worth about the same as a grain of sand, so it seems pretty equivalent ;-)
As an administrator, I want to see and manage (sort, order, search) all the DC
metadata files so I can re-use them for either adjustments or re-use (metadata
templates)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: MH-6910
URL: http://opencast.jira.com/browse/MH-6910
Project: Matterhorn Project
Issue Type: Story Card
Components: Architecture & Services
Affects Versions: 1.2
Reporter: Olaf A. Schulte
Assignee: Christoph E. Driessen
Fix For: Trunk
In order to facilitate the allocation of metadata, the admin should have access
to all the episode and series metadata files so they can be copied, enhanced
and re-used. As most events are re-occuring, this should facilitate the admins
work and make sure metadata are consistent over semesters etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://opencast.jira.com/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
--
Karen Dolan
Harvard University, DCE
617-998-8439
[email protected]
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
