Brian Cray’s Blog

An analogy to sell design iteration

Mon, 9 Apr 2012 08:54:00 -0400

The beautiful thing about a car is that it's an amazingly complex system that can be controlled with just a steering wheel and two peddles. Sure, race car drivers have many more controls at their disposal, but they're advanced users. Let's help our users learn to drive before we teach them to be race care drivers.

Javascript module pattern: When to use it and why

Thu, 23 Feb 2012 07:14:00 -0500

There have been a few criticisms of the javascript module pattern, despite its many advantages. Take for example Jonathon Snook's “Why I don't like javascript's module pattern”. While everyone has their own style, my fear is that people, given Snook's demanding presence, will take his word for gospel without understanding it.

This article isn't about teaching you the pattern, but more about when to use it and why—though I'll start with a brief example of the pattern to get us all on the same page.

A brief example in my favored flavor

var module = (function () {
    // private variables and functions
    var foo = 'bar';

    // constructor
    var module = function () {
    };

    // prototype
    module.prototype = {
        constructor: module,
        something: function () {
        }
    };

    // return module
    return module;
})();

var my_module = new module();

This appears to be a lot of unnecessary code at first glance, but each line is plays a key role in making the module pattern advantageous.

The when & why

Scalable. Modules are isolated pieces of code that when well designed, work independently of other modules and therefore can be removed and added as necessary.
Team-ready. Building a large-scale javascript application is simpler with the module pattern. Each developer on a team can be assigned a set of modules to develop and can work in parallel with minimal conflicts. Additionally, everyone can write in their own preferred style within the context of the pattern without preferences getting in the way of progress.
Localized. Anonymous wrappers automatically create a new "namespace" for the whole module. This has performance advantages in garbage collection and scope chain walking. Furthermore, variables can be passed into the anonymous wrapper to localize commonly accessed global variables, such as window, document, and jQuery, like so:
```
var module = (function (window, document, $) {
    // module stuff
})(window, document, jQuery);
```
Cross-instantiation private variables. Normally when you instantiate an object with something like new module(), a whole new clean object is created–and that's still the case. But the private variables will retain their values across instantiations.

Extensible. Want to dynamically add additional methods to a module? No problem.

// extend it with something_else();
var module = (function (module) {
    module.prototype.something_else = function () {
    };
    return module;
})(module);

With a few changes this same pattern can be used to "subclass" an existing module.

Deferrable. Another advantage of its isolation and containment is that you can inject it on demand without worrying about its impact on other modules. Using the following code, for example:

function inject_module (module_file) {
    var h = document.getElementsByTagName('head')[0];
    var s = document.createElement('script');
    s.type = 'text/javascript';
    s.src = module_file;
    h.appendChild(s);
};

Bonus: Tips for well-designed modules

Don't make modules explicitly depend on each other. Everything each module needs to work should be confined into either the module or plugins that are shared among modules.
Have modules communicate to each other through event subscriptions, not through direct calls to each other. They call this a pubsub. If you’re using jQuery, check out jQuery Tiny Pub/Sub. If not, here’s a good vanilla pubsub.
Create a light integration layer that handles module injection and interaction.

Conclusion

The javascript module pattern has many benefits through isolation and localization. They shouldn't be written off until you've given due thought into the design of your application and your team. I'm currently in the process of writing a large-scale javascript application based on this pattern, and I have to say, it’s a delight.

Finding success as a web developer

Thu, 19 May 2011 10:42:00 -0400

Let me start by setting the record straight. I'm not going to tell you how to build a huge successful startup because I haven't done it myself. But I have made a small name for myself, created a few minor successes, and hacked away a good path to follow (pun intended).

Finding success as a web developer means finding happiness and fulfillment—holistically just as much as monetarily. I'll do my best to help you find your way. And hopefully, your next successful interview. So how should you start?

Build something, then do it again

I've been interviewing a lot of developers for Topsy. It's amazing how many candidates don't have a portfolio. After all, making something that people can publicly use is often their primary job description. I can tell you right now, the developer who has a portfolio is more likely to get a call than the one who doesn't. Simple as that.

If you're lacking ideas, pay attention to your daily work routine. When you find yourself thinking "This could be better" or "I wish I had ______," you have your idea. An idea derived from this insight is likely a good one. Necessity is the mother of invention.

Do you have a good idea but you're holding back for the right moment? Don't wait for the right idea at the right time. Nobody is smart enough to solve that equation. Hell, who'd have thought that a photo taking app, Color, would raise $41 mil? WTF. Stop thinking and start executing. One of the biggest mistakes you can make is waiting too long.

And keep making stuff. Before you know it, you'll have a few tasty examples of your prowess. Proven experience? Check. Broad understanding of web development and implementation? Check.

So why the hell aren't you building something? Right this second? Shut up and build.

Become a social developer

No, I don't mean you should go to more parties. I mean you should share your work, share your inspiration, and be involved in helping others make better stuff. Being a social developer builds your reputation and sharpens your skills at the same time.

Absolutely the best medium for this is blogging. I hear a lot of people hesitant to start a blog because they don't have stuff to write about. But here's a simple place to start: if you've come up with a solution to a problem you're working on, blog it. Chances are others are having a similar problem. Even the simplest of solutions may result in a lot of exposure.

Another great social development opportunity is GitHub. Other than the huge benefit of having hosted version control, GitHub gives developers the opportunity to build solutions together. Others can follow your repositories and even fork them into new versions.

Combine your efforts by hosting the source code you blog on GitHub, providing exposure for your GitHub repositories and nurturing a deeper relationship with your readers. At the end of the day, discuss it on Twitter.

Keep learning

I have the privilege to work with people who make me feel like I know nothing. Why? Because it inspires me to keep learning. The world we call our profession is constantly in a state of change. Hell, as a front-end engineer I don't know half of what I should.

If you only have a hammer, everything looks like a nail. Learning not only makes us more resourceful and valuable, but it helps us approach problems with a much broader knowledge base for making informed, sustainable solutions. A great article about scaling from the perspective of a database architect starts with "Let me tell you a secret. I don't fix databases. I fix applications." To me this means designing the best solution to a problem requires more than applying your field of study. It requires the ability to look at a problem from a number of angles. Expand your toolbox.

And if you've managed to conquer all the languages of the programming world, pick up a few books on psychology, marketing, and social behavior. Learn, learn, learn.

Befriend failure

Failure is inevitable, and likely to happen more often than you'd like. Don't quit if you fail at first. The only chance you have of winning is by fighting. Failures are hidden morsels of life's greatest opportunities to learn. They give us the arsenal to fight the better fight. In the business world that translates to more success however you define it. But don't take it from me.

Entrepreneur.com says "You're fortunate to have failed. You now have the opportunity to learn how to turn bad luck into good luck. If you can do that, you'll have a life of more and more good luck."
Dropbox says "Failure is not the worst outcome, mediocrity is."
CafePress says "Fail fast and cheap. And learn from it."

Love what you do

The last but most important aspect of finding success as a web developer is to love what you do. Ask yourself this simple question: If you weren't being paid for web development, would you still be doing it? If the answer is yes, you're almost certainly bound for success.

Automatic translator built in javascript

Wed, 11 May 2011 08:39:00 -0400

When it comes to my blog, I'm always asking myself the same question: How can I make my content more engaging? I try to avoid so called "enhancements" like arbitrary visual embellishments or every-which-way navigation that distracts users from what they came for: a good read. I do my best to focus solely on making the content great.

I've done some playing in this area in the past, including estimated reading time and measuring simplicity. The other day, I thought I'd try something new. This is what I ended up with.

Javascript translation: How does it work?

Detect the user's Country Code using google.loader.ClientLocation (I've written about this here)
Translates the Country Code into a two digit language code
If the user has a different native language, redirect the browser to a translated version of the page

A look at the source

(function () {
    var loaded = false;

    test_cc = window.test_cc ? test_cc : false;
    test_url = window.test_url ? test_url : false;

    var inject_jsapi = function () {
        var h = document.getElementsByTagName('head')[0];
        var s = document.createElement('script');
        s.type = 'text/javascript';
        s.onreadystatechange = function () {
            if (this.readyState === 'loaded' || this.readyState === 'complete') {
                translate(test_cc || (google.loader.ClientLocation && google.loader.ClientLocation.address.country_code), 'en');
            }
        };
        s.onload = function () {
            translate(test_cc || (google.loader.ClientLocation && google.loader.ClientLocation.address.country_code), 'en');
        };
        s.src = 'http://www.google.com/jsapi';
        h.appendChild(s);
    };

    var translate = function (cc, lang) {
        if (!cc || loaded) {
            return;
        }
        loaded = true;

        cc = cc.toLowerCase();

        // http://www.mobilefish.com/tutorials/country_language_codes/countrylanguagecodes.html
        var cc2lang = {
            af: 'fa', ax: 'sv', al: 'sq', dz: 'ar', as: 'sm', ad: 'ca',
            ao: 'pt', ai: 'en', aq: 'en', ag: 'en', ar: 'es', am: 'hy',
            aw: 'nl', ac: 'en', au: 'en', at: 'de', az: 'az', bs: 'en',
            bh: 'ar', bd: 'bn', bb: 'en', by: 'be', be: 'de', bz: 'en',
            bj: 'fr', bm: 'en', bt: 'dz', bo: 'es', ba: 'bs', bw: 'en',
            br: 'pt', io: 'en', bn: 'ms', bg: 'bg', bf: 'fr', bi: 'fr',
            kh: 'km', cm: 'en', ca: 'en', cv: 'pt', ky: 'en', cf: 'fr',
            td: 'fr', cl: 'es', cn: 'zh', cx: 'en', cc: 'ms', co: 'es',
            km: 'ar', cg: 'fr', cd: 'fr', ck: 'en', cr: 'es', ci: 'fr',
            hr: 'hr', cu: 'es', cy: 'el', cz: 'cs', dk: 'da', dj: 'fr',
            dm: 'en', do: 'es', ec: 'es', eg: 'ar', sv: 'es', gq: 'es',
            er: 'ti', ee: 'et', et: 'am', eu: 'en', fk: 'en', fo: 'fo',
            fj: 'en', fi: 'fi', fr: 'fr', gf: 'fr', pf: 'fr', tf: 'fr',
            ga: 'fr', gm: 'en', ge: 'ka', de: 'de', gh: 'en', gi: 'en',
            gr: 'el', gl: 'kl', gd: 'en', gp: 'fr', gu: 'en', gt: 'es',
            gg: 'en', gn: 'fr', gw: 'pt', gy: 'en', ht: 'fr', va: 'lt',
            hn: 'es', hk: 'zh', hu: 'hu', is: 'is', in: 'hi', id: 'id',
            ir: 'fa', iq: 'ar', ie: 'en', im: 'en', il: 'he', it: 'it',
            jm: 'en', jp: 'ja', je: 'en', jo: 'ar', kz: 'kk', ke: 'en',
            ki: 'en', kp: 'ko', kr: 'ko', kw: 'ar', kg: 'ky', la: 'lo',
            lv: 'lv', lb: 'ar', ls: 'en', lr: 'en', ly: 'ar', li: 'de',
            lt: 'lt', lu: 'de', mo: 'zh', mk: 'mk', mg: 'mg', mw: 'ny',
            my: 'ms', mv: 'dv', ml: 'fr', mt: 'mt', mh: 'mh', mq: 'fr',
            mr: 'ar', mu: 'en', yt: 'fr', mx: 'es', fm: 'en', md: 'mo',
            mc: 'fr', mn: 'mn', me: 'sr', ms: 'en', ma: 'ar', mz: 'pt',
            mm: 'my', na: 'en', nr: 'na', np: 'ne', nl: 'nl', an: 'nl',
            nc: 'fr', nz: 'en', ni: 'es', ne: 'fr', ng: 'en', nu: 'en',
            nf: 'en', mp: 'en', no: 'no', om: 'ar', pk: 'ur', pw: 'en',
            ps: 'ar', pa: 'es', pg: 'en', py: 'es', pe: 'es', ph: 'tl',
            pn: 'en', pl: 'pl', pt: 'pt', pr: 'es', qa: 'ar', re: 'fr',
            ro: 'ro', ru: 'ru', rw: 'rw', bl: 'fr', sh: 'en', kn: 'en',
            lc: 'en', pm: 'fr', vc: 'en', ws: 'sm', sm: 'it', st: 'pt',
            sa: 'ar', sn: 'fr', rs: 'sr', sc: 'en', sl: 'en', sg: 'en',
            sk: 'sk', si: 'sl', sb: 'en', so: 'so', za: 'en', gs: 'en',
            es: 'es', lk: 'si', sd: 'ar', sr: 'nl', sj: 'no', sz: 'en',
            se: 'sv', ch: 'de', sy: 'ar', tw: 'zh', tj: 'tg', tz: 'sw',
            th: 'th', tl: 'pt', tg: 'fr', tk: 'en', to: 'to', tt: 'en',
            tn: 'ar', tr: 'tr', tm: 'tk', tc: 'en', tv: 'tv', ug: 'en',
            ua: 'uk', ae: 'ar', gb: 'en', us: 'en', um: 'en', uy: 'es',
            vn: 'vi', vg: 'en', vi: 'en', wf: 'fr', eh: 'ar', ye: 'ar',
            yu: 'hr', zm: 'en', zw: 'en'
        };

        if (cc && cc2lang[cc] && cc2lang[cc] != lang) {
            (function (uri) {
                document.location.href = 'http://translate.google.com/translate?langpair=' + lang + '|' + cc2lang[cc] + '&u=' + uri;
            })(test_url || document.location.href);
        }
    };

    inject_jsapi();
})();

More on GitHub

If you're a GitHub fan, feel free to follow, fork, or play with the source on GitHub.

Detect retina displays with javascript

Thu, 5 May 2011 10:08:00 -0400

I've been trying a way to detect a device's DPI for mobile design. While I haven't yet, I did at least find a way to detect whether the user is using a retina display. So without ado, here's how:

var retina = window.devicePixelRatio > 1 ? true : false;

Now the variable retina will be set to true if the user has a retina display. A simple if statement can be used anywhere to execute code based on the user's display.

if (retina) {
    // the user has a retina display
}
else {
    // the user has a non-retina display
}

Why?

A good is exam ple is if I have a 100x100 image (or video), the above code will tell me to upscale the image to 200x200 for it to look crisp on an iPhone 4 without forcing all users to unnecessarily download a 200x200 image. Especially given bandwidth is a major concern for mobile users.

if (retina) {
    var html = '';
}
else {
    var html = '';
}

Diving deep into javascript logical operators

Mon, 18 Apr 2011 08:49:00 -0400

I have lots of fun finding shortcuts in javascript, and logical operators can make for some interesting ways to act on a condition. In this article we'll look at the logical operators && (read: AND) and || (read: OR).

A few things to keep in mind:

Although some of these examples can also be accomplished with a conditional operator (condition ? expr1 : expr2), the point of this article is to explore the potential of logical operators.
Javascript evaluates logical operators from left-to-right, which means it evaluates what's on the left of a logical operator before evaluating what's on the right. So in a && b, a is evaluated before b.
In the examples below, true and false simply represent anything (variable, function, etc) that evaluates to true or false respectively.
Don't let shortcuts break code readability and maintainability. If your use of logical operators as a shortcut becomes to cryptic/complex, you may find yourself losing your mind.

If else, without the if else

// traditional
if (true) {
	do_this();
}
// alternative method with &&
true && do_this();

// traditional
if (false) {
	do_this();
}
// alternative method with ||
false || dont_do_this();

// do multiple things via anonymous wrapper
true && (function () {
	do_this();
	and_this();
	...
})();

// real example - test if DOM object exists before acting on it
jQuery('#alert').length && (function () {
	var el = jQuery('#alert');
	el.show();
	window.setTimeout(function () {
		el.hide();
	}, 5000);
})();

Conditional assignment

// setting defaults with ||
var my_setting = optional_setting || default;

// real example - if input#email is blank, defaults to none@none.com with ||
var email = jQuery('#email').val() || 'none@none.com';

// setting value only if something else is true with &&
var my_setting = test_me && setting;

// real example - setting email if valid with &&
var email = jQuery('#email').val().search('/[\d\w\.\-\_]+@[\d\w\.]/') > -1 && jQuery('#email').val();

// complex usage (mimic conditional operators)
var my_setting = (test_me && optional_setting) || default;

// real example - setting email if valid, with default
var email = (jQuery('#email').val().search('/[\d\w\.\-\_]+@[\d\w\.]/') > -1 && jQuery('#email').val()) || 'none@none.com;

Method calls on conditional variables

// use parenthesis to act on a condition
(check_if_true && use_this_if_true).method();
(use_if_true || else_use_this).method();

// real example - Add form field error above itself if it's not wrapped in a  with ||
(jQuery(this).closest('form') || jQuery(this)).insertBefore('Error!');

// real example - Add form field error only if it's a  with &&
// note: this will error if not in a form and not in a try...catch
(jQuery(this).closest('form') && jQuery(this)).insertBefore('Error!');

Conclusion

Javascript's conditional operators allow us to do some neat tricks. We looked at how to use them to bypass if...else, make variable assignments based on conditions, and call methods depending on conditions. But with all shortcuts, use caution. Knowing how javascript works will help you use conditional operators to their full potential while keeping you safe from unexpected results.

Time On Site & Bounce Rate: Get the real numbers in Google Analytics

Tue, 12 Apr 2011 14:21:00 -0400

Google Analytics has a major problem with the way it calculates its Time On Site metric: its based on the length of time between a user entering your site and their last page view. Can't see the holes yet? Here are 2 scenarios where this becomes a major problem (Bob will be our user):

Worst case scenario

In the above scenario Bob enters your site, loyally reads an article for 2 minutes and 13 seconds, saves it to his browser boomarks, then leaves. Can you see the problem? Bob never interacted with the webpage. To Google, this is a bounce. And bounced visits get marked with 0:00 Time On Site. In other words, your Bounce Rate just got inflated and your Avg. Time On Site just got its ass kicked.

Another bad scenario

Let's say Bob enters your site and even visits a second page, spending a total of 2 minutes and 13 seconds on your site before leaving. But Google messes this up too: since Bob never interacted with the 2nd page, Google doesn't know how long he spent on the second page. Therefore, Time On Site = Visit to second page - Entrance time = 1 minute and 11 seconds, not 2 minutes and 13 seconds.

Google's calculation of Time On Site and Bounce Rate is limited by its unit of measure: the Pageview. But Time On Site has very little to do with pageviews and Bounce Rates—defined as "the percentage of people who come to your website and leave instantly" by Avinash Kaushik—has nothing to do with pageviews.

Solution

With Google's Event Tracking API, we'll tell Google Analytics that Bob is still on our site every 10 seconds. To make things even better, an event is an engagement equivalent to a pageview, so it too increases Time On Site and unbounces the visit. The result? A more accurate picture of user engagement.

Javascript magic

Paste this javascript snippet right before </body> in your HTML pages. It won't matter if you're using the new or old tracking code.

(function (tos) {
  window.setInterval(function () {
    tos = (function (t) {
      return t[0] == 50 ? (parseInt(t[1]) + 1) + ':00' : (t[1] || '0') + ':' + (parseInt(t[0]) + 10);
    })(tos.split(':').reverse());
    window.pageTracker ? pageTracker._trackEvent('Time', 'Log', tos) : _gaq.push(['_trackEvent', 'Time', 'Log', tos]);
  }, 10000);
})('00');

Once this code is installed, your site will update Google Analytics every 10 seconds under the Event Category "Time", the Event Action "Log", and the Event Value will be based on the pattern of 0:10, 0:20, 0:30, 0:40, 0:50, 1:00, 1:10, etc.

Conclusion

Although Google Analytics has its flaws, it compensates in part with a powerful tracking API that keeps getting better. The snippet I've written above can more than solve its Time On Site and Bounce Rate reporting issues. Furthermore, if you're a Google Analytics ninja (or ninja in training), break out the event values into a histogram that shows the distribution of site visit duration. Cheers!

Surviving Silicon Valley

Wed, 10 Nov 2010 09:13:00 -0500

The past 2 months have been more crazy than any other time in my professional web life. Why? I'm surviving Silicon Valley.

Two months ago I joined Topsy, a real-time search engine powered by the social web. We have the largest index of tweets in the world, and turning all of that data into something useful for people is complex. Moreover, real-time and social are synonymous with fast-paced. Put the two together and we're talking really fast-paced.

But that's just how Silicon Valley rolls. The stakes are high as are the demands from the people expected to make things happen. So what does "making things happen" in Silicon Valley mean? Without further ado, here's a high-level view of what's happened during my first two months there.

Two months in Silicon Valley

Thrown into a highly complex search environment trying to keep up with some of the smartest search engineers in the world
Released a completely redesigned corporate blog
Designed a complete product using Django/Python, both of which I've never had past experience
Built an powerful copy & paste widget (coming soon to publishers near you)
All while moving from GUI editors with FTP access to VIM over SSH with Git version control

Wow. That's a lot. And I'm just getting warmed up.

I reflect on all of this often. Although I've seen myself as a strong developer having developed many popular web apps, I appreciate the developer I'm becoming … in just two months mind you.

But the real goal of this article is to prepare other smart developers around the world that are considering Silicon Valley for their next employment opportunity.

Tips for preparing to work in Silicon Valley

Treat everyone like they're your boss

Silicon Valley hires people because they're the cream of the crop—the best at what they do. The culture is very egalitarian in that a co-worker's advice is just as valuable as your boss' or their boss' advice when given in the context of their expertise. Unless obviously untrue, never should you doubt or underestimate their knowledge. It may be the best advice you've ever received.

When you're working with someone, think of your role in terms of how to make their jobs easier. If you do that, you'll likely to receive the same treatment back, because everybody respects co-workers who get shit done.

Get shit done

Silicon Valley startups represent a high performance culture. Shareholders, the nature of Silicon Valley, and the economics of technology all make things move fast. The only way to keep up is to simply get 'er done.

Additionally, the level of expertise required to work there means you're highly accountable to your output for two primary reasons. First, everyone is solving their own problems that help the business grow. Your problems are your own to the extent that you're ultimately accountable for solving them. Second, because everyone is a strong performer and the unforgiving nature of startups means the company is running lean. Your role is yours. Do it or say screw it and bounce out of Silicon Valley.

Burst your bubble

Over 50% of the tools I use to get my job done are new to me. I wasn't hired only because I knew the primary tools that were required for the role. I was hired because I had the capacity and the desire to learn and grow professionally and personally.

If you're working in a bubble (mine was LAMP) and thinking about working in Silicon Valley, make sure that you're comfortable with learning new tools even as you're expected to perform with them. Silicon Valley is no place for people unwilling to break their barriers, even drastically.

Conclusion

Surviving Silicon Valley is about capacity to perform. Do you have the capacity to perform?

On a related note, Topsy is a great place to work, and Topsy is always hiring. (And no, Topsy did not ask me write that)

Metadata design pattern for the web

Fri, 1 Oct 2010 08:01:00 -0400

The Web is shifting. Web pages are no longer silos of information. Twitter, Facebook, and blogs are adding conversations to the web, and those conversations are context for web content that can potentially provide an amazing amount of value to users.

The major shift began when people could begin commenting on diaries with Open Diary in 1998 and growing quickly in popularity when Google bought Blogger in 2003. Today, conversations are happening everywhere, and more people are joining in every day.

New problem: Conversations are silos

But now conversations are falling into silos. Commenting on a blog about an linked-to-article isn't the same as commenting directly on that article. If I'm looking at web content, I should be able to see what people everywhere are saying about that article. Instead, I have to become my own search engine robot—crawling the web to see what others are saying.

But why do I care what others are saying? Because it's social proof. Because it provides context. Information in context is infinitely more valuable.

Twitter redesign is tearing down the silos

Twitter's redesign is beginning to unlock this potential. Before the redesign, tweets were silos. I only knew that this person made such and such comment, and possibly that they tweeted such and such. But what exactly were they responding to? Who? Why?

After the redesign I instantly see what others are saying, who said it first, and even a peak at what's being discussed when I click on a tweet. Suddenly, a wealth of information is at my fingertips with each new tweet coming in.

Others want to demolish the walls, too

Recently InformationArchitects.com (@iA) posted their own redesign of Facebook, which shares many similarities with Twitter's redesign. Click on something posted on your wall, and a panel opens revealing context for the post.

Building a design pattern for metadata

In Twitter and iA's Facebook designs you'll see that on the left is the main content, and on the right is metadata, unlocked by clicking on the main content. I believe this should become more commonplace for content on the web.

Applications

Search engines

Imagine clicking on a result in Google and viewing discussions about a link, other pages that link to the page, and other popular pages on the site.

Content feeds

Twitter is already doing it. iA's Facebook redesign shows it. What about Google Reader or other aggregators? Aggregating content is not as powerful as aggregating content with context.

Websites

I'm thinking about this for my own blog: Imagine clicking on a link and getting context about it without leaving the article? Or when I visit a page it automatically pulls in conversations and metadata from the web to supplement my own content.

Web browser plugins

Same as above, but the UI is built into the navigator. Some of Safari's extensions are already doing this, including Twitter for Safari and Reddit Comments.

HTML5 Microdata: Why isn't anyone talking about it?

Wed, 8 Sep 2010 11:49:00 -0400

Many big web design blogs are raving about HTML5, as they should be. But if you read many of them, [1, 2, 3], you'll be bombarded with an over-publicizing of header, article, footer, et. al tags, which reminds me of circa 2002 when we were all jumping onto the XHTML bandwagon.

But 8 years later where'd XHTML get us? Suddenly we're moving back to HTML. Why? XHTML provided no actual benefits. It just meant we had to add meaningless bytes to our user's downloads.

HTML5 on the other hand is bringing with it a ton of actually useful technologies, including much needed advances in HTML forms, native video support, and a vector API/canvas.

But back to circa 2010/2002-wannabe. Here we are again bandwagoning (is that a word?) some futile tags of HTML5. Why get so excited about those tags? Look how flexible this is: div id="ANYTHING". Wow.

So my fellow web design bloggers: let's shift our focus to something that's a part of the HTML5 definition, changes the way we write tags, and has actual benefits: Microdata.

A few web design blogs, including one of my favorites, NETTUTS, has covered Microdata briefly, and I want to add some more fuel to the conversation.

What is HTML5 Microdata?

Old schoolies may remember this little thing called the Semantic Web. No I'm not talking about Semantic HTML, a fancy bit of jargon that by its mere mentioning can give web design newbies a glint of crazed evangelism in their eyes. No. I'm talking about actual ways to make the web more useful to users.

The Semantic Web would ideally help users find and use information because computers would know, for example, that an event is an event rather than a bunch of text. If a computer knows an event is an event, it could potentially add a mechanism to allow the user to add the event to his or her calendar. Otherwise, in what has been the norm, the computer arbitrarily displays the information putting the burden in the hands of the user.

While there have been many approaches to a semantic web, including XML, none of them have really taken off beyond APIs because Internet users don't read XML code. Users look at web pages. Additionally writing XML schemas was impractical and ill-adopted by web designers and search engines alike.

But "the times they are a-changin'." HTML5 is introducing Microdata, which is an API for adding semantic data to plain ol' HTML tags. This means that using plain ol' HTML tags, you can tell the a web browser or search engine that an event is an event, a person is a person, and so on.

How does Microdata markup look?

Using Microdata is simple, because unlike XML, you do the same thing you've been doing since you built your first website. The only difference is you add an extra attribute to your HTML tags, like so:

Before adding Microdata


My big event
My big event is going to be fun. You should come.
When: July 4th, 2022 at 6:00pm to July 4th, 2022 at 10:00pm.
Where: Fun Times Bar

After adding Microdata


My big event
My big event is going to be fun. You should come.
When: July 4th, 2022 at 6:00pm to July 4th, 2022 at 10:00pm.
Where: Fun Times Bar

As you'll see from the example above, we're still using plain old HTML tags, just adding some additional attributes.

Although completely going over all Microdata attributes is being the scope of this article, you can check out a a fantastic documentation on using Microdata at Dive into HTML5

Use Microdata for immediate benefits

Unlike all the ideology surrounding XML that never came to fruition, Microdata is already being adopted by Google as part of their rich snippets to aid in providing richer search results.

Google using Microdata events

Google using Microdata people

Google using Microdata reviews

Google has a list of rich snippets for more examples of how you can use Microdata to product richer search results for your own web pages.

Taking Microdata even further tomorrow

Google's adoption of Microdata is taking us a step closer to a semantic web, and there are still big steps to make. However, I believe Microdata may be practical enough to get us really rolling on the semantic web train. Here are a few things I believe would help:

Microdata adoption by browsers

What if a user rolled over a person's name and could add them as a contact, or roll over an event and add it to your calendar, all within the native web browser UI? That'd be something, and it doesn't seem like it would be that hard to accomplish. How about it Mozilla, Safari?

Microdata adoption by web developers

Web browsers and Google have little reason to support Microdata if us web developers aren't marking up our webpages with it. Plain and simple. Take a few moments to learn the Microdata API a little, and the semantic web will be right at our doorstep.

What are your thoughts about Microdata?

Finally, I want to hear your thoughts on Microdata. Have you had any experience with it? What are some potential uses for Microdata that I haven't discussed?