Better QlikView Trainings

What makes QlikView training so challenging is the unique nature of the tool. Unlike most other BI tools, QlikView uses an associative data structure, rather than a relational one. Associative data models store unique values of fields and use ultra-fast memory pointers to create the necessary associations. When you contrast this with the traditional relational data model (where tables play a central role and links are maintained through primary/foreign key relationships) it becomes clear that a radically different approach is needed for development and, consequently, for trainings.

 

No matter which tool you are using, there are some practices that are always a good idea to keep in mind. In our opinion, the most of important of these is to always tailor the training for the specific group that you are speaking with. All too often, a trainer will have his/her deck of pre-made PowerPoint slides and will never deviate from this material. Anyone who has ever spoken to a group of trainees can probably sympathize with this approach—having a script can greatly reduce the anxiety associated with public speaking. We are certainly not advocating "winging" a training! Rather, we are just stressing that it is crucial to know your audience before you ever arrive at the training center, so that you can prepare relevant material that will capture their attention. There is nothing worse than the sinking feeling you experience when you realize that nobody is listening to you. Simply creating fresh (as opposed to canned) content can greatly reduce the frequency with which this happens.

Having been in the audience for many presentations where the speaker simply reads verbatim from his slide deck, I can tell you first-hand that it is extremely annoying and makes for an excruciatingly dull presentation. Stop reading! PowerPoint is a wonderful tool that, when used properly, can help drive your points home. PowerPoint is not the presentation itself—it that was true, then why would a presenter be necessary? Our advice is to minimize the amount of text on any given slide; 3 or 4 short bullet points should be more than enough. Also, minimize the number of slides that the presentation uses—your audience simply will not be able to retain 100 slides of material. Finally, keep in mind that a picture really is worth 1,000 words; where appropriate, try to replace wordy text with a visual that can impart knowledge to your trainees in a single glance.

You may notice that our own training materials are quite long, and can sometimes be fairly wordy. However, these materials are simply intended to be a reference for students, and to help the instructor organize his/her own thoughts to make sure that no major topic is accidentally skipped. When I teach a course on either Developer or Designer, I hand the materials out before the course begins, but project an active QlikView application onto the screen (rather than the PowerPoint presentations that were used to create the manuals). To help students use the materials as a reference properly, I will often mention pages in the manuals that they may find relevant to the topic we are currently discussing. I suggest that those instructors who purchase our manuals use a similar technique.

 

About a year ago, I was asked to give an "advanced" training on QlikView Developer. My client specifically requested that the entire training be completed in a single day. When I arrived at the client site, a few things became clear. First, the supposedly "advanced" users had actually had very minimal exposure to QlikView—a beginner refresher course would have been more appropriate than an advanced training. And, second, only 6 hours of the actual workday had been allocated for the training. You can guess how much of my presentation the trainees were able to understand, let alone retain. To ensure that this does not happen to you, make sure that you space out your materials over a reasonable period of time. If you are truly training advanced users, and only need to teach a component or two, then a single workday may indeed be enough. More often, however, the scope of the materials for a QlikView Developer or Designer training will require something closer to a week (each!). The worst thing that you can do is rush through your materials just for the sake of getting through your entire deck. If you find yourself in a situation where you simply have no say as to the length of the training (a sad reality for most consultants), then make sure that your audience has a solid understanding of the basics of QlikView before you start discussing functions like INTERVALMATCH or AGGR. And yes, you may run out of time before you get to these, but it is infinitely preferable to teach a few things well than many things poorly. If you are fortunately enough to get a full week for your training, bask in the luxury and space the materials out over that entire week; a few hours per day of training, interspersed with interactive learning (discussed immediately below).

Study after study has conclusively shown that human beings cannot simply absorb 8 hours of a straight "brain dump." It is absolutely essential that your training include an interactive component. While this advice is hardly novel, the way that we suggest that you use interactive exercises is (unfortunately). The orthodox QlikView training model for a week-long training is to use the first 3 days to cover everything in the enormous Qliktech-canned PowerPoint deck, and use Thursday and Friday to run through interactive exercises. I have always found this approach quite funny. When is the best time to reinforce a concept through an exercise, immediately after the concept is learned or 4 days later? Exactly. You've taught your audience about the different types of joins? Reinforce that knowledge with immediate exercises that test the proper use of left/right/inner/outer joins. Not only will this help the knowledge sink in, but it will keep your room awake.

Suppose you are giving a training at a pharmaceutical manufacturer. You get to your first interactive exercise and it is...of course: the standard retail data provided with each QlikView training (Order Header, Product Master, etc.). If you use this data for your exercises, you are making a mistake. Try your best to get some of the company's own data prior to the training; if you cannot, then get comparable sample data, which should be widely available online. The goal of your training is to teach your users how to use QlikView. When you use data from an industry that is completely new to them, part of their brainpower will be wasted on first understanding how, e.g., retail data works. They will, partially, be learning something irrelevant. In addition, when these trainees graduate your course to become QlikView developers at their organization, they will have a harder time adapting what they learned in the training to their own purposes—and when they go through their notes to look at the examples from the training exercises, they will find them to be of little help. By contrast, when you use data that is relevant to your users, they will be more alert during the training, will understand your examples faster, and will retain the information better. And, finally, using their data will actually help you as the presenter—when users see their own data and metrics, you will be surprised at how many great questions they will ask and discussions they will initiate. It is certainly easier to spend 8 hours addressing questions and discussions than speaking to a silent room. Our advice is to reserve generic data for when you are teaching a mixed class from several industries and job roles.

 

Although it may seem obvious, I am constantly surprised at how often either (1) Designer training is offered before Developer, or (2) Designer training is offered without Developer at all. Our rule is that you can be a developer (i.e. data model architect) without being a designer (i.e. user interface architect), but not the other way around. In order to properly understand what a QlikView chart is calculating, it is essential to first understand how the relevant data is associated behind the scenes. If a designer does not understand this, he runs the risk of creating an application with wrong results (which is far worse than an application that simply does not display any data because of UI syntax errors). This is particularly true due to the QlikView's unique associate architecture, discussed above.

The temptation, especially if you are a seasoned QlikView professional, is to demonstrate your knowledge by explaining every function in QlikView, from LEFT JOIN to AGGR. Although you should certainly cover all basic concepts, keep in mind (1) that QlikView comes with a pretty decent Help file that users can use as a reference in the future as the need arises, and (2) that your audience may not need all the advanced functionality you are teaching. For instance, one of my previous blog posts discussed a very advanced way that true dynamic bucketing can be achieved in QlikView. I would not teach this concept to all my audiences because, frankly, it is not relevant to all organizations. Likewise, your audience may not be interested in HIERARCHY, INTERVALMATCH, or other specialized QlikView concepts. Often, you will not know exactly what concepts are going to be relevant in advance of the training. In situations like those, it is a good idea to maintain a flexible presentation style, such that you can easily skip over certain slides without losing the training momentum.

Among the least-taught areas in QlikView are the performance implications of one data model or UI over another. Anyone who has ever dealt with a QlikView dataset of tens or hundreds of millions of rows, however, knows that this is probably the most important consideration in the entire QlikView application. QlikView development can be extremely fast compared to other tools but, like any tool, a user must know best practices or he/she will "quickly" produce an application that is technically correct but performs slower than a sleeping snail. Make sure that your training touches on at least the most common pitfalls to avoid in best-practices QlikView application development. Example of such pitfalls include unnecessary calculated dimensions or AGGRs, synthetic keys, and use of IF statements over set analysis.