Nope, this isn’t a pastiche on Harry Potter, but a reflection on the reality on how far GUIs can take you.
Not long after I joined QlikTech, I attended a dinner with a group of QlikView users. One of my dinner companions, who’d been using QlikView for a long time, had also been trying out a visualization tool. He said something about his experience of using the two that struck me as very insightful: “What I can build in QlikView in 30 minutes, I can build in 10 minutes in a visualization tool. What I can build in a day in QlikView, I cannot build in the visualization tool.”
Based on my interaction with customers and prospective customers in the last few months, it’s increasingly obvious that people are beginning to get it. In their evaluations they are starting to see past the initial ‘wow!’ of an easily built chart, and comparing based on front-end experience and back-end power. Without the back-end power of QlikView to speed iterative, unconstrained analysis any front end would quickly lose its sheen anyway – pretty charts count for little if performance is poor, as users won’t or can’t wait. (QlikView’s strength here was borne out by BARC’s recent BI Survey, which ranked QlikView #1 for query performance vs. other ‘Visual Analysis & Data Discovery Vendors’).
What I still hear however is the comment (usually originating from our competitors) that ‘scripting is bad/outmoded/old-fashioned/too hard’. Wrong, wrong, wrong. Scripting is an aspect and evidence of the power of any platform. QlikView has always been a Business Discovery platform, not a single use tool, and will continue to be so with QlikView.next.
Wizards are great – and QlikView has them too for data integration - but they’re an option for simpler scenarios. It’s disingenuous to claim that a graphically driven wizard in any software product can facilitate building as broad a set of applications as a scripted development language can. Any GUI or step-through wizard has to present a small set of options to the user – if not it becomes complex and confusing to use. As such, at some point users inevitably come up against the edges of what they can do with a wizard: if they don’t, if all of the functionality of a BI product can be developed and deployed via a wizard, then that product must be limited in the value it can provide. Again: “What I can build in a day in QlikView, I cannot build in the visualization tool.”
Finally, if users cannot build what they want in a simple BI tool due to its backend limitations, then they are going to have to do scripting anyway, just externally to the BI product probably using (yup – you guessed it) custom SQL code, and that comes with its own set of demands and limitations. Just try writing the SQL to handle OUTER JOINS between multiple tables to display in a viz tool vs. the script to do so in QlikView (LOAD * FROM…). I know which is simpler - but again that speaks to the power of QlikView’s backend – its associative engine.
For QlikView the answer is wizards and scripts, to access the power of the backend and deliver the widest value via the most appropriate interaction for each type of user.