Expressing IT

With my limited skill-set with tools like Photoshop and Illustrator, I can honestly confess that I’m a better developer than I am a designer. But my background with core (server side) development with Java/PHP/COBOL , has been a very positive influence on my UI development skills. What I mean is, while creating my designs,i.e. whenever I do design, I think about how the design can be best converted into HTML-CSS and while doing the HTML-CSS, I give a thought about the backend technology and make reasonably sure that the HTML can be easily implemented into XSL loops or PHP snippets etc.

Over years, I have been thrown head on to designs by UI designers who probably donot have a clue what HTML or CSS is. All these years I have been thinking that I would asking for too much, If I just expect the designer, who is trying to shov his “impossible to code” design down my throat, to understand just a little bit what his design would be converted into. THAT would help right?

Then, I came across this post today … Web designers who can’t code …Thanks Lord! I’m just one of many who feel the same … The above artitle is a bit a long winded .. but worth the read, every word of it.

Thanks Elliot Jay Stocks … I feel relieved!

Here is some excerpts from Elliots article.

Wow, what a day! It started with one little tweet and ended with a discussion that seemed to sweep across the whole web design community. It appears there are some very strong opinions held on the subject of whether web designers should be able to code.
…
So, before we get into this, allow me to quickly recap what I said on this morning on Twitter:

Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No excuse.

… I should’ve been a little more specific in my tweet. I was talking about designers who don’t have even the most basic HTML and CSS skills to turn a flat design into an actual site. Not people who intentionally choose not to code; those who can’t. And I’m also referring only to front-end code here; of course it’s ridiculous to think that designers should also be amazing back-end programmers …

We get ‘web’ designs sent in Illustrator, 300dpi, impossible to code, no consistency / usability.
~ Amy Mahon

It’s getting late, and I’ve got to wrap this up somehow. I know there will be many who disagree with me, and my intention is not to offend or upset anyone who can’t code, but I hope that some of what I’ve said reflects some of the points that always come up when delving into this debate.

At the end of the day, I don’t lose any sleep over who can code and who can’t. I’m just genuinely surprised to find so many designers that lack front-end skills, as I thought this was a thing of the past.

Also read the comments , there were around 320 comments, as i write … they are worth a read.
Please read Elliots full post here .. Web designers who can’t code

Yesterday,  after the issue I encountered with the CSS Resets in Google Chrome… I thought of digging a bit deeper into the area of  User Agent Style Sheets …
Found this table on default values of CSS2.1 User Agent Style Sheets … ( for those unaware of what “User Agent Style Sheets” is follow What is User Agent Style Sheets (Specification) .

For a full list of CSS 2.1 User Agent Style Sheets defaults click here

Yesterday,  like every other “Ground Hog  Day” ,  I was working on some CSS/tableless  layouts. All was going well in IE 7, FF 3 and Chrome, untill suddenly,   I saw some un-ignorable margins seen only in Google Chrome.   Though very strange and worring, It  was some new bug/issue that I had come accross, there was  finally some spice in my mundane work . Sad (but nice) it got fixed within a few minutes of the probe…

Basically ,  It looked like  Google Chrome ignored my CSS Resets  ( margin:0px).  It actually was  caused by the user agent stylesheet (-webkit-padding-start:40px).  So the solution was to reset this style by setting padding:0 the misbehaving elements .
A  good way to prevent this problem from happening to any element is use a global CSS Rest as follows

*{ margin:0; padding:0; }

What is User Agent Style Sheets (Specification) ?
The following  excerpt is taken  from http://meiert.com/en/blog/20070922/user-agent-style-sheets/ , follow link to read more on User Agent Style Sheets

CSS 1 introduces the idea by stating that each User Agent (UA, often a ‘web browser’ or ‘web client’) will have a default style sheet that presents documents in a reasonable – but arguably mundane – manner. CSS 2 says that conforming user agents must apply a default style sheet (or behave as if they did) and that a user agent’s default style sheet should present the elements of the document language in ways that satisfy general presentation expectations for the document language; CSS 3 is likely to be of the same mind.

Since the CSS specifications leave it up to implementations whether to use a “real” style sheet for default display or not, it’s not astonishing that you don’t find a default style sheet in every browser’s installation folder. Unlike Microsoft’s Internet Explorer as well as Opera, for example (and as far as I know), Gecko browsers like Firefox and Netscape Navigator (look for “html.css”) but also Konqueror make it rather simple to comprehend their default styling.

 
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.

Have you seen animoto.com? Well! this is not an AD , I really liked it! and it is Kiss ASS UI indeed

I came across this site a few weeks ago. Saw the first page, dint bother much. For me, it was just another site with some rich flash content, allowing users to upload images, choose some track and convert it into a nice picture slideshow. Download FLV, and put it on any site of your choice( YouTube, MetaCafe, Facebook and the likes)… PERIOD.

Yesterday when I saw the internal flow pages, which took the user through creation of this slideshow…. I went OH WOW! When I realized that there was not bit of FLASH used. It was indeed a Rich User Interface. All UI developers must aspire to create or at least be a part of the team that has done this interface…. Absolutely brilliant!!! And Inspiring!

HAVE A LOOK … http://animoto.com/… and register and play with it … only then can you appreciate the genius.

When I read  this article on A List Apart “ Faux Absolute Positioning
by Eric Sol “, I was nothing less than IMPRESSED.  I was also depressed majorly , cause,  honestly I was wondering , why cant I come up with something fabulous as this.

Usually, when we create CSS layouts, we use “POSITION” or “FLOATS”  , or a very bad combination of both. Eric Sol and his team define a next to perfect technique of a new type of CSS layout technique , which they have christened as  “Faux Absolute Positioning” after the faux columns technique that simulates the presence of a column. 

You know that problem all of us CSS developers have with disintegrating layouts (The unexpected content changes that cause entire columns to wrap ,  when we use floated layouts ) … Well! Seems History!!!!
This layout technique  is still very young, and has to trashed out by all those CSS gurus out there, before it becomes an un written standard.   I’m happy to use it NOW! … and am already into  middle of converting my earlier problematic/floating un-necessarily layouts  into FAP layout already… and am glad to say the “we are already using Faux Absolute Positioning for this blog site as well ” … GO try it , NOW!

Kudos Eric!!

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

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