Qlik Design Blog

4 Posts authored by: Brian Munz

More and more, blog posts, news articles, and various other online media are incorporating data visualization.  A well placed chart or graph can drive home the point of the story being told.  While print has been doing this for a long time, unique to the web experience is the arrival of interactive visualizations which allow users to explore and experience the data in a new way.


Not to be left out, there are several options for easily embedding QlikView into websites.  While integrating QlikView into the web can be tricky (cross domain scripting, security concerns, etc.) there are some terrific posts on the web by Stefan Walther and Alexander Karlsson (amongst others) describing various ways a person can add some slight code to embed objects into a web page.


Using these same principles, I’ve also developed a tool which should make things as easy as possible for web novices to get QlikView visualizations into their site. Once this tool is implemented, a blog writer who is desperate for some visual aids on their post

blank page.png


could go to their QlikView app


use the tool in an app to add QliKView objects to a staging area where they arrange them how they want

app share.png

click the “export” button to get the iframe code

embed code.png

paste the iframe code into the html


and check out the new visualization on your site



This is very simple for the blogger, and by using iFrames, we are able to avoid cross domain scripting issues and also allow the objects within the frame to communicate with each other, making them interactive.


This solution is an example of how several different types of customizations can be used to create a helpful tool.  Click here to download the solution and documentation. To see embedding in action, visit the Image Gallery on the demo site.  The “Pinterest-style” image gallery is embedded into the site using these same techniques.

In a perfect world for developers and designers, their work would be approached by users on the same (or very similar) device.  Ensuring a consistent aesthetic and user experience would be simple because the developer’s experience would be the same as everyone else’s.


As we’re all well aware, unfortunately, we don’t live in a perfect world, and I’m not completely convinced that world would be all that perfect.  There are hundreds of different devices, screen resolutions, and operating systems that contribute to a nearly endless combination of user experiences while traversing the web.  In some ways this variety is very exciting in that it drives innovation, offers users choices, and potentially allows the user to customize their experience.

Luckily, despite this variety, the users are basically attempting to view a document or image which is a very old form of communicating information.  But what if we want users only on a particular device viewing our apps differently? 


For example, the Insurance Demo on the QlikView Demo site had a fairly large dashboard, and attempting to use the app on a phone would be very difficult without tiny fingers:

photo 2.PNG

In this case, tailoring this experience toward a particular device seems unavoidable.  Fortunately, device detection can be fairly simple to do on the web.  There is a variable called “navigator” that is set in most browsers that can be easily examined using javascript.  Navigator contains some important and useful information such as browser type, operating system, and whether or not the device identifies itself as mobile. 


So how do we get that javascript into QlikView?  Extensions of course!  Document extensions are especially useful for performing simple javascript tasks to gather user information and pass it into QlikView by using a QlikView variable.  This way, QlikView is able to take this variable and use it for whatever purpose it wants, which is much simpler than attempting to customize the page from the document extension itself.


The best part is that the extension itself couldn’t be simpler.  JavaScript has already done all of the work.  The deviceDetect document extension referenced below, for example, consists of four lines of JavaScript code to set a QlikView variable called “vDevice” to the browser information retrieved from “navigator”:


Qva.AddDocumentExtension('deviceDetect', function() {

      var mydoc = Qv.GetCurrentDocument();

      mydoc.SetVariable("vDevice", navigator.userAgent.toLowerCase());


Using this extension on the Insurance Demo, a sheet customized for the iPhone could be shown, creating a much nicer view:


photo 1.PNG

Click here to download the deviceDetect document extension.

Brian Munz

Helping Hands

Posted by Brian Munz Dec 20, 2012

tinyhandslogo.pngThe holiday season is often a time when we consider our blessings, our shortcomings, our needs, and the needs of others.  As a special Christmas blog post, I felt it may be good to share my experiences working with Tiny Hands International (THI), a non-profit organization that works specifically with orphans, street children, and sex-trafficking victims. It was an eye-opening experience for me that gave me insight into the needs of the victims as well as the organization itself.


I was having lunch several months ago with the founder of THI, John Molineux, who is a good friend of mine from college.  At one point in our conversation, John expressed that they had been looking for a good way to analyze the data they collect when they intercept trafficking victims at border checkpoints in Nepal.  Each year, 10-15,000 women are deceived and trafficked out of Nepal where they are then sold as sex slaves.  More specifically, John mentioned to me that they had been hoping for a tool that would allow them to visualize the paths the victims take when they are trafficked. This could be useful in identifying the most commonly used routes, and it could perhaps give insight into how they could best focus their efforts.  Of course, I knew QlikView could be a great help to them, and we got to work loading THI’s data.  Once they identified the paths of the victims geographically in the data, it was easy to use a map extension to visualize the paths, drawing the more highly traveled paths with thicker lines:


The data is very raw, and THI is thinking of ways to optimize their collection and identification of paths, but even so, some trends and useful information can be seen with the map.  For example, the dark red area on the east side of the map shows that a lot of activity is occurring at this checkpoint, including some of the thicker lines.  Of course, using QlikView’s associative filtering, we can choose to display only the top 15 routes:


Or focus in on a specific border checkpoint like the eastern one I mentioned earlier:


We were also able to use an expression to color the most traveled routes in red, while coloring the less traveled routes in yellow and green:


Overall, we were very excited to see start seeing the story the data was telling us, and ideas were flowing on how they could further optimize their data collection and leverage QlikView’s analysis in their planning.


What I realized in working with Tiny Hands International is that charity organizations are businesses too. They also need the ability to analyze data and be as efficient as possible. Knowledge is power after all, and wasted time, money, and resources mean a less effective fight against injustice.


More than that, working with THI was a staunch reminder for me that there are people in the world right now doing selfless honorable work to improve the plight of their fellow humans. Oftentimes I sit at my warm desk feeling separated from this world, but I hope that as I'm humbled through experiences like this, I will consider the ways I might help to affect positive change in the world.


If you’d like to support the work of Tiny Hands International, please go to their website.  A small gift from us could have a large impact on those in need.

The highly respected (fictional) scientist, Ian Malcolm, once chastised a group of scientists for being “so preoccupied with whether or not they could that they didn't stop to think if they should.”  Ignoring the fact that this statement was made in regard to ferocious dinosaurs that would soon terrorize mankind, there is truth held within for how we approach technology.

In this business we’ve all been guilty at one time or another of using the “more is more” approach in data visualization.  All too often we marvel at something that dazzles without stepping back for a minute to consider the story that’s actually being told by the data.  This is especially true with QlikView extensions.

There are a plethora of JavaScript libraries that display data in exciting and dynamic ways.  It flies here and there, spins, zooms, explodes, and distracts attention for a bit before the viewer attempts to decipher the information loosely assembled in the chaos.  With extensions we sometimes jump at the opportunity to cram a hot, buzzy technology into QlikView simply for the bragging rights. Sometimes what is needed is something much simpler.

ggss.pngWhen I began working on an extension to visualize medal counts for the Olympic Games this past summer, it was assumed that I would use a slick mapping UI similar to Google Maps or OpenLayers.  These powerful mapping tools allow developers to perform a wide variety of complex geospatial tasks, taking into account curvature of the earth, map projections, tessellation, and a variety of other things that will induce sleep in the average human being.

In order to achieve the effect of highlighting and coloring the different countries for this extension, it is not as simple as telling the Google Maps API to select country X and highlight it with color Y.  These mapping tools do not have country or region boundaries prepackaged.  Due to this fact, the actual longitude and latitude points for the boundaries of each and every country would need to be found and plotted as shapes on the map.  Not only is this a LOT of data for JavaScript to handle, geographical data is not easy to come by.

So, let’s take a step back. The question that needs to be asked is how much additional detail will users need?  The data we’re looking to visualize is not geographic in a technical sense.  We only need to display the countries of the world as concepts and entities, not as precise geographic objects.  In this case, the precision offered by the mapping tool is completely irrelevant, as is the map itself beneath the plotted shapes.  Why repurpose a complex and powerful mapping tool to draw a picture? Instead, why don’t we just, you know, DRAW A PICTURE?

Fine, but how do we do that? Enter SVG.  SVG (or Scalable Vector Graphics) is a form of vector imagery in XML format which draws shapes and lines as a series of paths.  While this format is not supported by all browsers (ahem…Internet Explorer), fortunately there is a JavaScript library called Raphaël that will draw SVG paths in old and new browsers.  Finding an SVG of the countries of the world was relatively easy, and from that point, I leveraged Raphaël in drawing the image.

Rather than explain further in great detail how I coded and created this extension, what’s more important is to emphasize the need to consider the goals of our data visualizations.  Just because we’re showing a map, must we use a mapping tool?  Clearly not, and by drawing the world map as SVG, we used the appropriate tool.  Our visualizations should yield to the data.  If the data is trying to tell a story, we should get out of the way and let it tell its tale.



For a more in depth and technical overview of the extension, please click here for a zip file containing the extension and a technical brief.

Filter Blog

By date:
By tag: