In CapricornVentis, we’ve been delivering great business discovery solutions in QlikView for several years now.  QlikView really helps you build great user interfaces that help people interrogate their data in new ways that they have never thought of before.

Before QlikView, much of my “Dashboard” design work would have been in SalesLogix CRM where we plugged various chart controls into the CRM data to display information such as Sales Pipeline, Performance, etc.  Similar things can be achieved with Oracle CRM On Demand Analytics.

No matter what system you use – BI, CRM, Database, you probably have access to some wonderful tools that allow you to present data to users in lots of different ways.

“What do you want to see on your dashboard”, says the chart designer.  ”Everything”, says the customer.  ”OK”, says the designer.

Stop!  ”Everything” is the wrong answer when it comes to dashboard design.

Think of your car dashboard.  It doesn’t tell you everything that is happening in your car.  It does tell you everything that you need to know, right now, to drive your car.

Think about it.  Many car dashboards don’t include a clock.  A clock is a “nice to have” on a dashboard – it isn’t critical to the running of the vehicle.

A “pure” car dashboard probably needs to have only 3 things – a speedometer, a fuel guage and an oil temperature guage.  Someone might argue that a tachometer is useful because it lets me know if I am over-revving the engine and also lets me know when is the best time to change gear.  We could have the argument but lets just add it in.  So, 4 things.  Everything else is “nice to have” and you don’t need it.

There are other things that I need to know about to run my car.  I need to know that my oil levels are good.  I need to know that my brake fluid is in between min and max.  These are things that I should check every week or so – but I don’t need to know about them right now as I drive this car.

It is the same with the business dashboard.

What do you need to know, right now, to run your business?

This is something that comes up every so often.  A question like, “we have sensitive data (such as salary!) in our system that we only want some users to see”.

This is all very straightforward on SBS where collaboration is not available.  Simply lock down the tab which has the sensitive data displayed using, for example, a condition based on the OSUser() function.

On an Enterprise server, where users can create their own objects, you don’t want them to even see that the field is there.

We can achieve this using the OMIT field in Section Access.  At a simple level, if you only have one field to hide, you can have the OMIT in the main Section Access table.  If you want to perhaps OMIT several fields, then the creation of a group of fields is the thing to do and then just link the user to the group ID.

In the example below, when user1 logs in they will not see Field1 or Field2.  When user2 logs in, they will not see Field2 or Field3.

Section Access;
LOAD * INLINE [
    ACCESS, USERID, OMITGROUP
    ADMIN, admin, 
    USER, user1, group1
    USER, user2, group2
];


LOAD * INLINE [
    OMITGROUP, OMIT
    group1, Field1
    group1, Field2
    group2, Field2
    group2, Field3
];




Section Application;


Fields:
LOAD * INLINE [
    Field1, Field2, Field3, Field4, Field5
    Value1, Value2, Value3, Value4, Value5
];

I am a great fan of Stephen Few.  Any of his books are worth reading for anyone who works in the data visualization space.

If you can’t get a copy of one of his books right now, then 5 minutes reading his article, “Data Visualization for Human Perception“, is a great introduction.  The commentaries by Ronald Rensink, Naomi Robbins and Robert Kosara are equally worth reading.

My belief is that the study of human perception to create great data visualization is fantastically interesting.  There is some fascinating research going on in the area of pre-attentive processing.

As computers get more powerful and the cognitive psychologists keep going with their ground-breaking research, we really are entering a golden age.  I look forward to being a part of it.

Even so, I have a feeling that we will still be using the humble bar chart for many years to come.  It is such an intuitive and simple visual data display method.  I wonder if the real breakthroughs will, in fact, be in enabling people to work more collaboratively with their data to discover new insights.

A brief guide to QlikView Server (QVS).  It is worth noting that the QVS Reference Manual is really good now and explains the specifics of this subject really well.

So, QlikView Server is a version of QlikView that runs on a server!  Simple, eh?  QVS will load documents into memory on the server.  When a client connects, QVS will send enough information to that clients so that they can display the information on their screens.  When the client makes a selection, QVS uses the memory and CPU power of the server to process that selection and then sends the screen updates to the client.  This means that the client doesn’t require to have enough memory and CPU to handle large volumes of data and complex calculations – hence why simple clients such as iPhone and iPad work so well.  The client just needs enough CPU and memory to render the screens.

QVS only loads each document once.  As each client connects, QVS will apportion them a separate area of memory to handle their data requirements (mostly cache of charts).  A “rule of thumb” is that each client will require and additional 10% of the document’s memory requirement.  So if the document loads into 1GB of memory on the server, each client will require approx. 100Mb of additional memory.  As each version of QlikView has been released, their memory handling technology has got better and better and v10 will handle many more clients in the same memory than, say, v8.5.

There are now just 3 main client types (previous versions supported a Java client also).  First, QlikView Desktop can be used as a client to access documents from a server.  When used as a client, you would notice that buttons such as “Save” and “Reload” are disabled because they make no sense for a client – the server will handle all of that.

The second client is the QlikView plugin for IE.  This is an ActiveX plugin that sits inside Internet Explorer.  It shares the same code base as QlikView Desktop so the experience is very similar.  It is still a “thick” client so does require installation – although it comes with an MSI for automated installation.

The third, an easiest to deploy, is the AJAX client.  This doesn’t require any installation because it works within a browser such as IE, Firefox, Chrome, etc.  As of QlikView 10 SR2, it is also supported in mobile devices such as Safari for iPad using HTML5.

The majority of Plugin or AJAX end users will access their documents via AccessPoint.  AccessPoint, by default, takes a user’s Windows Authentication information and will be able to present to them all of the documents that they have access to.  This means users won’t be confused by seeing documents that they won’t be able to open.  Users can also set “favorites” in AccessPoint so that they can default to seeing their most used documents.

Windows security is the default for QlikView server but not the only method available.  By turning on QlikView’s DMS authentication (not available in Small Business Server), the task of authenticating the users can be given to any other type of directory service or even a completely custom form.

Another really interesting session that I attended at Qonnections was on scalability. Here, we looked at using the JMeter tool (an open source product from Apache: http://jakarta.apache.org/jmeter/) to first record a set of interactions and then play them back multiple times with multiple sessions.

This is a really powerful tool. Not just for QlikView but for anyone developing web products.

I can’t record all the steps here, but there is a tutorial document and some sample files available from the Community page @ http://community.qlikview.com/groups/qlikview-scalability/forum/default.aspx