Tim Kadlec

Learning From Monkeys

While ~~browsing YouTube~~ diligently working, I stumbled upon a video showing how to open a banana like a monkey. I like bananas, and who doesn't like monkeys, so I gave it a watch. Turns out, I've been opening bananas the wrong way my entire life.

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.

One Step Forward, Two Steps Back

Microsoft made great leaps forward with IE8, and just when I start thinking they deserve a nice pat on the back for embracing standards, they give me another reason to lose faith in them.

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

Developing Smarter with Progressive Enhancement

Progressive enhancement is not only a smart idea, but it's the right idea for anyone looking to produce cost-effective websites. It is alright if your site doesn't look exactly the same in every browser. In fact, because of factors like font rendering, it's impossible to maintain the exact same appearance across all browsers. Getting clients to accept that fact is important because it can save them both time and money (not to mention save you a few headaches).

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?

A Big Day for Microformats

Today was a big day for Microformats - very big. First, they announced that the new value-class-pattern is ready for implementation. The value-class-pattern is a great step forward, as it provides needed accessiblity improvements, and in my opinion, gives the developer a bit more flexibility over how to structure their markup.

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:

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.

Building a Stronger DOM

In Nate Koechley's excellent talk on Frontend Engineering, he talks about the importance of building a "stronger DOM". By marking up your site with meaningful elements and attributes, you give your markup more value and provide a richer experience for both users and machines.

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.

<fieldset> and <legend>

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:

<form action="" method="post">
<fieldset>
<legend>Team Captain</legend>
<label for="captain">Name</label>
<input type="text" id="captain" name="captain" />
</fieldset>
<fieldset>
<legend>Player #2</legend>
<label for="player2">Name</label>
<input type="text" id="player2" name="player2" />
</fieldset>
</form>

<q>

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.

<p>"<q>Remember that drover, the one I shot in the mouth so's the teeth come out the back of his head?</q>", asked Munny.</p>

<cite>

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:

<p>"<q>Remember that drover, the one I shot in the mouth so's the teeth come out the back of his head?</q>", asked <cite>Munny</cite>.</p>

<dfn>

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.

<p>The <dfn>dfn element</dfn> is used to markup the defining instance of a word or phrase.</p>

<ins> and <del>

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.

<p>SXSW's parties are a great time to <del>booze it up with</del> <ins>mingle with</ins> fellow developers.</p>

<address>

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:

<address><a href="mailto:tim@timkadlec.com">tim@timkadlec.com</a></address>

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.

Ideas and Alibis

Ideas and alibis are very much alike. Everyone has plenty of both. Some are good, and some are bad. The big difference is that while no one has a problem using alibis, very few are willing to consistently act on their ideas (me included).

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.

Book Review: Object-Oriented Javascript

Who Wrote It?

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?

We're Going Streaking

It's April. The weather is starting to get nicer, Easter is around the corner...and hundreds of people are going streaking! No, you don't have to be nervous about heading outside today. This kind of streaking is completely un-offensive (hopefully). Once again it's time for the annual CSS Naked Day.

CSS Naked Day is a way of promoting web standards by stripping off all the CSS on a site to show that by structuring your HTML in a way that is semantic and makes sense, your content is still useful even without all the pretty design. If you want more information, you can check out the official CSS Naked Day site, and the almost 400 participants.

Don't worry, this site will return to its regular design and layout on the 10th.

SXSW 2009: In 350 Words or Less

I started working on a recap post of this year's SXSW, and every time I did, it turned into a short novel. There's a lot of exciting stuff that goes on there. Since few people, other than say...my mother, want to read about my trip in that much detail, I thought I should trim it down. So here is my recap, in 350 words or less:

SXSW 2009

If you're going to talk about SXSW, the discussion will inevitably revolve around three topics: presentations, parties and people.

Presentations

This year, whether due to incredible content or the broadening of my interests, there were multiple presentations I wanted to see each session. Thankfully I feel like I chose wisely, as I can honestly say I enjoyed every presentation. Not equally necessarily, but each presentation had value that I could glean from it, and each held my attention.

Parties Events

As always, the parties were a fantastic opportunity to let loose and mingle with fellow web developers and designers. I always hesitate to call them parties though. For one, to be able to attend the last two years, I've needed funding from my employers, and it's harder to sell a conference where the word "parties" is frequently used.

More seriously, I hesitate because they aren't parties in the typical sense. These are parties geek style. Like most parties there is beer (Shiner Bock if you're doing it right) involved, but conversations are about things like Javascript performance and new CSS techniques. In general attendees are intelligent, and the conversations reflect that.

People

That's the beauty of SXSW - the conversations. You meet fantastic people from all over who are interested in the same kinds of things that you are. I'd heard people say that each year they come back it feels more like coming home. While I'm not ready to go that far, I will say that it was great to catch up with people I had met last year, and to meet new people to catch up with next year.

I'm hoping to make the AJAX Experience this year, but as of right now, SXSW is the only major conference I've attended, so I don't really have anything to compare it to. However, it's safe to say that the rewards of going greatly outweigh the costs of doing so, and SXSW should be one of the conferences on your yearly radar. If you can get to Austin next March, I highly recommend it, and hopefully, I'll see you there.

A Better Way to Get Educated

As you may remember, secondary education for web development and design is something that interests me greatly. I've mentioned before that the curriculum taught in most colleges tends to be dated and in need of definite help. Opera published their Web Standards Curriculum, and that was a great step in the right direction, but The Web Standards Project (WaSP) has taken it to an all new level with their recently launched InterAct Curriculum.

WaSP's InterAct Curriculum was specifically developed to help take some of the pressure off current educators in creating and maintaining a curriculum based on current industry standards. Thanks to the work of numerous educators and industry professionals, the InterAct Curriculum accomplishes that. The current, and initial, release contains 11 courses that fall into one of six general tracks:

Foundations
Front-end Development
Design
User Science
Server-side Development
Professional Practices

A Complete Package

There's a lot of work that went into the development of the curriculum. For each course there are assignments, core competencies, learning modules, recommend textbooks and additional recommended reading. The content in each course is carefully selected, the books include fantastic titles like Designing with Web Standards and PPK on Javascript, and the recommended reading contains some great writing from around the web, including articles from Opera's web curriculum.

There are two other releases scheduled, one in March of 2010 and one sometime after that. Each will contain a few more courses, as outlined in their roadmap. The best part is, this is an ongoing project and community driven. That means that the curriculum will not become stagnant, but will continue to evolve with current industry standards.

Getting Involved

Being community driven, there are plenty of ways to get involved. Educators can contribute assignments and modules that they've implemented in their own courses and believe to be helpful. There is also a place to discuss the curriculum and input suggestions or criticisms to help fine tune the subjects addressed.

Get the Word Out

I doubt if many educators (if any for that matter) will argue against the value of having the curriculum available to them. Considering all the work that went into its development, and the fact that industry experts were envolved, ensuring that the curriculum lines up with current practices, it's just too valuable a resource to pass on. I think the biggest challenge then, is to make sure and get the word out about the curriculum.

We need to go out and start sharing the information with local college professors and advisory teams. If we can start communicating the value of adjusting existing curriculum to model the roadmap laid down by WaSP, that would go a very long ways in speeding up the adoption of these courses and helping to increase the level of competence for new professionals fresh out of school.