The most difficult problem for QlikView beginners is, “Where do I start?” I will show you the things that a business user will do with a QlikView dashboard so that you get a feel for "the possible." As a designer, you won’t typically need to create data models, but you will need to understand how they work so that you can build the best information tool possible. I will teach you to bring in some pre-prepared data elements and to explore how the data interacts.
Mike Reagan has over 10 years' experience as a business analyst working with companies like CR England, MarketStar, RIM, and HP. He has over five years’ experience as a QlikView Designer. He has an MBA from the University of Utah and BA in Communications from Brigham Young University.
Section Introduction Transcripts
Section Introduction Transcripts
Natural Joins Make for Easy Data Models Welcome back. In the first module I mentioned that it would be helpful to have some basic Excel skills. Now we're going to use those to bring in some data. One of QlikView's strengths is you can bring in data from pretty much anywhere, mix and match SQL Server, Access, Oracle, Excel, AS/400, QlikView QVDs, whatever, it doesn't matter. Once you bring it in, it's all just facts and dimensions to a QlikView designer. We'll start by loading a couple of Excel tables. It's a place where most QlikView beginners get their first data. Next, we'll touch on QlikView QVDs. QVDs are QlikView tables that are optimized for small size and fast loading. Finally, I'll teach you to set up defaults to make it quicker and easier to build an app, and to help in this design consistency. As I take you through the various QlikView skills, keep in mind that it's a tool that's evolved over 20 years. As a result, there are many ways to accomplish a task, and I'll teach you what I found to be the best and most efficient. But I'll also try and point out some alternative approaches that you may find fit your style.
Filters, Selections, and KPIs – Quick-look Dashboard Elements Well we did it. We learned how to bring in data from Excel and then we built, well, we copied and pasted a data model for the AdventureWorks app. Now, it's time for the good stuff. Let's build something. In the first module, we talked about the dashboard metaphor and how it's based on the dashboard of a car. You're driving along, you take a quick look to make sure that you have gas, or that you are aren't speeding too much, and you're back to watching the road. Your car's dashboard isn't much use past telling you that you need to do something else, or just keep on keeping on. Your QlikView app needs to have some of those same elements. You need to be able to take a quick look to decide if you need to dig deeper into your data or get back to work. We'll start with a list box. Believe it or not, list boxes give some designers headaches. They'll tell you that they're ugly, or that they take up valuable space. My view is that the use of the green/white/gray indicators is an extremely valuable visual indicator. The current selections box should be included in almost every dashboard. It's so easy to click around filtering data that your users will get lost. This object lets your users know at a glance that they've applied filters. A closer look gives them a chance to understand and change what they've done. Text objects are your go to for things that just can't be done with a table or graph. You can display the results of your expressions, create styling elements, display images, and well, maybe plain text. BI experts and purists tend to dislike gauge charts, because they take up a lot of space and don't show a whole lot of information. I tend to think that they can fit the needs and expectations of your business users. I'll teach you to build one, with the caution that you should only use them sparingly. Finally, we'll build a search object. They don't really fit that dashboard metaphor of a quick look, but they're not deep dive elements either, so we'll include it here.
Dig Deep with Charts and Graphs We've built ourselves a dashboard. That pesky sales manager can finally quickly look to see how our sales are going, he just can't see why yet. That's where the deep dive objects play. Since the first thing you always hear is, can you make me a pie chart, we'll start there. Before you throw your computer across the room yelling, pie charts are evil, please understand that sometimes you have to build stuff that isn't too useful in order to get people to use the things that are. We'll talk about the mechanics of building the charts and also find ways to make them a little less bad. Bar charts are your go to for displaying groups of data, they make it easy to see small differences. Line charts show trends, a great example is sales over time. Don't succumb to the temptation to use one just because you haven't yet. Using a line chart for something like sales by territory is just bad practice. Your users will always want detail that backs up your charts. The most useful object to show that detail is a straight table. Pivot tables are similar to straight tables in that you use both dimensions and expressions in the build, but they let the users collapse and expand the rows and columns. That functionality seems extremely logical, especially to Excel users, but it comes at a high price. They are the most resource intensive object, which means if you have a lot of data a pivot table could really slow down your app. They also have other quirks that we'll explore as we build. Finally, we'll look at table objects. A table object is simply a data dump that reacts to your filters, you can't add any aggregation expressions, only dimensions.
Dashboard Presentation Is the Key to Dashboard Adoption We are just about there. We've built everything we need for our app and now we just need to present it. The last step in your project is to lay out your work and your first objective needs to be to make it clean. By that, I mean you need to be aware of the different things on your app that might distract your users from actually engaging with the data and understanding what they're seeing. An example is the chart junk that we got rid of in our charts. There's no need to label something that's obvious, the same principle is true with your presentation. Your app needs to be contained, a start and an end if you will. Don't make your users wonder how much longer it can go on. One of the best things about teaching something you love is that you have to put into words something that you just know, and one of the things that I've learned over the years is that some dashboards are just painful to look at and to use. The only way I could describe this object was to call it unpainful, and that really didn't seem like a real word, but according to the internet it is, so let's go with it. Make your apps unpainful to look at and to use.