Captivate 8 responsive design, breakpoints, iPhone 6 and heartbreak
December 26, 2014 11:33 PM Subscribe
I'm trying out Captivate 8's new responsive designs and HTML5 output and am very annoyed with how smartphones handle the HTML5 video. For now, I'm setting up alternate, video-free content for the Mobile breakpoint. But the huge size of modern phones means that their landscape viewports are often as wide or wider than the portrait viewports of proper tablets. Is there any way I can set up alternate content based on a device being a phone (popping out video in its own player) versus a tablet (displaying video like a civilized device)?
I would like the smartphone view of any page with embedded video to be replaced by simple alternate content with no video at all displayed because of the native player issue on phones. When I keep my mobile breakpoint at 480 instead of Captivate's default 320, this means the landscape view of my iPhone 4 meets the criteria for "mobile" and I get the alternate content I want for that device as defined within that breakpoint.
But as this site documents, a lot of modern phones are much taller and can have widths of 568, 667, or 735 pixels in landscape mode. Those values are too large to set as breakpoints for mobile: my primary breakpoint is set at 1024 and the tablet at 768. It gets really messy when I start looking at tablets like the Galaxy Note 8, which is only 601 pixels wide in portrait mode -- yes, narrower than a "phone" like the iPhone 6 or 6 Plus at 667 or 735 in landscape mode.
So if I set my mobile breakpoint to 735 (thank you, iPhone 6 Plus, you jerk), I'm locking out a lot of perfectly good tablets from displaying video when used in portrait mode. Apart from putting the breakpoint for mobile back to 480 and telling people on the opening page of a presentation that any screens with embedded video will be a pain to load on smartphones, what are my options?
I would like the smartphone view of any page with embedded video to be replaced by simple alternate content with no video at all displayed because of the native player issue on phones. When I keep my mobile breakpoint at 480 instead of Captivate's default 320, this means the landscape view of my iPhone 4 meets the criteria for "mobile" and I get the alternate content I want for that device as defined within that breakpoint.
But as this site documents, a lot of modern phones are much taller and can have widths of 568, 667, or 735 pixels in landscape mode. Those values are too large to set as breakpoints for mobile: my primary breakpoint is set at 1024 and the tablet at 768. It gets really messy when I start looking at tablets like the Galaxy Note 8, which is only 601 pixels wide in portrait mode -- yes, narrower than a "phone" like the iPhone 6 or 6 Plus at 667 or 735 in landscape mode.
So if I set my mobile breakpoint to 735 (thank you, iPhone 6 Plus, you jerk), I'm locking out a lot of perfectly good tablets from displaying video when used in portrait mode. Apart from putting the breakpoint for mobile back to 480 and telling people on the opening page of a presentation that any screens with embedded video will be a pain to load on smartphones, what are my options?
Response by poster: Digging into the code to add some conditional statements based on user agents may be a way to go, but it has always felt like a can of worms to me, and these commenters (admittedly, not dealing with my specific query about video) seem very skeptical about the reliability of that approach. I'm digging through this Google page, too.
When I design in Captivate, all these items are meant to be visible at any given time: table of contents, playbar, and the complete set of screen content (text, images, animations, custom buttons, quizzes, interactive elements, embedded video, and closed captions for accessible courses).
So if I design a screen that is as simple as embedded autoplaying video plus Captivate-built closed captioning, or a video plus some additional text to be displayed in sync with the video, the popout player takes the user away from all that supporting content to experience the video alone.
At this moment, the only partial solutions that I can think of are:
1) Presenting all the content possible within the video (adding always-on subtitles instead of user-controlled CC and any text or images that are supposed to be displayed in sync with parts of the video ). This would take some additional work within a video editor for every screen that uses video versus editing within Captivate only, and it would still be a rather annoying, disorienting user experience, I think.
2) Setting the breakpoint for the mobile view to 735 (to exclude all those damn phablets) but including some text on the page to tell tablet users that if they see this page, they should turn the device to landscape to load the full set of content. But this requires that the user change the way they use their device and could still potentially lead to some false positives. I could add an explanation for why the course is designed that way, but it really isn't the user's problem that I have these challenges, right?
posted by wexford_arts at 6:12 AM on December 27, 2014
When I design in Captivate, all these items are meant to be visible at any given time: table of contents, playbar, and the complete set of screen content (text, images, animations, custom buttons, quizzes, interactive elements, embedded video, and closed captions for accessible courses).
So if I design a screen that is as simple as embedded autoplaying video plus Captivate-built closed captioning, or a video plus some additional text to be displayed in sync with the video, the popout player takes the user away from all that supporting content to experience the video alone.
At this moment, the only partial solutions that I can think of are:
1) Presenting all the content possible within the video (adding always-on subtitles instead of user-controlled CC and any text or images that are supposed to be displayed in sync with parts of the video ). This would take some additional work within a video editor for every screen that uses video versus editing within Captivate only, and it would still be a rather annoying, disorienting user experience, I think.
2) Setting the breakpoint for the mobile view to 735 (to exclude all those damn phablets) but including some text on the page to tell tablet users that if they see this page, they should turn the device to landscape to load the full set of content. But this requires that the user change the way they use their device and could still potentially lead to some false positives. I could add an explanation for why the course is designed that way, but it really isn't the user's problem that I have these challenges, right?
posted by wexford_arts at 6:12 AM on December 27, 2014
Best answer: I don't think there is going to be a good way to do annotations with the popup player. But closed captions should be done with HTTP Live Streaming and WebVTT in modern browsers.
That doesn't get you all situations, but it does get you closer.
posted by sbutler at 10:42 AM on December 27, 2014
That doesn't get you all situations, but it does get you closer.
posted by sbutler at 10:42 AM on December 27, 2014
Best answer: You're not going to be able to achieve what you describe here with media queries alone. Responsive design is about designing web pages in such a way that all the content is available to all the devices, regardless of screen/browser size. What you want is a mobile solution distinct from the desktop solution, in which case, you should be using browser/device detection, which can only be done via scripting, and isn't 100% reliable. But it's your best bet.
posted by eustacescrubb at 10:10 AM on December 28, 2014
posted by eustacescrubb at 10:10 AM on December 28, 2014
Response by poster: Ah, well. I didn't think there was much of a solution for this specific issue, but at least I have some new things to read. Thanks!
posted by wexford_arts at 5:30 PM on December 29, 2014
posted by wexford_arts at 5:30 PM on December 29, 2014
This thread is closed to new comments.
What is it about the popout player that's a problem? Maybe we can suggest a work around.
posted by sbutler at 12:59 AM on December 27, 2014