I just read Ruben Perez's 5-peseta comment (5-peseta must be very
valuable), so I won't create the duplicate story card.
- Karen
On 8/9/2012 9:09 AM, Karen Dolan wrote:
Judy,
Thanks for the response. I'll go ahead and add that story card "As an
admin I want to create a new series from an existing one so I don't
have to re-enter the same data semester after semester".
I apologize for simplifying the situation. My thought is that real
"metadata fanatics" are happiest with the raw unadulterated XML, which
should already be available ( bug fest fodder?) through the series and
[episode?] REST endpoints.
- Karen
On 8/8/2012 7:08 PM, Judy Stern wrote:
Hi, Karen.
Exactly! I don't think anyone would call the student worker you
describe as a "metadata fanatic"; the student is likely more like the
user Ruben describes when he says "I was starting from the premise
that the system administrator (meaning the person who administers
Matterhorn at an application level, the "operator", if you like)
doesn't know (nor wants to know) nothing about XML files, Dublin Core
or the likes." It's all about thinking about who the user is and
what their goals are. We all agree that there's a need for metadata
reuse; it's just what the experience is that's in question, and my
point was simply that the UI you create for the administrator Olaf
has in mind is different than the administrator Ruben describes. Does
that make sense?
While I don't know when/if someone will be available to add this
functionality to current admin UI, it's a good idea for you to add
your suggestion to MH-6910. (Ruben's right that we really should have
two separate story cards...I might suggest creating one called ""As
an admin I want to create a new series from an existing one so I
don't have to re-enter the same data semester after semester" but
maybe somebody has a better idea... but if you don't have the time or
interest in creating the second story card I think it's okay to put
your suggestion in tMH-6910 so at least it's available in jira.)
Judy
On Aug 6, 2012, at 7:52 AM, Karen Dolan wrote:
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]
_______________________________________________
_______________________________________________
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]
_______________________________________________
