Display and Utility Widgets

Display and Utility Widgets provide specialized Page functionality without the more extensive configuration required by Data Table, AI Agent, or Payment Widgets.

This page covers two Widgets:

Widget	Purpose
Chart Area	Provides a designated display area for charts and visualizations supplied by supported Page logic.
Login Info	Displays information associated with the signed-in Project User within a navigation area.

These Widgets serve different purposes. Chart Area provides a visual destination for application-generated output. Login Info uses the Project's authentication context to present account-related information.

Both are placed through the Page Editor and can be positioned and styled using the surrounding Page Elements. Their configuration and runtime behavior depend on the particular Widget.

Chart Area

Chart Area provides a dedicated area on a Page for displaying charts or other supported visualizations.

Use it when Page Flow or supported custom Page behavior needs a predictable location for visualization output. For example, a reporting Page might use Chart Area to display sales totals by month, with filters and a Data Table Widget showing the underlying records.

Chart Area is a display target. Adding it does not automatically select Project data, calculate statistics, choose a chart type, or render a chart. The Page must also have supported logic that prepares and supplies the visualization.

When to Use Chart Area

Use Chart Area when you need to:

• Reserve a stable location for a chart or visualization.
• Present summarized Project data visually.
• Position a chart alongside headings, filters, buttons, or explanatory text.
• Refresh or change a visualization in response to supported Page interactions.
• Create a reporting or dashboard Page with multiple distinct visualizations.

Use the Data Table Widget when users need a record-oriented table with actions and data controls. Use Tables and Cards for ordinary visual tables, comparisons, and grouped content.

Chart Area can complement either option; it does not replace them.

Adding a Chart Area

A typical setup workflow is:

1. Open the Page in the Page Editor.
2. Select the section or layout area that should contain the chart.
3. Open the Element Library and locate Chart Area in the Widgets section.
4. Add Chart Area to the selected location.
5. Select Chart Area and open Element Settings.
6. Configure its Width and Height options and adjust the surrounding layout as needed.
7. Configure the supported Page Flow or custom behavior that will supply chart output.
8. Save the Page and use Preview to test the chart with representative data.

The Chart Area is commonly placed inside a Container, Row, Column, or another suitable layout area. The surrounding layout influences the space available for the visualization.

For more information about arranging Page content, see Layout Elements.

Chart Area Settings

The Chart Area provides the following element-specific settings:

Setting	Purpose
Width	Controls whether Chart Area uses its default width behavior or fills the available width.
Height	Controls whether Chart Area uses its default height behavior or fills the available height.

The available choices allow the default behavior or filling the available space. These settings affect the Chart Area's dimensions, not the chart's data, calculation, chart type, or appearance inside the rendering logic.

Width

Use the default width behavior when the surrounding layout already provides an appropriate area.

Use the fill-width option when Chart Area should occupy the available horizontal space within its parent layout.

For example, a dashboard Column might contain a Heading followed by a Chart Area that fills the Column's width.

Height

Use the default height behavior when the existing Page layout provides a suitable chart area.

Use the fill-height option when Chart Area should occupy the available vertical space in its parent layout.

Fill height depends on the space supplied by the parent. If the surrounding Container, Column, or section does not have a meaningful height, filling the available height may not produce the chart size you expect.

When a chart appears too short or is difficult to read, inspect both the Chart Area settings and the sizing of its parent elements.

Supplying Chart Output

Chart Area provides a location for rendering, while other Project functionality supplies the visualization.

A typical application workflow has three parts:

1. Obtain data. Retrieve permitted Project data or receive a result from a supported operation, such as Cloud Flow.
2. Prepare the visualization. Use supported Page behavior or custom code to transform the result into the chart output required by the implementation.
3. Render the result. Direct the supported chart behavior to the intended Chart Area.

For example, a Page might retrieve monthly order totals, prepare a chart from those totals, and display the chart in Chart Area.

The precise rendering method depends on the chart implementation used by the Page. Chart Area itself does not establish a particular chart library, chart API, Page Flow block name, or data format.

Page Flow and Chart Area

Page Flow runs in the browser and can coordinate supported chart interactions with the rest of the Page.

Possible application patterns include:

• Loading data when a Page opens.
• Responding to a filter or date-range selection.
• Requesting updated data after a user action.
• Updating surrounding labels or summary values when the selected period changes.
• Coordinating chart output with a Data Table Widget displaying related records.

Where protected processing or trusted business rules are required, Page Flow can use permitted Backend operations such as Cloud Flow rather than implementing those rules solely in browser-side logic.

Do not assume that adding Chart Area creates a working chart or automatically connects it to a Database table. The chart-rendering behavior must be implemented separately using supported functionality.

For related workflows, see Page Flow and Cloud Flow.

Example: Reporting Dashboard

Consider an application dashboard that shows monthly sales and recent orders.

A possible Page layout is:

Dashboard Page
  Heading (Sales Overview)
  Row
    Column
      Text (Monthly Sales)
      Chart Area
    Column
      Card (Total Orders)
      Card (Total Revenue)
  Row
    Date or Filter Controls
  Data Table Widget (Recent Orders)

In this example:

• Chart Area provides the location for the monthly sales visualization.
• Cards summarize important figures.
• Filter controls allow the user to select the period, with Page Flow coordinating supported interactions.
• Data Table Widget provides a record-oriented view of orders.

The Page's data and chart-rendering logic must be configured separately. Chart Area does not generate the monthly totals or update the chart simply because these other elements are present.

Responsive Chart Layouts

A chart that is readable on desktop may need a different layout on a smaller screen.

When designing Chart Areas:

• Give the parent section sufficient width and height for meaningful chart content.
• Allow surrounding Rows and Columns to adapt to the intended screen sizes.
• Avoid placing several narrow charts side by side on mobile.
• Check whether chart labels and other rendered content remain legible.
• Position filters and explanatory text where visitors can use them without losing the chart's context.
• Preview the Page at desktop, tablet, and mobile widths.

Chart Area's Width and Height settings control its available display space. The behavior of labels, legends, axes, and other chart content depends on the separate chart implementation.

Testing and Troubleshooting Chart Area

Symptom	What to Check
The Chart Area is empty	Verify that Page behavior supplies chart output and that the required data or rendering operation succeeds.
The chart area is too small	Inspect Width, Height, and the dimensions of the surrounding layout elements.
The chart looks crowded on mobile	Review parent layout, chart size, and the responsive behavior of the rendered visualization.
A chart does not reflect a changed filter	Confirm that the relevant Page interaction retrieves or prepares updated data and updates the visualization.
Data appears incorrect	Check the data source and calculations separately from Chart Area's layout settings.

Test with empty, small, and large data sets. Where appropriate, provide a clear message or other suitable Page content when the required data or visualization cannot be displayed.

Login Info

Login Info displays information associated with the current signed-in Project User within an application navigation area.

Use it when authenticated Pages should give visitors a recognizable indication of the account under which they are using the application.

Login Info is typically placed inside a Menubar or another supported navigation structure. It is a login-related display element; the surrounding menu structure can provide other destinations and account actions.

When to Use Login Info

Use Login Info when you need to:

• Show account-related information for the signed-in visitor.
• Provide an account area within application navigation.
• Help users recognize the current authenticated session.
• Keep account context close to links for Profile, Account Settings, or other related Pages.
• Include account-related information in a common header reused across authenticated Pages.

For navigation structures and menu configuration, see Menus and Navigation.

Project Users and Creators

Project Users are the people who use the published application. They are different from Creators, who collaborate on building the Project in the Project Editor.

Login Info concerns the login context of the visitor using the application. It should not be treated as a display of the Creator account currently editing the Project.

The information available to display depends on the Project's authentication context and the Login Info element's supported behavior.

Adding Login Info

A typical workflow is:

1. Open the Page or shared Header Page Slice in the Page Editor.
2. Locate the Menubar or supported navigation area where account information should appear.
3. Open the Element Library and add Menubar Login Info or the available Login Info element within the appropriate menu structure.
4. Position it alongside the relevant navigation items, commonly near the end of the Menubar.
5. Adjust the surrounding menu structure and supported visual styling through Element Settings.
6. Save the Page or Page Slice.
7. Use Preview to check the result with the intended authenticated Project User context.

Use an existing menu pattern from the Element Library when possible, rather than rearranging nested menu elements without understanding their relationships.

Login Info Behavior

Login Info reflects the current visitor's login context.

When a visitor is signed in, it can show the login-related information available to the element. The exact fields and presentation depend on the Project's user configuration and supported runtime behavior.

When a visitor is not signed in, Login Info does not create a session, authenticate the visitor, or grant access to restricted Pages.

Login Info is not itself a complete account menu. If the application needs links or actions such as Profile, Account Settings, or Sign Out, use the appropriate surrounding menu items and supported interaction configuration. Do not assume that displaying Login Info automatically implements those actions.

For example, an authenticated application header may have this visual arrangement:

Dashboard    Orders    Reports    [Login Info]    Account ▼
                                                   Profile
                                                   Settings
                                                   Sign Out

The Account popup and its actions must be configured as navigation or interactions through the supported menu elements. Login Info provides the login-related display, not the entire account workflow.

Login Info Settings

Login Info does not require extensive Widget-specific configuration. Its primary behavior comes from the current visitor session and the Project's user configuration.

Use the surrounding Page Editor tools to:

• Position Login Info within the navigation layout.
• Adjust nearby Menubar Items and Popup Menus.
• Apply supported styling through Element Settings.
• Preview the result in the appropriate user and access context.

Do not assume Login Info exposes the same content, action, or styling settings as ordinary Text, Link, or Button elements. The available settings depend on the selected element.

Reusing Login Info Across Pages

For Structured Pages, a shared Header Page Slice can contain common navigation and Login Info.

This allows the same header arrangement to be maintained across multiple Structured Pages without editing each copy independently.

When using a shared header:

• Keep account-related navigation consistent.
• Verify that links work from every Page using the slice.
• Check the layout on desktop, tablet, and mobile.
• Test how the shared navigation appears in the intended user and access contexts.
• Remember that changing the shared Page Slice affects the Pages that reuse it after publication.

For details, see Editing Structured Pages.

Login Info and Access Control

Displaying account information is not the same as controlling access.

Login Info does not replace authentication, Page access restrictions, User Groups, or authorization for Database and Backend operations.

For protected Pages or operations:

1. Configure access restrictions in Page Settings.
2. Use the appropriate Project Users and User Groups configuration.
3. Apply the necessary Database access rules and trusted Backend authorization checks.
4. Use Page Flow for supported interface behavior, not as the sole enforcement mechanism for sensitive permissions.

For example, an administration menu may show links to reports or user management. The destination Pages and their protected operations must enforce the appropriate permissions independently of the menu's visibility.

Testing Login Info

Test Login Info as part of the complete navigation experience.

Check that:

• The correct login context is reflected for an authenticated Project User.
• Signed-out visitors see the appropriate experience for the Project configuration.
• Account-related links and actions work as intended.
• Navigation remains usable on smaller screens.
• Shared headers behave consistently on every relevant Structured Page.
• Restricted Pages and operations remain protected even when their URLs are accessed directly.

If the expected account information does not appear, verify the Project User session and supported Login Info behavior before changing unrelated menu settings.

Choosing the Right Widget or Element

Requirement	Recommended Option
Provide a target for supported chart output	Chart Area
Show detailed Project records with table controls and actions	Data Table Widget
Create fixed comparisons or manual visual tables	Tables and Cards
Display KPI summaries or grouped information	Card elements in Tables and Cards
Display login-related information in an authenticated navigation area	Login Info
Create navigation links and account-related menus	Menus and Navigation
Control who can access a Page	Page Settings
Coordinate Page interactions and permitted data operations	Page Flow

Good Practices

• Choose the Widget for its purpose. Use Chart Area for chart output and Login Info for account-related display, not as general replacements for Page Elements.
• Separate display from behavior. Supply Chart Area with supported chart logic; use surrounding menu elements for account navigation and actions.
• Use meaningful layout space. Size Chart Area and its parent layout so visualizations remain readable.
• Make visualizations understandable. Provide chart titles, labels, and other context through the appropriate Page content or chart implementation.
• Use shared navigation when useful. Keep Login Info and related account navigation consistent through a shared Header Page Slice where appropriate.
• Test realistic runtime states. Preview charts with representative data and Login Info with the intended authenticated and signed-out contexts.
• Enforce access independently. Use Page restrictions and trusted Backend checks rather than treating navigation display as a permission rule.
• Verify responsive behavior. Review charts and navigation at desktop, tablet, and mobile widths.

Common Mistakes

Avoid these patterns:

• Expecting Chart Area to generate a chart automatically. It supplies a display target; chart data and rendering behavior must be configured separately.
• Ignoring the parent layout. Fill Width or Height cannot compensate for a surrounding layout that does not supply appropriate space.
• Confusing Chart Area with a Data Table. Charts summarize or visualize information; Data Table Widgets provide record-oriented tables and actions.
• Assuming chart responsiveness is automatic. The rendered visualization may require its own appropriate layout behavior.
• Expecting Login Info to implement an entire account menu. Configure account links and Sign Out behavior through supported navigation or application actions as appropriate.
• Using Login Info as an access check. Showing account details does not authorize access to protected data or operations.
• Testing only the editor appearance. Verify real Page behavior, user context, and responsive layouts through Preview.
• Changing shared navigation without checking dependent Pages. Updates to a shared Header Page Slice can affect several Structured Pages.

Display and Utility Widgets work best when their focused functionality is combined with the appropriate Page structure and Project configuration: Chart Area provides a place for visualization output, while Login Info provides a place for authenticated account context.

Related Topics

• Widgets
• Element Library
• Element Settings
• Layout Elements
• Tables and Cards
• Data Table Widget
• Menus and Navigation
• Editing Structured Pages
• Page Flow for Forms and Widgets
• Users
• User Groups