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
- 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.
