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.

Then, I decided to optimize the images (what few there are). I ran Smush.It from the YSlow tool in Firefox. That compressed the images which I then downloaded to my computer and then promptly pushed right back up to the server. It took me 5, maybe 10 minutes and it cut the image size by about 33% total.

The icons for the RSS, Twitter and LinkedIn links in the footer were separate images – each requiring its own HTTP request. By using the SpriteMe bookmarklet, I was able to generate a new sprite and the necessary CSS in a few minutes and trim those 3 HTTP requests down into one. I also ran OptiPng from the terminal window on my Mac on the new sprited image to shave off about 40% of the size.

I then minimized the CSS and Javascript (what little I was using) using OMG, which shaved ~30% off the file size of each.

Without any of these optimizations, my YSlow grade was a C and my page size was about 150K. After the 1/2 hour investment (if that…I’m being generous here) my YSlow grade came in at an A with a page size around 80K. Not bad for such little work.

There’s much more I can, and will, do here (caching, data-uri’s, etc.) but the moral of the story is that not optimizing your sites because it takes too long is just no longer an argument you can use. Make use of the tools available to you, and it’s downright scary how quickly you can speed up a site.

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.

Finally, with a new design, comes slightly different content. Historically, I’ve always treated the site as a place for web development related articles exclusively. The problem with this is that A) it’s not particularly personal and B) my interests have expanded greatly. So, going forward the site will no longer be limited to just web development – though there will still be plenty of that. Let’s just say if I find it interesting, and feel inclined to write about it, it’ll make it’s way onto the site. As a result, the blog will also reflect a slightly more personal tone than it historically has.

There’s still a few rough spots to iron out with the new look – so if you stumble upon anything missing or that obviously looks out of place, feel free to shoot me a line about it if you feel so inclined.

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.

One popular phrase you hear thrown around is the “wisdom of crowds” – the many are smarter than the few. However, it is important to note that the wisdom of crowds does not equal crowd psychology (the power of people acting collectively). Instead, the wisdom of crowds is only true when the crowd consists of a variety of people with different viewpoints, opinions and backgrounds.

Why is it that we need this diversity to excel and grow? It’s because as we become certain that something is true, our mind locks onto that idea. We have a tendency to filter out any information that may conflict with our firmly held opinions, and only focus on those that support them. This behavior, of course, strengthens our existing opinions and sheds no light on alternate solutions and beliefs that may be superior to the ones we have chosen to latch onto.

As Jonah Lehrer says in How We Decide, “The only way to counteract the bias for certainty is to encourage some inner dissonance. We must force ourselves to think about the information we don’t want to think about, to pay attention to the data that disturbs our entrenched beliefs.”

The way to overcome our certainties, and to challenge ourselves to new heights of accomplishments and knowledge is to consider other perspectives than our own, to surround ourselves with people who will challenge our beliefs. And then we must listen. We must not filter out their commentary, we need to consider it and view our problems with a fresh perspective. That’s how we develop our skills and that’s how we create new, innovative solutions.

Basically, for those of you who haven’t seen it, it shows how a typical person opens a banana using the stem. As we all know sometimes this method works just fine and sometimes the stem is tough and we have to struggle a bit to peel it, smashing the top of our banana in the meantime.

A monkey, meanwhile, simply pinches the other end of the banana, which causes a split in the banana peel, and then smoothly peels the banana. It works amazingly well.

What’s the point? The point is, this morning I thought I knew all there was to know about peeling bananas. I would never have expected that there was a better, more efficient technique I could be using. I was very confident that my method was the best one out there.

How many times do we take that approach with our design or development skills? We assume we know all we need to know about a topic, so instead of continually experimenting and reanalyzing our techniques, we plod along confident that our current method of work is the best. Even if there is a better way, we certainly wouldn’t find it by reading that book or that blog.

Meanwhile, there’s a better way out there. It might be only a minor improvement, or it might be something that completely alters the way we work. We won’t know it though, unless we continue to question our knowledge and show a consistent desire to improve. Sometimes, no matter how much we think we know, we can learn from even the most unlikely sources.

The recent announcement is that Outlook 2010, like Outlook 2007, will use Microsoft Word for it’s rendering engine. No…you read that right…Word’s rendering engine. A rendering engine that doesn’t support simple CSS statements like float, width or height. Here’s their stance on why they’re opting to use the Word rendering engine again:

We’ve made the decision to continue to use Word for creating e-mail messages because we believe it’s the best e-mail authoring experience around, with rich tools that our Word customers have enjoyed for over 25 years. Our customers enjoy using a familiar and powerful tool for creating e-mail, just as they do for creating documents. Word enables Outlook customers to write professional-looking and visually stunning e-mail messages.
William Kennedy
Corporate Vice President, Office Communications and Forms Team

Now I understand their desire to allow their users to create “visually stunning” emails easily. However, the side effect of their current method of enabling that is that they force anyone creating HTML emails to tailor to their poor support of current HTML and CSS standards. Unfortunately, the team behind Outlook apparently doesn’t think these standards apply to email. They claim that there is “no widely-supported consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability.” Really?

In response to their announcement, fixoutlook.org was set up and encouraged Twitter users to retweet in protest of the decision. At the time of their statement, over 20,000 people had tweeted the message. I understand that Twitter users are only a subset of the people who will be using and developing for Outlook 2010, but still….how can 20,000 people, many of whom are developers and designers who work with these technologies daily, not demonstrate some sort of consensus? Even if not, wouldn’t the logical move be to try to support as much of the HTML and CSS standards as possible?

In the meantime, this really sends an inconsistent message about Microsoft’s willingness to play nicely with others. While the IE8 team made a commitment to improving their standards support significantly, the team behind Outlook 2010 is ignoring them and is forcing everyone else to make the effort to play along with them, making it very difficult for innovation across the board.

If you’re on Twitter, head over to fixoutlook.org and be sure to add your name to the list of people who realize how bad of an idea this is. If you’re not on Twitter, how about telling the Outlook team your thoughts on their article defending their choice to use the Word rendering engine. Let’s find out how many people equal a consensus.

More Information

• The Email Standards Project original call to action
• Jeffrey Zeldman’s thoughts
• Outlook’s Response to the Protest

Let’s take an example. Let’s say that our client, Great Sprockets Inc., wants a design with a few rounded corners and semi-transparent backgrounds sprinkled in. We decide not to use progressive enhancement. Everybody should get these rounded corners and semi-transparent backgrounds.

So, we oblige. We create some 24-bit PNGs for the backgrounds. IE6 doesn’t support PNG24 transparency natively, so we add in a call to a script to fix that. We create a few images for the rounded corners, add a couple of extra element to our markup to position them, and we’re good to go.

Now our other client, Even Greater Sprockets Inc., also wants rounded corners and semi-transparent backgrounds. However, recognizing that neither is important to the actual branding of the site, they agree to practice a bit of progressive enhancement.

So, using two lines of CSS, we give rounded corners to all Firefox and Webkit-based browsers. Again, using CSS, we use RGBa to create semi-transparent backgrounds in the browsers that support them, and let others fall back to a fully opaque background color. And that’s it. No images, no extra Javascript calls, and no extra elements in our markup.

One client has ensured that every visitor to their site with a relatively modern browser, regardless of browser capabilities, gets rounded corners and semi-transparent backgrounds. As a result, they added time to the development of their site, and therefore money to their bill. In addition, they’ve increased the time it takes for their page to load by adding a few extra HTTP requests necessary to load the necessary images and scripts.

The other client has offered these embellishments only to browsers that support them natively. As a result, their development time is lower, and so is their bill and page load time. Their branding is still in tact, and their site still looks good, it’s just without a few added aesthetic touches.

Which option makes more sense to you?

That was a pretty big announcement in its own right, and I was very pleased to see the new pattern approved and garnering a bit of buzz. That announcement, however, was trumped by Google announcing that they will be starting to index Microformats and RDFa and using that data to enrich their search results.

Microformats has been around since 2003, but the adoption has been a bit sluggish. While overall quite easy to implement, it can been difficult to demonstrate the value of using Microformats at times due to a lack of major support, and therefore, major incentive. That shouldn’t be a problem anymore, because Google is definitely providing that major incentive.

How They’ll Be Used

Google has a good vision for how to make use of the harvested data in their results. They’ll be providing these “rich snippets”, as they’re calling them, to provide both additional content and meaning about the pages in their search results. For example, a page featuring reviews will feature the average star rating, and number of reviews the page contains, right there in the search results.

In addition to reviews, this initial launch will also provide “rich snippets” for people. Using contact information parsed from sites like LinkedIn, for example, search results may indicate a person’s job title and location, to help users determine if the results they are looking at are likely to be associated with the person they’re looking for.

On top of that, Google plans for to use these Microformats to allow users to be a bit more specific with their searches. An example given was that a user could search for all reviews on a printer where the average rating was over 3 stars. This allows users to tailor the content they receive by the context in which they are interested.

Not only does this new feature enhance the user experience, but the use of Microformats and RDFa data should also provide signifcant value for sites smart enough to markup their content using them. According to studies done by Yahoo on similar enhancements to search results, they found these kinds of improvements resulted in a significant improvement in click-through rates, in some cases up to a 15% increase.

More Coverage

There’s been lots of great coverage on Google’s announcement, and I highly encourage you to have a look at some of the insights offered in the posts below:

• Introducing Rich Snippets
• Google Announces Support for Microformats and RDFa
• Google Engineering Explains Microformat Support in Searches (Interview)
• Google Search Now Supports Microformats and Adds “Rich Snippets” to Search Results

In addition, if you haven’t explored Microformats, I encourage you to do so now. With Google starting to index Microformats, and in turn leverage the harvested data to enhance search results, whether or not Microformats are valuable is no longer debatable.

In addition, a strong DOM provides you with numerous attributes and elements that you can make use of to style the content to your hearts desire. This gives you much more power and control with your CSS, and helps to greatly decrease your usage of extraneous divs and classes

A very quick way to improve your markup skills, and therefore the value of your content, is to expand your knowledge of HTML elements, and start making use of a few you might not have been aware of.

and

The fieldset element is used to group related controls and labels within a form. They are a great way to help make your form easier to understand, and more accessible for speech-navigated user agents.

It should be used in conjunction with the legend element to provide an even richer and more usable experience. The legend element basically defines a caption for the fieldset. Here’s an example of how you could use these elements in your markup:

3. Team Captain
4. Name
7. Player #2
8. Name

An often forgot element that you can start using immediately in your text is the q element. The q element is very similar to the blockquote element, but should be used in a different context. The blockquote element is meant to be used for longer, block-level quotes. The q element, on the other hand should be used for short quotes.

All major browsers, other than IE6 and IE7, will automatically insert quotation marks around the content within the q element, according to the HTML spec. There’s a few ways to work around this, but my favorite solution is the one proposed by Stacy Cordoni in an A List Apart article from 2006. Her solution is to remove the quotes from around the q element using the :before and :after pseudo-classes to even the playing field. Then, with each of the major browsers not rendering quotes, you can insert them directly into your markup, ensuring that all browsers render your quote the same.

• “Remember that drover, the one I shot in the mouth so’s the teeth come out the back of his head?“, asked Munny.

The cite element is used to identify a reference or citation to another source, like a book or another website. By default, each of the major browsers render the cite element in italics. Making use of our q element example, adding the cite element would give us something like this:

• “Remember that drover, the one I shot in the mouth so’s the teeth come out the back of his head?“, asked Munny.

The dfn element is used to markup the defining instance of a word or phrase. It’s important to note that it is not intended to markup the actual definition itself, but instead the word or phrase being defined. Most major browsers will render the content within the dfn element in italics, though of course you can alter that as you wish with CSS.

• The dfn element is used to markup the defining instance of a word or phrase.

and

Here’s one for anyone who writes any sort of articles online. You can use the ins and del elements to identify content that has been either inserted or deleted since the content’s publication. The ins element, by default, is underlined, and the del element, by default, is striked through.

• SXSW’s parties are a great time to booze it up with mingle with fellow developers.

The address element is slightly misleading. One would think you would use it to mark up a physical address, but that’s not necessarily the case. The address element is actually intended to contain the contact point for the document containing it. While this certainly could contain a physical address, it doesn’t have to. It could house any sort of contact information provided that it is contact information for the author and/or owner of the document in question.

For example, I could use the address element to provide my contact information since I am the owner of this article, like so:

• tim@timkadlec.com

By default, the address element is rendered in italics in each of the major browsers.

See For Yourself

If you’re interested, I put up a page with examples of each of the elements above. I did not apply any CSS, so you can see how each element is rendered by default in different browsers.

Excuses, Excuses

There are several reasons why people tend to pass on acting on their own ideas. Some of the major ones are fear of criticism, fear of failure, self-doubt, or the feeling that there is not enough time. Based on these reasons, we can come up with a multitude of alibis for not pursuing these ideas.

One that I commonly use is that the “time is not right”. I often tell myself that I should wait on acting on my ideas until sometime where the circumstances are better aligned for it. Sometime in the future when I have more of the knowledge necessary or where I have more time available to me; that’s when I’ll move forward on my ideas.

The fact though, is that postponing ideas quickly becomes a habit. The truth is, there will always be more research that could be done, and there will always be distractions that make us feel like we don’t have the time to act. Acting on an idea will always expose yourself to criticism, and there is always the chance that the idea will not be perceived as a success. If we keep waiting until the circumstances are “just right”, we’ll be putting that idea in a perpetual holding state, until either we decide not to act on it at all, or someone else has already beaten us to it.

Make Your Ideas Count

At least by acting on those ideas, we make them count for something. They may not be met with an extraordinary amount of success, and occasionally they may even be met with flat out failure (though I believe that if you really go after your idea with vigor, true failure will occur very infrequently). For each non-successful idea you have and pursue, that is one more lesson you’ve learned and one more step you’ve taken towards making your next idea meet with greater success.

The conclusion then, is that ideas were meant to be pursued, not postponed. Quit coming up with excuses and start moving forward on those ideas and goals that you’ve been putting off. If you never try any of them, it is a certainty that none of them will work out. By pursuing them, at least you give them the chance.

Object-Oriented Javascript is written by Stoyan Stefanov, a web developer at Yahoo. Stoyan’s thoughts on all things web can be found at phpied.com. He also runs a blog on iPhone development, and a site dedicated to Javascript design patterns at JSPatterns.com (it’s been quiet for quite awhile now, but I’m hoping to see it brought out of retirement).

What’s Covered?

Exactly what you’d expect given the title….object-oriented Javascript! Actually, the book covers a lot of information, starting with the basics (variables, loops, functions, etc.) all the way through to a few basic, albeit useful, design patterns.

The book is very well written and its discussions precise. Stoyan doesn’t take a lot of time going through complex examples. Instead, he gives bite-size chunks for you to play with and expand upon. If you’re someone who prefers playing with concepts yourself over going through expanded examples in books, this book is right up your alley.

While the book has chapters on the DOM and primitive data types, it is in the discussions of topics like closures and inheritance where the book really stands out. These sometimes confusing topics are presented in a very clear and concise way, helping to break down the learning barrier that so often stands in the way of truly understanding those subjects.

Should I Read It?

The book is intended to be accessible to even developers with no prior Javascript experience, and it does a reasonable job of doing so. Thankfully, the information is covered very well, making it likely that even the introductory chapters will be worth the read for more experienced Javascript developers.

I’m sure the refinement and overall quality of the information presented is in no small part due to the plethora of quality technical reviewers. It’s clear Stoyan took the task of accurately presenting this information very seriously, as his list of technical reviewers sounds a bit like a who’s who of web development.

Final Verdict

I really enjoyed Object Oriented Javascript and highly recommend it. For beginners, its not as soft an introduction as DOM Scripting, nor is it as exhaustive in detail as PPK on Javascript. That being said, its content is perhaps the most complete of any Javascript book accessible to beginners that I’ve read thus far, and it’s certainly one of the best written books I’ve read. Even more experienced developers will find very useful information in some great coverage of more advanced object-oriented techniques and very useful appendices.

Great…Where Do I Get a Copy?

• Buy Through Amazon.com
• Get the book from Packt Publishing