Optimized and predictable Ajax applications

Optimized and predictable Ajax applications Consider inherent browser, system, and user differences

Level: Intermediate Judith Myerson ([email protected]), Systems engineer and architect, Freelance writer 30 Oct 2007 Wouldn't it be nice for developers if all browsers, computer models, and Ajax application users were the same? Maybe, but the reality is that they are not. Developers face a myriad of challenges when developing applications that behave predictably across browsers, computers, and individual user settings. When users transfer Ajax applications from one browser type to another (and especially when they transfer an Ajax application into a Web service portal), they're not guaranteed the same browser experience because of each browser's inherent limitations. In this article, author Judith Myerson gives a brief discussion of these limitations and what pitfalls to avoid, including some helpful solutions for optimizing browser differences. Introduction Discover some of the challenges developers face when developing Ajax applications that are maximized for all types of computers, browsers, and users. Because it's not uncommon for users and developers alike to work with multiple browsers, problems can arise for Ajax developers because users frequently transfer applications from one browser type to another. It's impossible to provide your users with complete cross-browser equivalency because each browser has a few inherent limitations that can affect the way Ajax applications display (and even perform) on a Web page. Common browsers include Microsoft® Internet Explorer®, Opera, Firefox, and Konquerer. With the exception of Konquerer, which runs only on Linux®, these common browsers run on Windows®, Linux, and Apple's Mac OSX. Because there are several popular browsers in use today, it benefits you as a developer to familiarize yourself with the many differences between popular browsers. This article will help you recognize hardware differences in computer types (including their memory, disk sizes, and their number of USB ports) as well as software limitations (such as font availability, HTML extensions, and form elements). After considering performance issues among different computer systems, you'll get possible solutions for optimizing browser differences for users moving applications from one browser type to another and for converting an Ajax application into a Web services portal. Along the way, you'll learn about (and how to avoid) common Ajax development pitfalls. So many computer types, so little time! While many developers favor the PC for converting Web pages into Ajax portals, Macintosh users also perform these types of conversions. If you use the latest version of the same browser to view a Web page on both a PC and a Macintosh system, you'll probably notice that the page displays differently on each computer. And, different models of both the PC and the Macintosh can have different screen sizes and corresponding canvases. The canvas size and resolution on certain models of Macintosh computers can differ significantly from those of certain PC models, despite their settings being the same. These differences in computer type and model can affect not only the way fonts are displayed, but many other settings as well. You have a lot to consider when crafting Ajax applications that behave consistently and present predictable user interfaces, regardless of your user's choice of browser, operating system, or brand of computer. Get tips on factors to keep in mind to optimize your applications for maximum performance and ease of use. When developing Ajax applications, you need to consider page widths and heights and how applications will display given that users can differ significantly in their resolution settings (for example, 800x600 vs. 1024x768). Applications that appear to display well with the larger resolution setting may require a lot of scrolling for a user who has set their computer to a smaller resolution. And, if your applications require too much scrolling, you risk losing visitors to your site. Back to top Memory and disk space differ If a user's memory is not sufficient to perform complex calculations, their computer will try to find space on the disk to complete the calculation. If the allocation of parts of either memory or disk space have been exhausted before a calculation process is complete, your user will get an error message that memory or disk space has run out. A root cause for this type of problem within Ajax applications has to do with how an Ajax application handles memory, disk space, and other system resources. Developers can choose to either alleviate the strain on the system resources needed to complete the calculation or fix the application. To alleviate the strain that could result in system overloads, you should, for example, clean up unwanted files or plug in an external USB disk drive to store and run your larger Ajax applications. To fix the application, you should, for example, divide it into modular parts and provide exception handlings for each part that will make it easier for you to identify the source of the problem. Back to top USB ports The more USB ports a computer has, the more USB devices that can be plugged into it. An optimal computer should have at least two ports to accommodate more powerful USB devices, such as a portable 120MB USB external disk drive with a Y cable. This device is useful if one runs out of internal disk space to store and run Ajax applications. If more than the maximum USB ports a computer can provide are needed, a user could opt for a USB hub. If the hub comes with a Y cable, a user can plug both into the USB ports on the computer. Note: If you try to plug a huge external disk drive into a hub that comes without an adapter, neither the drive nor a Web service portal will work because the hub has less power than the external drive needs. To get the drive to work, a USB hub that offers more power with an adapter is needed. Back to top Font issues Let's look at two font issues: availability and compatibility. Font availability The text in Internet Explorer for Windows looks different from the same text in Internet Explorer (or Navigator) for Macintosh -- specifically, text in a font set a certain size on a Macintosh computer looks smaller than it looks on a PC. As a developer, you need to know the maximum size text can be when using common text sizing methods for PCs and Macintosh computers. The font a specific PC user prefers for browser viewing may not be available for other PC models or Macintosh computers. If a specific font is not available on a specific computer, the font is set to the default type on that computer. (To determine font availability on a PC running Windows, select the Fonts icon from the Control Panel located on the Start menu.) Font compatibility Many developers find it daunting to make text the same size across browsers and platforms. The problem is that browsers have different ways of allowing users to adjust font size. For instance, in the Windows environment, Internet Explorer offers five type sizes: Largest, Larger, Medium, Smaller, and Smallest. Mozilla Firefox allows users to enlarge or shrink font size or return to the original size. Opera, on the other hand, lets users adjust the font size by selecting a percentage from a list. Therefore, no two browsers give the same results when the font size written into an application changes. Even if you set a font size to a descriptive value, such as medium, you will see different results in different browsers. One way of getting around the problem of making text the same size in multiple browsers is to use Cascading Style Sheets (CSS), with either percentages or em values for font sizing. As a last resort, you can use pixel sizes that are based relative to the screen resolution. Back to top HTML standards In addition to JavaScript and XML, Ajax applications use HTML, DHTML, and the Document Object Model (DOM). An Ajax application uses HTML to build Web forms, while DHTML is used to mark up the HTML so your forms can be updated dynamically. Because the DOM works with the structure of your HTML and XML returned from the server, a problem can arise because newer standards and form elements are not universal. Latest HTML versions Because newer portions of the HTML standards display Web pages better in later browser versions, most users upgrade their favorite browser. However, newer standards often are not completely supported in the latest versions of some browsers because, in practice, these standards usually run ahead of what the browsers support. While no browser yet supports 100% of the latest version of the HTML standards, some browsers come closer than others. Because support for the latest HTML tags isn't yet universal, you could be building your pages with parts of the language that not all browsers understand. If a browser can't translate part of your page, it will not be able to display what you want to see. For example, when you use some overlapping layers in Internet Explorer, these layers might not be translated properly in the earlier version of the same browser or in a different browser type. For example, Opera and Firefox may display a small portion of the overlapped layers, which Internet Explorer does not display. I recommend using Web development software (such as Microsoft Expression® Web) to preview your page in multiple browsers before releasing it for general consumption. Form elements Depending on both the version of HTML standard and the browser you're using, form elements can vary in size, spacing, and typography. Form elements can affect how much room pull-down menus, text input fields, and other form elements can take up. You may like the way the form elements display on a page in one browser; however, on another browser using the same form elements that you use for the first browser, you may find the form elements might not display the way you want. Back to top Performance issues You need to consider a few performance factors of your applications before releasing them for consumption. Among these are the speed of the browser you choose, the size of any large XML files, and the impact of any add-ons. Browser speed In my opinion, Opera seems to be the fastest browser for Windows applications. And while Firefox is not any faster than Internet Explorer, I believe it is the better choice for standards support, security, and features. However, it is still not as fast as Opera. For Linux applications, I think Konqueror is the fastest for starting and viewing basic pages on KDE. However, as soon as script or images are involved, I think Opera is the faster choice. And while Firefox performs well overall, I don't think its script, cache handling, or image-based page speed can compare with those of Opera. On Mac OS X, Opera and Safari are both very fast, with Safari 2 being faster at starting and rendering CSS, but with Opera still being faster for rendering tables, scripting, and history. Navigator seems to be a popular choice for Mac OS X applications, over Firefox and Internet Explorer. While Opera appears to be the fastest browser for running applications, I don't think the zoom feature for adjusting type size is as user-friendly as Internet Explorer's type size options or Firefox's Ctrl options. And if you use Microsoft Expressions Web design tool for previewing your Web pages, Opera is not listed as an option. XML file size Be careful and judicious with the usage of large, text-based XML files because they slow down browser response time and can even tie up network traffic. An alternative to large, text-based XML files is to use binary XML (covered in detail in my first article on speeding up Ajax applications while dodging Web service vulnerabilities; listed in the Resources section). Browser add-ons Many add-ons available for browsers, such as pop-up blockers, tab managers, and UI themes, can affect Ajax applications in unexpected ways. For example, you can set up a pop-up blocker to block new browser windows from opening. What you may not immediately know is that the pop-up blocker can consume browser window real estate and hide parts of an application. When parts of a browser are consumed, an Ajax application might not display as intended. The developerWorks Ajax resource center Check out the Ajax resource center, your one-stop shop for information about the Ajax programming model, including articles and tutorials, discussion forums, blogs, wikis, events, and news. If it's happening, it's covered here. Ten tips and pitfalls Listed below are handy tips building optimized Web pages, as well as pitfalls to avoid. These suggestions are helpful for users of Ajax applications as well! Developers: Avoid using HTML extensions and be careful about using cutting-edge features of the language that may not yet be supported by all major browsers. Developers: Don't rush to build pages with HTML features supported by the newest version of a browser. Developers: Design your pages to work for the last two versions of the major browsers. Developers: Alleviate strain on memory, disks, and other system resources by minimizing the drain on them. Developers and users: Refresh Ajax applications, if needed, by either restarting the Ajax application or, as a last resort, rebooting the computer. Developers and users: Periodically delete unused and unwanted computer files, freeing up disk space so applications run optimally. Developers and users: Install more memory or plug in an external 120MB USB hard drive. Developers: Simplify your layer options when you design Web pages for your Ajax portal. Developers: Modularize the Ajax application for easier identification of the source of problems. Include exception handlings in Ajax application. Developers: Avoid text size problems by using CSS to set the application's font size in either percentages or em unit values. As a last resort, use pixel sizes. Back to top Conclusion Input from a team of developers, testers, system administrators, and potential users can help Ajax developers optimize browser differences when developing Ajax applications and converting an Ajax application into a Web service portal. To minimize the impact of browser differences on your Ajax application, a lot of planning must go into its creation, testing, and deployment, which helps ensure its optimal performance and predictability. Resources Learn Read "Speed up Ajax applications while dodging Web service vulnerabilities" (Judith Myerson, developerWorks, August 2007). Judith Myerson's collection of developerWorks content provides information on how to work with Web services in enterprise-wide SOAs. Judith Myerson's series, Use SLAs in a Web services context , has details on service-level agreements. Get details on how you can use IBM® Rational® ClearQuest and IBM Rational Functional Tester Plus to reduce testing time to check for cross-browser compatibility. Want more information on Ajax tools? Read about them in "Survey of Ajax tools and techniques" (Shachor, Rubin, London, and Kallner, developerWorks, July 2007). Check out the Ajax Resource Center, your one-stop shop for information on the Ajax programming model, including articles and tutorials, discussion forums, blogs, wikis, events, and news. If it's happening, it's covered here. Read Judith M. Myerson's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems. Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition . Bring your organization into the future with RFID in the Supply Chain , which explains business processes, operational and implementation problems, risks, vulnerabilities, and security and privacy. Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators. Get products and technologies IBM trial products for download: Build your next development project with IBM trial software, available for download directly from developerWorks. Discuss Participate in the discussion forum. developerWorks blogs: Get involved in the developerWorks community. About the author   Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, RFID technologies, and project management.