When The User Comes First

Far too many projects and marketing campaigns today start by answering the question "What value does this have for our company?" The question shouldn't center around the company, the question should center around the users. What we should be asking is "What value does this have for our users?"

It's a very simple concept, but it is one that, if adhered to, would fundamentally alter the priorities of a project. If the user comes first, SEO takes a backseat to content strategy. Accessibility and performance cease being afterthoughts and become crucial components of a site. More time is given to user research to determine what users expect to find on your site, and where they expect to find it.

The irony is that by putting the users first, the success of the project would greatly be improved. Build something that users care about and want to use and they'll reward you with their loyalty.

Imagine if every company took the time to ask, and more importantly to answer, this question before launching their projects. Wouldn’t that be refreshing?

Quick Optimization Using Webgrind

I was recently working on a site whose code I was inheriting and the pages took much longer to process than I would've liked. Caching helped, but I wanted to get to the underlying issue so I fired up Webgrind to see if I could trace the problem.

Webgrind is a freely available PHP profiling frontend that sits on top of XDebug. Using it, you can see how many times different functions are called and find what functions called them. You can also quickly see the inclusive cost (time spent inside a function plus calls to other functions) and self cost of each function.

Viewing the logs for the last page load, I could see that mysql_query was called a whopping 52 times and accounted for 84.93% of the processing time (which was at an unacceptable ~3.1ms).

Using the Webgrind frontend, I was able to trace back 23 of those calls to one function. In turn, this function was called by one other function 17 times. I decided to focus there first.

Again, with the help of Webgrind, I could see that this function was called several times, in  separate files, for each page. The function produced the same results each time it was called.

The quick and simple fix, then, was to use a property to cache the results of that function call. So the first time it was called, it would process completely and run the necessary queries. The next time it was called, it would check it's cache property to see if a value existed for the parameter being passed. If the value did exist - it would return that value.

This simple optimization immediately brought the total queries down from 52 to 36. They still accounted for 74% of the processing time, but that time had dropped dramatically from 3.1ms to ~2ms.

36 queries was still more than I wanted. A similar function to the one I had just optimized was responsible (both indirectly and directly) for 25 of the remaining 36 queries, so I thought I'd take a look there next.

Looking at the source, I could see that while the function asked for a boolean parameter to indicate if it should run certain queries, it never actually checked the value of that parameter. So no matter what, it was running all the queries, all the time. Fixing that error brought the total query count down from 36 to 16 and the total time to process the page was now ~1ms.

As a surprising bonus, there were no locations in the code that I had to change now that the function had been corrected. People hadn't been expecting to get those extra values in their return object, so they never tried to use them unless they had passed a true value in for that parameter.

All in all I was able to take the query count down from 52 to 16 and the processing time from ~3.1ms to ~1ms. There's more room for optimization, but this is certainly not a bad start for about 45 minutes of work.

SXSW Panel Pimping

The SXSW panel picking madness started last Wednesday. After attending the conference twice, I finally got around to submitting a talk this time around. If you're interested in web performance, neuroscience, and in particular how those two areas intersect, feel free to give it the old thumbs up. Either way I'll be attending (already registered and got the flight and hotel booked) but I'd love to get the opportunity to hear myself talk share some information while I'm there as well.

Enough self promotion. After having taken a look through the options, here's a few more talks that I'm really hoping make the cut. Again, if they sound interesting to you, please give them a thumbs up in the PanelPicker.

• PHP Performance on a Budget


• Making the New Yahoo! Homepage Fast!


• "Performance Enhancing Drugs"... for the web!


• Nothing is True, Everything is Permitted. Not!


• Understanding Humans: New Psychology and the Social Web


• Seductive Design: Creating Sites Your Users Love


• All Our Yesterdays: Digital Cultural Preservation


• Developers: Saving the Web From Your Dick Move (Hoping they correctly answer their fifth question with "You don't have to")


• Long After the Thrill: Sustaining Passionate Users


• Project Management for Humans (No Robots Allowed)


• Challenging the Challenge of Accessibility on Yahoo! Homepage


• How Progress Bars Change the Way We Live

If any of you have a panel submitted, or came across one particularly interesting, feel free to let me know. I know many people frown upon the annual "panel pimping" but I actually enjoy it. There are quite a few panels I probably wouldn't have heard about otherwise.

Performance Toolbelt: CSSEmbed

One of the biggest keys to improving the load time of your site is minimizing the number of HTTP requests. There's a lot of overhead involved with each request, and many requests can very quickly slow down your site. One great way to eliminate extra requests is to use data URIs instead of images. If you want the nitty-gritty on what data URIs are, and how to use them, there are a few excellent posts by Stoyan Stefanov and Nicholas Zakas that walk you through the details.

Data URIs can be tricky to implement efficiently however. Since they are a Base64-encoded representation of an image, there is a built-in level of obfuscation that can make manual maintenance tedious. Thankfully, Nicholas put together a command line tool called CSSEmbed which takes the pain out of using them.

CSSEmbed is a very straightforward tool that parses a stylesheet and converts all references of images to their data URI equivalents. Installation is as simple as downloading the .jar file and placing it where you'd like. Then you use a simple command specifying any options, the file to output to, and the file to parse, like so:

java -jar cssembed.jar -o styles_uri.css styles.css

Since versions of Internet Explorer prior to IE8 don't support data URIs, you have to use MHTML as a workaround (again, Stoyan has an excellent post with more info). The command for that is very similar — you just need to make sure to declare a "root" (for example, I'd use http://timkadlec.com as my root for this site) which CSSEmbed will use in the MHTML.

java -jar cssembed.jar -o styles_mhtml.css styles.css --mhtml --mhtmlroot http://timkadlec.com

Right now, to my knowledge, you can't parse an entire directory of CSS files, but that's about the only thing I can think of that I'd like to see added. It's a great tool to use during an automated build to really simplify the process of using data URIs and I definitely encourage you to go download it and give it a try.

Another New Addition

A short week ago (June 30th), my wife and I were lucky enough to welcome our second healthy baby girl into the world. Just like her big sister, Jessica Claire weighed in at a healthy 8 lbs 15 oz.

Her big sister, thankfully, thinks Jessica is at least somewhat interesting so far and likes to come and "talk" to her. Both girls, as well as their mother, are doing well (if not a bit tired).

I'm sure there's going to be plenty of barbies and tea parties in the future (heck, there's already some "Ring Around the Rosie") but I'm sure I won't mind. I'm just a happy dad whose two little girls have him firmly wrapped around their fingers.

Who's Stupid?

Andy Rutledge wrote a post that is frighteningly on target. He argues that the "quality of your client experiences is directly proportional to the quality of your professionalism". He goes on to state that if your clients are "stupid" you may want to take a step back and consider who may truly be responsible for these failed interactions. He starts by pointing out how you can set yourself up for failure before you even start on a project:

If you don’t research and vet your potential client before asking them to sign your contract, stop being stupid. If you bid on projects even though the potential client doesn’t know much about you or why you’d be a good (or bad) choice for them (they “just need a web designer”), stop being stupid.

He continues by analyzing how web designers can continue to lay the groundwork for "stupid" clients by failing to have a proper workflow in place:

If you aren’t the one defining the project process, stop being stupid. If you don’t define, police, and unfailingly adhere to specific milestone requirements and deadlines for both yourself and your clients, stop being stupid. If you’re producing design artefacts before completing a comprehensive discovery process, stop being stupid.

Too often, we rush blindly forward into new projects and new relationships with clients. This process is not at all conducive to high quality work. Quality work requires an investment of time and a devotion of resources. To craft a site of true quality, you need to take a step back and slow the process down — making sure you understand the problem you are trying to solve and ensuring that the solution you are proposing is the right solution for that particular problem.

While the stupid tag may feel a bit confrontational it does not detract from the argument that Rutledge is making: not all failed relationships are the fault of the client. By failing to invest the proper amount of time and attention into planning, research, and careful consideration of requirements, firms and freelancers often set themselves up for failed client relationships.

Version 3.0

For the second time this year, I'm launching a redesign of this site. Shortly after putting the last redesign live, I started wishing I'd have allowed for a little more flexibility in the types of content I produced. While I still enjoy writing full, detailed posts at times, there are a lot of times I just want to share a quick thought, or pass along a quote from an article I found particularly good.

I gave Tumblr a try for a little bit, and I loved the freedom it gave me to post content I found important, regardless of how much detail I felt it warranted at the moment. Really, the only thing I didn't like was the fact that I was now blogging in two different places - this site and my Tumblr blog. Since Tumblr had no easy way to import all my old posts from Wordpress, I decided to make use of the custom post type capabilities in Wordpress to build my own version of a tumblelog.

Since the frequency of posts will undoubtedly be picking up with the additions of these shorter post types, let me know if any of you would prefer to have a feed for just the "feature-length" posts. Right now, the main feed pulls everything.

The underlying structure didn't change a ton - it's still HTML5 based. As of the time of this post, there's only one image being used in the site (other than anything called by the Google Analytics script). The rest of the graphical elements are a combination of CSS gradients and data URIs to help reduce the number of HTTP requests.

So have a look around. The plan is for this version of the site to stick around awhile.

Mobile User Behavior Groups

According to an article on Information Week, Google classifies mobile users into three behavior groups:

The “repetitive now” user is someone checking for the same piece of information over and over again, like checking the same stock quotes or weather. Google uses cookies to help cater to mobile users who check and recheck the same data points.

The “bored now” are users who have time on their hands. People on trains or waiting in airports or sitting in cafes. Mobile users in this behavior group look a lot more like casual Web surfers, but mobile phones don’t offer the robust user input of a desktop, so the applications have to be tailored.

The “urgent now” is a request to find something specific fast, like the location of a bakery or directions to the airport. Since a lot of these questions are location-aware, Google tries to build location into the mobile versions of these queries.

I think it’s a pretty accurate categorization, and a good thing to keep in mind when you’re building your mobile site or app. Each “type” of user is interacting with your content with a different goal in mind, and the experience should be tailored accordingly.

To comment, or not to comment...

Derek Powazek shares his thoughts on turning off comments:

I turned off comments in the last redesign of powazek.com because I needed a place online that was just for me. With comments on, when I sat down to write, I’d preemptively hear the comments I’d inevitably get. It made writing a chore, and eventually I stopped writing altogether. Turning comments off was like taking a weight off my shoulders. It freed me to write again.

I too have been trying to decide whether to continue using comments on my main blog. On the one hand, I can sympathize with Derek. I often “hear” the comments I’ll get, or won’t get, and ultimately allow that to either adjust the content in a post, or don’t publish the post at all.

On the other hand, I truly do enjoy the good discussion that can sometimes takeplace, and I don’t want to lose that. Perhaps a reply by Twitter option (as Jon Hicks is considering) is a decent option to generate that discussion without the feeling of obligation?

On delinkification...

Nick Carr makes a very interesting and compelling argument for “delinkification”:

Links are wonderful conveniences, as we all know (from clicking on them compulsively day in and day out). But they’re also distractions. Sometimes, they’re big distractions – we click on a link, then another, then another, and pretty soon we’ve forgotten what we’d started out to do or to read. Other times, they’re tiny distractions, little textual gnats buzzing around your head. Even if you don’t click on a link, your eyes notice it, and your frontal cortex has to fire up a bunch of neurons to decide whether to click or not. You may not notice the little extra cognitive load placed on your brain, but it’s there and it matters. People who read hypertext comprehend and learn less, studies show, than those who read the same material in printed form. The more links in a piece of writing, the bigger the hit on comprehension.

I like the approach taken by Readability. They generate a list of footnotes from the links, and then remove any special formatting for links within the text. I still have my links, in their original context, but I’m no longer distracted by them since they appear to be regular text at a glance.

The Great Mobile Debate

There's been an ongoing debate in the world of mobile development as to how mobile apps should be distributed, via an open system or a closed system, and consequently, how one should approach mobile development. We could probably also call this debate "Apple versus everyone else".

The issue has been brought up many times, usually right after Apple announces some change in the way they accept applications into their store. With each change, invariably some apps, and some companies who have built a living off of those apps, get the short end of the stick and are no longer deemed acceptable for Apples' standards (whatever they may be at that particular minute).

Performance Toolbelt: Page Speed

Like it's older brother YSlow, Page Speed, released by Google in in mid-2009, is primarily a tool to audit and analyze the performance of your site. However a closer looks shows that there is in fact a lot more that Page Speed can do.

What Does It Test

Page Speed analyzes the performance of a page based on a set of 26 rules (as of version 1.7) that Google has documented. Each rule is given a priority code based on how great the potential impact would be on the page load time. Once Page Speed has determined which rules are broken, it gives the page a score between 0 and 100, which can be exported in JSON format, or sent straight to ShowSlow.com - a tool for recording YSlow and Page Speed scores over time.

Jobs Has Spoken

Most likely you've heard by now about Steve Job's open letter about why their mobile devices do not support Flash, and why they don't intend on changing that. Everyone and their mother has an opinion about it, but I still couldn't resist posting a few quick thoughts I had while reading it.

The Pot Calling the Kettle Black

I generally really like Apple products. They really know how to polish up a beautiful user experience, probably better than any other company I know of. So while I wouldn't go so far as to call myself a fanboi, I will say that I drool heavily over most of their devices. Yet despite my generally positive view towards Apple, even I have to admit I found it funny when Jobs was calling out Flash for being "100% proprietary". It's true of course, but Apple has little room to talk.

Performance and Beauty

By now I'm sure that most of you have heard about the recent announcement by Google that speed is officially a factor in their rankings. This seems to have caused a little bit of panic amongst some people in the web community.

One web guru who you may have heard of, Jeffrey Zeldman, posted an article on Sunday wherein he describes the choice he feels designers are now faced with:

So now we face a dilemma. As we continue to seduce viewers via large, multiple background images, image replacement, web fonts or sIFR, and so on, we may find our beautiful sites losing page rank.

It's a fair enough point to make  - sometimes a designer will need to make a decision between additional aesthetic effects and improved performance (but not that often). What followed in the comments was disturbing though - many people were actually viewing Google's move as a negative thing and seemed to be very worried about it's effects.  Some felt Google was simply abusing their power, others believed they'd have to sacrifice good design in order to receive a decent ranking. The situation, I think, needs a little diffusing.

Performance Toolbelt: SpriteMe

As I mentioned in a prior post, there are a lot of really good tools available to developers to aid in making performance optimization quick and easy. I've decided to highlight some of my favorite tools that I've come across and thought I'd kick things off with Steve Souders excellent SpriteMe bookmarklet.

Having a lot of images in a page can be very costly. Each image requires an HTTP request, and each HTTP request comes with plenty of overhead. I've seen pages with 20+ icons, each requiring their own request - that's a serious hinderance to performance.

What I Read in 2009

For 2009, I decided to start actively reading again (something I had done very little of since high school). I managed to get through 38 books and while I'm not exactly setting a goal, I'd like to at least maintain a similar pace this year.

If you just want the highlights, I'd say that Neverwhere, Replay and The Road are at the top of my list as far as fiction is concerned. For non-fiction, Brain Rules, Blink and Trade-Off probably top the list.

Performance Optimization Made Quick and Simple

Optimizing your site's performance doesn't have to be very difficult. Take this site for example. Typically, I take care of optimization as part of the build process. However, for the sake of demonstration, I thought this time around I'd take care of each step by itself, using freely available tools where applicable.

First off was setting expires tags and turning gzipping on. Since I've done this in too many .htaccess files to count, this was simply a copy/paste job with very little tweaking necessary.

Changing Things Up

After a very long, drawn out design/build process, I finally decided to just get it over with and push the new design live (as anyone not reading this in their RSS reader can see). There's a few bits of code and a little bit of styling I've not quite fine-tuned yet, but if I keep waiting, the design would never get put up. As it is, it's been sitting on my computer in virtually the same state it appears now for the last month or so without being touched.

In addition to a new look, the underlying code has changed. I used to blog on a home-brewed VBScript based system. This incarnation of the blog, however, is built on Wordpress. It's also built using HTML5 and makes use of some CSS3 selectors for presentation. The idea was to simplify the publishing process to encourage more writing, and as part of that, I also wanted to simplify the look a little bit. Using HTML5 and CSS3 just give me an excuse to play around with those technologies a bit.

The Power of Dissonance

People tend to associate with people most like them. We hang out with people with similar hobbies, career paths, social circles and viewpoints. There's a certain level of comfort in surrounding yourself with people like yourself.

Comfort, however, is not often equal to progress. When it comes to expanding your mind to new possibilities and advancing your knowledge and skills, a little dissonance goes a long way.