From my point of view, the requirement is, to have a configurable solution. And in my opinion, Osnabrück needs this too. Local solutiona are always bad solutions. This thread is a good source for requirements engineering and than you can update the ticke with a good global solution.
Nils > I understand your concerns from your point of view. Not everyone wants > to register their institution just to provide the student a better > smartphone/tablet experience. > When so many developers are against it I will rewrite the ticket > information and only implement a local solution. > > Denis > > On 1/27/12 11:45 AM, Tobias Wunden wrote: >> Hi Dennis, >> >> you will get another -1 from my side. I very much welcome the mobile >> application, but since it is a development that happened outside of the >> project in terms of architecture, design and development and in addition >> comes with its own license, I don't think it is wise for a couple of >> reasons to add links to it from the out-of-the-box Matterhorn >> installation: >> >> 1) It only works well for those installations that have been registered >> with the developers (you). >> >> 2) It is not clear to me whether the app is a project that is officially >> (from a community standpoint) a part of Matterhorn. I am not saying that >> it isn't, but as long as that has not been sorted out, I see the link as >> a prejudice to other "related" projects. Let's say I develop a new >> capture device (that you may or may not buy), and that capture device >> offers a unique feature that can be reached via an http link. Would you >> want to have that link in the Matterhon admin ui out of the box? I don't >> think so. >> >> In my mind, those institutions that offer video that is encoded for the >> mobile client will make sure to integrate links to the client into their >> presentation layer (portal, page, feeds, ...). Putting the link into the >> engage ui out of the box is just one more thing that is working for some >> but not for others. >> >> Tobias >> >> >> On 27.01.2012, at 11:06, Denis Meyer wrote: >> >>> Something like this came into my mind but Chris is obviously against >>> it. >>> I think we have to vote about it. >>> >>> On 1/27/12 8:47 AM, David Horwitz wrote: >>>> An observation from an android phone user: >>>> >>>> - When I click on a link in the browser for a youtube video I get a >>>> dialogue asking whether I want to open the video in the browser or the >>>> youtube app, with an option to store my preference. >>>> >>>> Not sure if its implementable for non google property but seems a >>>> reasonable way to approach the issue. >>>> >>>> D >>>> >>>> On 01/27/2012 09:40 AM, Nils Birnbaum wrote: >>>>> Some ideas that came in my mind: >>>>> >>>>> An institution could have a dedicated website for mobile devices or >>>>> an >>>>> app. So this has to be full customizable in the config. You need an >>>>> on/off >>>>> button, off by default, and key-value pairs for the URL and the link >>>>> text. >>>>> >>>>> <opencas...>.mobile=on/off >>>>> <opencas...>.mobile.url=link to app or mobile site >>>>> <opencas...>.mobile.text = "Watch this episode on our mobile-site" >>>>> >>>>> or >>>>> >>>>> <opencas...>.mobile.text = "Watch this episode with the matterhor2go >>>>> app" >>>>> >>>>> Just my two cent >>>>> Nils >>>>> >>>>>> I meant it in the broad sense of the work, not the http sense. >>>>>> Regardless, the >>>>>> preference for not having this displayed as a default is still one I >>>>>> hold. >>>>>> >>>>>> (and the ticket explicitly says "If so, display a link (and/or sth. >>>>>> else) >>>>>> to the >>>>>> matterhorn2go app") >>>>>> >>>>>> Do UI changes normally go through a UX process as well? We do want >>>>>> to >>>>>> keep >>>>>> things consistent across our UIs, don't we? >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> Quoting Denis Meyer<[email protected]>: >>>>>> >>>>>>> The ticket does not say "redirect", it explicitly says "display a >>>>>>> link". >>>>>>> >>>>>>> Denis >>>>>>> >>>>>>> On 1/26/12 10:23 PM, Christopher Brooks wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> There was some brief discussion on this ticket, >>>>>>>> http://opencast.jira.com/browse/MH-8525 , about whether the engage >>>>>>>> UI >>>>>>>> should detect the platform of the user and redirect them to the >>>>>>>> Matterhorn2Go app. I just want to clarify that I'm a -1 to this >>>>>>>> plan >>>>>>>> for the following reasons: >>>>>>>> >>>>>>>> 1. Lots of tablets play Matterhorn fine. >>>>>>>> 2. matterhorn2go is not Matterhorn. It's a separate project with >>>>>>>> a separate license. I think it's great, but it's not ECL and I >>>>>>>> don't >>>>>>>> want to redirect users to it by default. >>>>>>>> >>>>>>>> If this feature is going to be added then it should be able to be >>>>>>>> disabled, and should be disabled by default. Maybe even a >>>>>>>> "redirect_on_tablet" key that points to a URL of some kind. But >>>>>>>> it >>>>>>>> shouldn't be redirecting to matterhorn2go by default. >>>>>>>> >>>>>>>> (I share Hanks view that there are likely to be many similar >>>>>>>> projects >>>>>>>> that institutions may want to brand or value-add) >>>>>>>> >>>>>>>> Chris >>>>>>> _______________________________________________ >>>>>>> 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] >>>>>> _______________________________________________ >>>>>> >>>>> _______________________________________________ >>>>> 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] >>>> _______________________________________________ >>> _______________________________________________ >>> 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] >> _______________________________________________ > _______________________________________________ > 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] _______________________________________________
