Developing QlikView Apps for the iPad

All observations here are as of QlikView 11 SR1 (11282).




Overview

In my last article I talked about my overall impressions of QlikView on the iPad.  To review, I am excited about it as it will revolutionize the way we consume data in business.  

But the experience does have some issues that are specific to the iPad.  Most of these are very minor and can be thankfully worked around without too much effort.  The key with all of this is balance.  We want to ensure that the user performance is as optimal as possible regardless of the appliance that will be used to access QlikView.

Ratio

The first area we must focus on is screen ratio.  Now it is easy and perfectly OK to perfectly ignore this issue by building a sheet that is very long (or wide) that basically encourages the user to scroll down through the entire page like a blog for example.  I have seen examples of this and it works well on the iPad.  But if you do not take this approach, then you should strive to create the perfect ratio that encourages an automatic “snap-to-fit” on the iPad.  In my experience, that ratio is 1024:628, or my preferred overall resolution of 1320:810 (more on size later).  You might need to experiment with this template to reach the perfect balance.  You want the snap-to-fit gesture to automatically place the edges of all your objects to be in view. 

Ignore the ratio issue with this type of a layout so users assume scrolling down the page:

Respect the iPad screen ration with this style of a layout (not to scale):

Whatever you do, make your choice obvious.  If you follow the long approach, it would be wise to have an object or two that crosses the threshold of viewable vs. non-viewable space so that the user can easily observe “there is more to discover” rather than having to consciously look for a window scroll bar.

Size

Size or resolution goes hand-in-hand with ratio.  I know when I am developing for the iPad that users will actually be using their desktop/laptops as well as the iPad.  I personally find that limiting the overall resolution of an app to 1024:628 pixels makes for a very small footprint on a typical office workstation monitor.  Besides, the newest version of the iPad is double that size with a native resolution at 2048:1536.  That is actually too large for most office monitors!  So I have found my “sweet-spot” at 1320:810.  This creates a very presentable window on most monitors while also creating that “snap-to-fit” ratio we talked about on the iPad.  An added advantage of more pixels is that when a person zooms with the newer iPad, we will retain a sharper image as we move to a higher overall resolution.

The other issue concerning size, is that the iPad will naturally reduce the height of the tab row with an increase in the overall width of the application when it is fit to the screen.  This means that you need to be cognizant of the balance so that the tab row is easily navigatable or not use a tab row at all.  Either way, this will affect the “perfect ratio” slightly, so some adjustment might need to take place.

The easiest way I have found to make that adjustment is to place an almost transparent 10x10 text box in the lower right corner of your screen.  Of course, you must subtract 10 from the X and Y since the text box consumes 10 pixels both ways.  But fine adjustment of this text box and then testing on your access point with an iPad will get you to that perfect fit.  And then I just leave that text box there on each sheet so that the iPad knows what to snap to.  A user will likely never notice it.

Text in a Text Box

So once we get past the big issues of ratio and size, there are many small inconveniences that have to be worked through.  The first is the positioning of text inside a text box.  You have probably noticed on various browsers up to this point, that text placement can vary inside a text box.  If you have ever placed a text image like an icon on top of a text box with text, you have definitely seen your images “move” in that text frame. 

What is actually occurring is that different browsers treat fonts and font sizes slightly differently.  So Internet Explorer might fit 150 Arial 10pt characters into a text box while Google Chrome might fit 155 characters into the same width box.  Observe the following:

QlikView Desktop:

Google Chrome:

Internet Explorer:

iPad:

The above scenarios illustrate this is not a one-size-fits-all scenario.  The other problem with the way the iPad in particular treats text boxes is that regardless of the vertical positioning you select, text will always appear Top justified.

So my approach then is to make all my text boxes top justified.  To solve the character spacing issues, the only thing you can do is to purposely decide where line breaks will be.  This will minimize the issue, although it does away with the convenience of natural word wrapping.

Font Sizes

When navigating on an iPad, we use our big fat fingers.  Our fingers in reality are a poor substitute for the fine control of a mouse when it comes to selecting something.  That means we need to make our buttons and our selection areas larger than normal.  If a person is expected to click on something, you need to use at least an 11pt font.  For chart legends and other displayed text, you can go to 10pt or maybe 9pt.  But, keep in mind that the overall resolution of your app will enlarge or shrink the font sizes when the screen is fit to the iPad.  I would suggest that after you have settled on the overall resolution, create some list boxes of different sized fonts and try them out. 

Objects

Multiboxes – I have heard people say that multiboxes are a no-no for the iPad.  I have only gotten in-depth the experience on version 11 and I think they are fine.  The only issue is that I would not use grid style multiboxes in any application because the AJAX client renders them as the normal multibox.  This is an AJAX issue, not an iPad issue. 

Sliders – It is very frustrating using a slider on an iPad in its current form.  For the life of me, I can’t get consistent operation no matter what I do.  Unless you want users to throw their iPad across the room, don’t use them.

Horizontal Scroll Bars – I have no problem using objects with a vertical scroll bar.  Just sliding your finger up and down the left side operates it well.  And for that matter, horizontal scroll bars on straight tables and pivot charts work fine too.  But for some odd reason, if you create a horizontal scroll on visual charts like line charts or bar charts, it is difficult to engage the scroll control.  I have set my charts to continuous or not set a x-axis limit for the most part. 

Hover Help – This is kind of obvious.  There is no way to hover on a touch device.  So, all those fancy help hovers and chart value popups will not be accessible when using an iPad.  A nice way to do this for help and definitions is with an “info” button placed on top of an object or somewhere else on the sheet.  For values that normally popup, you will need to display expression as text or maybe allow fast change to a straight table.

Right Click – Another obvious problem is that there is no right-click on a touch device.  So all the fancy options you get when right clicking an object are not accessible.  The easy fix for this is to go to captions and add the “menu” icon.  This will allow a user to click on this icon and pull up all the right click options.  Of course this might not be a necessity…

Missing Functionality – You might notice many missing features in the iPad AJAX experience compared to the desktop AJAX experience.  Here is a list of what you cannot currently do on the iPad:

Right Click Object Menus:

• Properties
• Copy
• Print
• Export

AJAX Menu Options:

• Selections
• Repository
• New Sheet Object
• Select Fields

So why can I “Send to Excel” on an iPad but I cannot popup current selections?  Your guess is as good as mine.

In Summary

Luckily, there are not that many items to consider when balancing an application for multiple device use.  Just being aware of the issues will help us create more universal applications. 

The iPad and other mobile devices represent a huge potential to get QlikView into the hands of more people in more places.  So let’s encourage that movement by creating applications that work well with these new devices.