Archive for the ‘ User Interface Desgin ’ Category

Best Practices: Working with JavaScript’s

Thursday, May 15th, 2008 By Nikhil

Include JavaScript’s at the Bottom of the HTML Document

If you do not have document.write ( or any dynamic generation of page contents using javascripts) to insert part of the page’s content in your scripts, move the script include statement to the bottom of the page, before the end of the BODY tag.
The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won’t start any other downloads, even on different hostnames.
There are also ways to dynamically create SCRIPT nodes and load remote scripts after the page is loaded using AJAX .

Externalise you JavaScript’s

Using external JavaScript files will result in faster loading of pages because the JavaScript files are cached by the browser. Inline JavaScript’s’ in HTML documents get downloaded every time the HTML document is requested. This might actually reduce the number of HTTP requests made but it subsequently increases the size of the HTML document. External JavaScript’s are cached by the browser; the size of the HTML document is reduced without increasing the number of HTTP requests.
Please note that, if users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files.

Pack Your Javascript Files

In case of JavaScripts , unlike CSS, the files could crunched using some standard algorithms that would give a reduced file size than simply removing spaces or tabs. An example of javascript packer can be found here http://dean.edwards.name/packer/

Get rid of any Duplicate Scripts

It is very unusual that entire scripts might be duplicated, but a review of the ten top U.S. web sites shows that two of them contain a duplicated script. Duplicate scripts but obviously reduces the performance by creating unnecessary HTTP requests and wasted JavaScript execution.
Also, in many instances, though the scripts names are different, there is a likelihood of duplicate scripts within the same page due to team size and number of scripts.

Minimize accessing DOM elements where possible

Accessing DOM elements with JavaScript is slow so in order to have a more responsive page, you should:
• Cache references to accessed elements
• Update nodes “offline” and then add them to the tree
• Avoid fixing layout with JavaScript

Separate Behavior from Content and Presentation

Just as we separate Presentation (CSS/XSLT) from Content (XHTML/XML), we should also separate Behavior (Javascript). This is called unobtrusive Javascript. Just as we link to external CSS files, we should link to external javascript files.

Instead of hard coding behavior into the content (e.g. onmouseover, onclick, etc.), behavior should be dynamically added to elements, classes, and unique elements (IDs) using the DOM. The foundational document, the content, should contain only valid XHTML/XML and no javascript.
Javascript should augment content by adding behavior. The content should remain useful and usable without javascript (or without full javascript support).


get ExpressingIT News by Email Subscribe to ExpressingIT by Email or  Follow Me on Twitter


Best Practices : Be aware of the page weight

Wednesday, May 7th, 2008 By Nikhil

I have saved this article ages back, so Sorry! I dont remember the source … but it seemed useful , for us who have to be aware about the audience for whom we develop the site for … so here i is

Page weight can be used to determine the download time for a given page on a variety of Internet connection speeds. By way of example, the following table shows the download times for three different pages at a number of popular connection speeds.

Page Weight Download Times

Connection Speed

20 Kb Page

40 Kb Page

100 Kb Page

14.4 Kbps

12 sec

25 sec

62 sec

28.8 Kbps

6 sec

12 sec

31 sec

33.3 Kbps

5 sec

10 sec

26 sec

56 Kbps (V.90)

2 sec

5 sec

13 sec

64 Kbps (ISDN)

2 sec

4 sec

12 sec

128 Kbps (DSL/Cable)

1 sec

2 sec

6 sec

256 Kbps (DSL/Cable)

<1 sec

1 sec

3 sec

Benefits of reducing page weight?

The positive impact of reducing page weight benefits both website owners and consumers. Potential benefits include:

  1. Pages load faster. The most obvious impact of reducing page weight is that your website’s pages will load faster for visitors, regardless of their connection speed.
  2. Lower page load times create more comfortable visitors. Visitors are less likely to become frustrated and go elsewhere if your pages load quickly. On the other hand, slow-loading pages are one of the surest ways to lose visitors and potential customers.
  3. Faster load-times will contribute to increased conversion. More visitors will stay on your site longer. More of them will end up making purchases, signing up for your newsletter, or book-marking your site.
  4. Your brand perception will be enhanced. Returning customers and first-time visitors alike will be more inclined to describe your site (and business) as “professional” if your pages load quickly.
  5. Pages with clean, solid code will often be indexed more effectively by natural search engines.
  6. Pages optimized for weight can actually save bandwidth charges on high-traffic sites. 100,000 pages each weighing 150 Kb will require twice as much bandwidth from your ISP than 100,000 pages each weight 75 Kb. For ISPs that charge for bandwidth used or for overages, this reduction can create significant savings on bandwidth charges.

Consider the following data, published in a report

Visitor Abandonment

Page Load Time

Percent of Users
Continuing to Wait

10 seconds

84%

15 seconds

51%

20 seconds

26%

30 seconds

5%


get ExpressingIT News by Email Subscribe to ExpressingIT by Email or  Follow Me on Twitter


Best Practices: Working with CSS

Thursday, April 24th, 2008 By Nikhil

Put Stylesheets at the Top

If you want a page to load progressively; that is, we want the browser to display whatever content it has as soon as possible, put the CSS at the top of the page inside the document HEAD. This makes pages appear to be loading faster, as this facilitates progressive rendering of the page. This is especially important for pages with a lot of content and for users on slower Internet connections.

It is a documented fact that to enhance overall user experience, it is important to provide progress indicators and visual feedbacks. To avoid having to redraw elements of the page, in case if their styles change, some browsers, including IE, blocks rendering of the page until the CSS is fully loaded. Because of this, the user is gets to see a blank white page.

The W3 HTML Specifications’ also states that the CSS must me include in the HEAD section of the HTML page. Also note that, In IE @import behaves the same as using <link> at the bottom of the page, so it’s best not to use it.

Avoid Using Browser Specific features

Filters : Use of filter increases memory consumption and is applied per element, not per image, so the problem is multiplied. Also, Filters are IE Proprietary, hence will not work as intended in other browsers. If you want transparent or gradient backgrounds, use 1Pixel with images.
Expressions : CSS expressions are a nice feature to have in CSS, but still is IE specific feature. Also, it is important to note that, these expressions are evaluated when the page is rendered and resized, scrolled and even when the user moves the mouse over the page. Needless to say this could affect the performance of your page. Hence in simple words ,Avoid using CSS expressions, unless you feel its pros’ weighs more than its cons’

Externalise you CSS

Using external CSS will result in faster loading of pages because the JavaScript and CSS files are cached by the browser. Inline CSS in HTML documents get downloaded every time the HTML document is requested. This might actually reduce the number of HTTP requests made but it subsequently increases the size of the HTML document. External CSS are cached by the browser; the size of the HTML document is reduced without increasing the number of HTTP requests.

Please note that, if users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files.

Pack Your CSS File

Packing or crunching your CSS is the practice of removing unnecessary characters from code to reduce its size thereby improving load times.

The CSS can me crunched by removing all the comments and any unwanted characters like white spaces, newlines etc.


get ExpressingIT News by Email Subscribe to ExpressingIT by Email or  Follow Me on Twitter


Best Practices for a UI Developer

Friday, March 14th, 2008 By Nikhil

For ages, I have thinking to consolidate all the BEST Practices , I have been reading every now and then. Finally! I did get down to put it to pen. I realized that It is going to be mammoth task creating this mammoth document , so I decided to dedicate an entire category to it, so I could keep adding stuff about best practices as and when i encounter them…

Well! the content here will be a amalgamation of my personal UI development Best Practices with those written by the standard developers like Yahoo , Google etc.

Watch this space and keep browing the Best Practices Category


get ExpressingIT News by Email Subscribe to ExpressingIT by Email or  Follow Me on Twitter


What are DOCTYPES? What are BROWSER QUIRKS & STRICT Mode?

Saturday, September 15th, 2007 By Nikhil

Simple speaking (for those who never heard about doctype before today)! DOCTYPE is the declaration in a HTML document that comes before the <HTML> tag, that looks something like this ( pasted from the source of this very page)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


Why use doctype?
It all began when browser standards were introduced by W3C. The earlier web developers implemented CSS according to the wishes of browsers, to have the pages rendered correctly in them and most websites had CSS that didn’t quite match these specifications/standards.

Therefore solution to this problem was to

  • allow web developers who knew their standards to choose which mode to use.
  • continue displaying old pages according to the old (quirks) rules.

And DOCTYPE was born.

So, based on whether you page is designed to standards or not , you choose the appropriate doctype.


Relation between Doctype & Browser modes
Doctype is the statement that tells your browser what mode it should render the HTML page in or rather to be more precise how should the browser interpret the CSS in; Quirks Mode or Strict mode.

Old pages written before these standards were introduced don’t have a doctype. Therefore when there is no DOCTYPE in your HTML then the browser is in QUIRKS mode.
But if the DOCTYPE is defined as one of the following , then the browser is said to be in STRICT Mode.

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>


get ExpressingIT News by Email Subscribe to ExpressingIT by Email or  Follow Me on Twitter


 Subscribe to ExpressingIT RSS
get ExpressingIT News by Email Subscribe to ExpressingIT by Email
 Follow Me on Twitter