Recently we have seen a dramatic change when it comes to deciding which screen size to design a new report or dashboard for. It’s always been a struggle for BI app designers to optimize applications to fit to the different sizes of desktop PCs and laptops, but adding mobile devices like smartphones and tablet PCs to the mix makes it even more complex.
The most natural solution of the past was to design two different views – one for the desktop and one for mobile deployment. But we no longer recommend this approach as the lines between different device categories are blurring.
Netbooks are encroaching on notebook and iPad territory, coming closer to their display capabilities. iPad has initiated a storm of new devices from other vendors with similar screen size. Even worse (from an app design point of view), Internet giant Amazon.com launched its Kindle Fire, whose screen size sits between traditional smartphones and tablet PCs. And now new devices like the Galaxy Note and the Galaxy III by Samsung, whose screen sizes are between the iPhone and the Kindle Fire, have found their own fans.
Although size does matter, screen size is not the sole point to consider when designing BI apps. There’s orientation to consider – which devices are optimized for portrait or landscape orientation – and on top of this, different vendors also offer a wide variety of pixel density – defined by pixels per Inch (PPI). For example, the new iPhone 4S with its Retina Display is able to display more pixels on its 3.5″ display than a decent netbook.
For app designers, it is impossible to create separate reports for every device, especially at organizations where BYOD (bring your own device) is the standard. This would end up being a total nightmare from a maintenance point of view. So what can we do? It’s time for a new and intelligent approach that will allow us to use one app and one report or dashboard layout for all devices.
Organizations cannot appl(e)aud a vendor lock-in
Now that modern mobile devices (e.g. smartphones, table PCs) have made great strides in their rich user interfaces and people are accustomed to using them in daily life, they’re becoming ubiquitous in the workplace as well. Checking email and synching calendars to mobile devices are common tasks for business people, many of whom are hungry for richer business applications – like mobile BI apps that allow them to interact with their performance information anywhere, anytime. Mobile BI is on the top list of projects for decision support at organizations around the world, and managers are eagerly looking at solutions currently on the market and learning that they’re one of two breeds: native apps or Web apps. Which one is the future of mobile BI?
Native apps are applications that are device-specific – that is, they are platform and hardware dependent. They became necessary when Apple launched the iPhone and forced all developers to create applications specific to the device to be sold on its App Store. Since 2007, developers have created hundreds of thousands of native apps for iPhone that have been downloaded billions of times. But all of these apps need to run through the evaluation process of a single company for a single device category.
Although the iPhone has made some strides into the corporate world – managers do love these gadgets for their stylishness, ease of use, and the device-specific applications themselves – competition isn’t standing still. Many BI vendors have developed native apps to run on iPhones and iPads or have at least provided a front-end interpreter to handle BI presentation layers. But at what cost? Is it worth it for these vendors to put their focus on a single platform when there is an alternative? Does the small bit of increased functionality in a native app justify the decision to go that direction?
A recent Gartner report shows that Android will be the leading platform for mobile devices at the end of 2011 and that Microsoft, with their Nokia partnership in place, is expected to gain back a decent market share. Neither Google nor Microsoft are betting on a “walled garden” approach, but instead heavily promote Web apps.
So what makes Web apps different than native apps?