Importing external charts into QlikView

[#1]

We are doing a gap analysis on the capabilities of the QlikView in terms of extending the functionality to add new charts that are not readily available in QlikView.

We found some really cool charts (fusionCharts) and hoping to get such charts in QlikView.

Until then, for our analysis, we would like to know if there is any way we can import some external charts into QlikView?

Cheers,

Chakri

[swuehl]

Not sure if I understood your requirement for external charts right, do you mean non-standard / not built in chart types, but accessing QVs data model?

You might want to look into "extensions", that's a way to extend the available chart type with custom ones.

There is a demo on the QV web site http://demo.qlik.com/detail.aspx?appName=Extension%20Examples.qvw

and I think also with the QV10 demos installed.

These are just demos, you could create more chart, but that would need some coding.

Hope this helps,

Stefan

[#3]

Chakri,

I am not sure what kind of chart you are looking for. You can import google charts from http://code.google.com/apis/chart/ which can be called as a image in qlikview. The only problem is that they are not interactive as native qlikview charts.

I haven't used fusion charts but i guess they can be used as they are jscripts.

Kiran Rokkam.

[mountaindude]

You can indeed use extensions, but IMHO they don't (yet) at all live up to the requirements of anything more than quite basic charting applications.

For example, if I've understood things correctly, there are in reality limits to how much data you can pass from QV to the extension. This has become a limiting factor (and ultimately made me ditch the idea of using extensions for this) in all cases I've tried using them (not too many to be honest, maybe a handful).

There might be workarounds - QV 11 might solve this - nobody would be happier than I.... BUT to me QV's lack of native/built-in modern, visually appealing charts a major problem.

FusionCharts, HighCharts, d3, Protovis all have (once again, IMHO) charts that simply are *much* nicer looking, have smoother animations etc etc.

Several of QlikView's competing products also have better looking charts (but I'd still say QV wins in terms of fast prototyping and development).

At the end of the day, many end users of QV applications are likely to have seen better looking stuff elsewhere online. I quite often get this feedback from users of the apps I've developed: "Great to have all this data, but it looks kind of boring compared to these custom-built dashboards we also have" (built using some of the previously mentioned tools).

And they are right - comparing the two systems side by side, QV never wins on visuals.

Anyway, 'nough ranting.

Extensions are cool and I agree with Stefan - give the demos a try and see if they meet your general ideas, if so you can always extend them with your own requirements.

good luck!

Göran

[#5]

I confirm that the volume of data extensions objects can handle is a limited factor, mainly because all the processing code is done in javascript on the client side which takes a very long time if there are more than a few rows of data. Native QlikView objects are rendered on the server side and only the resulting images are sent to the client.

In my opinion the use of extensions will remain marginal until there is some way to enable processing on the server side to overcome this limitation.

[Brian_Munz]

BTW, there's newer and better extension examples here:

http://us.demo11.qlik.com/QvAJAXZfc/opendoc.htm?document=qvdocs/Extension%20Examples.qvw&host=Demo11

Documentation exists for these as well.

I agree with you guys to an extent, however, I wouldn't say that javascript isn't useful past a "few rows of data." But, you're right for huge amounts of data, a client side language like JS isn't the best without tailoring the data for it. Although I don't see a huge amount of limitations for certain charts.  For example despite a QVW having an enormous amount of data, that data still needs to be condensed down into a way that able to be visualized (in a percentage, or a total by month or year, etc.) so by the time the data gets into the extension it is often condensed down into such a way that it is usable.  For example, with an org chart visualization, you can start with an enormous amount of data, but what's the point since it's too much data to even make sense of?  It would just be one enormous blob that would take up the size of a wall.  Similarly a pie chart with 300 slices doesn't make sense.  YOu just need to have QlikView do the heavy lifting and pass the data in formatted in a way that allows for faster processing.

For the products that were mentioned above, such as fusionCharts, protovis, etc.These are all based in some way in javascript so they can be used, but will also be limited in terms of a huge amount of data. I just think the mistake is to throw all of the data into a JS based tool or library without tailoring that data to it first.  For example, like was said above, in the AJAX client, QlikView works with the data and pushes out an image of the chart.  But, what does that chart contain?  Maybe it's a bar chart with 9 bars, an x/y axis, and values representing the bars.  That's a lot of data condensed into a somewhat simple visualization data-wise.  So the extension only needs to know that last information in order to render a chart. Just give the extension the bars with the values and the x/y measures.  That would end up being a small amount of data and processing.

But, I agree that visually QlikView the product itself needs an upgrade as far as look and feel of charting and I know there is a lot of work currently being done to improve it.  Because even if javascript can provide these slicker charts that people want, I don't feel like extensions should simply be there to fill in the gaps as much as provide an ability for more custom solutions and integrations.  Ideally, any more commonly used visualization should be native to QlikView eventually.    

[Brian_Munz]

Oh, btw, you mentioned FusionCharts...in the v10 extensions example doc that was posted early on, the Gantt chart was built using FusionCharts.  I think there's documentation somewhere on how this was done, if you'd like me to find it.

[IAMDV]

Hi Brian,

I am looking for something similar. We need to integrate external objects to QV. It will be great if you can provide any documentation.

This is great thread, thanks to all.

Cheers - DV

[Alexander_Thor]

Agree on all the points Brian made. In our qvws we always make an effort to make sure we use the correct granularity and make sure our graphs are looking good in accordance with the amount of data.

Why aren't we looking at extensions the same? Sure, we do run into a few bottlenecks when processing something like hundred thousend rows but other then that we are heavily using extensions for various reasons.

Not to forget that we finally are able to interface against external data WITHOUT incorperating them into our data model, a huge plus.

Still the ability to execute server side code would fill a few caps that we have today, not in the visualization box but to run long running processes, managed and secure code to integrate with other system or a nifty little event messaging pipeline would be sweet

[#10]

I am working on an extension to do map rendering, and drawing a map with few thousands objects is frequently done. It may be an exception but in this case server-side processing is a must to keep the UI responsive.