Working with Data Visualization Best Practices for Story Design

In this lesson, we will focus on design-specific best practices for pages and widgets when building and viewing stories. If you plan your story design, then build it using the best practices for performance optimization in story design, you are laying the groundwork for a story that performs well.

If your story has a lot of data-bound (process-heavy) widgets, then the processing data from those widgets can impact on your story's performance.

When you are building your story, the system offers performance optimization tips for story design, where applicable. For example, it may suggest splitting a page with ten charts and five tables across two pages so they are not all loaded at once. However, remember as with any tool, the larger the file, the longer it takes to load, so if you have 15 pages, the tip may suggest reducing the number of pages in the story.

One of the ways to optimize your story design when planning your story is to take into account a widget's unit weight. In SAP Analytics Cloud, each widget type is assigned a unit weight. For stories, it's recommended to keep the weight per page at a maximum of five units.

If you have a page that contains a lot of widgets, you may quickly reach the maximum weight and could start to see performance issues with your story. For faster performance, you can change the types of widgets that you're using or reduce the number of process-heavy widgets per page.

Let's take a look at a story that is over the maximum weight (the full list of unit weights for each widget type is listed below the scenario).

In the following table, you can see the number of widgets, the unit weight, and the total weight for the story shown below. The total weight for the page is 5.5, so for faster performance, you could consider changing the types of widgets that you're using or reducing the number of widgets per page.

The following table shows the widgets and the associated unit weight for that widget type.

There are some design choices that improve the performance of stories that use tables and charts, reducing rendering time for the story.

• Limit the number of cells in a table.
• Avoid an initial state of tables with complete drilldown.
• Avoid charts with more than 500 data points.
• Avoid linking too many charts (linked analysis): This will trigger an update to the values every time the selection or filter changes.
• Apply the Top N feature: With high cardinality dimensions, consider manually setting the Top N values rather than using Auto Top N.

  When Auto Top N is used, all the data is transferred from the system before the Top N data is rendered. When a Top N is used, the data is sorted, and only the Top N values are selected in the system and sent.

Geo maps are a great way to visualize data geographically, however, there are some design choices that you can make to improve performance:

• Reduce the number of data points displayed on maps.
• Enable location clustering for 1,000+ points, instead of the default of 5,000+ points.
• Construct the layout of maps to limit zooming and panning if location clustering is enabled, as each movement submits a backend query.

While it is possible to upload larger images, it's recommended to use smaller file sizes. This helps with better performance, especially for users with low network bandwidth. Smaller images mean a reduction in RAM usage on the local device. In fact, you may encounter problems when trying to upload images that are larger than 10MB.

Consider trying the following when using images in a story:

• Upload background images that are 1Mb or smaller. To get a good quality background image, you could use a compressed web image, or you might want to use an SVG image instead of PNG, JPG, or BMP images.
• Leverage header images, whenever possible.

Expanded page filters or input controls are convenient because you can quickly select members or search for members in the control. However, it is recommended to design them so that they are collapsed in the initial view as the query will only be sent to the backend system when the user interacts with the input control instead of on page load.

Turning off the Cascading Effect option for the input control increases performance. When you use an input control, Cascading Effect is selected by default.

In the example below, when Cascading Effect is enabled for Country, then when a value is selected, the City values update along with the chart requiring an additional request to refresh the data. If Cascading Effect was disabled, then only the chart would update and the City values would not change.

SAP Analytics Cloud provides functionality to create on-the-fly calculations called calculated measures on story level. However, for best performance, it's recommended to create the calculations on data source level where possible. This allows the query to be processed in a more efficient way.

Performance issues can occur when you are building the story, it isn't limited to users viewing and interacting with a completed story. When you are creating stories, the speed with which you can add and configure widgets and other elements depends on how often calls are made to the underlying data sources. Let's look at how you can optimize your story building performance using the Optimizing Story Building Performance setting in the model.

By default, every modification to your table or chart from the Builder panel sends a query to the server, resulting in an immediate update to the table or chart. For example, when adding or removing a dimension or measure, you need to wait for the chart or table to be updated before making another change. Depending on the size of the model, the response time can be slow; this can put a heavy load on the server. For this reason, one of the best practices for story design is to reduce the number of queries.

If you activate the Optimizing Story Building Performance function in the model preferences, then data updates during story design are prevented.

To turn off the automatic data update during story design:

1. Open the model Preferences.
2. Select Data and Performance.
3. Toggle on the switch under Optimize Story Building Performance.

When a change has been made in the Builder panel, the refresh icon will appear. Simply click the icon to apply your changes and manually trigger a data refresh in the story.

The Lite Viewer is an extension of the optimized story experience. It is a viewer that is designed to load the lightest version of the application. While it improves the performance of stories that are opened through a URL, it does not support all the features that are currently offered in the full viewer.

The Lite Viewer will open automatically when you select View when building a story if the story does not contain any of the unsupported features, for example script APIs or planning data actions. So, simple stories with a less complicated design are more likely to launch in this mode.

To view a comprehensive list of features supported in Lite Viewer and the usage restrictions, you can go to Supported Features and Usage Restrictions.

When you are viewing a story in Lite Viewer, any unsupported features are grayed out, however, you can easily switch to the Optimized Design Experience story View mode by clicking Open the Story in Full Viewer, as you can see in the example below. But remember, once you open the story this way, you cannot revert back to the Lite Viewer in the current tab using the back button. You will need to open the story in a new tab or using the story URL.