Just going to tag on to the end of this conversation, with a few random thoughts, at various levels. 1) Very nice work overall! I think this is going in the right direction. 2) I agree with Chris that user testing would be a good idea, and I'm quite sure I can contribute to this (doing the testing, maybe even coming up with the protocol). 3) Can I suggest for the default date format that we just stick with the international format defined by ISO (ISO 8601): YYYY-MM-DD. This way we're not "favoring" anybody. 4) "See more" is an example of what can happen when incremental UI changes are made without full consideration of the (cognitive) impacts. "See More" was originally a link placed right next to the series name, to mean "See More recordings in this series". (See Tona's designs at http://opencast.jira.com/wiki/display/MH/Conceptual+framework+-+global). I don't know at what point the Series name was removed from the UI, but you're right that "See More" makes little sense on its own, and even less when it becomes a tab. (All the other tabs are about *this* video.) 5) Has the Osnabruck team been following the work that's being done on the Fluid player? (I've not had time to examine it closely, but I'm guessing they had decisions to make that we'd find interesting if not entirely applicable.)
Judy On Mar 5, 2012, at 11:18 AM, Christopher Brooks wrote: > Hi, > >>> 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. >> I'd like to answer 2. & 3. together: Just imagine that A B C... would >> be 15/01/12 22/01/12 29/01/12 instead if you sorted the recordings by >> date. The scale would be adopted to the available space and the time >> you are running your Matterhorn server already. Additional we might >> add a date-picker here too. This would simply replace the paging by >> something more meaningfull. I can never remember in our current >> installation if the recordings from last september are on page 21 or >> 35. If you jumped to last december you can scroll up and down and the >> continuous scrolling will automatically reload the new data. > > I'd be open to this method I think. > >> And navigation by searching just works if you know what you are >> searching for. The navigation with the letters works better for >> browsing through the content. > > Right, what I really want is "temporal browsing", and our current UI > supports that "kind of", and I find myself doing it lots so I wouldn't > like to lose it. > >>> 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. >> It's outside scope for us, but feel free to contribute this. And if >> we start it here we probably should incorporate such a templating >> anywhere in the system. > > I think so too. We're pretty focused for the next six months on > analytics issues, but hopefully after that there will be some > opportunity to contribute to the general UIs. > >> This is not a mockup for the embed-player. We would not touch it and >> keep it as it is currently. > > Does the mock up change the underlying player at all (SWF)? > >> currently no sorting for episodes in the rest interfaces) and the top >> information menu will make it into 1.4. I don't know how far we will >> get with the accordeon below the player. And we will keep the tools >> area on the left for 1.5, so there should be enough time to test this >> concept. > > Great. In principle I'm on board with this, specifics to be discussed > after they go in. > >>> - 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.). >> We have not prototype we would like to discuss this first, before we >> would spent our time on this. > > I'm fine with just testing a certain rev number too, from a branch or > wherever it is being developed. > >> system. The colors we introduced are variations of the already used >> colors. In our point of view these colors hamonize quite well and >> they are not as saturated as the red, orange, blue-green and black >> that we currently use to make the controls and the matterhorn >> appearance more decent and let the content be more in the focus. > > I've got some light colour blindness and really don't care much about > colours, but I just want to make sure things are as harmonious as > possible (and with our website). I like the idea of coming up with > some CSS files to skin things, and we can always just go back to the > current ones if we can't find agreement... > > Chris > -- > 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] _______________________________________________
