Qliktech needs to address differing functionality across browser clients

[#1]

Am I the only one, or is it really frustrating that certain things only work within the IE plugin, whereas others only within the Ajax client?

For example, macro functionality is greatly restricted when using Ajax (indeed some macros that work perfectly fine in IE plugin don't run at all within Ajax). And third party extensions only work within Ajax. There are other examples, where a choice has to be made between which client to focus your design around. But this shouldn't be the solution. It shouldn't matter whether you design for IE, or for Ajax. I would expect to get the same results.

So if you want an application that makes use of both extensions and more complex macros, well ... you can't !!

Documentation provided by Qliktech is quite poor in this area and I have yet to find a definitive document that offers a useful summary of what can/can't be done in either environment.

I'm interested in others' thoughts on this. Is it something Qliktech is planning to address? Surely the company is doing well enough now that it can invest the resources into making a product that operates consistently and is client-agnostic.

Regards

James

(using QVS and QVD 11.2 SR1 64 bit)

[danielrozental]

IE Plugin is sentenced to dissapear, so I wouldn't bet on QT investing any money in it.

Macros are usually not a good idea anyway, but hopefull Ajax will increase support for them.

[Bill_Britt]

Daniel is correct. Microsoft is dropping support for the OCX as we know it now. So, in the future you will not have to worry about which one to design for.

Bill

[#4]

Thanks to both for your replies. I had heard that the plugin would eventually disappear.

On the subject of macros, I would argue that they are often a good idea. We have a number of regular reports that are run using macros that auto-generate numerous spreadsheets by looping through selections, for example. A lot of time can be saved via macro automation.

I have always believed that the inbuilt Qlikview reporting is actually very poor. You can generate PDFs, and distribute QVW files (if you have Publisher) but that's about the limit of it. There is a real absence of other options in the market. If a reliable reporting package existed that allowed users to generate spreadsheets, or populate document templates, then macros wouldn't be required anyway!  (There is a product that claims to do all of this, built by a third party developer, but we have trialled it and it proved to be even less reliable than the macro approach).

So I do hope that Qliktech listens to its customers and either enhances the functionality of Ajax, or else starts to really make ground in improving its reporting. It would seem a step back to me if the plan was to go with Ajax (as it seems to be), but going down that road stripped out functionality that a lot of people rely upon.

James