videoPlayer tests

Fri Feb 17 21:13:48 UTC 2012

Hi Alex,

I've had a little more time to look at your notes in depth. My comments are inline below.

Thanks again!

Michelle

> 
> videoPlayer -> /demos/VideoPlayer.html
> 
> videoPlayer starts maximized an then resizes itself to the normal sizes. The effect is more visible if the FireBug is on.  Is this how it's suppose to be?

As you know, since you opened the FLUID-4605 issue, this is a bug that would be good to fix. 

> Alt Label "Mute" is being displayed below the sound slider which makes it very hard to read when you hover over Mute/Unmute button.

This should be handled by the high fidelity changes in FLUID-4556.

> Clicking Mute/Unmute button will leave sound slider in the videoPlayer control panel. Is this how it's suppose to be?

This has changed in the FLUID-4556 branch.

> UIO. If you set text size to the max it will shift some of the  elements in the control panel to be on a separate line. I assumed that the expected effect suppose to change the videoPlayer sizes but also would keep its structure and form. Is this how it's suppose to be?

I created FLUID-4611 to handle this issue.

> UIO. Weird case. If you set text size to the max it will increase font size as well as videoPlayer control button sizes. Now refresh the page, text will stay resized while buttons will be small.

This is fixed in the FLUID-4556 branch.

> UIO. When you set a Text Size to the max as well as Spacing to the max you will see how caption area will be overlapped with time slider. Presumably should be solved by using captionator?

> Whenever you have captions on the screen (play or pause does not matter). Changing caption language will remove a caption panel from the videoPlayer. Presumably should be solved by using captionator?

Let's wait until the captionator branch is done to see whether these are still bugs.

> UIO. Weird case. The issue which is an agglomeration of the issues listed above. videoPlayer looks very confusing and hard to use if you set everything to the max Text Size, Line Spacing and Make Inputs Larger.

Could you open a JIRA with a screen shot of this?

> UIO.  In the top bar. Emphasize links tells in the description: Makes links larger, bold, and underlined. But it increases the size of the sliding box in the time and sound slider. Is this how it's suppose to be?

I'm not quite understanding what you are seeing here, can you open a JIRA with a screen shot?

> Caption area is not clickable through. Is this how it's suppose to be? Presumably should be solved by using captionator?
> videoPlayer shows a captions control panel right in between the other video control buttons when you click on Captions button instead of showing a panel popup or a separate clearly distinctive div panel. This action also sets caption button on top of all other control buttons… pretty interesting UI changes.

Let's wait until the captionator branch is done and see whether these are still bugs.

> Very minor comment - do we need to show the alt for captions even when we clicked the button? (youtube example does not do it). I presumed that user aware of what he/she clicks on the screen and reads first. Otherwise you need to move mouse away from the captions button so that Alt would not hover over the controls area blocking the appeared panel. All alts are left aligned with button but not centred relative to the buttons?

I think we should show the tooltip, but we should probably fade it after some period of time. Perhaps we can get an opinion from a designer. 

> The whole dom expansion of the elements tend to expand to the bottom relative to the elements which causes interactions (e.g. When you hover over sound button a sound slider will appear at the bottom expanding . A new captions menu will also extend video controls shifting all other controls lower relative to their initial positioning). Does it make more sense to modify dom modifications so that new elements appear above the videoPlayer or expansion goes from bottom to the top. (again I bring youtube example since it is very convenient to watch video and modify its settings without seeing too many modifications to the DOM of the page and without additional scrolling respectively). As a good example would be: Make videoPlayer fullscreen, then you are forced to scroll down a browser window every single time you want to adjust volume since the volume slider will expand the video component at the bottom. Furthermore you have to keep your mouse close to the appeared slider otherwise the panel will go away which forces to use mouse wheel only.
> 

This has changed in the FLUID-4556 branch.

> mammals demo -> /demos/Mammals.html
> 
> Weird case. If you set UIO options on the videoPlayer page and then navigate away to the Mammals page all UIO options will be applied EVEN to the top UIO panel itself. You can observe the same behaviour if you navigate away from Mammals page to videoPlayer. Is this how it's suppose to be?

Yes, this is as designed. 

> The first video on the page does not work. It does not show video current time as well as total time of the video. If you click play/pause multiple time you will make video current time appear there. 

This has been fixed in the FLUID-4587 branch. 

> Almost the same as #2 one. If you click maximize/minimize multiple times you will see an interesting effect. The videoPlayer container will shrink to 0 size positioning all controls in one vertical line.
> The caption controllers modify caption settings only for the second video on the screen.

This should be handled in the FLUID-4589 branch. 

> When you maximize videos they will be shifted far to the right.

Full screen is behaving really badly. We should either pull that button out or fix this behaviour. FLUID-4570

> Some captions are on top of the video which completely blocks UI interactions with the video if you set Text and Line spacing to the max. Related to the remark #10 and #6 of the videoPlayer tests.

Let's check this again once the FLUID-4556 branch goes in.

> Very minor comment - every video is inside of some black container. Is this how it's suppose to be?

This has been changed in the FLUID-4587 branch. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20120217/20fefbc1/attachment.html>