Why CSS's CLIP is your friend

When you get to the point on a project where page load-time becomes a concern, there is a usual play book that most of us pull out.

1. Glob your CSS and JavaScript into as few files as possible.


2. Pack or minify your JavaScript.


3. Trim whitespace in your CSS.


4. Start pre-loading images for roll-over effects.

Maybe you go so far as to lazy-load content via JavaScript. However, I will still do you one better...

Glob your static images onto one image map. Place all of your icons, or all of your tabs and their rollover counterparts into one larger image. Then, in the css of each image element, add a Clip definition to the CSS or style attribute.

What are the benefits?

In this case, the whole is less than the parts. This means smaller file size, but more importantly, it means far less packets. Each file is at least three packets on the wire. So, with lots of small files, such as a dozen or so icons, you can reduce the number of packets on the line by as much as two-thirds.

The second nicety of using clip is that mouse-overs are really smooth when you just shift the clip's rect rather than swapping out images.

There is another cool side-effect. If your site is slow loading for any reason, (i.e. client's machine is bogged) images will load in neat batches, rather than trickling in. This tends to actually make your site seem like it is less broken. Many users are more often annoyed by that one image that has not loaded, than when the whole lot is still loading. It is just distracting. Pay attention next time, I bet you will agree.

What are the pitfalls?

There are only two. First, clip: rect(); can be a pain to specify. You almost never get the math right the first time. (x,y,w,h) would have been a far better specification. Second, you need to pay close attention to what images you group together. Do not group together an image that should be jpeg with an image that should be a gif, and when grouping gifs, pay very close attention to the color pallet and make sure you are grouping like-images and not sacrificing too much picture quality.

That said, this trick is one that really should make into a lot of developers performance play books.

Opening up to OpenSocial, OpenID, hCard and oAuth

So, there is a flood of propaganda coming out of the web 2.0 conferences either about OpenSocial, OpenID, oAuth or hCard. And many people seem to be smoking the peace pipe and passing it along. Sorry, but I don't smoke, and I don't read the tabloids. Usually, I like to wait until a technology is bound and in print, before I am ready to commit. Sorry, but it is an old guy's habit after seeing too many idealogical fads hit the Internet.

However, a co-worker said something today that actually made sense to me. And it was not about only having one login to remember, or how cool it was to link all your accounts together, or any other feature set that has been tried before. It was the way he related the registration process to a check out process, and indirectly related the registration information to credit card information.

...Okay, so you probably do not get why this excited me enough to write a blog about it, but read on...

For the last few weeks I have been doing a lot of reading on usability, design, and marketing. And the only thing that I think every time someone mentions these technologies is "So great. You want me to both convince users to register with my site, and do so using a process they are unfamiliar with?" What if my user does not have a GMail or Blogger account? How are you not setting me up to just confuse a lot of people? I mean, how do you expect to sell this to non-geeks? The n00bs? My mom? (Yes, my mom is my favorite test-case for usability. If she gets it, everyone does.)

So, the concept of these services as personal information brokers in the same way that Visa and Mastercard are brokers of my credit card information is powerful. If registration is a checkout, your login is your credit card information, and sign-in is like Amazon's 1-click purchase. This ability to relate these systems to a very well established user interaction might just give this whole thing some credit. I can now see a small sliver of light that suggests this stuff might make it to hard copy, might be around in three years, and might be worth my time considering.

To the many behind OpenSocial, OpenID, hCard, oAuth, and whatever else is out there, my suggestion is this: Stop selling this stuff to me, the web 2.0 geek, and start figuring out how you are going to sell it to my mom. You do that, and you will have a recipe for success. So, please go fire up your branding iron and get to work, because you have long chasm to cross if you really want this to catch on.

Zero-width whitespace and what it can do for you...

One of the most common layout problems I see in the web 2.0 space is accounting for the odd shaped content some people post. Long URLs are among the most common nuisance. Take for example:

http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=G12&q=zwsp+zero-width+space&btnG=Search

A long URL like this often overflows its container and is a layout nightmare. Most people's response is to simply set an overflow value, and either hide the remainder, or have a horizontal scrollbar. Neither of these solutions are ideal. Either way you are obscuring content, and I think everyone agrees that, in a web layout, horizontal scrollbars are the devil.

The solution to this problem is Unicode character U+200C. (a.k.a. ​ or &zwsp;) This character achieves the exact opposite of the common non-breaking space ( ). Zero-width space does not render a visible space to the screen, but acts like a space for breaking up text when wrapping. Here is a javascript example of how to use it:

function linkify(text) {
  var pre = text.substr(0,text.indexOf("http://"));
  var rest = text.substr(text.indexOf("http://"));
  var url = rest.split(/\s/,2)[0];
  rest = rest.split(/\s/,2)[1];
  var link = '<a href="'+url+'">';
  link += url.replace(/(\/|\+|=|\-)/g,"$1&#8203;");
  return pre+link+'</a>'+((rest)?rest:'');
}

For the URL above, this would render the following html:

http:/​/​www.google.com/​search?hl=​en&client=​firefox-​a&rls=​org.mozilla%3Aen-​US%3Aofficial&hs=​G12&q=​zwsp+​zero-​width+​space&btnG=​Search

Now this link nicely wraps to fit inside its container, and one of your worst layout nightmares is easily solved. I don't think it takes much creativity to figure out the other potential applications for this character.

I cannot tell you what a pain it was to make sure every &, <, and > symbol in this post was properly escaped, so I hope you found this helpful.

Good UI's are engineered.

I have crossed the designer-engineer border many times, and I have come to the conclusion that many people have the wrong mindset about "UI Design". Many relate the "design" closer to designer jeans, than they do to say designing a bridge. While it is the decoration that makes the finished product appealing, it is the structure that is most important.

This is how most UI Design processes go:

1. List out desired features
2. Sketch a few ideas
3. Mock until everyone agrees on something

The bitter truth is:

1. Features change
2. Usually your first instincts are wrong
3. Design by committee will give you a camel

UI Design is really no different than Network Design, Architectural Design, or any other form of structural design. You need to approach it with a set of given base parameters and develop a metric to measure all proposals against. A more proper procedure would be as follows:

1. Define the primary needs that the product provides
2. Script out the most common use cases
3. Draw flow charts to illustrate user paths
4. Define set of controls and display elements
5. Group related/parallel actions accordingly
6. Sketch out various options of all necessary screens
7. Measure if controls are present when wanted
   
8. Measure distance to action and number of clicks to complete action

Once screens, grouping and positioning is defined, it is now the time for decorations that will make actions intuitive and draw the right attention to the right items for each screen and to invoke the appropriate emotional responses from users. But, doing this earlier in the process often blinds you to other layout possibilities.

Now when you look at this second process, it may seem longer and more daunting. However, the truth is that when you skip over the initial scripting and mapping process, you loose the metrics by which you may measure the successfulness of all future design proposals. When you follow the complete design process, you actually can spend less time in mocking process, and have a more measurable certainty of success in the end.