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.

It is time to take the WWW behind the shed and put it out of its misery.

Almost everything that makes up the WWW is a hack. HTML, HTTP, SMTP, are all antiquated technologies. These old technologies were engineered with the sole intention of delivering and sharing text documents. Early web browsers and e-mail clients shared this same basic vision in the beginning. Even today, most media requires plug-ins and other technologies in order to be shared over the web. Where is the problem? It lies in the expectation in the end-users of the Internet. Over the last several years, the major players on the Internet are not delivering documents, but services and applications, which infer an expectation of user experience.

The expectation of a controlled user experience is not a reasonable expectation of the Internet. The Internet by definition does not have any of the building blocks for a true user interface. Cookies are a terrible way to manage state, and HTTP+HTML has no traditional support for static or persistent elements. To go further, the standing trend over the last several years has been to deliver web-based applications. The complexity of these applications has been growing over the years to include two-way communication, streaming data, persistent state, and all of the other elements that traditional computer applications contain. All trying to be consistent across dozens of different browser/OS combinations with different connection rates and privacy and security restrictions.

HTML Limitations

• Inconsistent across different platforms
• Not intended to be used as a UI framework
• Poor state control
• No built-in multimedia control

HTTP Limitations

• 2 connection limit per DNS host name
• Does not support Keep-Alive

The worst part of this combination is that the services that rely upon these technologies to deliver their service have little or no control upon how the two interact, because their service is a slave to whichever web browser the client uses to access them.

Standing Hacks

• Frames
• DHTML and DOM
  
• Plug-ins and ActiveX objects
• Java Applets
• XMLHttpRequest object

Java Swing

Java's Swing framework was probably the first reasonable attempt of a resolution. Its failures and shortcomings were few. Java is too heavy of a language for a UI framework. It isn't powerful enough to be fast and efficient. Java Runtime Environment has too much access to the client's machine, and not enough security for most people. On top of this, Swing's anti-aliasing and 2D drawing is less than attractive.

XULRunner

From those wonderful guys at Mozilla, XULRunner utilizes XML and JavaScript and runs within the Gecko Runtime Environment. It is still young, but shows great promise.

Adobe AIR

Adobe's Integrated Runtime, which was previously named Apollo, shows great promise. Not only does it utilize Flash and Flex, but also JavaScript and HTML. There are quite a few Open Source Flash initiatives such as MSASC and SwfMill for compiling ActionScript and XML into SWF files. Also, ActionScript has matured nicely over the years. If Adobe open-sourced an ActionScript compiler, this may just be the winning platform for the best way to build and distribute your applications.

While HTTP and HTML will most likely remain the foundation blocks of the Internet, I have great faith that many of the services out there with web-delivered applications will be looking towards other technologies such as AIR or XULRunner in order to better control the user experience and deliver richer applications.

Update:
This blog post criticizes web browsers failure to utilize multi-threading in multi-core systems. It is a valuable point and felt it worth adding here. http://pinderkent.blogsavy.com/archives/147

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.