Editing Structured Pages

A Structured Page is assembled from independently managed sections called Page Slices. Instead of maintaining the entire page as one continuous content structure, you select and arrange Page Slices to create the page's layout.

Page Slices can be reused across multiple Structured Pages, making it possible to maintain common content centrally while allowing each page to have its own structure and page-specific sections.

Structured Pages are particularly useful for multi-page websites, landing pages, and applications that share navigation, headers, footers, promotional sections, or other reusable content.

This guide explains how to compose Structured Pages, create and manage Page Slices, edit their content, and understand the effects of shared content on other pages.

Understanding Structured Page Composition

When you open a Structured Page for editing, the Page Editor displays a composition view rather than immediately opening a visual content editor.

The composition view organizes the page into three areas:

Area	Purpose
Header Page Slice	An optional top section, typically containing branding, navigation menus, or other content displayed above the main page body.
Body Page Slices	The main content of the page, assembled from one or more Page Slices arranged in a defined order.
Footer Page Slice	An optional bottom section, typically containing footer navigation, contact information, legal notices, or other recurring content.

Each Page Slice contains its own editable Page Elements and layout structure.

For example, a Structured Page for a business website might consist of:

1. Header — A shared navigation header containing the company logo and primary menu.
2. Body Slice 1 — A hero section introducing the business.
3. Body Slice 2 — A section highlighting products or services.
4. Body Slice 3 — A promotional section shared with other pages.
5. Footer — A shared footer containing contact information and additional navigation.

The Structured Page determines which slices are included and their arrangement. The individual Page Slices determine the content displayed within each section.

This separation allows you to modify the page's composition without having to rebuild the contents of its Page Slices.

Composition vs. Content Editing

Working with Structured Pages involves two distinct editing activities:

Editing Activity	What It Controls
Structured Page Composition	Which Page Slices are included, their placement in the header, body, or footer, and the order of body slices.
Page Slice Content Editing	The Page Elements, layouts, text, media, styling, and other visual content contained within an individual Page Slice.

For example, moving a promotional Page Slice above a feature section changes the composition of the Structured Page. Changing the heading or image inside that promotional slice modifies the Page Slice itself.

If the promotional slice is shared, changes to its contents can affect other Structured Pages that use it. Changing the composition of one Structured Page does not rearrange the composition of other pages.

Adding Page Slices

Page Slices are added and managed from the Structured Page composition view.

To add a Page Slice:

1. Open the Structured Page from Pages & Forms using Edit.
2. Locate the header, body, or footer area where the slice should appear.
3. Use the available controls to add a Page Slice to that area.
4. Select an existing Page Slice or create a new one.
5. For body slices, arrange the new slice in its intended position.
6. Save the Structured Page and use Preview to verify the composition.

The appropriate choice between an existing and a new Page Slice depends on whether the content should be reused or maintained independently.

Using an Existing Page Slice

Choose an existing Page Slice when you want to reuse content that is already defined in the Project.

Typical examples include:

• A navigation header shared across several website pages.
• A footer containing common company information.
• A promotional banner displayed on multiple pages.
• A call-to-action section reused across product or service pages.
• A common informational or branding section.

When multiple Structured Pages reference the same Page Slice, they share its content definition.

For example, consider a website containing Home, About, Services, and Contact pages. All four Structured Pages can use the same navigation header.

If the navigation menu is updated in that shared Header Page Slice, the updated content is reflected across the pages that reference it when the changes are published.

You do not need to make the same content change separately on each Structured Page.

Creating a New Page Slice

Create a new Page Slice when the required content does not already exist or should be maintained independently of existing sections.

For example, a Services page may require a section describing service packages that is not appropriate for any other page.

After creating the Page Slice, open it for editing and add the required Page Elements.

A newly created Page Slice can be used for a single page or reused across multiple Structured Pages later.

Page-specific and shared Page Slices describe how slices are used, rather than necessarily representing different content types. A Page Slice used by only one Structured Page is effectively page-specific. When the same Page Slice is referenced by additional Structured Pages, its content becomes shared across those pages.

Consider the intended scope of the content before reusing a slice. If two pages require similar content with different wording, layout, or behavior, maintaining separate Page Slices may be more appropriate.

Editing Page Slice Content

To modify the contents of a Page Slice, select Edit for that slice from the Structured Page composition view.

The Page Editor opens the individual Page Slice for visual content editing.

Editing a Page Slice is similar to editing the content of a standard Page. You can add, select, configure, rearrange, and remove supported Page Elements.

These include:

• Layout containers, rows, and columns.
• Headings, paragraphs, labels, and other text elements.
• Images, icons, and supported media.
• Links, buttons, and navigation elements.
• Tables, cards, and data display structures.
• Input controls and supported Widgets.

Each Page Slice maintains its own hierarchy of Page Elements.

For example, a promotional Page Slice might contain a container with two columns. The first column displays a heading, description, and action button, while the second displays an image.

You can modify the elements and layout within that slice without changing the contents of other Page Slices.

Editing Workflow

A typical Page Slice editing workflow is:

1. Open the Structured Page's composition view.
2. Select Edit on the Page Slice you want to modify.
3. Select an existing Page Element or add new elements to the slice.
4. Configure the elements' content, layout, styling, and available interaction properties.
5. Save the Page Slice.
6. Return to the Structured Page composition view.
7. Preview the assembled page to verify the changes.

Because a Page Slice may be shared, verify whether its modifications are intended for all pages that reference it.

Changes to the slice's content are not limited to the Structured Page from which you opened it.

For detailed instructions about adding elements, nested layouts, styling, HTML import, and other content operations, see Editing Page Content.

Reordering Body Page Slices

A Structured Page can contain multiple body Page Slices arranged in a specific order.

The composition view provides controls for changing their arrangement.

For example, a landing page might initially contain:

1. Hero section.
2. Features section.
3. Customer testimonials.
4. Call-to-action section.

You can rearrange the body slices to display customer testimonials before the features section without editing the content of either slice.

Reordering affects the structure of the current Structured Page.

It does not modify the content, names, or definitions of the Page Slices, and it does not change their placement on other Structured Pages that use them.

After changing the order, preview the page to ensure the visual transitions and content sequence remain appropriate.

This is especially important when adjacent slices use different background colors, spacing, section boundaries, or layouts that were designed to appear in a particular sequence.

Removing Page Slices from a Structured Page

You can remove a Page Slice from the composition when its content is no longer required on that page.

Removing a slice from a Structured Page is different from editing or deleting the Page Slice's underlying content definition.

For example, if a promotional banner is shared across five Structured Pages, removing it from one page's composition should not be treated as removing that banner from the other four pages.

The slice may remain available for reuse elsewhere in the Project.

Removing vs. Deleting

Action	Effect
Remove from Composition	Removes the Page Slice's inclusion in the selected Structured Page.
Edit Page Slice	Changes the content of the Page Slice, potentially affecting every Structured Page that references it.
Delete Page Slice	Removes the underlying reusable content definition, which may affect other pages that depend on it.

When removing a slice, verify that the page continues to contain the required content and functionality.

For example, removing a Page Slice containing navigation buttons may leave users without an expected way to reach another part of the application.

Also review any Page Flow, links, Widgets, or other configuration that may depend on elements within the removed slice.

Working with Shared Page Slices

One of the primary advantages of Structured Pages is the ability to reuse Page Slices across multiple pages.

A shared Page Slice provides centralized maintenance of its content and appearance.

For example, a company website may use the same header and footer on every public-facing page.

Rather than maintaining separate copies of these sections, each Structured Page can reference the same Page Slices.

When the company logo, navigation menu, or footer content changes, you can edit the corresponding Page Slice once.

Understanding the Scope of Shared Changes

Changes to a shared Page Slice affect every Structured Page that references it when the updated Project is published.

This applies to modifications such as:

• Changing text, headings, images, or media.
• Adding or removing Page Elements.
• Modifying layout, spacing, or visual styling.
• Updating links, menus, or navigation controls.
• Changing the configuration of supported elements and Widgets.

For example, changing the label of a navigation button within a shared Header Page Slice affects that button wherever the shared header is used.

Before modifying a shared Page Slice, consider whether the change is appropriate for every page that uses it.

Shared Content vs. Independent Content

Not every repeated-looking section needs to use the same Page Slice.

Use a shared Page Slice when the content should remain consistent across multiple pages.

Use independent Page Slices when pages require different content, configurations, or maintenance schedules.

For example, an announcement banner displaying the same message throughout a website is a good candidate for a shared slice.

However, separate product pages displaying different promotions may be better served by independently maintained slices, even when they have similar visual layouts.

If the content of a shared slice needs to diverge for a particular page, create a separate Page Slice for that variation instead of changing the existing shared content.

Page Slices and Application Behavior

Page Slices can contain interactive Page Elements, such as links, buttons, input controls, and Widgets.

The Page Editor defines their visual structure and configurable properties. Application behavior can involve Page Flow, Widgets, Data Design, and other ioLoop capabilities.

When reusing interactive content, consider both its visual presentation and its expected behavior.

For example, a shared navigation header might contain:

• Links to the application's main pages.
• A button that opens a registration Form.
• An account menu containing user-related actions.

The visible elements are maintained within the Page Slice, but their behavior must still be appropriate for the Structured Pages in which the slice appears.

Page Flow Considerations

Page Flow provides browser-side application logic for supported user interactions and application events.

When a Page Slice contains elements that rely on Page Flow or other application functionality, review how those interactions operate in the context of each Structured Page using the slice.

Important considerations include:

• Element References — Verify that the relevant Page Elements remain available and that Page Flow references are valid.
• Navigation — Confirm that links and navigation actions lead to the intended destinations from every page using the slice.
• Data Dependencies — Review any elements or Widgets that depend on application data or dynamically populated values.
• Page Context — Check that interactions depending on the current page or its configuration work correctly wherever the slice is used.
• Backend Operations — Ensure that any required Cloud Flow operations or other backend functionality are configured and authorized appropriately.

For example, a shared header might include an account button whose behavior depends on the current user's authentication state.

Test that button on each relevant Structured Page rather than assuming that a correctly displayed shared header guarantees identical behavior in every context.

Similarly, removing or replacing an interactive element inside a Page Slice may require reviewing associated Page Flow logic or other references.

For more information about implementing browser-side behavior, see Page Flow.

Structured Page Settings and Layout Behavior

A Structured Page has its own Page Settings, separate from the individual Page Elements contained in its slices.

These settings control page-level properties such as:

• The page's URL and publishing status.
• Public or restricted access.
• Page metadata and SEO information.
• Fonts and typography configuration.
• Included JavaScript and CSS assets.
• Advanced page styling and layout options.

For example, two Structured Pages can use the same shared Header Page Slice while having different URLs, page titles, access configurations, and metadata.

Sharing Page Slices does not require the Structured Pages themselves to have identical page settings.

Footer Behavior

Structured Pages support a Footer Type setting under the Advanced section of Page Settings.

This controls how the footer is positioned within the page layout.

Footer Type	Behavior
Standard	The footer follows the page's content and appears at the bottom of the normal document layout.
Fixed	The footer remains in a fixed position as the page is viewed or scrolled.

Use Standard for typical website footers that should appear after the main content.

Use Fixed when the application requires persistent footer content or controls.

The Footer Type setting controls the footer's layout behavior; the contents of the Footer Page Slice are managed separately through the Page Editor.

When using a Fixed footer, preview the page at different screen sizes to ensure that the footer does not interfere with the visibility or usability of other content.

For more information, see Page Settings.

Saving and Previewing Structured Pages

Structured Page editing involves changes at two levels:

1. Composition Changes — Adding, removing, selecting, or reordering Page Slices within the Structured Page.
2. Page Slice Changes — Editing the content, layout, styling, and supported configuration of individual Page Slices.

Save changes as you work to retain them in the Project's development state.

When editing a Page Slice, save its content changes before returning to the Structured Page composition view.

After modifying the composition, save the Structured Page and use Preview to test how the assembled page appears and behaves.

What to Verify in Preview

When previewing a Structured Page, check the following:

• Composition — Confirm that the header, body slices, and footer appear in the intended order.
• Visual Continuity — Verify that spacing, backgrounds, typography, and section transitions work together.
• Shared Content — Confirm that shared headers, footers, and other slices display correctly.
• Responsive Layout — Test how the assembled page behaves at different viewport sizes.
• Navigation — Verify that menus, links, and buttons lead to the intended destinations.
• Interactive Behavior — Test relevant Page Flow actions, Forms, Widgets, and data-driven content.
• Dependencies — Check that changes to the composition or individual slices have not broken references or expected workflows.

If you modified a shared Page Slice, preview other Structured Pages that reference it.

A change that works well on one page may have unintended visual or functional consequences on another.

Previewing may execute application logic, including Page Flow and connected data operations. Consider the effects of workflows that modify data or interact with external services during testing.

Saving vs. Publishing

Saving changes retains them in the Project's development state. It does not automatically update the published application.

The typical workflow is:

1. Edit the Structured Page composition and any required Page Slices.
2. Save the changes.
3. Preview the assembled Structured Page.
4. Verify other Structured Pages affected by shared-slice modifications.
5. Use Publish Project to release the updated application.
6. Use Launch Project to verify the published result.

This allows you to prepare and validate changes before they become available to application users.

When to Use a Standard Page Instead

Not every interface requires a Structured Page.

Use a standard Page when its content is primarily maintained as an individual screen and does not require section-level reuse.

Use a Structured Page when the interface benefits from reusable sections, centralized content maintenance, or independently managed content bands.

For example, a standalone application dashboard may be simpler to maintain as a standard Page, while a multi-page business website with common navigation, footers, and promotional sections may benefit from Structured Pages.

The presence of a header, body, and footer does not by itself require a Structured Page. The important distinction is whether the content should be managed as a single page or assembled from reusable Page Slices.

For a detailed comparison, see Page Types.

Where to Go Next

• Page Editor — Understand the Page Editor environment and its main actions.
• Editing Page Content — Learn how to add, arrange, and configure Page Elements within a Page Slice.
• Page Elements — Explore the available interface elements and their configuration.
• Page Flow — Learn how browser-side application behavior is implemented.
• Page Settings — Configure page URLs, access, metadata, fonts, code, and Structured Page footer behavior.
• Previewing — Test page appearance and application behavior before publishing.