Performance & Scaling
This is the fifth and final installment of our Performance & Scaling series, a collection of blog posts and technical articles on improving the speed and efficiency of your Exago BI environment. Last month, we reviewed how to optimize your configuration. This month, we culminate with a discussion of what remains after admins have done all the network, hardware, data, architecture, and configuration optimization they can: user experience.
Users rely on UI cues and past experience to determine whether a slowdown is reasonable or unreasonable. If the average report takes about five seconds to execute, a seven-second execution will not seem unreasonable—but a 20-second one might. Conversely, a user accustomed to waiting 30 seconds for a report will find 20 seconds refreshingly fast. Users’ satisfaction with the application’s speed, therefore, depends greatly on how fast they expect it to be.
Admins know that even once a system has been fully optimized for performance, it will still sometimes be necessary for users to initiate processing-intensive tasks. There will also still be users who encounter a slowdown and, drawing on past experience, consider it unreasonable even though it is not. It becomes the administrator’s job to ensure that these experiences do not result in user frustration and/or abandonment of the product.
Your first opportunity to shape users’ performance expectations is during product training. Giving users a glimpse of what happens behind the scenes when they execute reports will help foster understanding. Here are some key concepts worthy of inclusion:
- First, make users aware that they are using your application to interact with a database. Explain that, in most cases, if a user is seeing data object names, data field names, or data values, these were retrieved from a database. Not all end users will have given thought to where the data is coming from or even realize that it has to travel to get to them.
- Database calls can be “expensive.” This depends on the nature of the data being retrieved
- Retrieving a lot of data is usually more expensive than retrieving a little data. This is why users may be required to apply filters before running reports.
- Some data objects (views, stored procedures, and other dynamic objects) require processing before retrieval. Analogies are helpful here: Sometimes a database call is like asking a waiter to bring you a ham sandwich—pretty straightforward, no cooking involved—and sometimes it’s more like asking for a full ham dinner with all the sides. They’re both orders, but one requires a lot more processing than the other.
- Crosstab reports become exponentially larger with each column or row source added.
Relaying these concepts will help users understand that sometimes slowdowns are reasonable and necessary.
Lastly, it is important that you invite users to communicate with you regarding performance. If a user is experiencing frustration due to a slowdown, the application either has a performance problem or a UX problem. Both are worthy of administrative concern. Users should know whom to contact with questions and incidents before they arise.
One way to mitigate user frustration during report execution is to give an estimated wait time. By default, Exago BI displays a progress bar, text indicating which step of the execution process the application is working on, and a timer indicating how long the execution has taken so far. The number of variables affecting report execution time makes this duration impossible to predict out-of-box, but individual instances of Exago BI could use monitoring to estimate an expected wait time and communicate that to users. Although this method would not be able to predict execution times with 100% accuracy, such signposting could give users a more concrete idea of how long a reasonable and necessary wait might be.
In Exago BI, you also have the option of applying extensibility that will warn users of possible performance concerns before they occur. This may be as simple as adding tooltips to large data objects or launching a custom dialog box. Or it might involve performing a cursory report audit designed to halt problematic executions and flag design flaws. Whatever the method, the goal is to clue users in on ways they can improve their experience.
Together, education and signposting serve to replace user frustration with trust—trust in the application and, in the event of a issue, trust in the people who manage it. Trusting users are more likely to share their feedback, which goes back into improving the product. Layering these UX principles on top of the technical practices discussed in the Performance & Scaling series will go a long way to making Exago BI as performant as possible.
Images licensed under CC BY 2.0 via Pixabay.