Just a quick answer since i (we) have not studied all the #proposal in detail.
I personally like most of changes proposed. Without me being an UAX expert (and then probably not being right in some respects), I think they improve the look and improve/don't harm the usability. I share Chris' concerns regarding the colours --even though I like them, I think it's not about tastes but about keeping a uniform "branding". However, I like the side-menu idea --we have been using it (as you could see in the Unconference video page) for a while in our PuMuKIT integration and it is so handy. Re. the date format: I think it is a deeper discussion, since there are significant differences in date representation that should be taken into account if we want to "please" all the possible costumers (the position of the month and day number, for naming the classical problem). That being said, I don't see anything specially "wrong" with the date format, but I agree with that being configurable (even though that could be applied to the whole UI). BTW, "Mittwoch", if my German is not so rusty, means "Wednesday". Seems like a busy day in Osnabrück ;-) Best regards 2012/3/5 Christopher Brooks <[email protected]> > Hi Ruediger et al, > > Here are some thoughts on specific features described on > http://opencast.jira.com/wiki/display/MH/Engage+1.4 . I'll try and > tease them apart point by point. Overall I really like some of the > looks you have changed here. > > 1. Sorting on title and other attributes. > > +1, feature request we have been asked for locally. > > 2. Removing paging and replacing by continuous scrolling. > > I like the idea but there is a good use case for paging that we see > here. E.g. "I know the lecture was about a month ago, the course is > two months in, so I'll just jump to halfway down the list of item". > How can we keep support for this feature while allowing the continuous > scrolling? > > (the historical list of lectures is likely of higher interest > than the historical list of wall posts; does a continuous scrolling > method fit out needs?) > > 3. Implement A B C D E F G... for recordings list > > Don't like it much as it clutters things up. Prefer that people just > search. > > 4. Implement a series tab > > I like it. Have come comments on the metadata described in the mock up > (prefer a different date format, don't know what Mittwoch means, etc. > etc.), but overall I like it. > > Here's a thought: Allow admins to create a "template" that describes > how the episode is rendered. E.g. that could write something like: > > <span>$thumbnail</span> > <span><b>$episode.name</b></br><i>by $episode.instructor</i> > </span> > > etc. > > Outside of the scope of what you are providing, but this would allow us > to both have a consistent and cohesive delivered project yet limit the > amount of custom coding that needs to be done to make the UI > customized. > > Same load ten at a time for episodes here, or a scrollbar and loading > all episodes? > > 5. Video controls/timeline functions > > In this mock up: > > http://opencast.jira.com/wiki/download/attachments/26574976/playermockup.jpg > > What does the gear icon mean? > Will the scrubber be shown by default? (I think it should be) > > I don't mind the accordion but worry that embeded single stream video > will make it difficult to pull off (what if there isn't room for all of > the items in the button group? e.g. if this video was half the size it > currently is, what would happen with "view statistics", "view > chapters", "view comments", etc? > > What does "See more" mean as a tab in the bottom area? > > Agreed on > 2 video streams as a useful feature. > > 6. Toolbox on the left > > Not sure on this, it dramatically changes the way the player works. We > need the ability to add more tools, but I'd like to hear some usability > results first. Is it confusing to students? > > 7. Download, Share, Shortcuts > > I don't mind this information being up here. Guess it means it won't > show up in the embedded player, but I think I am ok with that. > > > General comments: > - Significant changes to the UI warrant not just gut instinct but some > usability testing. Is this really in scope for 1.4? If so, there is > no hope of us getting it out for May. > - If you have a deployed prototype, I can see about getting some > usability testing done here, maybe Judy can as well? We could at > least do some less formal usability testing (think aloud, etc.). > - I have strong feelings on the colours. I don't care about the actual > colours much, but I think it's part of a bigger marketing question > for our application. > > Regards, > > Chris > > > On Mon, 05 Mar > 2012 12:10:15 +0100 Ruediger Rolf <[email protected]> wrote: > > > Hi list, > > > > we would like to propose a general concept for the engage player in > > the upcoming releases. Depending on the timeline for 1.4 we would > > start with these changes and see how far we will come for the next > > release. Other enhancements from this proposal may make it to later > > releases then. > > > > http://opencast.jira.com/wiki/display/MH/Engage+1.4 > > > > Please see this as a working document. These are the ideas that we > > had here in Osnabrück how we can improve the Engage UIs. As I tried > > to write down the concept on the page already here simply some > > highlights: > > > > Matterhorn Media Module: > > + Series View > > + Sorting of Series and Episodes > > + Continuous scrolling instead of paging (as known from facebook i.e.) > > > > Matterhorn Engage Player: > > + 4 functional areas where UI elements for new features can be placed. > > + no more dialog overlays. > > > > About the color scheme: > > Please keep in mind that we implement this as CSS afterwards. We > > would like to introduce some new colors to give the UI a fresh > > updated look. It will be easy to make changes to the color scheme, > > when we implemented the engage UI in HTML. So the discussion what > > will be the colors we release matterhorn with can be one of the last > > things that we have to decide about before a new release... If > > somebody wants to contribute to this discussion then he should simple > > create the new CSS files. > > > > > > We are open for comments and contructive feedback on these designs. > > This proposal is based on what we in Osnabrück are willing to > > contribute into development in this area. If you would like to > > request/propose extensive changes from our approach please keep in > > mind that you should be willing to contribute resources for your > > ideas too. > > > > Thanks > > Rüdiger > > > > > > -- > Christopher Brooks, BSc, MSc > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > 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] _______________________________________________
