This is the second article in the Mobile Browsing series, which explores issues related to the Nokia Web Browser and Web development for users using mobile browsers. In this installment, we will look at how content is provided for mobile devices, take an overview on usability issues, and explore development and testing environments. Future articles will research practical techniques, such as designing navigation and using CSS, and provide examples to illustrate the topics.

A different approach

When a browser requests a page and accesses a Web site, it announces its identity by providing User Agent information. Based on this, the content of the site can be tailored for that particular browser. For Web designers, customizing the Web site for a particular browser is often an unwelcome but necessary task. It is good practice to try to design a site that works well in all major browsers without having to fall back on ”fixes.” The situation has improved in recent years, but skillful coding is still needed to achieve the correct results across standard desktop browsers and platforms.

With mobile platforms, the situation has perhaps been even more difficult. Mobile browsers have technical limitations concerning display size, processor speed, and network latency. In addition, users may be billed for the amount of data that is transferred during a session.

There are different methods for tailoring content for browsers. Content can be modified on the server side (before sending the data to the mobile client device) or on the client side (in the actual mobile browser). The solution might also be a combination of the two.

A server-side solution is achieved with the use of techniques such as Java™, PHP, and ASP programming languages. Based on the information supplied by the browser, the server can modify the content and structure of the requested page. For example, the server can automatically strip large images, restructure the content to better fit the mobile display to ease scrolling, and remove parts that are not supported by the client browser. As a result, the user does not have to download extra content over a limited bandwidth, the browsing becomes faster, and the amount of transferred data is kept to a minimum. The rendered page may fit the mobile device screen, but it can look very different from the “Full” site layout.
There have been problems where the server pushes “Mobile” content to the Nokia Web Browser, which leaves the user with a much reduced version of that Web content.  For any developer of content targeting mobile devices it is important to include a clear link to the “full” HTML page.

A practical example of the server-side approach is used by the Opera Mini browser. Opera Mini uses a remote server to pre-process Web pages prior to sending them to the mobile device. An engine on the proxy server reformats and compresses the original Web page before sending and may adjust the images on the page before passing the data forward.

Another example of a server-side solution is Google Mobile. The Google mobile search service is formatted to fit a small display. After performing a search and selecting a link from the results, the Google server reformats the Web page to fit a mobile display. For a demonstration, type “nokia” on the mobile search service and select the first link. Then use the normal search and compare the results. Both of these approaches are successful in delivering mobile content, but are a solution to a problem that does not exist with the Nokia Web Browser. It can render the full Web content without resorting to server portals or filtered pages.

Server-side solutions require active upkeep and development. Because there are several different mobile browsers (and different versions of the same browser), all with different capabilities and restrictions, the server administrator has to constantly test and update the modification scripts. There are useful open source solutions that are available to help query and return the correct information (for example, see the Wireless Universal Resource File).

In general, implementing server-side solutions requires more initial work and assumes a level of server access and expertise that goes beyond the simple Web design skill set. For many smaller site owners, server-side scripting is something to be avoided, and many hosting companies charge additional fees for providing this service.

Adopting a client-side solution involves a different approach. The requested page is sent "as is" to the mobile device, and any possible tailoring of the content is done in the browser rendering engine. The Web developer can include JavaScript™ and alternative CSS styles to reorganize the content that is actually processed on the browser.

The Nokia Web Browser aims to deliver a full, desktop-like browsing experience. Web developer can be sure that the user will see the page as it is designed, without external reorganizing of the content. From the user’s point of view, this approach is quite simple and natural: a Web site has the same look and feel on all browsers. Branding and “sense of location” — both important elements to the success of a web space —  are properly maintained.

However, it is still advisable to take the mobile browser limitations into consideration while developing Web sites. The key is making the sites easy to adjust to the mobile device, without a major overhaul of the entire site or maintaining a separate site for mobile use.

W3C Mobile Web Best Practices — Developing usable Web sites for mobile browsing

The World Wide Web Consortium (W3C) has created basic guidelines for Best Practices for delivering content to mobile devices. Although the W3C practical guidelines are a useful starting point, they do not cover all the issues relevant to the Nokia Web Browser, and many of the restrictions do not apply to the Nokia Web Browser as such. The following link gives a brief summary of the W3C mobile guidelines: Summary —  Mobile Web Best Practices 1.0.

The principal objective of the W3C guidelines is to improve the user experience of Web browsing when accessed from mobile devices. The context of mobile use, device capability variations, and bandwidth issues may affect the presentation of Web pages. Although browser and device usability are important (for reading, navigation, and interaction with content), the focus of the guidelines is primarily on Best Practices for improving the usability of a Web page with regard to the following issues:

• Presentation: Many Web pages are laid out for presentation on desktop-size displays. Because of the limited screen size of mobile devices, the subject matter of the page may require considerable scrolling to be visible, and users may not get immediate feedback as to whether they are accessing the right content. Creating a mental image of the site quickly is important; this should be assisted by adopting a consistent style.
• Input: Since mobile devices often have a very limited keypad, lengthy URIs are difficult to type correctly and forms are hard to fill in. The “back button” functionality built into the Nokia Web Browser eases navigation considerably. However, it still may be difficult to recover from errors, broken links, and so on.
• Bandwidth and Cost: Mobile networks can be slow compared to fixed data connections and often have a measurably higher latency, which can lead to long retrieval times. Also, the user may be paying separately for mobile data transfer. The browsing experience may not be satisfactory if Web pages contain content that the user has not specifically requested. In the mobile world, this extra material contributes to poor usability and may add considerably to the cost of retrieval.
• User Goals: Mobile users typically have more immediate and goal-directed objectives than desktop Web users. Their intentions are often to locate specific pieces of information that are relevant to their context, and they typically are less interested in lengthy documents or leisurely browsing.
• Advertising: Some mechanisms that are commonly used for presentation of advertising material (such as pop-ups, pop-unders, and large banners) may not work well on small devices. If advertising exists, the user experience of the site as a whole, including advertising, should be as compact and effective as possible.
• Device Limitations: Rendering Web pages— for example reflowing pages, laying out tables, processing long and complex style sheets, and handling invalid markup — can stress the CPU. Because of this, page rendering may take a noticeable time to complete. Some devices have limited memory available for pages and images, and exceeding their memory limitations can result in incomplete display as well as other problems. For Nokia devices, refer to the Device Feature Tables for more information on precise memory and cache sizes on individual devices.

One clear benefit of mobile browsers is that the full Web goes wherever the user goes. Users can access a Web site immediately, whenever they want, within the immediate context that prompted the need. With the integration of new technologies such as location, imaging, voice recognition, and touch screens, the range of possibilities for services and functions is growing rapidly. Also, particularly in developing countries, mobile devices are more common than desktop computers. Web-capable mobile devices will play an important role in deploying widespread Web access.

Development and testing environments

During the process of Web site development, the Nokia Web Browser can be considered as just another browser upon which to test and verify the design and functionality. However, testing should be incorporated in the early stages of development. Developers should run a quick test on the mobile browser every time they make large layout or design changes or add advanced functionality to the site. If developers have a defined set of test cases for Web site testing, they should check their applicability with the mobile browser and modify them or add new ones if necessary.

During development and testing, developers may discover that there are some features that simply cannot be displayed with the current version of the Nokia Web Browser. If these features and functionalities are essential to their Web site, they should not dismiss them simply because of this restriction — browser features are being developed continuously (for example, version 3.1 of the Nokia Web Browser adds native support for Macromedia Flash Lite from Adobe), and the problem may be solved this way. However, they should also consider the impact and possible solutions for the problem. Does the lack of a particular feature cripple the site completely? How can this situation be avoided?

The normal Web development approach can be used for both desktop and mobile devices. For testing and verification, there are the following alternatives:

• “Quick and Dirty.”Desktop browser/IFrame: A quick testing method that does not require special tools or access to a particular device is to simply use a resized version of a common desktop browser. Alternatively, developers can use a tailored IFrame for presenting content. IFrames are an inline HTML element that allows another HTML document to be embedded inside the main document. You can download a sample iFrame here. There are also online services for emulating mobile device behavior; for example, see www.yospace.com.
• “Heavy Duty.” SDK emulator: Software Development Kits include emulators for testing browser behavior. The emulator provided in S60 Platform SDKs for Symbian OS, for Java does provide all Nokia Web Browser functionality (excluding MiniMap and text rendering), but is a smaller, lighter download. The S60 3rd Edition SDK for Symbian OS, for C++ is a larger package, but it provides full browser functionality. Web pages loaded as local files need to be placed in a specific location and opened with the SDK file manager. For the Java SDK the default local file location is “C:\S60\Devices\S60_3rd_MIDP_SDK\bin\epoc32\winscw\c\Data.” For the C++ SDK the default location is “C:\Nokia\Epoc32\wins\c\nokia.”
• ”The Gold Standard.” On-device testing: The best way to test the full functionality of the design is to access the material over a live connection. This allows the developer verify the site design and functionality from the mobile display, using the actual device keys and input methods. On some devices it may be possible to test the files locally by transferring them to the memory card.
  

For rudimentary testing purposes, a sample IFrame is provided with this article. Developers can use the IFrame to quickly see how their site would look on a mobile browser display. The IFrame size is defined to be the standard QVGA (320x240 pixels) size. Note that while an IFrame is good for quick testing and demonstration purposes, it should always be augmented with at least one of the other methods listed above.

Taking mobile browser issues into consideration does not have to mean that existing processes are turned upside down —  rather, these browser issues can be adapted to fit into the development and testing methods and processes already used in the developer's organization.

Back to top