QV Design – a Design Blog About Qlikview (Obviously)
Welcome to QV Design; a new blog more focused on driving design & layout enhancements of Qlikview; though not to the exclusion of the architecture and scripting elements that we all know and love. Over the coming months I have around 50 or so posts I’ll be looking to present including several new chart types, layout princiapals, design ideas aswell as scripting and insights gained from working with Qlikview for numerous companies from large to small for over 5yrs, where I can I’ll present example files to spread the aesthetic love as far as possible.
So, why do I feel there’s a need for a design led Qlikview blog? Simple; 99% of Qlikview dashboards I’ve seen look terrible and I firmly believe that it’s giving Qlikview, Qliktech and all those who work in the space a bad name, so I’m going to try and do what I can about it. At this point it’s probably wise to describe what I mean by ‘look’; to me it’s both the appearance of a dashboard AND how effectively it transfers knowledge to the user through visualisation and usability; I’d happily accept ugly dashboards if they conveyed knowledge expeditiously; but 99 times out of 100 if it’s bad aestheticly then it’s bad at knowledge transfer. For me that’s the crux of any dashboard; ‘Knowledge Transfer’, of course the script, data model and system architecture are important but they’re just steps to get to the dashboard itself; the place where the magic really happens; where the knowledge is transferred, the insights gained and the potential delivered.
What’s the reason for this aesthetic shortfall? Personally I feel there are several reasons but chief amoung them is the fact that most Qlikview developers are exactly that; developers, who come from a SQL, Oracle, Cognos, BO (old world BI if you like) etc etc development background and quite often have had no involement or interest in aesthetics or data visualisation and now thanks to Qlikviews integrated nature they’re being asked to handle the full data to dashboard process where previously their responsibilty would stop at the the data warehouse. I don’t want to appear harsh on developers; some of my best friends are developers, and I readily acknowledge how important skills previously gleaned elsewhere in the BI and DB realm are when focused towards Qlikview however I firmly feel that this shouldn’t be at the exclusion of usablilty and appearance.
If at this stage you don’t believe this to be the case I’ll provide a short tale about a recent Qliktech conference for the launch of v11 in the City (London) at which around 15 of the UK’s top Partners showcased their wares. As I walked round the demo area looking at each partners demo screen I counted 14 dashboards that had stock charts with stock colours with a literney of visual no-noes (Radial Gauges with no axis’ anyone?). Now there isn’t anything inherently wrong with default charts or the default colour scheme but you can’t tell me that 14 out 15 dashboards all fitted perfectly with ‘out of the box’ charts. For the record the 15th dashboard by Granger Smith Consulting was apparently designed by a graphic designer.
As a final note I should point out that I love Qlikview, I’ve used it pretty much everyday for since 2007, it pays my mortgage and it forms 100% of my working focus, that said I don’t intend to only focus on the positives of the Qlikview world; where I feel Qlikview is wrong I’ll try and address it.