To contribute, our work please visit the survey page and send feedback. It usually takes less than a minute. Thanks.

So finally, I have another great idea for Kevin Rose for a new start-up. What about tracking comments and backing the contribution of the overly hyped dotcom bubble’s useless applications?

What’s wrong with these options are their being more than annoying. As a developer in debugging, I’m not looking for extra extra performance but to be able to see what’s going on inside in every point of view. But, Firebug now asks me anytime I debug a page to enable the debugging tools and doesnt remember my choices when I re-visit or return to those pages. I’m feeling like my entire adult life is going to be consumed by being forced to select the right options every two seconds. I hope this is just a bug, otherwise I want my old and dull Firebug back.

Usually mathematicians love this not-so-freaky humor and use a lot to show relation btw the maths and business major but today while we were talking about masters in computer science, my sample give me an inspiration that it both applies to our situation.

The problem with today’s world can be summarized into a few sentences. Media that we’re uploading to media share services like Youtube and Flickr, is usually used on different mediums like our blogs or on other social platforms. So adding these kinds of rich media with jumble embed codes to everywhere is a lot nervous. What would happen if these providers give you an opportunity to fetch some essential information about the media with its permalink?

Leah Culver announced that OEmbed comes with an idea to distribute machine readable data for embed elements from photo, video and rich content providers. So as you provide the media’s permalink, it returns you its title, description, embed code and etc.

Below there is an example of getting some information from Flickr about this photo. There is a sample scenario below ask provider more about the picture via oEmbed.

As you see above, Flickr returned us the details about the picture. So, you can easily develop more complex applications which combine multimedia elements from different sources by providing only links.

At the moment, Flickr, Viddler, Qik, Pownce, Revision3 and Hulu is giving support to OEmbed. Please visit the official page for the specifications and the API back points.

I remember the first day I played a little bit with asynchronous requests and manipulate the DOM tree with the new content, back in the early 2005 I suppose. In a minute, I started crying from happiness and the magnificence behind the idea was so marvelous that it can even change everything I know about the existing web architecture. I asked for a while why we are not developing systems where back-end servers are only sources of raw data just like how my idea implemented into the reality with web app APIs today. Dynamically appending elements to DOM with info coming from servers and removing them were giving a lot better performances than re-requesting the full page again for minor changes - in fact even for major evolutions.

That old and junky looking JavaScript became my hero in the next few days and I decided to get into the design patterns and anything geek in the air about it. Today, JS, Adobe’s Flex and many more provides us to design better systems with less back-end connections. So why not? I believe there comes a day that back-end will become pure data and front-end will become the UI, just how it should work like.

A Flickr page without style sheets (left) and WAI homepage without style sheets (right).

Flickr is still staying on tables for non-tabular data. The usages of the lists are unbearable and lack of the good mark-up design is undeniable. It is totally in a contradiction with an almost perfect page structure example: homepage of W3C’s WAI. On Flickr, everything is a mess, including the hidden elements. Besides there is a list of failures that are captured in a few minutes:

• There are so much onclick, onchange attributes that ruins the whole mark-up. Keep the events on a separate js file to help search engines index what’s essential.
• Some of the style sheets are loading inline, why do end users have to load the same piece of CSS code on every page? Where’s the chance of using less bandwidth by caching the style sheet files then?
• Tiny icons near links aren’t backgrounds of the link elements. Which machine is interested in reading tones of useless tiny icons without any alt attributes?
• Some buttons have all uppercase titles which can be done with CSS easily without endangering the accessibility.

If the whole mark-up studied in detail, there are many more situations that are against of all W3C recommendations and web standards groups around the world. So the question is back again? What’s the importance of following standards then?

Then, what else is so great about microformats?

When you enter a blog, it’s usually easy to segment certain particles like blog posts, blogroll(s), tags and etc. Because, your brain is already aware of the blog pattern and its elements. In computing, unfortunately same thing doesn’t apply for machines that easily. As an example, let’s take a web crawler that regularly visits your blog and indexes the updates. Can it name a blog post block or even your blog’s being a blog? In practical, it’s a costly process to make it learn the blog patterns from pure HTML/XHTML mark-up without any helpers. This is the one of the major problems of today’s web. But luckily, instead of the complex pattern recognition techniques, microformats came with a simplistic idea: adding extra information into your mark-up to define some segments that machines can easily name what they are.

This technique is very similar to the philosophy behind the usage of fundamental HTML/XHTML elements. For instance, we know an a tag mentions a link and h1, h2, h3... tags are used for titles. They all have significant meanings, so web browsers know how to react when they cross one while parsing the source mark-up. Even more, some of today’s search engine crawlers like Googlebot finds headings and puts extra meaning to them.

So instead of using only HTML or XHTML standard tags, why aren’t we using more complex structures? For instance, in a web page, if I want my name to be machine readable, I can mark-up my name in the following way:

<author>JBF</author>

So an XML parser can easily find the author tag and learn about my name. But this mark-up isn’t validating the standards, so we should find another way to embed this extra information without going against all the web browsers and W3C. Microformats community makes it with class. Tags are not the only option for putting extra information inside the source. Any tag attribute is also fine. But class is the most suitable one among the all attributes. Let’s see what mf community imagined back in the 2004:

<div class="hcard"><span class="fn">JBF</span></div>

hCard specification tells that, every hcard class features contact information. hCard is totally a re-specified IETF vCard standard clone. Inside hCard, you can see the fn class which means there is the formatted name of the person inside. The rest of the hCard elements can be seen on hCard page on mf wiki. So again a parser can easily parse through the source and extract hcard and inside classes to segment the author information.

There are already many specifications are defined by the mf community such as hCard, hCalender, hAtom, hResume, geo and etc to abstract many of the today’s most common patterns on the web.

But, is it all perfect?

Nothing in life is, of course. Microformats seem to be a simple and easy to adopt idea, but in real life, for example we usually refuse to list all information about us one after another. So I’m wondering why hCard isn’t designed to support distributed information about contact information. And what about the extra effort we should spend on microformats while posting? Is everyone feeling nuts about it to consume more energy on mf? Is it possible to abstract information as a pattern? And what’s the optimal pattern number that can be specified within open standards?

Another question appears in mind when I hear about hAtom can be used instead of feeds. So we won’t need an extra feed to let our readers follow us from different mediums. But why to waste network traffic with formatted data and then use processor power to extract information inside. Isn’t separating data from UIs a better idea?

These are my questions and maybe you have the answers!