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

Updates to IFrame properties visual editor dialog #1536

Open
zachberry opened this issue Sep 21, 2020 · 2 comments · May be fixed by #1828
Open

Updates to IFrame properties visual editor dialog #1536

zachberry opened this issue Sep 21, 2020 · 2 comments · May be fixed by #1828
Labels
editor enhancement New feature or request stale
Milestone

Comments

@zachberry
Copy link
Member

zachberry commented Sep 21, 2020

What we have now in the editor to edit/set iframes was a first step so some of these aren't surprises. That said, the biggest pain for authors adding in iframes is:

  1. Don't know if it's setup correctly / working until you preview
  2. Lots of options, some which aren't clear
  3. In the XML/JSON you can specify the type of content, which sets defaults for how to display the iframe - there's "media" and "webpage". Those don't play super great with the visual editor UI
  4. If you want to embed (for example) vimeo you'd need to get the <iframe embed code, then know enough HTML to pull out the "src" attribute, and then copy the width and height into our UI.

Suggesting a revamp of the dialog to solve these problems:

Editing a brand new iframe:

image

Here we let you paste the iframe embed code from a site, and we'll auto extract all the relevant information - really just "src", "width" and "height". There's also an assumption we'll make here - if you paste in <iframe> code we'll assume you're probably embedding media, and if it's just a regular URL you're probably embedding a webpage. Once you paste in something this first dialog could expand:

image

Here we go ahead and try to embed what you pasted just so you can confirm it's working. If they click the "No" link here it could expand to explain that some pages may restrict their content inside an iframe, or, to make sure if you're trying to embed media to use the iframe code and not the regular url

If you click Yes you'd get to this step:

image

(I didn't draw having one of the Content type options selected, but it one of them would be selected in the actual UI)

Here if you click 'Change' it would take you back to the previous page. We'd also go ahead and pre-select Content type for you, based on the assumption I mentioned from earlier.

Assuming that 'Video or other media' is selected, the rest of the dialog is a smaller subset of options. Sizing would define the dimensions of the iframe. The first choice - full width - sets the iframe to the maximum width (same width as questions, which extend past the text). The second choice is similar, it just maxes out at the same width as the text. Finally the last option uses the exact width.

IF the iframe that they copied had width and height values then we can determine the ratio of the iframe - typically for video that will be around 16:9. If you pick the first two responsive options we basically set the width to 100% and use the ratio to determine the height (the iframe node already does this stuff) - but then we don't really need to show you the Width and Height inputs since they are just needed for the ratio. However the 'Edit dimensions' link would let you change those values.

If you picked the Fixed size option you'd be shown the width and height inputs.

If you paste in <iframe> embed code but there isn't a width and height then we can't determine the ratio. In that case, we'll assume a 16:9 default with a size of 600 * 338.

Next option - Loading - would replace "autoload". Using a select box instead of the toggle just so that we can explain the different choices, and in the example you can see a warning about why the auto option might be negative. Additionally, we could add in a lazy-load option, if we use IntersectionObservers to determine when the iframe is on the screen.

IF you pick one of the auto-load options you don't need to set the title, so when selecting one of those options we'd hide the title input.

FINALLY, you can click "Show all options" which would give you every option that we're hiding (such as which controls to display, etc). I don't have that UI mocked up here.

IF you paste in an YouTube link we'd notify you that we have a special display for YouTube video and ask if you want to convert this to use the YouTube chunk instead. That UI isn't mocked up (This could be moved to a separate issue)

Second, if you paste in a URL (not <iframe> code) and we assume you're embedding a webpage the sizing options are a little different. In that case the width is always fixed, and the height is what can change. So instead of "Sizing" we'd probably switch that label to "Width", since it describes the width. below that we'd have an input for height, since we do need that - but the placeholder text would be set to the default if you don't set anything (which I believe is 500px?). If you picked the Fixed size option we would then add an additional input for you to set the width in px.

@zachberry zachberry added enhancement New feature or request editor labels Sep 21, 2020
@zachberry zachberry added this to the Upcoming Priorities milestone Sep 21, 2020
@zachberry
Copy link
Member Author

zachberry commented Sep 21, 2020

To support the changes above, the type attribute would be expanded to accept "none" as an option, meaning accepted values would be none, webpage and media. When an iframe is newly created in the editor it would default to none - that allows you to know when to show the first dialog or the second. An iframe of type none should ignore all other properties (if an author manually writes a document with <IFrame src="website.com" type="none" /> the src property should be ignored and the iframe would be rendered as empty in the Viewer). We'd make a note in the docs that none typically wouldn't be used when writing XML/JSON.

The new Sizing property I'm thinking should be called sizing, with these possible values: max-width, text-width and fixed. In order to not break existing documents if sizing is not set the default should be fixed, which is current behavior. However, in the UI when creating a new IFrame the default selected choice would be the "Responsive - full width" option (or max-width).

Current IFrames (retroactively considered to be fixed) have their widths max out at the same width as the text. I think the best option moving forward is to now max their widths out at the max possible width (aka same width as questions). This is a breaking change that will change the look of existing documents, however this gives more freedom to authors and potentially causes an iframe that used to have to scale down to no longer scale. My thought is that when choosing the "fixed" option the dimensions of the iframe are the most important consideration, and we should bend as much as possible to allow for the size to match as expected. I'm open to feedback on this however.

@zachberry zachberry modified the milestones: 20 - Tanzanite, 21 - TBD May 3, 2021
@maufcost maufcost linked a pull request May 20, 2021 that will close this issue
@zachberry zachberry modified the milestones: 21 - Beryl, 22 - TBA May 24, 2021
@zachberry zachberry modified the milestones: 23 - Rose Quartz, 24 - TBA Jun 24, 2021
@zachberry zachberry modified the milestones: 24 - Sunstone, 25 - Bixbite Jul 26, 2021
@deundrewilliams deundrewilliams linked a pull request Feb 28, 2022 that will close this issue
@stale
Copy link

stale bot commented Sep 21, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep our backlog under control, but we thank you for your contributions.

@stale stale bot added the stale label Sep 21, 2022
FrenjaminBanklin added a commit to maufcost/Obojobo that referenced this issue Mar 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editor enhancement New feature or request stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants