When Netscape and Internet Explored were using different tags, it was considered “complex”. Certain features worked in one browser, but not in the other, so developers had to put in more effort to make their pages compatible in both. Some problems could be overcome with just a little extra coding, but some major layout differences remained. This not only doubled the development and QA effort, but created an inconsistent user experience.
Compatibility issues, not only between browsers but also between operating systems, have plagued the software industry since its inception. And today, the increasing use of mobile devices adds yet another dimension to those challenges. Not only does each device have a different operating system with a different pre-installed browser, but there are also different form factors. For example, there are different screen sizes with different resolutions.
The emergence of Web apps has come very close to solving the first two problems. Web apps are HTML pages that conform to the UI guidelines of each device. In other words, they incorporate Java script code to support gestures, content zooming, and other user interactions that were previously available only in native applications. While Web apps may not offer all the gestures required to create the Angry Birds game, for example, they are sufficient for navigating BI content on tablets and smartphones without compromising the user experience – which was the biggest fear among IT professionals. But in reality, Web apps liberate IT from the need to go to proprietary app stores in order to deploy applications. IT staff can maintain complete control over the application, while providing users with the best possible experience.
This is why many consumer sites, such as gmail, Facebook, and Twitter have begun to migrate from native to Web apps. And, it is also why we have redesigned some of our reporting technologies, such as Active Technologies, as Web Apps – to enable IT teams to develop once and deploy on any device.
The form factor poses a much bigger problem. Real estate, or screen estate as it is referred to in the digital world, is critical, because there is only so much that one can do in any given space. A large report, let’s say 400 rows and 400 columns, may display well on a laptop, or even on a tablet, but will be impossible to read on a smartphone. In the past, many companies have tried to implement automatic conversion, to fit such content to a smaller form factor. Some layouts are more suitable to this approach. For example, a dashboard that contains four charts can easily be converted to a single chart display where the user swipes through all the charts, one by one. But remember that report discussed earlier, the one with 400 rows and 400 columns? There are many ways in which users can view it, and they may all disagree on what the best way is.
In these cases, media query is the best way to go. The developer associates multiple layouts, designed for each form factor, to each report and dashboard. When the report is run by the end user, the technology recognizes the device and utilizes the specific layout/style sheet that the developer has prepared for it. This may seem like a deviation from the principle of “design once and deploy anywhere”, but it is not. The report is indeed developed once, but the tools allow developers to preview it for multiple form factors, and make layout adjustments for each. As a result, the development effort to build and QA the report is the same. The only difference is the content positioning adjustments, which in most tools is done via drag and drop. This approach offers a completely customizable experience for any device, at a very low cost.