Content Editor Sandbox

Purpose

The Content Editor Sandbox aims to demonstrate all possible implementations of the IAL JSS Component Set on a BAUPage Template:

• to guide UX Design possibilities
• to help BAs identify where feature extension or new components might be required
• to provide a single location for QA regression testing of component functionality
• to show new Content Editors how components may be populated and added to a page
• to audit component set and identify behavioural inconsistency/bugs

Components should be reviewed at four optimised breakpoints

• 1920px (Full)
• 1280px (Desktop)
• 768px (Tablet)
• <768px (Mobile)

Known issues with the page:

• Page width exceeds device width at lower breakpoints - this is caused by a bug on CTAList component. TECHNICAL TASK 49364 raised to resolve.
• Rich Text paragraph styling is not correctly implemented. Ticket to be raised - once resolved, this will cause all paragraphs to appear with too much vertical spacing. Many 'nbsp' paragraphs will need removing site-wide to correct.

IAL JSS Component Set

For purposes of this page, the component set comprises all components that can be added to multiple pages. Specialist components for specific pages such as Article, Account, Checkout, etc are excluded.

SEO recommendation: H-Tags

Below are H-Tags H1-H6, as rendered using markup in Rich Text component. Usually these tags are hardcoded to a field, so may render differently depending on the component.

The primary purpose of H-Tags is to tell page crawlers and screen-readers

• what order to read the page in
• what the most important subject of a page section is

Ideally, the front-end Design matches up with this

• H1 tags are rendered as the largest text near the top off the page to indicate importance and summarise subject.
• Text size gets smaller with each subsection.

But sometimes UX Designers will want to alter the size and style of an element.

In these instances, we should not edit H-Tags. Instead we should use style classes.

• Example: An 'eyebrow' that appears above the H2 section title. This may look like an H6 (uppercase; primary theme; font size) but it is better handled as a unique class so as not to confuse read-order.
• Example: An H1 page title renders at H4 size so that more text can fit into the available space. This may look like an H4 (size) but is better handled as a unique H1 Class, so as not to lose the SEO value and read-order of H1.

This ensures that the text looks as Designers intend, but still makes sense for machines, providing best Accessibility and therefore best SEO.

This is H1

This is H2

This is H3

This is H4

This is H5

This is H6

Content Container Block

Below is a Content Container Block component. Component allows editor to add a large banner image with centre aligned Title (H1/H2), plus two CTAButtons.

A video can play in place of the banner image if required.

A logo of fixed size can be added if required.

Adding the Content Container Block to the page enables editor to add the Navigation Block to the page.

Image sizes for use

A single image field is used for Logo at all breakpoints, therefore dimensions must suit largest instance. 

Design considerations:

• More than two CTAButtons can be added in the component CTA list, but they will not be rendered with correct spacing.
• Editor can include a Sound On/Off control for User via component setting in Presentation.
• Despite its name, this component is really only set up to be a Container for the Navigation Block. Any other component is better managed by adding below the Content Container component, not in it.
• BUG? Seems like the breakpoint images are not quite right. Though it is possible to add a Desktop banner image, the Full image is still used as source at 1280 breakpoint. Therefore, any image used currently needs to be large enough for 1920, but with the focus of the image within a 1280x720 cropping 'safe space'.

Example 1 - Full Width

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

This is the Content Container Block with all fields populated and sound control setting on, for use as a page Hero. A Navigation Block is added.

As seen on campaign pages The Final Mile, Grenadier Trails, Testing & Development (Grenadier VS).

This is the Content Container Block with simpler settings - no video or logo, no Navigation Block. Can still be used as main page Hero if heading field set to H1, but if used later in page, heading is set to H2 for good content structure. 

This is the Content Container Block with minimal settings, for use as a page break. The Heading field can be left empty, though not ideal from SEO perspective. Logo is included here, but is optional. Could be used to display video with limited controls (compared to In Page Video).

CTA List

Below is a CTA List component. Component allows editor to add multiple CTA Buttons including Share, SlideIn, CTA button, WatchVideo.

Design considerations:

• Stacks at mobile but no vertical padding between each button by default. This cannot be set within component either. TECHNICAL TASK 49364 raised to resolve.
• No horizontal padding between each button. This cannot be set within component either. TECHNICAL TASK 49364 raised to resolve.
• Horizontal Margin settings do not render for this component. There is no left align. Buttons are added centred. There is no wrap breakpoint, just switches to mobile display below 768px. TECHNICAL TASK 49364 raised to resolve.

Example 1 - Full Width

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

Example 2 - Normal

Item added directly in the One Column Container with layout setting Normal.

Margins: None

Homepage Promo

Below is a Homepage Promo component. Component allows editor to add a large banner image with Title, Description and single CTA.

Image sizes for use

Design considerations:

• Currently the CTA is embedded. This means editors can never remove the button entirely (see example). It also means that possible CTAs limited to one.
• The image and text box are stacked instead of layered at lower breakpoints.
• Slightly different behaviour at 1920 when set to Full Width
• Despite its name, this component can be used on any page

Example 1 - Full Width

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

Example 2 - Normal

Item added directly in the One Column Container with layout setting Normal.

Margins: None

HotSpot

Below is a HotSpot component. Component allows editor to add a large banner image with multiple HotSpot Points which appear over the image in positions defined by the editor. Each HotSpot Point can display text and video when selected.

This shows the new HotSpot design, activated by checking the Product Page Design component setting in Presentation. The legacy design is currently still supported but in the process of being phased out.

Image sizes for use

A single image field is used for all breakpoints, therefore dimensions must suit largest instance (1920). 

Ideally an image of double the standard dimensions is used, to ensure detail is not pixelated when the zoom feature is triggered.

Design considerations:

• Currently the same image source and HotSpot Points are used at all breakpoints
• Only Rich Text and Video are currently supported; ticket USER STORY 47267 will extend functionality to support image and CTAButton
• This component renders according to the designed 'Full Width' style, regardless of additional settings added in Presentation
• There is no limit to the number of HotSpot Points that may be added

Example 1 - Full Width

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

Example 2 - Normal

Item added directly in the One Column Container with layout setting Normal.

Margins: None

Example 3 - Full Width + Forced Narrow Margins

Item added directly in the One Column Container with layout setting Full Width.

Margins: Desktop (0px 640px); Tablet (0px 63px); Mobile (0px 20px)

As a repeating and consistent Design requirement these should be a baked-in Layout Setting for all components, like Full Width and Normal.

Pixel by pixel setting for every breakpoint & every component adds much build time and leaves users with too much scope for inconsistent layouts.

Even if applying for every component, there is a gap in available margin fields. 'Desktop' margin is applied for 1920 and 1280 breakpoints. These breakpoints will frequently have different margin requirements.

Example X - Legacy Design

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

This is Hotspot with legacy design settings. Use of this layout is being phased out, after which only the 'Product Page Design' setting will still be possible.

Quote

Below is a Quote component. Component allows editor to add pull quote either as simple text or as text with image. 

There are now 6 possible renderings of the Quote component, using various settings in the Presentation.

Image sizes for use

Quote With Image

Quote On Image

Design considerations:

• This is component is a good example for clean asset management

1. Image renders at 16:9 regardless of breakpoint
2. At the same time, there are small/medium/large field allowing different intrinsic size versions of the image to be served for render.

Example 1 - Full Width

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

Example 2 - Normal

Item added directly in the One Column Container with layout setting Normal.

Margins: None

Example 3 - Full Width + Forced Narrow Margins

Item added directly in the One Column Container with layout setting Full Width.

Margins: Desktop (0px 640px); Tablet (0px 63px); Mobile (0px 20px)

As a repeating and consistent Design requirement these should be a baked-in Layout Setting for all components, like Full Width and Normal.

Pixel by pixel setting for every breakpoint & every component adds much build time and leaves users with too much scope for inconsistent layouts.

Even if applying for every component, there is a gap in available margin fields. 'Desktop' margin is applied for 1920 and 1280 breakpoints. These breakpoints will frequently have different margin requirements.

Example 4 - In Container Component

Item added in the HeroContainer. When adding to Container components, no layout setting required.

Margins: none (Items added to Containers should behave according to the Container settings)

Related Articles

Below is the Related Articles component.

Component allows editor to add up to 3 Cards each with Title, Description, Image, Link. The row can also be given a Title.

Cards can be created locally (specific to this page only) or at global level (re-used many pages).

Image sizes for use

• 400x267 (3:2) - dimensions actually rendered vary depending on device display size

Design considerations

• Text alignment always Left. Centred not an option.
• Overall Title is optional - in Example 1 it is populated for the first row component, unpopulated for the second row component.
• Title, Description, Image fields for each card are optional, but empty description field is rendered.
• Link is mandatory. If this field is empty the card does not display. Therefore, may not be used simply to display text/image in three column layout.
• Link is not a separate button. Therefore, style cannot be changed from the one shown.
• Link is not a separate button. Therefore, SlideIn content link cannot be used.
• Date field is only rendered if linking to a target page with Date value (ArticlePage or descendant). It cannot be manually populated or hidden by editor.
• Tablet breakpoint stacks 2,1.
• Single source image is repeatedly cropped horizontally from approx 21:9 to 1:1 as display reduces, but maintains a 245px height. This can make it difficult to select an image best fit for all displays.

Example 1 - Full Width

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

Example 2 - Normal

Item added directly in the One Column Container with layout setting Normal.

Margins: None

Rich Text

Below are several Rich Texts components.

Design considerations:

• Other styles like h6 in primary theme appear to be possible but must be added manually via HTML edit. Extent of theme classes to be investigated. Improvements needed for UI.
• Dark theme for this component turns text white only. The dark background must currently be added by placing the Rich Text component in a Container with the background. E.g. Hero Container
• No dedicated Grey theme for this component. A grey background must currently be added by placing the Rich Text component in a Container with the background. The Rich Text component would remain set to Light theme. No examples of Container with this setting currently.

Example 1 - Full Width

Item added directly in the One Column Container with layout setting Full Width.

Margins: none

Example 2 - Normal

Item added directly in the One Column Container with layout setting Normal.

Margins: None

Component allows editor to add text including:

• hyperlinks internal and external which render in INEOS Red and underlined, as per design
• HTML tables (see separate section)
• theme-primary span class which allows editors to force a highlight in INEOS Red
• theme-secondary span class which allows editors to force a highlight in INEOS Blue *DOES NOT SEEM TO WORK - BUG?*
• Small span class which allows editors to force a small footnote/disclaimer text size
• Text alignment:

This text is aligned Left (default)

This text is aligned Centre

This text is aligned Right

• Also H tags:

This is H1

This text shows how paragraph spacing render following the H Tag above. Vertical and horizontal spacing should not be forced inline by adding empty paragraphs and/or style classes to whole chunks of text - this gives too much scope for User to stray from standardised UX Design, and excess markup is detrimental to accessibility and SEO.

This is a second paragraph added with <p> tag markup - note there is no double space as expected from UX Designs. Where rich text is spaced for good readability elsewhere on this page, we have forced this space with excess markup.

This is H2

This text shows how paragraph spacing render following the H Tag above. Vertical and horizontal spacing should not be forced inline by adding empty paragraphs and/or style classes to whole chunks of text - this gives too much scope for User to stray from standardised UX Design, and excess markup is detrimental to accessibility and SEO.

This is a second paragraph added with <p> tag markup - note there is no double space as expected from UX Designs. Where rich text is spaced for good readability elsewhere on this page, we have forced this space with excess markup.

This is H3

This text shows how paragraph spacing render following the H Tag above. Vertical and horizontal spacing should not be forced inline by adding empty paragraphs and/or style classes to whole chunks of text - this gives too much scope for User to stray from standardised UX Design, and excess markup is detrimental to accessibility and SEO.

This is a second paragraph added with <p> tag markup - note there is no double space as expected from UX Designs. Where rich text is spaced for good readability elsewhere on this page, we have forced this space with excess markup.

This is H4

This text shows how paragraph spacing render following the H Tag above. Vertical and horizontal spacing should not be forced inline by adding empty paragraphs and/or style classes to whole chunks of text - this gives too much scope for User to stray from standardised UX Design, and excess markup is detrimental to accessibility and SEO.

This is a second paragraph added with <p> tag markup - note there is no double space as expected from UX Designs. Where rich text is spaced for good readability elsewhere on this page, we have forced this space with excess markup.

This is H5

This text shows how paragraph spacing render following the H Tag above. Vertical and horizontal spacing should not be forced inline by adding empty paragraphs and/or style classes to whole chunks of text - this gives too much scope for User to stray from standardised UX Design, and excess markup is detrimental to accessibility and SEO.

This is a second paragraph added with <p> tag markup - note there is no double space as expected from UX Designs. Where rich text is spaced for good readability elsewhere on this page, we have forced this space with excess markup.

This is H6

This text shows how paragraph spacing render following the H Tag above. Vertical and horizontal spacing should not be forced inline by adding empty paragraphs and/or style classes to whole chunks of text - this gives too much scope for User to stray from standardised UX Design, and excess markup is detrimental to accessibility and SEO.

This is a second paragraph added with <p> tag markup - note there is no double space as expected from UX Designs. Where rich text is spaced for good readability elsewhere on this page, we have forced this space with excess markup.

Editor view also supports the following:

• Extra Small span class which allows editors to force an almost illegible text size - use case for implementing not known - was not a Content request
• Bold span class which allows editors to force bold markup without simply using the out-of-the-box strong ('B') function - use case for implementing not known - was not a Content request
• There are also CSS style options for forcing various margins in-line, but these will not be demonstrated as Editors should never need to use such overrides - margins should be managed exclusively at outside of components to avoid code bloat, reduce errors in translation, promote re-usable items, and to prevent users from straying from standardised UX Designs. Use case for implementing not known - was not a Content request

Example 3 - Full Width + Forced Narrow Margins

Item added directly in the One Column Container with layout setting Full Width.

Margins: Desktop (0px 640px); Tablet (0px 63px); Mobile (0px 20px)

As a repeating and consistent Design requirement these should be a baked-in Layout Setting for all components, like Full Width and Normal.

Pixel by pixel setting for every breakpoint & every component adds much build time and leaves users with too much scope for inconsistent layouts.

Even if applying for every component, there is a gap in available margin fields. 'Desktop' margin is applied for 1920 and 1280 breakpoints. These breakpoints will frequently have different margin requirements.

Example 4 - In Container Component

Item added in the HeroContainer. When adding to Container components, no layout setting required.

Margins: none (Items added to Containers should behave according to the Container settings)

Example 5 - In Tabs Component

Item added in second tab of the Tabs component. When adding to Structure components like Tabs, no layout setting expected required.

Margins: none (Items added to Structure component should behave according to the Structure component settings)