Challenges of Multi Device Support with Portals

Introduction

Portals have been around for some time now, delivering content to standard browsers. A good definition of a Portal is; “A web portal is an entry point to a set of resources that an enterprise wants to make available to the portal's users.” (Tran, 2002).

The components of a portal include an aggregator. The aggregator is combining the content, for instance pages and portlets together to fulfill a user's request. The challenge for content authors even in supporting HTML markup is to get a common solution for each popular browser. Portals will want to support the top market browsers and any that their clients need. Desktop browsers (different js/css/dom, todo:elaborate a bit on IE/FF/Safari/other browser challenges).

The task is daunting when we introduce thousands of devices with several protocols, different markup, different support for css and javascript (Figure 1). Additionally, the device may or may not use color, therefore a content author will want to fallback to a black and white image when necessary.

Figure 1.

The many devices and applications in Portal (Landrum, 2009)

When building a quality user interface for a mobile device, the obvious challenge is presenting the right UI artifacts in a smaller window. A developer must understand the use case and stick to the essentials. Unlike a desktop screen where some pages have superfluous areas that can be filled, a mobile device does not have that option. Window space is at a premium.

A designer should use the best practice guidelines. A designer will want to “where appropriate, use device capabilities to provide a better user experience on more capable devices.” (W3C, n.d.). The use of color images or color with fonts is common place but what will the fallback be on a basic device? Coding a fallback technique done well will help with maintenance but may not eliminate updates to the code.

It might be suggested by some that a smaller user interface might help performance because there is less content to request, but it is important to note that lesser doesn't necessarily mean improved performance. What the application requests from Portal is the key. The designer must know the expense of the request to the backend that Portal is aggregating for any request, but it is more important to a wireless device crossing it's telecommunications provider network. Supporting mobile device clients requires performance testing of the Portal and appropriate sizing of the server infrastructure. Delays in the backend will magnify the delay at the device due to the nature of the network topology.

The standards for device identification and support are JSR 188 (Java Community Process, n.d.) and W3C Device Description Repository Simple API (W3C, n.d.). Portals using the standards provide the confidence that their technology is extensible and proven technology that has subject matter expert support. Portals deploying applications for mobile devices by building homegrown, non-standard applications with device support logic in their applications are destined to become maintenance drain. Your business does not want their return on investment impacted by poor architecture choices that will have a lasting impact on the deployment.

Good design practices of for a portal architecture include decoupling the application logic from the device attributes to support many devices. A good design will have application code separated from the layout, branding and customized attributes for the markup delivered to a device.