From The QVDesign Crystal Ball: What’s .next for Qlikview?

In 2001 as a student I wrote a White Paper for Nokia as part of a ‘future thinking for mobile’ competition where I outlined the inclusion of GPS functionality in mobile devices, them accessing & caching map information based on GPS data, location based advertising and other related services and judging by my iPhone I was pretty much spot on so it’s time to do the same for Qlikview!

Anyone who works with or is interested in Qlikview should by now have heard a little about Qlikview.next – if you haven’t you’d better catch up because your world is about to change markedly, mostly for the better but potentially for the worse.

There have been blog posts a plenty via the Community: http://community.qlikview.com/blogs/theqlikviewblog/2012/10/24/enabling-the-new-enterprise-with-qlikviewnext-in-the-age-of-empowerment, various commentary pieces from other blogs: http://www.quickintelligence.co.uk/whatever-next/ and lots of presentations from the perpetually in motion around the globe Donald Farmer at Business Discovery World Tour Events but nothing really tangible has been revealed. Therefore I’m going to mix a little hypothesis, assumption, knowledge and snippets of information together to try and look at not only what Qlikview.next is shaping up to be but perhaps more importantly what impact it’s likely to have on each and every member of the Qlikview family.

The outline of what Qliktech are trying to achieve with Qlikview.next has been covered in a recent White Paper that can be downloaded here: http://www.qlikview.com/us/explore/resources/whitepapers/the-qlikview-next-product-scenarios It’s an interesting document that pulls back the covers to reveal a little information but firm specifics remain elusive, it strikes me as being a more ‘high-level aims’ kind of document. I won’t go though each of the 5 themes as there’s plenty about each of them out there already so I’ll focus on a few key areas and the potential impact of all this change.

First of all let’s get rid of the marketing fluff; for me there aren’t 5 key themes for Qlikview.next, the areas that are going to have the biggest impact are: it’s mobile, it’s open and it’s simple.

1. It’s Mobile

Firstly in my experience when people talk about ‘mobile’ they aren’t talking about ‘mobile’ at all, they’re in fact talking about ‘Always Accessible’ – it’s only ‘mobile’ by the virtue of the fact that humans are by our very nature; mobile; we commute, we visit the factory floor, we sit at a desk in office A one day and B the next. If I’m going to have access to my dashboard at all times then it has to be mobile; having a dashboard available shouldn’t make me more mobile it simply means I can get more out of my time whilst I am mobile.

So let’s start again…

1. It’s Always Accessible

Qlikview.next is being developed as a touch (read ‘mobile / Always Accessable’) UI first and a desktop ‘point & click’ one second. Just have a think about that for a moment. A product that has I’d estimate way under 10% of it’s consumption and less than 1% of it’s creation carried out via a touch interface currently is making it’s next product primarily to suit these small percentages – it’s either madness or incredibly prescient. I certainly don’t think of it as madness; touch interfaces will continue to grow both through new hardware such as Microsoft’s Surface or through software designed for touch from the ground up such as Qlikview.next itself becoming more accepted and appropriately designed. However there’s a massive danger; do you develop a UI for touch and as a result lessen the appeal or ability of the desktop UI? I know Qliktech are saying that it will be a great interface on both but, well, they would say that. It’s akin to the situation makers of amphibious cars face; both a car and a boat share elements just as interfaces do; they need an engine, they’re controlled by a driver, they get you from A to B but you’ll never see an amphibious car out performing a car on the road and a boat on the water – it can’t happen, there has to be compromise. It’s a simple law; the more multi-purpose you get the less able you are to meet the specific needs of a particular niche; you get conflicts of requirements that lead to compromises in one or all areas. Now I firmly believe that Qliktech will get closer to a hybrid that performs well as both a touch and desktop UI than any amphibious car achieves its goal but I worry unless it’s perfect someone has to loose out somewhere.

I’ve heard it said that Qlikview.next will be the exact same UI across both areas and be great at both – I can tell you now that that’s not possible so I take it that there will be the same underlying menu and functionality options but they’ll be presented and interacted with in different ways dependant on the hardware. That sounds obvious I know but to date I’ve never seen it implemented on a 1 for 1 level ie: where you can do everything easily via touch that you can via a desktop – or vice versa. In every example I can think of where there’s a desktop and a touch version of a business app the touch one always gets dumbed down to a certain extent to make way for the casualness of touch. I have plenty of apps on my iPad that are replicated elsewhere that I prefer to use via a touch interface; a quick browse for a house on Rightmove or searching eBay for example but those are all casual ‘lean-back’ tasks not the ‘lean forward’ that analysis can demand. It seems Qliktech are trying to change this – which is great if they can pull it off; their UI designers will have to be the best in the world if they’re going to manage it.

I know 2 years from now things will be very different but I know from my Qlikview usage currently if I’m sat at a desk with a both a PC and a tablet in front of me it will always be the desktop I turn to for dashboard analysis and yes touch will be more prevalent in 2, 5 or 10yrs time but people will still be sat behind desks…and we won’t have decent amphibious cars either!. How very Luddite of me. I feel that for the foreseeable future mobile is simply something that’s to be used when ‘desktop’ isn’t available; yes it will allow more Data Discovery at the top of a telegraph pole or down a mine but come on; what about the millions of people who from here to retirement will likely be stuck behind a desk.

A simple test; how many work tasks can you currently do on a tablet? Baring access issues you can probably do most – great. Now think how many you’d prefer to do on a tablet over a desktop when the desktop is there and booted up ready to go; I’m sure there are some; updating your calendar for instance but for me in nearly all cases I’d choose the desktop – I’m typing this post on a 15in MacBook Pro and I have an iPad less than 2ft away sitting unused. It’s a case that mobile  / touch is great but only when it’s either a) casual and suited to touch or b) a desktop isn’t convenient. Don’t get me wrong; some elements of Qlikview consumption are casual and suited to touch; viewing the Global Games App for example but from my experience most usage of Qlikview in the business world goes deeper than that away from a dashboard and closer to reporting and analysis which is far from casual. Of course as touch interface design improves we’ll see more and more complex apps that become better consumed via touch than desktop but in the case of complex analysis it can’t change the data and so I feel its complete adoption will remain constrained.

As long as the ‘lean-forward’ non-casual consumption, creation and administration of Qlikview isn’t adversely impacted by this focus on touch then it’s all good but a part of me worries Qlikview.next is going to jump too far ahead of the ‘touch adoption curve’ and devalue itself in the name of ‘consumerization’ and simplicity.

Key Point: Qlikview.next will be entirely different at every touch point, be it developing, managing or consuming and everything will be angled towards being ‘Always Accessible’ be it to access a dashboard, amend a dashboard chart or administer the Qlikview environment.

A piece of loosely related future prediction: perhaps not the next iteration but certainly within 3yrs the iMac may well look something like this: http://perceptivepixel.brandgreenhouse.com/products/active-stylus and have a totally reworked OS to support it – when something like that happens touch will really have come of age and a touch focused version of Qlikview will make total sense…until then who knows.

2. It’s Open

Until relatively recently Qlikview has always been a fairly closed walled off product – yes it can connect to a good number of data-platforms but in terms of functionality or data going the other way it’s been limited. I know it’s possible to embed charts in Sharepoint and we can create extensions to bring in new chart types but I firmly believe that as of Qlikview.next what’s available currently will appear to be miniscule. We’re already seeing with 3rd party products like QVSource that new connectors to weird and wonderful datasources are being created almost daily and I think that will become much more core in Qlikview.next – probably through some sort of IP deal between Qliktech and Industrial Codebox. How’s all this connectivity achieved; through API’s, and it’s through API’s that Qlikview itself will open up and let other products and solutions access its core functionality. Apparently the very basest levels of API’s that Qlikview itself uses to function will be open to developers, again it’s time for another ‘just think about that’ moment. Should it be fully realized Qlikview.next will be able to connect to virtually any datasource (not just platforms like SQL or Oracle but ‘sources’ such as GoogleAnalytics, weather feeds, Twitter etc) that exposes an API and conversely all of Qlikview will be exposable via it’s own API’s – that’s monumental and quite what impact it will have I’m un-sure but it will be huge. Just think if you’re able to bring in feeds of lower level but still relevant data – a stock price feed, weather data, twitter streams – quickly, freely and easily; it opens a whole world of new types of analysis; is there a correlation between my sales of Product A and cloudy weather – who knows, but you will know when the barriers to finding out all but disappear and then you’ll be able to act accordingly.

In much the same way we’ll see more and more usage of Extension Objects in Qlikview.next. It was noticeable at this week’s Business Discovery World Tour event how many more extensions there were on show and this will only continue in the future and I expect Qlikview.next to enable their creation and usage even more. Extensions won’t merely be small objects based around one visualization, I think it will be even greater than that; for example application level integration with R – not just in an individual Extension Object but available for use across any object via traditional expressions; expressions from R seamlessly sitting alongside native Qlikview ones – to me that’s truly open and truly awesome.

I think the impact of this will be 2 fold. Firstly Qlikview apps will begin to diverge; they’ll have more bespoke elements, tailored visualizations, altered peripheral functionality etc all designed to better meet the needs of the deployment in question. The second impact will be on developers of Qlikview: as we’re seeing with Extensions a developer increasingly needs to be multi-skilled not only in Qlikview but in Java, HTML C# etc in order to get the most out of the product and as more possibilities are opened up so the range of skills demanded will increase (The actual role of the core ‘Qlikview Developer’ will drastically shrink but I’ll get to that in section 3.).

Key Point: Qlikview.next will be open, open to data from all sources and platforms and open in terms of letting its data and functionality be used by other products and platforms.

3. It’s Simple

‘It’s Simple’ refers entirely to how Qlikview is used and appears, the product won’t be simple in the background but it will appear simple to the user. This is all very ‘Apple’ in that very complex things are done in the background to make things appear simple and intuitive to the user.

Right now I can tell you Qlikview.next will look very similar to the below:

Qlikview.next? – No Tableau.now

“Wow! Where did you get that exclusive!?”- simple: logic, experience, research and Tableau. Qliktech will deny it to the hilt but without doubt the biggest driver in the way Qlikview.next will look and be interacted with is Tableau, it won’t be identical; we’ll still have association and they won’t but the look and feel will be very close. How do I know this? Let me explain; Data Visualisation – what every Qlikview developer does and every dashboard presents – is a science, there’s a right way backed up by extensive research, logic and proof and a wrong way backed up by 3D charts, bad colour choices and users getting the wrong impressions of their data. Yes people will disagree as to whether an axis line should be this weight grey or that one or what the optimum distance between bar chart columns is but these are tiny differences of opinion; Tableau does visualization (largely) demonstrably right straight out of the box; they’ve invested heavily in academic research to get there ($200m more in the next few years), ergo; for any other vendor to do it ‘right’ they have to occupy the same space and present information in the same way with the same look – it’s not open for debate. Think of it this way: when flying machines were first being designed in the late 19th and early 20th Century there were a myriad of sizes, shapes and solutions (as with dashboard visuals now) but look at aircraft today and the vast majority follow the same design principals, not because it arbitrarily looks prettier but because it’s right; it’s safer, faster, cheaper, more efficient etc. We’re going to see the same thing in Data Visualization; a coalescence around what is inarguably right and it’s Tableau who have started this march in earnest ahead of everyone else and it’s up to everyone else to follow and follow they must.

The flying equivalent of a 3D Pie Chart

I once read a great line about using Tableau; “Don’t mess with the charts as someone who knows far more about data visualization than you has spent a lot of time thinking about what’s right and what’s wrong.”. For those that don’t know Tableau prides itself on it being easy for an end user to create their own dashboards (I feel this is also a weakness when it comes to enterprise level data), users can easily point it at a datasource, load the data, select the fields they want and Tableau will choose the most appropriate chart and create it automatically to be ‘right’. Qlikview.next will also do this through its ‘Suggestive UI’; if you select zipcode data it will know you’re likely to want a map, you want dates and sales information it will suggest a line chart and both will be correctly formatted by default once created. Others are following this route; Excel 2013 will contain the same ‘Chart Suggestion’ ethos. This is a (mostly) good way to go as to be quite frank most dashboard developers are creating the visualization equivalents of flying contraptions from the last century; they’re clueless, so it’s right that the visualization software you use guides you down the right path.

Why do I say this is ‘mostly’ good – simply put if the software and the end user (sorry Donald) can create a ‘right’ dashboard quickly, intuitively and easily then why on earth would they need a Qlikview Developer to the same extent? Undoubtedly once Qlikview.next is established we’re going to see fewer pure Qlikview Developer roles out there, yes there’ll still be people needed to set the environment up and get things rolling but the dedicated Qlikview dashboard developer may well become a rare beast indeed. This has the potential to greatly affect the Qlikview market; Qliktech Partners will see less ongoing need for their core Qlikview services and many developers will no longer be required – for the customer this is great; better dashboards with less outlay and time, but for the likes of me who consult on Qlikview dashboard creation it’s undoubtedly bad; we must therefore prepare to adapt.

A personal must have for Qlikview.next loosely in the ‘Simple’ theme is a public Qlikview cloud: it needs to be possible that anyone can download / access online a public version of Qlikview for free, load data in (perhaps from limited sources or volumes), create an app and then publish it to the Qlikview cloud for free to embed in a website or share via a blog. This would send low-level Qlikview usage through the roof and get the associative data way of thinking out there and really show people that Data Discovery is the way to go – products like Tableau get the visualization right just like any other product is capable of but Qlikview.next will have that ‘right-ness’ and the special ingredient of association which others can’t copy. Without a freely accessible cloud Qlikview risks becoming a business only backwater as SaaS upstarts take all the attention & glory.

Key Points:

 1) Qlikview.next will look a lot like Tableau; it has to. Tableau does visualization the right way, to not be like it is to be wrong – it’s as simple as that. It’s like saying “I’m going to design a new car and give it 17 wheels, 1½ engines and a joystick instead of a steering wheel” – it might work but it’s not ‘right’ and can be proven to be so.

2) With Qlikview.next there will be a lessened demand for traditional Qlikview development as the actual consumers of the information will be the ones who create more of the dashboards they use themselves with the guiding hand of the software.

Conclusions:

There are lots of other areas where Qlikview.next will differ from previous iterations as well as other dashboard and visualization solutions that have gone before; the enhanced collaboration (which I remain to be convinced about), thin clients for all, revised Access Point, offline iPad usage (available now), new charts, server based development and many more things all of which will impact the way we all create Qlikview apps. However for me the 3 high level changes outlined above are the ones that are likely to have the biggest impact both in improving the Qlikview experience and also reshaping the Qlikview ecosystem.

So when is all this change likely to appear? Donald Farmer specifically mentioned ‘entering Beta in the New Year’ at this weeks conference but personally I think it will be a little after that when the wider world gets a first glimpse of Qlikview.next; I’d estimate end of Q1 2013. After that I’d expect a relatively long Beta cycle simply due to the fact that we’re looking at such sweeping changes to the product so I’d be surprised to see the first major full Qlikview.next release before Q4 next year – there may well be more than one.

There’s one final point and it’s not a good one. I’ve head from Qliktech many times in the past things like ‘we’ve got this great new feature’ and it turns out to be something totally illogically implemented or we’ve had Service Releases rescinded due to sloppy testing, so I’m skeptical as to how they’ll cope with the wholesale changes we’re looking at with Qlikview.next. I’m hopeful that many of the challenges can be overcome; they’ve hired lots of new employees specifically for Qlikview.next in the fields that count but the aims for what Qlikview.next will be; all things to all people on all devices, is such a radical and far reaching idea that it will be impossible for there not to be problems along the way.

So I await the reveal of Qlikview.next eagerly, hopefully and with a slight sense of trepidation; it’s undoubtedly going to shake up the current state of play in the Qlikview ecosystem and some people will win and some will loose so you’d better pay attention and make sure you come down on the winning side.

Key Point: Business Intelligence and data visualization is going through the natural transition that all relatively new industries go through; everyone is heading towards a central homogenous point as ‘evolution’ removes the weaker players & solutions and the ‘right’ way comes to the fore. The end point for BI & data visualization is a little past where Tableau is now and it’s where I hope Qlikview.next will jump close to, if it doesn’t it will lay itself open to fresh challengers in the market who see this inalienable truth and act upon it.

Everything is going to change – it has to.

All the best,

Matt

Advertisements
Comments
22 Responses to “From The QVDesign Crystal Ball: What’s .next for Qlikview?”
  1. I want QlikTech to get it right but I’m getting tired of hearing about their vision and goals. I want to start seeing some screen shots and specific features.

    • qvdesign says:

      Chris,

      I agree; I’d love to see something concrete; visions and goals are all well and good but they need to be delivered to be of worth.

      I’m happy to wait (a bit longer at least) if it means Qliktech gets it right.

      All the best,

      Matt

  2. Dan Murray says:

    I’m not unbiased as I evaluated Qlikview and Tableau in 2007 and saw at that time that Tableau did a superior job making the correct visualizations. Since then I’ve become a consultant helping other people achieve results with Tableau quickly. These projects are typically fast, focused and not at all like the traditional BI consulting service providers are accustomed to providing – long, complex and technical.

    Good post. I agree with your accessments and expect that the competition between the vendors will just drive improvements in every project that survives the battle in the marketplace. This will just provide more good choices for consumers.

    • qvdesign says:

      Dan,

      Thanks for the comment, I totally agree that this ‘competition to what’s right’ is only going to be beneficial for data consumers and we’re going to loose & gain some vendors along the way – it’s going to be an exciting 12mths.

      I wouldn’t be surprised if Qliktech were waiting for the Tableau 8 reveal on the 5th Nov to see where they’ll stand in the market and give them time to adapt before their own unveiling.

      Out of interest do you know if Christian Chabot’s keynote will be Live-Streamed?

      All the best,

      Matt

  3. qlikster says:

    Really great post Matt.

    Would also be interested in your crystal ball projections for how scripting will change in QlikView.next. Will there still be a load script somewhere in the background available but somehow created from dragging and dropping components in the touch interface or could the script go altogether?

    • qvdesign says:

      Chris,

      Thanks for the comment, I’ll have to check my Magic 8-Ball for scripting insights…

      Right, it says you’re spot on with the scripting / GUI hybrid. I, I mean ‘it’ thinks that in the basic sense users will be able to easily connect via an improved/simplified wizard to a datasource load it into memory and then drag and drop to create dashboards and associative data visuals. However that can’t go all the way; there’ll still have to be the script editor in the background (perhaps with basic script already written by our dragging & dropping) for the really complex ie ‘everyday dirty business data’ that always needs that element of transformation – if only to set the associations.

      Plus there’s the upgrade path to think about: Qliktech can’t tell all their customers: ‘you’ve got to re-write all your dashboards’, Qlikview.next has to be able to run existing .qvw’s (doesn’t it!?), and there’s no way the scripts can be automatically converted; they’re far too complex.

      I think we’re seeing with Direct Discovery a new slightly different approach from Qliktech, as I understand the ‘Direct’ load statement you specify a few fields from a table to load in to associate with the wider model but EVERY other field from the table is then implicitly loaded in for use even though the actual data isn’t in-memory. This may well be something Qlikview.next utilises more.

      In summary what I think the 8-Ball is saying is: simple UI for getting simple datasets visualised and dashboarded but still scripting for the more complex, dirty data.

      I won’t ask you about the API Connection IP – it would ruin the surprise.

      All the best,

      Matt

      • qlikster says:

        Hi Matt,

        Thanks for your reply – reflects my thoughts too.

        We are of course keen to ensure QVSource plays well with QlikView.next and I have already reached out to QlikTech regarding this.

        I am hoping they will get in touch when QlikView.next gets a little more developed and that we can be involved in the early testing and have input to make sure users get a great experience of loading data from our tool.

      • mellerbeck says:

        You think there will be an upgrade path 🙂 My gut tells me it will be such a break that it may as well be a new product.

      • qvdesign says:

        Michael,

        There has to be an upgrade path – surely, definitely, hopefully, maybe?? I just can’t see Qliktech being able to say to their existing customers who are increasingly large global enterprises “sorry but if you want to upgrade you need to re-write all your reports and dashboards”. If they do it’s maddness and they’ll loose the trust of their customers no matter how good the product is.

        The only slight possibility if they don’t have a traditional upgrade path is that there may be some kind of legacy solution whereby one Qlikview install / environment can serve both old and new .qvw files.

        I hope your gut isn’t right…but I wouldn’t be totally un-surprised if it was.

        All the best,

        Matt

  4. Tom brown says:

    Great post Matt, your thoughts on this explain why I, like Dan Murray above, run a Tableau consulting firm and not a QV consulting firm. But I also agree with Dan, that as more and more companies mimic the Tableau way, that will only make Tableau better.

    Cheers

    Tom

    • qvdesign says:

      Tom,

      This is kind of a Devils Advocate question; do you not find with a Tableau consultancy you’re not need that much as Tableau does much of the work for the users? Of course they need educating in Data Viz a little and the environment needs setting up etc but that longer (and chargeable) consultancy just isn’t there.

      I have to say with Qlikview that usually the length of the development isn’t due to the shortcomings of the software it’s due to the complexity of the data and the requirements: because Qlikview is capable users demand complex reports and dashboards from it which regardless of solution requires time.

      Of course a solution that needlessly requires teams of people to implement isn’t a good idea, but there comes a point where getting complex insights from complex data is just simply complex and needs time and consideration.

      My concern for Tableau is that it will show others the path to visual & interaction correctness but then be surpassed in other areas; such as Qlikviews association model which once the visuals are sorted will create brilliant, easily accessible ways to explore & present data.

      It will be interesting to see what Tableau release on the 5th Nov with Tableau 8.

      All the best,

      Matt

      • Tom brown says:

        You’re right Matt, tableau needs far less consulting time than QV, so Tableau so silting firms like mine tend to work for lots of customers doing short, high value projects. We rarely spend multiple weeks or months building reports and dashboards, as this is best done by the end users, we simply facilitate this.

        This is a very good thing in my eyes, tableau has created a product which most people can use we’ll, and that frees consultants up to work in the really high value stuff like making complex data sources available for analysis.

        So this is much he same as you describe above, when we spend a long time with customers, it is because they have complex requirements, such as a combination of really granular security needs and 500M row record sets for example, not because we’re building dashboards, we usually leave that to the clients themselves, and train them how to do it well.

        V8 is going to upset the BI apple cart again I’m afraid! Qlikview.next might need a rethink!

        We’re running a session in London on November 16th to go through v8 features and their implications if you can make it.

        Cheers

        Tom

      • Harry says:

        Given all the crowing about how much easier easy Tableau is to use, one would not expect a “Tableau Consulting Firm” to be a smart investment. I suspect such firms actually make their money structuring the data for Tableau to consume using other tools. (Tableau has no ETL capabilities and needs pre-structured data sources). So hopefully QlikView.Next does retain the powerful ETL capabilities that it has today, as they are a powerful differentiator).

  5. stevefewster says:

    Hi Matt, good insight, could not agree more on all your points. As someone who lives in the Saas world you only have to look at vendors like Bime, Klipfolio, RoamBI, Geckobard, Cyfe and a plethora of others to see where the future is headed for Qlikview, Tableau and the like.
    Steve

  6. I think there is an important point you’re missing here. I’m very curious about my data, and dependent on analyzing it correctly to survive in my job (University Enrollment Management: You might think of it as Admissions and Financial Aid.) I don’t have the time or the inclination to learn advanced scripting, but I drove the Tableau implementation at my university. Had the tech staff done it, we almost certainly would have gone in a different direction.

    So, as long as QlikView is dependent on scripting for access, it’s going to lose the opportunity to generate demand from the end-user side. And people like me who need data are growing weary of having to tell someone else how to serve up our insight.

    I don’t think the real divide between Tableau and Qlikview is one of graphic standards; most of the people who use Excel or Tableau or any software to visualize data (actually, most of the population) are aesthetically deprived.

    The difference is in the access to the insight. Tableau gives it to me, and to the developers.

    • lewandog says:

      Well put Jon!! To build upon your observations…speed to market, and the ability to be less dependent on IT were critical for me. Though the users go crazy for it, the up front technical requirements associated with QV removed it from my list fairly quickly.

      I guess the questions to QV is…who is your customer, and what are you trying to accomplish?

  7. Thanks for such a through post Matt. Interesting thoughts. I’m a big believer that we are on the cusp of a major change in computer interfaces, I don’t think it’s as simple as desktop vs touch issue. I think there is something bigger in the wings, although I have no idea to if qv.next will drive or even ride on that train.

    My biggest worry about .next is that QV will lose it’s core value (to me and my customers) proposition. That proposition is a single package, rapid results tool. In my experience, it’s those disruptive features that make QV successful. It’s been incredibly successful in the mid-market where the formal data dictionary / semantic/ metadata layer does not pencil out financially.

    The white papers have talked about a “Platform”. But what platform — other than the associative DB, which is remarkable — does the product have? We are short on large scale ETL, so we add Expressor. We are falling behind on visualization, so we create object extensions so others can pick up the slack. We don’t have out of the box vertical solutions, so we delegate to QlikMarket, which so far has been confusing and of little actual value.

    i understand there has been some significant talent acquired at QT to develop QV.next. I hope they can deliver a game changing disruptive product as a I am a QV fan.

    • qvdesign says:

      Rob,

      Thanks for the compliment and comment. I agree we’re on the brink of big changes in the digital interaction world through technologies like enhanced multi-touch, Kinect style solutions and IBM’s Watson system (and of course combinations of all 3 and more). I’m hoping with Qlikview.next that Qliktech is angling to take advantage of these coming changes but I too worry that it will move too far and loose sight of where it’s strengths lie.

      You’re points about what Qlikview has other than the Associative Model are entirely correct; I used to think the answer was ‘In-Memory’ but that is now offered (though perhaps not bettered) by rival solutions and the other offerings are equally widely replicated in the market. I still think as an overall package it provides the balance between flexibility and speed of deployment and for me association is the very definition of a killer app.

      Seeing the major things we’ve seen from Qliktech in recent years listed in your comment (Extensions, Expressor and QlikMarket) makes me realize the paucity of development we’ve seen from Qliktech. Since I started using Qlikview in 2007 I’ve seen Set Analysis, Mekko Charts, Expressor, Extensions, Touch Interface, QlikMarket, tweaks to the server and a few other minor additions, together they sound quite impressive but it’s perhaps only Set Analysis that’s been truly developed in house and delivered on it’s promise.

      All the other areas either weren’t developed in house, have had both positive and negative impacts (Extensions) or simply haven’t lived up to their promise – or had very little promise in the first place and shouldn’t have had time wasted on them.

      By their own admission most of the releases since version 8 have been little more than incremental and didn’t really warrant an entirely new version number on their own, however I don’t think we’ll be able to say that about Qlikview.next.

      I’ve heard similar things about talent acquisition at Qliktech and I’m hopeful they’re up to the task but when I hear things from them like ‘we’ve hired a diverse range of people; iPad kids app developers and even a furniture designer’ I do wonder – you’d never ask a software engineer to design a chair and expect it to be the best in the world so why does it work the other way?

      All the best,

      Matt

  8. Kourosh Ghovanlou says:

    Hi Matt, I would be interested to hear what your crystal ball has to say about some of the visual elements available in QV.next. I’m talking about the tricks we can achieve now through the use of photoshop, images in text boxes, variables and conditional shows. I can’t see it being easy to acheive that on a touch device?

    Also the (I admit) few companies that I’ve worked with on Qlikview have all had a similar set-up – IE8 on XP. We always end up going with the plug-in because of the thin client’s performance. I’ve not heard much yet about how compatible this ‘one client to rule them all’ will work on older browsers. Especially where HTML5 and CSS3 is not an option.

    • qvdesign says:

      I have to admit I too usually recommend the IE Plugin as the way to go as in the majority of cases the AJAX client isn’t good enough and looks nothing like the product that was often demoed to a customer. I’d also like to know how the HTML 5 / CSS3 platform is going to work because as you say the majority of business machines still run XP and IE8 and have no opportunity to upgrade without the approval of a central IT Department. I’d imagine that it may well be hard luck – they’ve said Qlikview.next will be in HTML 5 so I don’t see many other options than it not being optimized / compatible with older IE versions unless there’s some kind of legacy AJAX version.

      As for the visual elements and their creation via a touch device I’d say that there will be a distinction between ‘you can’ do it via a tablet and ‘you’d actually choose to’ – that goes for all complex operations; be it creating graphics, writing script or administering the environment. I certainly think the tailoring for Touch will be focused towards the consumption of Qlikview apps and perhaps a little canned chart creation (things an Information Consumer / End User might do) but I think you’ll always want to use a desktop interface for app development unless nothing but Touch is available.

      I am hopeful that we’ll see some visual improvements in what can be created (or not – who needs ‘Rainbow Borders’!?), even if they’re relatively simplistic like having more than one font in a Text Box. Ultimately though Qlikview will never be Photoshop so you’ll always need to import images if you want relatively easy to cerate bespoke visual touches.

      All the best,

      Matt

  9. Joe Mako says:

    Nearly any application can create a decent chart, what is more important is the logic used to get there. If Qliktech thinks that the magic that Tableau has is just the “Show Me” button and default visual best practices, then they are just looking at the surface, and missing the core thing that makes Tableau a joy to use. Qlikview is dialog driven, and Tableau enables a conversation with data through VizQL, a kind of grammar for graphics. Until Qliktech has a technology that competes with VizQL, I do not consider them competitors.

    • qvdesign says:

      Joe,

      I agree that any application can create a decent chart but the vast majority require a competent user to create them at the moment but I think we’re going to see a movement to more being akin to Tableau in the near future.

      VizQL is an interesting concept and whilst not working in the same way as Qlikview’s associative in-memory model they both achieve similar results in allowing the user to ask more questions that the first one they thought of. I’d hope that Qlikview.next will allow at least to some extent for users to interact more with the structure of their visualizations; change dimensions, expressions and chart type it’s self just as they can currently interact with the data via selections. Of course they probably won’t be able to fuse the visualization creation to the SQL / MDX as Tableau does but with their in-memory reaction speed they should be able to get close to the functionality via slightly different means (I hope).

      All the best,

      Matt

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: