Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full screen vs Fill window.... thoughts? #339

Closed
JohnSmith-LT opened this issue Jun 17, 2015 · 8 comments
Closed

Full screen vs Fill window.... thoughts? #339

JohnSmith-LT opened this issue Jun 17, 2015 · 8 comments

Comments

@JohnSmith-LT
Copy link
Collaborator

We have both options in the wizard, recently I was asked why and I couldn't really answer other than to say that they are legacy options...

People can understand what 'Fill Window' does but when they select 'Fill Screen' they expect it to go full screen... wondering what other think about this...

It's relatively easy to do actual 'full screen' but how do we handle the toggling with 1 button. Caveats are that you cannot go full screen from onload event, only from a user interaction like click. My thoughts are:

Going full screen would solve the iframe issue and also to some extent the peer review issue #213 but would it cause issue with previous LOs...

When you click fullscreen button first time (or on load if you've selected fullscreen option) user gets a popup where they can select either full window or full screen and this is then remembered until they reload the LO

'Full Screen' Isn't really supported on mobile so we should always default to Fill Window there...

@ronm123
Copy link
Collaborator

ronm123 commented Jun 17, 2015

Hi John
yes legacy as in they were both needed for the Flash Player version because filling the windows was desirable but some didn't like the stretching that would happen so full screen kept the ratio/shape without stretching. Arguably that still applies and if we followed suit for html playback we should replicate the full screen option and maintain the ratio without stretching horizontally. That said it's probably easier to deprecate the full screen option if we can.

Until we get the xot template fully responsive I think a more useful feature if its possible would be a browser zoom button so that the shape/ratio is preserved but the view/zoom of the LO scales until the height of the browser window is reached.

Just some thoughts...

@JohnSmith-LT
Copy link
Collaborator Author

Hmm, I can still see a use for the Full screen option as it would allow iframed LOs to breakout, something that cannot be done at present even if the browser is full screen...

I can see with the flash player why people didn't like the aspect ratio change because it also skewed images and text but that doesn't happen with the HTML version... With HTML version though it does change the usefulness slightly though because the text or images don't scale and can end up really small on a big screen...

@JohnSmith-LT
Copy link
Collaborator Author

Actually Ron, thinking about this more, I think that there are two distinct issues that have been raised...

I do agree with your idea of deprecating the onload "full screen" option in the LO options in the wizard... it doesn't really make sense as is, especially in the browser world as default full screen is considered a security risk and is restricted without user interaction such as a click...

The other issue maybe is what the minimise/maximise button does... We were demonstrating some LOs at a session recently and they were all iframed in a webpage. Several people clicked the 'full screen' button only and were curious why it didn't actually do anything (since the iframe was the same size as the LO)...

Do you think that the maximise button is something that could/should have the option of enabling true full screen mode(where possible)? Maybe with a popup to allow full window/full screen to be selected or maybe through a 3 way toggle?

@ronm123
Copy link
Collaborator

ronm123 commented Jun 18, 2015

Hi John
not sure if there's an easy and reliable way to detect if the LO is being viewed via an iframe but if there is perhaps it should work like this..
User clicks existing 'fill window' button when viewing an LO (Note: Tooltip ought to say 'fill window' rather than 'full screen'
If currently in an iframe opens a full screen pop-up/new window
If not currently in an iframe just fills existing window as it does now but perhaps also prompts do you want to view full screen? Y/N

Not sure exactly what you mean by a 3 way toggle?

@JohnSmith-LT
Copy link
Collaborator Author

So you think it would be better to open a new popup window rather than use the same browser fullscreen api that the likes of Youtube use? I've recently felt that opening new windows is slightly frowned upon as they can open in a new window, new tab, behind current window or not at all depending on browser settings...

By 3 way toggle I meant Off-Full Window-Full Screen-Off... but that was probably a bad idea from the outset...

@ronm123
Copy link
Collaborator

ronm123 commented Jun 18, 2015

Hi John
no sorry busy with other things so not too much time to think it through. I was thinking more about your scenario of breaking out of the iframe.

Whenever I embed an LO within another page e.g. Moodle or blog or bootstrap project etc I usually manually add a link below the embedded LO to open in a new window. So I was really just thinking about that being built-in to the interface/button functionality.

I do think though that a users choice to fill the current browser window is different to a users choice to view full screen hiding everything else including address bar etc.

@JohnSmith-LT
Copy link
Collaborator Author

No worries, it's not high priority anyway so i'll keep thinking about it...

@thexerteproject
Copy link
Owner

We should just remove full screen for now. If you wan true fulll screen you can get it from the browser. I think this is something the end-user should be in control of: I don't want people launching full screen content without my say-so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants