In my experience, many QlikView customers like the idea of trying the Qlik Sense platform, but have trouble adjusting to the differences. A primary reason is that early Qlik Sense efforts often entail trying to build an application with QlikView-like design and function. This is understandably frustrating, just as it would be frustrating to try to build a QlikView-like application in Tableau or an SSRS-like report in Qlik Sense — or a Qlik Sense-like application in QlikView, no doubt.
QlikView users “rely on” features because they are available, and developers and users are accustomed to them. But if the same users tried Qlik Sense, having previously used a platform other than QlikView, there would still be a non-overlapping set of features they seemingly couldn’t live without from the old platform. Yet somehow, myriad platforms meet the needs of businesses around the world, with users blissfully unaware of what they are “missing out on” in competing platforms.
Business Intelligence platforms have different behaviors, features, strengths, and weaknesses, so seeking to create a nearly identical experience on alternate platforms is quixotic — far less valuable than investing that time in understanding the strengths of a platform and how to best leverage it.
After working hands-on with Qlik Sense for a few years (since it was called “QlikView.Next”), and almost exclusively this year, I have a good sense of their relative strengths and how my approach to designing applications has changed on Qlik Sense projects. In this post, I will describe, from a QlikView perspective, what Qlik Sense does better. In the next post, I will describe what QlikView still does better, and, in the final post in the series, I will describe how my QlikView approach to designing applications has shifted on Qlik Sense projects.
My goal is not to try to get people to 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. The lists will not be comprehensive, focusing on the most common use cases, not custom applications, which is a more obvious differentiator for Qlik Sense.
Headaches with QlikView that you don’t have to worry about in Qlik Sense
Loading data/data model
- Faster overall reload performance for the exact same operations, at least compared to QlikView 11.2.
- Central management of data connections means no more externalizing database connections (if you had the foresight to do that) in files that were difficult to secure for people who needed access as developers.
- In Qlik Sense, it is impossible to accidentally, permanently lock yourself out of an application with Section Access. You can always open it with no data.
- Find and Replace in the script is very user-friendly, including highlighting the number of instances of the search string on each tab.
- Responsive design means that you no longer have to agree upon one screen resolution to build to, which inevitably doesn’t work well for some users and devices.
- Snap-to-grid means that you no longer have to spend time carefully aligning positions and sizes of objects down to the pixel to avoid an app looking sloppy.
- The selection bar at the top means no longer having to include Current Selections and Global Search objects on every sheet.
OOB charts do not require you to change dozens of properties to look decent and consistent with other objects. Once you have been working with Qlik Sense for a short time, doing this in QlikView feels like an exhausting exercise.
- Many of the text colors and sizes are automatic and consistent to emphasize or de-emphasize appropriately in object titles, subtitles, and footnotes.
- Users experience better calculation performance, in general, because the UI is not as conducive to having a large number of objects open and calculating at the sheet at the same time, nor do the objects have places to house a nearly infinite number of expressions throughout their properties.
- The much-overlooked Selection Tool toggles showing a page with all filters on it. This means not having to dedicate a large amount of space on each tab for Mulitboxes for commonly used filters.
- As a result of many bullets here, less time is needed to develop the UI, period. This was a more significant time commitment on QlikView projects.
- KPI objects actually look good compared to QlikView gauge charts, and they automatically scale large numbers to show in thousands, millions, etc.
- There is a native map object that doesn’t rely on hacking a scatter plot chart and computing dynamic Google API URLs.
- Text in Text Objects can be formatted nicely, with alternate text sizes, bold, italics, etc., all within a single object.
- There is no software to install for developers and thus no more need to keep versions of QlikView Desktop and Server in sync.
- Drag and drop, baby! Create new objects, dynamically color objects, etc. with only clicking and dragging.
- Developing in a browser means that you can have the script, data model viewer, and interface open at the same time, in different tabs. No more Ctrl-e, Ctrl-t switching.
- Master Visualizations are a better way of handling “linked objects” than relying on context menus and the like, often realizing you had accidentally created a copy of something that wasn’t linked, in QlikView.
- Master Measures carry the labels with them across charts, not just the formulas, as with using Variables to centralize expressions.
- Users can create their own content just as easily as developers. Comparing this experience to the QlikView AJAX menu for creating objects and changing their properties is a night and day improvement.
Stay tuned for part 2.