Optimized and predictable Ajax applicationsConsider inherent browser, system, and user differences  |
|
Level: Intermediate Judith Myerson (jmyerson@bellatlantic.net), 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. 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.
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.
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.
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.
Let's look at two font issues: availability and compatibility. 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.) 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.
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. 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. 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.
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. 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. 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). 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.
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!
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. Learn
Get products and technologies
Discuss
|
||||||||||||||||||||||||||||||||||||
