Part 1 of this series describes what Qlik Sense does better than QlikView, from the perspective of an experienced QlikView application developer. In part 2, I described the inverse: what QlikView still does better than Qlik Sense. In this final post in the series, I will describe how my approach to application development has changed as I have gotten to know Qlik Sense better.
My goal is not to try to make people forget about QlikView and move on to Qlik Sense, but to help those accustomed to QlikView pilot Qlik Sense in a way that is informed by the strengths and differences in the platforms.
What you can practically expect in Qlik Sense applications to best leverage the product, compared to QlikView
Loading data/data model
Very little has changed with loading data and the data model. The same amount of time should be budgeted for data modeling in Qlik Sense projects as on QlikView projects.
- We still use and recommend template apps for QVD generators and spending a bit of time coming up with an overall structure for organizing QVDs, even though folder connections are now managed more smartly, through Data Connections.
- QVDs are still recommended for reducing impact on source systems, incremental extracts, and data re-use.
- BI developers will likely still need some level of access to the folder structure of the development environment (not necessarily UAT or Prod) to delete QVDs, modify included files, or create folders to organize QVDs. A difference is that the application files themselves will not be among those files, instead being administered by the server and accessed through your browser.
- The Data Manager will not realistically be used by developers in its current state. It’s not practical or efficient to build a whole data model with it or to use in QVD-generating applications.
Build less and more simply, enable more. Less time is needed to build the front end in a Qlik Sense project compared to QlikView projects.
- Users will be creating their own content through self-service, so the UI design can focus on addressing only the most important business value and most commonly asked questions by the application audience. (Note: we are not saying to skip the design time, just that you should focus it on the main business value and not each user’s personal whims.) This often amounts to less UI content in the base application that is published, while the base content in QlikView apps was all most users would ever get.
- That simple content may be spread out over more sheets than were required in QlikView, however. The grid function and lack of object layering with show/hide make it difficult to design sheets with built-in workflows. No more hidden tabs or “subtabs” (without extensions): analysis and detail may sometimes be on different sheets.
- Qlik Sense is not as good at creating generic reporting interfaces like people did in QlikView, like report builders, and you’re unlikely to see apps with a bunch of filters and one table that users are exporting to Excel. The good news is that self-service has made these obsolete.
Built-in functionality replaces some things developers used to have to manually do.
- We still use template applications for UI, but they are much simpler, without sample layouts (currently), sample report builder interfaces, etc.
- There is no need to put the same set of objects on every page: lots of filters, Current Selections, Search Object, a background image. These are obsolete due to the selection bar and Selection Tool. This also means more room for visualizations!
- Responsive design means that there do not have to be separate desktop and mobile sheets or intended designs.
- All of your applications will have a consistent appearance, navigation, and interactivity — not based on the skills or preferences of the developer.
Generally better calculation performance and RAM footprint.
- We have observed generally faster calculation time in Qlik Sense compared to QlikView, allowing for acceptable response time with even larger data models.
- This may be attributed to fewer objects and expressions visible and calculating on a sheet at one time. Another reason is the lack of “always one selected value”, popular among developers but a drag on RAM and CPU.
There are some additions and omissions in UI objects compared to QlikView.
- Native maps and KPI objects are good. There are smart additions to some visualizations when it comes to handling an extremely large number of data points. Text objects can be formatted very nicely, where individual words can be formatted differently.
- You may find yourself looking for a chart property from QlikView that doesn’t exist in Qlik Sense, like the ability to put a measure value on the axis instead of on a data point. Some of these are getting added back over time. If you last checked out an older version of Qlik Sense (pre-June 2017), I would check again: these are the kinds of niceties that are being added with each release.
- Time is spent making sure an analytical need is met, not making the chart a pixel-perfect representation of a user/developer/designer’s ideal.
Much has been made of extension objects, but most apps use them sparingly. The most common use case is not custom visualizations, but navigation and user interactivity.
- There are some downsides to extensions, so we tend to use only a few basics (Sheet Actions + Navigation, qsVariable), unless functionality is absolutely required: they may break with Qlik Sense updates, may not have responsive design, no export to Excel, may not look consistent with other chart objects, may not be compatible with NPrinting, may contain unsafe code, and so on.
- The most common extensions we use are on the verge of being put through the ringer and certified by Qlik. Note that these, too, are not visualizations, but for navigation and functionality.
Much less time is needed to fine-tune the appearance of the front end, compared to QlikView.
- Changing dozens of properties in a chart — down to each column’s alignment — to make it look just right and carefully sizing and aligning objects are things of the past. Fewer options and better defaults = less time fiddling.
- Realistically, a lot of the time spent tweaking the appearance of QlikView is not time well-spent. Hiding tabs, making it look like something other than QlikView, painting the formats of every property of each object. Is this really adding business value? Also consider the design tenet that more features translate to decreased usability. I’ve seen a lot of QlikView apps that require instruction manuals.
There is continued reliance on variables.
- We still externalize expressions using variables. We even define Master Measures using Variables. Partly this is so we can define Master Measures using multiple variables, but there is also no find and replace Expression Overview equivalent in Qlik Sense, which makes mass expression updates a pain.
Invest some time to stock the Master Library with Measures and Dimensions for users to create their own content. Self-service in Qlik Sense is real, not just the BI buzzword that all companies claim.
- It has always been a folly to try to build the answer to every possible request into the UI of a Qlik application, but Qlik Sense can actually back up its self-service claim.
- You do still have to build a sensible data model for most users. Think of this as a semantic layer.
- I haven’t found Master Visualizations to be especially useful except during development of the base application, as a stand-in for QlikView Linked Objects.