Why do developers need a checklist for Qlik?
I have been asked many times throughout my career, “how do you know what to look for when reviewing a Qlik application?” It’s simple really: I use a checklist. For the past 15 years, I’ve continued to develop the QlikView Developers Checklist. But 15 years is an entire era in technology, and Qlik moves at lightning speed, so as times have changed, I’ve adjusted the list to keep up with those developments.
To understand the “why” behind this list, let’s first look at the “how”.
I’ve leveraged this checklist in a few ways over the years:
- As a guide to best practices. Developers, whether they are data team members or community developers, should use the checklist as a guide to best practices.
- As a guide for reviewing applications prior to production deployment. In a data team, I’ve used this list as a review guide prior to moving applications to production.
- For knowledge transfer. With Community and business creators, I have used this as a guide for training and coaching. As Qlik community creators develop new solutions, they can reference the checklist for everything from performance tuning to data modeling.
- From a training perspective, I have used the checklist as a guide for topics and content – what do users and product managers need to learn? Which topics may fall by the wayside? Which will provide the most value as core concepts?
A step-by-step process for using the Developer checklist
I think it’s important to note that although this list applies to Qlik, these core elements can be applied more broadly to analytics application development. It’s simply a programmatic way of breaking down tasks into manageable bites and checking your work to make sure it’s as thorough as it can be.
When reviewing a Qlik app, I typically look at three areas:
- The script
- The data model
- The User Interface (UI)
To give you a taste of the elements of the checklist, I introduce a few from those categories below.
Best practices for scripting in Qlik
On the checklist, I provide a dozen or more items to review, but of them, I think these are the most unmissable – basically, the two I check the most.
Use Numeric flags where possible
This seems like a small item, but in apps with a lot of tables, a complex data model, and a lot of data, it's critical. Why? Because Qlik processes numbers a lot more efficiently than text when evaluating an equation.
Taking this step will save a lot of stress on compute/CPU utilization and allow chart objects to calculate, and therefore render, much faster. That means end users will have a better experience and make your Qlik apps more like Speedy Gonazales.
Make it easier for end users with friendly names for UI fields
This item isn’t about performance; it is about ease of use for the business. If you want business users to become more self-sufficient (i.e, create a self-service app), field names like “Company” are more meaningful than “ar.Act_Co_Lng_Nm”.
Remember, your users are your audience, and they have to know what they’re looking at to draw conclusions. Obscure names obscure their meaning. Make it clear.
Best practices for building your data model in Qlik
Of several call outs in this section, I typically focus on the following two elements: Correct granularity and cleaning up timestamps. Again, this may seems small, but these finesses will make your operation run much more smoothly.
Correct granularity of data for the use case
I can’t stress this one enough. I typically find this part is most useful for community developers: it’s crucial to get the granularity right. If you’re granular enough, the analysis will be meaningless. If your granularity is too low (more often the issue), the app can be bloated, slow, and results may look correct at first, but will look strange after some analysis. Typically, in a straight table in the UI, Qlik will collapse duplicate rows, so the row counts may be right, but the summaries are off.
Remove timestamps
Unless it is absolutely required and there is no way around it, do not keep the timestamps. Remove them in all other cases. You can do this with a simple FLOOR() function in the script. If you do need the time, you can split the date and time into two different fields. This will help with processing times and calculation times on the front end. User Selections will react faster and users will have a better experience.
Best practices for Qlik UI performance
These best practices will help endear your user base to you because Selections will render quickly and pages will load fast.
Avoid IF() Statements in calculated Chart Dimensions
It takes a lot of processing resources to evaluate an IF statement that is used for a Dimension. In fact, Calculated Dimensions should be avoided in general. Why?
First, if the dimension is calculated, then it is only found in that chart, and it has to be replicated every time it is needed. To avoid this, move the IF() Statement to the script, so that dimension is calculated at the time of reloading, removing the burden on processing selections, and the dimension is available to the entire app.
Minimize string comparisons
Typically, for most developers and especially community developers, this will come in the form of an IF() statement. Rather than doing the sting comparison in an expression or dimension window, move the comparison to the script. The script is the best place to process IF() Statements, especially those that have several nested arguments.
Other considerations for improving Qlik development
Best practices are more than just UI performance. Here are some suggestions that fall outside of that area, but which are broadly considered to be very important for (1) user experience and (2) future development. Avoid building up technical debt because of an unpolished app.
Standardize naming conventions
Having standard ways of naming things will help with maintenance and move you away from entropy to organization in the long run. For example, starting every variable with a lower case “v” helps others know immediately when a variable is used in Set Analysis, rather than a field. Naming keys in a standard way, like “key|field” helps identify keys quickly, when using the search feature in the script. There are many more examples, but the core of this component is to keep your house in order.
Performance tuning
If the app you are reviewing is slow to reload or slow to render, try reducing the number of rows or columns. Very “wide” and very “deep” data tables perform poorly. Make it slender and sleek.
Get the full checklist today
This Qlik-based checklist can be used in few ways, and is broadly applicable to other analytics and development platforms.
To recap:
- Share the checklist with developers to use while they’re building the Qlik apps.
- Keep it as a good reference and reminder of best practices for Qlik App Development.
- Socialize the checklist a straightforward training material for community developers and other Qlik Content creators
- Use it as an anchor in Qlik application code reviews.
- Identify golden standards and provide an avenue for best practice deviations to be documented.
Download the checklist here.
How DI Squared helps with data modeling, app dev, and more
If going it alone isn’t your bread-and-butter, or simply isn’t in the cards right now, we’re here to help in a variety of capacities. If you're looking to clean up the cruft code to lay the foundation of a stronger data model and analytics program, reach out to us for a free 1:1.
