Qlikview vs Qliksense - segmentation or replacement?

[davdiste]

Hi all,

Several IT providers in the last period are changing their offering from Qlikview to Qliksense.

Among the motivations IT providers give:

- Qlikview is becoming obsolete

- Soon Qlikview will be dismissed

- Qliksense is smarter

- Is more efficient to concentrate the training of technical skills on one of the two solution

In your opinion, which of the following statments is more true and why?

1) Qliksense will replace Qlikview. The aim of the solutions is the same and Qliksense is more aligned with the business needs of customers

2) Qlikview and Qliksense are different. An IT partner capability to provide BI projects based on both solutions is a point of strenght

[davdiste]

Hi Steve,

I've appreciated your comment and I'm reading your topic on th blog.

Thanks

[davdiste]

Thanks Henric for the answer,

Your opinion for me is more than important, maybe the more important.

Is really hard to get used to answer 1), Qlikview in the last 4/5 years gave me a lot of satisfaction (and is giving a lot of satisfaction my customers too).

Best regards.
Davide

[hic]

QlikView is still the more mature product, and I too - just like many of our customers - use QlikView a lot. So we need to support and improve QlikView for many years to come. And we will.

But that shouldn't stop us from making Qlik Sense better, so that more and more customers choose to use Qlik Sense. Also, we are making it easier to have a mixed environment (having both QlikView and Qlik Sense) and re-using resources for both. Only this way can we support the BI journey of our customers while focusing our development efforts on modern technology.

HIC

[davdiste]

Thanks Peter

[stevedark]

Hi Henric,

I'm pleased to hear that regarding bringing more and more of the features of QlikView through into Sense, and that this is where Product Design's head is at.

My slight confusion with this though is if this is the objective why has it simply not been done over the past couple of years?

You mention Buttons, so let's take that as an example. There is an excellent extension for this available on Qlik Branch. Written by Qlik's very own Stefan Walther. We both know that this extension is going to be stable and well thought through. With Stefan being on the team there, Qlik has the perfect opportunity to sort the commercial and technical arrangements to make that extension part of the core product, rather than one I have to download and install separately at each site I deploy to.

If there was a real desire from Qlik to move toward feature parity of the products I can't see why we still do not have buttons.

Whilst other features are drip feeding through (variable column headings a couple of releases back and condition columns just recently), there are some real blinding omissions - a straight line trend through a line chart is one I have mentioned to you previously.

I am playing devil's advocate here a bit, as I do know a little about the challenges in achieving these things, and what your own opinions are on some of the issues. I do think though that more clarity needs to be given to the user community at large, so that questions like the one Davide asks here do not even need to be asked as the direction is clear.

Perhaps a discussion to continue over a beer at some point soon...

Cheers,

Steve

[robinrouleur]

Hi Henric

That is fantastic to hear!  Can you tell me if you have show/hide sheet object (based on expression) or bar offset (e.g. for use in your Gant example) on your road map for availability soon?  We are very keen to move to Sense but these are road blocks, particularly the show/hide functionality.

Regards

Robin

[hic]

An object show/hide functionality like we have in QlikView wouldn't work well with the responsive design that we use in Qlik Sense. So, I am skeptical to having a QlikView-like solution.

We are however looking at creating a container object that could solve that business problem. The container would then have some logic (defined by the app developer) that defines which of the sub-graphs to show. And this way the container would follow the responsive design logic, while internally having a conditional show/hide of its internal charts.

HIC