Expressing IT

Re-Cycling is Buzzword and In Web Development it means no different.  It conserves energy, in terms of effort!

Over years of writing CSS and creating HTML from designs,  I have followed a few best practices, in pursuit of saving time and energy in what we commonly term as “Re-Inventing the Wheel”.  Time and time again, I have told myself, that I must create a few templates , some standard re-usable CSS  that I would use  OUT OF THE BOX in my future work. Though not completely but  I did manage to achieve some of goals.

In furthering, Re-Use of CSS , I had a  look at the few CSS frameworks that are commonly available to us and  decided to put them to use,  as these are tried and tested  and created by much experienced developers , than myself . More importantly “AVOID RE-INVENTING”.

Though common knowledge  to veterans,  I have tried to pen some key concepts/best-practices/thoughts that has gone into creating these frameworks, to make RE-CYCLING of CSS possible. Hope this will help some CSS developers who are just about to and recently boarded the CSS bandwagon!

Keys Re-cycling of CSS :

Use Naming  Conventions

This has to be the most important factor in making the CSS/HTML re-usable. Giving consistent names to page elements enables re-use of page components and their styles with little or modifications. In line with this argument,  Even HTML5 , in a major change change over its predecessors ,  is to introduce some structural tags  viz.  <article>, <section>, <header>, <aside>, and <nav> [What will HTML5 bring?].  Even with HTML 4(or lower),  it is best to name standard sections of your page consistanly like in the simple example below…

Remember,  Most pages on your project , end up having the same core structural elements. Identify these common core page elements ….

<div id="container">
   <div id="header">...</div>
   <div id="nav">...</div>
   <div id="sidebar">...</div>
   <div id="footer">...</div>
  </div>

Reset Default Styles ( CSS Resets) : Whether you use a framework or write your own , you must provide CSS Resets  [What are CSS Resets?], as they reduce or sometimes  eliminate  visual inconsistencies that  occur between various browsers.  In simple words the CSS Reset Mechanism  sets the styles of HTML Element  to  zero or null values, thus overriding any  browser default values they may poses.  This provides a clean slate to set the   properties of  these elements void of any User-Agent Defaults [CSS2.1 User Agent Style Sheet Defaults]. All the CSS  frameworks do have of reset mechanism. If you are writing you own CSS Resets, a word of caution is that if you happen to forget to reset a key property,  It could lead to cross-browser issues, that are very difficult to debug. Remember,  Keep a copy of the reset styles and drop them into each new project you create.

 body, div, dl, dt, dd, ul, ol, li,
 h1, h2, h3, h4, h5, h6,
 pre, form, fieldset, input, select, textarea,
 p,blockquote, table, th, td
 {
   border:0px;
   margin:0;
   padding:0;
 }

Set Defaults (Baseline Styles) to Elements :

After you have set ( to zero or null)  the default Values of certain attributes  of certain HTML Elements, It is necessary to apply some styles across every instance of these elements. These default setting could vary as per the design or according the best practices you follow.

Most CSS frameworks, always introduces some new defaults,  in addition to resetting default browser styles.
These defaults being void of the User-Agent Defaults(  stripped away by the CSS Reset), these will be consistent across browsers .

Remember, Baseline styles are used to  set  styles that are going be used design-wide. eg .

html { font-size: 77%; font-family: Arial, sans-serif; }
strong, h1, h2, h3, h4, h5, h6 { font-weight: bold; }

Abstract Styles for Common HTML Components and Common Classes :

Most project consisting of several pages will have common HTML elements used across the site, for e.g.  Some sort of forms, alerts and errors ,  Custom Popups, LightBoxes etc.  Since such components are used over again across projects, It will be useful  to  provide a set of classes associated with predefined styles for these components  and  you can save yourself a lot of time.

Apart from defining reusable styles definitions for the common HTML Components , we could abstract styles classes  pertaining to typography, color or even  layout.  I myself tend you use … common classes like Clearfix, Font08, FontGrey, AlignL, DisplayB etc.

form input{ border:0px;   background:#ffffff; padding:0px 10px; _padding:0px 0px; height:26px; color:#000000; line-height:30px;  font-size:1.1em; }
form textarea{  border:0px;   background:#ffffff; color:#000000; font-size: .9em; line-height:1.5em; overflow:visible; }

.fbold{font-weight:bold; color:#cccccc;}
.fgrey{ color:#666666;}
.flightgrey{ color:#bbbbbb;}
.clearfix {clear:both;}
.divider{border-top:1px solid #647B06; border-bottom:1px solid #9CC00A; height:0px; }
.displayb{display:block;} .displayn{display:none;}
.alignr{text-align:right} .alignc{text-align:center}
.floatr{float:right; } .floatl{float:left;}

Fixes to common browser quirks

Various browsers implement CSS code and provide varying level of  support for the CSS specifications.  The result of this  …. “Browser Quirks”, that we developers are left to tackle.    Especially, IE6  haunts most CSS coders with a deadline to meet. The good news is experience has  brought  together  possible REUSABLE fixes to these issues  ( Often termed as CSS Hacks) .

Remember ,  Keep these hacks/fixes handy

  /* The following zoom:1 rule is specifically for IE6 + IE7.  */
   * html .clearfix,
   *:first-child+html .clearfix {
          zoom: 1;
     }

Keep Refining Your  CSS

• The habit of re-cycling will not come to you in day. It has to developed. So plan your Re-Cycling . Bear this in mind that you could abstract defaults styles,  typography definitions, Layouts , HTML Element Styles etc.  Try to think ahead.
• Also look back at your past projects, it will help identify styles that you tend  to use often across porjects. Abstract it.
• Remove any unused styles.  This practice will keep your CSS framework from a common symptom called “Bloating” -
• Remove repetitive styles .
• Build a set of styles that are flexible enough to port it across projects.

A Look At CSS Frameworks

Finally.  If you are inspired and intend to use one or more of the CSS frameworks, Heres is quick list of a few popular ones ….

• 960 Grid System : The 960 Grid System is an effort to streamline web development workflow by providing commonly used dimensions, based on a width of 960 pixels. There are three variants: 12, 16 and 24  columns, which can be used separately or in tandem.  Thought nothing that you cannot create one for your own easily enough,  The framework provides grid templates for print in PDF format, that one can use to sketch your page designs.Bet ,  It would make a professional impression , if you carry a few sheets  when you go to a client for UI requirements gathering. It also provides basic grid templates for popular design software like Fireworks, Flash, InDesign, Illustrator, Photoshop, Visio,  etc. providing a “starter for ten”  to begin your design work.
• Blueprint :  Blueprint provides distinctly classified CSS files for Resets, Grids, Forms, Print, Typography , Plugins for buttons, tabs and sprites etc. It also provides support for IE as a separate include.
• SenCSs : Unlike  the above two, SenCSs ( pronounced Sense) , doesnt have CSS definitions for Layout. It does include  fonts, paddings, margins, tables, lists, headers, blockquotes, forms and more.
• BlueTrip : Its original claim to fame was that , it was  a combination of the best features provided by other others frameworks like Blueprint, Tripoli … from where it gets its name.  Its feature set includes 24-column grid, typography styles , orm styles, print, buttons etc.
• YUI Grids : Brought to you by the Yahooo Developer Network ,  supports fluid-width (100%) layouts as well as preset fixed-width layouts at 750px, 950px, and 974px, and the ability to easily customize to any number. As you can see , Its technically just the layout Components. YUI also provided  HTML/CSS  sets for other page elements
• YAML (Yet Another Multicolumn Layout)
• Emastic

Remember , using CSS frameworks  doesn’t imply that you are  lazy  to create one of your own … It implies that you are smart to learn from others experience & mistakes , SAVE TIME and INCREASE PRODUCTIVITY!!!!

 
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.

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

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.

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 200x200px 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.

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

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.

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