Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.

Optimize Pages

In Nintex Apps, the creation of pages can be done quickly using declarative tools. However, creating efficient, streamlined pages with an effective end user workflow may benefit from a bit of optimization.

Design before you build

When you work with Nintex Apps, you can—and should—wear two hats: designer and builder. While it's tempting to just dive into building—especially if you feel sure you know what you (and your users) want—there are real benefits to thinking about the application from a design perspective. One of these is page efficiency.

Think about both the broad and specific goals for the page. Often page builders set broad goals for an individual page:

  • I need a page where the end user can do every single action they might need to perform with an account, and see all the related records and create new opportunities.

That's a lot for one page—and the resulting outcome may be messy and inefficient. , start from a straightforward user story, for example:

  • As a user, I want to be able to view Contact details and perform a small number of related actions.

Then, after you've decided on a broad goal, break down that goal into smaller milestones by asking some questions:

  • Does all the data need to be on the page the moment it loads?
  • What about placing some of the content or features in a popup/modal, or using a sliding panel for new account creation?"
  • Would some of the content benefit from having its own page?

Explore how to break up the page into obvious, intuitive chunks. This will help craft a better user workflow and allow you to manage what data is loaded when; optimizing the page's performance.

Managing Load Time in Pages

A good rule to follow is only load data when it's needed.

Models govern the data loaded into a page and can impact how quickly and efficiently pages load. For example, if you have a model returning data that isn't actually employed until the end user clicks a tab or an accordion section, configure that model so that it loads only after the user action. This decreases initial page load time by only rendering the data needed up front.

Limit how many fields are included in models

When you build a model, it can be tempting to add all the fields you might need when using that model. This means, however, that whenever you're loading that page, all those fields must load as well, even if you are not using them in any component.

General guidelines:

  • If you're not using a field on a model, remove it.
  • Don't add fields to a model just so you can later export them later. This will result in bad page performance, especially with large blocks of data. , check out your connection documentation for better export options.

Use multiple models with component accessories

Imagine you are using a component accessory like a popup/modal (or a sliding panel, or a drawer) to reveal more details about a record displayed in a table. Don't fill a single model with all the fields needed for both the table and the popup, or you'll be loading every field every time you load the page. , use one model for the table—with only the fields needed for the table—and a second, separate model that includes all the detail fields for the accessory. Set the conditions on the second model so that the accessory only queries the model when it's actually accessed by the end user.

Exercise caution with page includes

Page includes are a great way to use one page in multiple places, but bear in mind that they can add to load time, sometimes significantly.

Note:  If you using a page include specifically to circumvent the maximum XML page size that Nintex Apps enforces, then your page is too big. Reconsider the scope of the page and explore other ways to achieve it.

Improved user experience

Limit fields in tables

Tables are powerful, and it can be tempting to pack them with a bunch of fields (which display as columns) but having a large number of columns can render the table unreadable.

General Guidelines:

  • If you have 15 (or more fields) in the table, it's probably too many. Think about how much data your end users can absorb in a single scan of the table. Try to keep the initial table display to 5-8 columns.
  • Need to ensure the user has access to additional columns? Hide the columns initially and let the end user show them when needed.

Use component accessories thoughtfully

Extending data into an accessory—such as a popup/model, sliding panel, tab, drawer, or wizard—should provide a clean and concise user experience, but only if you ensure that the accessory serves a single purpose: allowing the end user quick access to occasionally necessary data. Ask yourself:

  • Does the accessory provide data that needs to be viewed in the context of the current page, or would it be better to place that data in its own page?
  • Is the accessory's workflow simple and straightforward, or is complicated, with no clear purpose?

Note:  If you have layout components (Tab Set, Responsive Grid, Accordion, or Tab Container) in your popup/modal or drawer, this could be a red flag. Understand that you are asking end users to navigate through multiple levels to find their data.

Optimize Personalization

Personalization is the sum of an end user's "remembered" settings (like opened tabs, filter settings, etc). Using the Personalization Mode property on the General tab gives developers the ability to decide where personalization information is saved: client-side ( items already loaded onto the page ) or from server-side ( content in the connection itself ).

What's the difference?

  • With server-side storage, Nintex Apps remembers the user's last settings whether they are simply refreshing the page or moving from a desktop to a mobile device. Nintex Apps can also manage those settings to ensure that, as pages change, everyone's personal settings are kept in sync. Server-side is the default setting for new app pages.

  • For non-authenticated users (visitors to a public-facing website, community and portal users), client-side personalization is the best option, since these users either don't have a record in the connection, or there's not enough room to store personalizations for a large group of public users.

    Note:  By default, Nintex stores personalizations for community and portal users to Client-side in Configure > Organization Defaults. Even if server-side is chosen for the page, non-authenticated use client-side storage for personalizations.