When QlikView meets Pokémon

Some people build QlikView dashboards to review the financial outcomes of their companies. Others use it to monitor their everyday operations in plants and warehouses. There are individuals who even create applications to analyze fun stuff like the Olympic Games or TV Series. In my opinion, QlikView should be exclusively used to answer humanity’s greatest inquiries and analyze relevant topics that affect our lives and our future; important things such as Pokémon 😛

When I was a kid, I used to play Pokémon games all the time. Blue, Yellow, Silver, Sapphire, Stadium, Snap, Pinball, Trading Card Game, you name it. And well, since everyone’s going a little crazy about Pokémon Go these days, I decided to create a QlikView document based on the original 151 Pokémon in the first generation (speaking about mixing good stuff).

Today’s post isn’t exactly a tutorial. I’ll just share the QVW I created and highlight some interesting features I think you can use to improve your own applications. Even if you’re not exactly the biggest Pokémon fan, be sure to check it out. I’m sure you’ll find something that strikes your attention! As usual, you can download all the materials here.

About the app

The first interesting thing about this app is that all the data comes from http://pokeapi.co/ using the Qlik REST Connector. At first I thought it was going to be difficult, but it’s as simple as creating an OLE DB connection. You just type in the address and the server will respond with a JSON structure that can be easily interpreted by the connector. After that, it’s QlikView as usual.

I only added some variables and a FOR cycle so I could read several tables (one for each Pokémon) without manually modifying the connection string. For more references, go to the QVD Generator included in the materials.

By the way, if you want to add extra tables to the data model, be sure to check PokeAPI in detail. They have a lot of information that you can retrieve in the same QVD Generator and make this app even better.

Quick Tour

I’m sure you’ve already downloaded and opened the app by now, but let me give you a quick tour around it:

Dashboard: This is the first step of our journey! The opening tab displays general information about all the Pokémon in Gen 1 like the types, chains, forms and habitats.

Pokémon: This one is one of my favorites. The second sheet gives you all the information you need about a Pokémon. From its weight and height to all of its stats or even the moves it can learn. Use the arrows to navigate or just look for your favorite Pokémon with the search button.

Stats: If you’re really trying to become the very best (like no one ever was), the Stats tab will help you recruit an appropriate team.

Scatter: You know me too well, no QlikFreak app is complete until it gets a scatterplot!

Histogram: A simple, yet powerful visualization. If you’re not familiar with these charts, why don’t you take a look at this post?

Moves: Now, now… Which Psychic moves with high power and accuracy can my Fire Pokémon learn? Wait, is that possible?

Pokédex: To be honest, I get a little excited every time I see this tab. Since I’m not very fond to JavaScript, I asked my lifelong friend and colleague, Alejandro Morales a.k.a. alejandro.evolcon, to help me out with an extension object. Don’t forget to install the QAR and turn on the Web View first! (Detailed instructions in the README file). By the way, have you seen his projects in Qlik Branch? They’re pretty cool!

Visualization Tips

There are several interesting lessons that can be learnt from this app, especially in the visual end. These are my favorites:

You don’t always need explicit filters

Sometimes you don’t need to include list / multi boxes to let the user interact with your app. Our PokéDashboard is designed so that the user can click directly on the charts and tables to answer questions like “How many dual-type Pokémon are there in the forest?” or “Where do final-form, psychic Pokémon live?”.

However, you should never deploy an app that doesn’t let the user know which selections have been made. In this regard, even though Current Selections boxes are my favorite option, footers can be really good too 😉

Persistent Colors

There’s nothing more uncomfortable as a QlikView user than working with charts that don’t have persistent colors. I hate that “Dory” effect.

When you build a multicolored chart (specially area-based objects such as pies or block charts), it’s a good idea to go to the Colors tab and check the Persistent Colors box. With this, the brown area will remain brown and the green one will remain green despite of the selections you make.

Wireframes

There’s an unwritten rule in the QlikView word that dictates that all the apps must be organized like this:

You know, the classic wireframe. Time filters on top, other filters on the left hand side and the charts in the middle. I don’t know why, but almost every demo and every real-world app I’ve seen has this distribution.

Don’t be afraid of changing the standards. Create a KPI belt in the bottom. Use a three-column wireframe. Build an extra-wide table. Go nuts and include a goddamn Pokédex in the middle of the sheet. Sometimes you’ll end up with trash, but some others you get a fresh looking design that stuns the end-users.

Take for instance this 1-3-1 structure:

Highlight the important things

Always help the user spot the important things. Whether you’re working with a table, a list box or a chart, you can use colors, styles and other visual cues to remind your colleagues to look at certain elements.

Give context to the data

When it comes to analyzing data, context is everything. If you present isolated figures, users will have a hard time trying to find the story hidden behind them. Always try to include references such as the last year’s performance, budgets or industry standards depending on the nature of your data. You can give context in several ways, for instance, “on a scale from Caterpie to Mewtwo, how good is this Pokémon?”

Color encoding

Associating colors with ideas is usually a good thing, especially when the color code has been established beforehand. In our application, there’s a clear pattern in colors based on the Pokémon’s type. As you can see throughout the document, electric Pokémon are always yellow, poison types are purple and blue is restricted to water inhabitants. This encoding is persistent in tables (background), charts (bubble color) and even as a color mosaic for the moves.

Consistency, alignment and distribution

If you want to create an easy-to-navigate dashboard, you cannot forget about consistency. Using standardized fonts, color palettes and -above all- aligning and distributing all the objects on the sheet, makes you applications look more elegant and professional. The design toolbar offers useful options in this regard, so there is no excuse for not having a tidy dashboard.

Give more details on demand

Most of the times, a dashboard will benefit from having some extra information that is only displayed on demand. For example, when you select only one move, you can see its detailed description and effects:

Usability

Golden rule: If something looks like a button, it should be a button. Don’t get users the wrong idea. High usability interfaces don’t need explanations and can be discovered on the go. For example, in the Pokédex tab, all the buttons are real buttons 😛

Did someone say chart junk?

OK, I plead guilty on this one. Heavy gridlines, frames, redundant labels, ornamental axes, backgrounds, overly complex fonts, shadows and images are usually a bad thing for dashboards. However (and this will sound weird), I don’t think that all the chart junk is bad. Sometimes it helps you to spice things up a little bit and create a better experience for the users. Just don’t exaggerate. [Again, I plead guilty.]

Extra explanations

There are some things that are obvious for the developers but not so easy to see for an average user. If you fear any chart, table or KPI might cause doubts, include a pop-up legend or even a text object to clarify:

Interactive Sort

One of my favorite things about Straight Tables is their Interactive Sort functionality. Do you need to find the strongest Normal Pokémon? Check. Who’s the fastest beast in the Grasslands? Check. Out of the 10 largest Pokémon, who has the lowest Defense. Check. Life’s so easy when you can sort stuff out.

 

QlikFreak Score

Note: If you’re not familiar with the classic Pokémon games you might want to skip this section (really).

Throughout the application, you’ll find a KPI called QlikFreak Score which is my way of comparing the combat abilities of any Pokémon. Though most of the times, the sum of all the stats is enough to get a general idea of how strong a Pokémon is, I decided to create a new metric with a slightly different perspective that also takes into account the trainer’s personal preferences. Here’s how I came up with it:

First, I created a Box Plot to check if all the stats had the same scales and distributions. Why? Well, from my experience in the games, a variance of 10 points in HP is not as relevant as 10 points in Attack, so I thought that taking a closer look at all the ranges would be interesting.

As you can see, some of the stats have wide ranges (HP: from 10 to 250 points) and some others are considerably smaller (Sp. Def: from 20 to 125 points). Therefore, I decided to normalize all the scales so they could be comparable by using a Min-Max formula.

However, in the meantime, I also realized that some of the stats had an unusual distribution. For example, look at the following histogram depicting the HP score of all the Pokémon from Generation I:

Using this visualization, we can easily conclude that the average Pokémon has around 60 or 65 Hit Points (highest part of the curve). However, there’s a small bar far in the right with an insane score of 250 points: Chansey. If I used this number (which is much higher than any other element) for the Min-Max Normalization, I would “punish” the rest of the observations leaving them with a very low grade.

My solution (which has no solid statistical foundations) was to “cut off the tip of the tails”. In other words, I didn’t use the actual minimum and maximum values. Instead, I used the fractile() function to get rid of the first and last 2% so the outliers wouldn’t affect the scores (Sorry Chansey, I know HP was your only good stat).

These normalized scores give you a more realistic view of each Pokémon’s abilities. However, I wanted to include my personal preferences into this calculation as well, so instead of a simple average or sum, I decided to give each stat a weight.

For instance, if all the stats are equally important to you, the default distribution would be enough:

Giving each element a weight of 16.6%, the top performers would be:

However, if you are -let’s say- a physical trainer, you can change the table so that the Attack and Defense are way more important:

As a result, your top Pokémon would be:

If you want to give it a go, just open the script, change the Map_Stat_Weight table in the Stats tab and reload the document!

---

Well, I think that’s pretty much it. I hope you liked today’s post. By the way, if you want to learn more about data visualization, there’s a special discount on my book Creating Stunning Dashboards with QlikView until august 31. Just use this code (AJMBIKF50) on Packt’s website to get 50% off the following ebooks:

• QlikView 11 para Desarrolladores
• Learning QlikView Data Visualization
• Mastering QlikView
• Creating Stunning Dashboards with QlikView
• Qlik Sense Cookbook

If you liked this post, be sure to share it with your friends and colleagues. Don’t forget to follow me on Twitter (@QlikFreak). Until next time!

PD. I promise my next post will be serious QlikView stuff again. Well… maybe.