Well, I made the calculation (peseta is not legal tender anymore) and 5 pesetas amount to roughtly 4 dollar cents... Not much after all, huh?
So I understand that another story isn't needed or that I should be the one creating it. I do think the story where this conversation comes from should be reformulated, but it is Olaf's story after all, and I don't want to interfere. As I also said in my last comment, there are "manpower" concerns, too: an interface such as described would be ideal, but it would take much more work than simply exposing the metadata files for the user to duplicate them (which I still see as a very awkward solution). So creating that user story in less technical terms is OK, but I'm afraid it won't be much more than a show for the gallery if we cannot gather resources to implement it. I would do it myself, but I'm not much of a UI developer... 2012/8/9 Karen Dolan <[email protected]> > 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<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<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<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<http://opencast.jira.com/secure/ContactAdministrators!default.jspa> >>>>> For more information on JIRA, see: http://www.atlassian.com/** >>>>> software/jira <http://www.atlassian.com/software/jira> >>>>> >>>>> ______________________________**_________________ >>>>> Matterhorn mailing list >>>>> [email protected] >>>>> http://lists.opencastproject.**org/mailman/listinfo/**matterhorn<http://lists.opencastproject.org/mailman/listinfo/matterhorn> >>>>> >>>>> >>>>> To unsubscribe please email >>>>> matterhorn-unsubscribe@**opencastproject.org<[email protected]> >>>>> ______________________________**_________________ >>>>> >>>> >>>> -- >>>> >>>> Karen Dolan >>>> Harvard University, DCE >>>> 617-998-8439 >>>> [email protected] >>>> >>>> >>>> ______________________________**_________________ >>>> Matterhorn mailing list >>>> [email protected] >>>> http://lists.opencastproject.**org/mailman/listinfo/**matterhorn<http://lists.opencastproject.org/mailman/listinfo/matterhorn> >>>> >>>> >>>> To unsubscribe please email >>>> matterhorn-unsubscribe@**opencastproject.org<[email protected]> >>>> ______________________________**_________________ >>>> >>> ______________________________**_________________ >>> Matterhorn mailing list >>> [email protected] >>> http://lists.opencastproject.**org/mailman/listinfo/**matterhorn<http://lists.opencastproject.org/mailman/listinfo/matterhorn> >>> >>> >>> To unsubscribe please email >>> matterhorn-unsubscribe@**opencastproject.org<[email protected]> >>> ______________________________**_________________ >>> >> >> >> > > -- > > Karen Dolan > Harvard University, DCE > 617-998-8439 > [email protected] > > ______________________________**_________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.**org/mailman/listinfo/**matterhorn<http://lists.opencastproject.org/mailman/listinfo/matterhorn> > > > To unsubscribe please email > matterhorn-unsubscribe@**opencastproject.org<[email protected]> > ______________________________**_________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
