Mar 12 2009

A Good UI Design must be standards compliant. or should it? My TOP 10 UI Design Rules

 
Neither I am very new to User Interface(UI) development nor  am I  a veteran and as I always put it, I fit into the profile of UI developer more than that of a designer, with no regrets. Oh Well! What was I writing about? … For a while( must be in years not any less) now , every now and then when I do get into a bit of UI Design ( when the professional designer has gone on a holiday), I  always cant stop thinking  whether my design should be properly complient or not (sincerely,  not that I could achive 100% standards compliance, If I wanted too ).  Then I tell myself,  what crap! …  The design should be simple, nice  and primarily seem usable ,  it should not make visitors run away… or bounce ( to be technical).  What good would  a nice tableless CSS layout be  to the visitor, who is oblivious to all the smart HYPERTEXT and Cascading Style Sheet  under the skin of your webpage…  Zilch!
It should look nice and be easy to use …  then comes the all standards stuff.

I stumbbled accross this blog entry by  Jason Fried of 37 Signals (For those who are not aware 37 signals  are  the onces who have created some awesome web apps like Basecamp, Campfire etc)  who wrote something similar in 2004 and believe me, almost 5 years and  not much changed since that …  I was happy to read his post , as I totally agree with what he has to say and the also the fact , her is not sure about what is telling about its just his gut feeling and so is mine :)

Jason Fried  : “There’s way too much talk about CSS and XHTML and Standards and Accessibility and not enough talk about people. CSS and Standards Compliant Code are just tools — you have to know what to build with these tools. Great, I’m glad your UI doesn’t use tables. So what? Who cares if it still doesn’t let people achieve their goals. Web standards are great, but people’s own standards include getting things done (and that’s still too hard to do online).

UI designers are making the same old fundamental “forgetting about the human being on the other side” mistakes — except this time their code looks better. Humans — not code validators — use interfaces.”

Checkout Jason Fried’s full article

DISCALIMER :  This doesnt mean that we shouldn’t bother about standards at all.  Standards are good to have and stick to them as much as possible .  We only have to understand that Good UI design doesnt always mean 100% Standards Complience or Vice-Versa ….

From my list of my lessons learnt,  I follow a few UI Design and Development Golden Rules …  Heres the TOP 10 … not that you have follow them too …  :)

1. Take care of your users. The users can make or break your site. DONOT make user look like an total idoit , utterly incapable of using your website. That is BAD!

2. Keep Simplicity and Ease of  Use your primary guidlines. Too many  things  on the screen, the higher the probability that a user will get confused or distracted from their original task.

3.  Be in the LIMITS … DONOT indulge too much into USABILITY,  ACCESSIBILITY and STANDARDs.  Use standards effectively and make them understood to the team . This will ensure right consistency in the product

4. Prototype the requirement. Since , these days the Use Interfaces are RICH , Prototyping always is better  than  just making simple wireframes and the latter is void of decent interactions, it would fail to provide the client a clear picture of the final product that is being developed. Always, It is easier to convert the prototypes into final deliverables. Also! with prototyping any interaction issues could be ironed out earlier in the development cycle.

5. Consistency in your design and interaction is very Important. Donot confuse your user with unpredictable interactions and gizmos.

6. Understand your “Design Mission Statement” .  Aways focus on the primary action of the page beign designed. Also, make a list of  your seconday actions on the page, and prioritise them.

7. Provide proper feedback to the site users.   With most of the websites designed around AJAX , provide visual cues to the user about changes to page . The user has to given an acknowledgement of the completion of  any task he performs.  Donot make the user wait and guess, for eg. provide progress indicators for file uplaods.

8. Use controls  appropriately. For e.g  Use  Select drop down list  for small lists only , donot let the user choose one of 200 cities using select boxes.  Understand the difference between a button and a link. A link and button have different purposes , donot use one for the other . Provide the right control  to make interacting with a page easier.  Avoid using Menus, that are more that two levels deep. Do not reinvent the wheel. Use standard controls, customise them only if very necessary. Define any custom controls required for your site  first hand, so that they could be created and tested independently, ready for use accross site.

9. Donot  ITERATE too much on the design. Remember! The whole  product consists more that design alone.  Build appropriate timelines  into your project schedule for design iterations and stick to it.  Iteration helps us to find out what works and what doesnt , pick out the trouble spots.  As a good interface takes time,  provide time for iterations  in the begining of the development cycle,  so that  design iterations doesnot directly equate to REWORK.  Too much rework could jeopradize deadlines.

10. Sit back and think like a user sometimes.


Jun 6 2008

Best Practices: Keep the Number of DOM Elements Small

More the DOM elements on the page, slower it renders, slower is the DOM access in JavaScript’s. A high number of DOM elements can be due bad layout design. For instance, nested tables might have been used for layout purposes. Use any HTML Tag where is makes sense semantically. For E.g. DONOT use tables for layouts, but DONOT hesitate to use them where you have to display tabular data, and hence will use reduce DOM elements, in comparison, to a similar structure created using DIVs only..

To test the number of DOM elements in your HTML page, just type the following in the Firebug’s console:document.getElementsByTagName('*').length

There is no set standard as to how many DOM elements are too many. Check other similar pages that have good markup.Eg. Yahoo! Home Page is a pretty busy page and still under 700 elements (HTML tags).


Jun 2 2008

Best Practices: Using AJAX

Use GET for AJAX Requests

It has been found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it’s best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.
An interesting side affect is that POST without actually posting any data behaves like GET. GET is meant for retrieving information, so it makes sense (semantically) to use GET when you’re only requesting data, as opposed to sending data to be stored server-side.

Avoid Synchronous AJAX Calls

When making “Ajax” requests, you may choose either async or sync mode. Async mode runs the request in the background while other browser activities can continue to process. Sync mode will wait for the request to return before continuing.
Requests made with sync mode should be avoided. These requests will cause the browser to lock up for the user until the request returns. In cases where the server is busy and the response takes a while, the user’s browser (and maybe OS) will not allow anything else to be done. In cases where a response is never properly received, the browser may continue to block until the request is timed out.
If you think that your situation requires sync mode, it is most likely time to re-think your design. Very few (if any) situations actually require Ajax requests in sync mode.


May 22 2008

Best Practices: Working with Images

Optimize Images

Optimization simply means keeping the size of the image small keeping the quality of image to the required level. There are loads of procedures that once can carry out to optimize images before they are loaded on to the server for delivery. The tools that we use for creation of these images (Photoshop, Fireworks etc) usually have tools that allow users to optimize the image for web use.
• Check the GIF’s to see if they are using a palette size corresponding to the number of colors in the image. When an image is using 4 colors and a 256 color palette, then the image could be further optimized

• Convert GIF’s to PNG’s where possible and see if there is a saving. More often than not, there is. Do not hesitate to use of PNG’s, as they are fully supported by most of the commonly used browsers. Expect of the animation capabilities a PNG can do what a GIF does, including transparency.

• For the images used in CSS sprites, arrange the images in the sprite horizontally as opposed to vertically usually results in a smaller file size. Also, combine images with similar colors in a sprite. This helps you keep the color count low, ideally under 256 colors so to fit in a PNG8.

• If you are using a favicon.ico, keep it small, preferably under 1K.

Use properly scaled/resized image.

Always try and use resized images, i.e. don’t use a bigger image than you need just because you can set the width and height in HTML. If you need to display a 100px X 100px image on the page, then do not use a scaled down 200×200px image.

Use Progressive Images

A web browser already renders Images progressively. To do even better, simply save your GIF or PNG images with the “interlaced” option, or your JPEG images with the “progressive” option.

There is ongoing debate among web users as to whether use of progressive image is a blessing or a hindrance. Also a progressive image weighs approximately 20% more than its non progressive counterpart. So , If you think you layout uses images that will not hamper the user –experience by it being progressive, feel free to do so.


May 15 2008

Best Practices: Working with JavaScript’s

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).


Apr 24 2008

Best Practices: Working with CSS

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.


Mar 14 2008

Best Practices for a UI Developer

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


 
NDK home | Expressing IT | Expressing Palate | Expressing Penmenship | Expressing Awe | Expressing Myself