Posts Tagged ‘Articles’

YUI 3: Lighter, Faster, Easier to Use

Friday, June 19th, 2009

I wrote a YUI 3 primer for SitePoint, check it out and let me know what you think!

My Interview of John Resig (Creator of jQuery) for SitePoint

Friday, December 5th, 2008

My interview of John Resig for SitePoint just went online. Go check it out, leave a comment and spread the word. :-)

From Yahoo! Pipes to the “next big thing” on the web

Sunday, March 4th, 2007

There are a growing number of startups vying for your attention. Each offering a new service–or an old one rehashed–that they believe you should sign up for. A lot of the services are free and quite useful in their own right, though I strongly suspect that the abandonment rate of these services is proportionally creeping higher the more of them come online.

The reason for this of course is very simple. You only have so much attention to give to any one service before you have to get on with the rest of your life. The more services you subscribe to, the more you’re going to have to split your attention across the sum of them. This phenomenon is similar to what happened with visiting websites back in the 90s. Back then the only mechanism we had to keep ourselves on top of what was going on at our favourite sites was to visit them periodically. But with a hundred or so bookmarks, visiting each one daily became a real hassle, if not completely impossible. A novel solution to this problem came along in the form of RSS feeds, now known simply as feeds. This allowed a computer to do the visiting for you and present you with a single, central, updated list of everything that was going on.

Though feeds are great for keeping on top of our favourite sites, the increasing push toward the web as a platform is quickly bringing with it more complicated scenarios. Take for example twitter. It’s a sort of hybrid between chatting and blogging, and it’s addictive. But now I’m checking my email, my feeds and twitter throughout the day. To say nothing of trying to manage my calendar, todo list and photos. In order to do this today, I need to have about as many windows (tabs) open and jump between them whenever I want to check on or update one of the services. But jumping from window to window, or tab to tab, is impractical, cumbersome and tedious. What’s more, a lot of the data I use in one service often needs to be reentered into another.

In order to solve this dilemma of services, the web development community has begun exposing APIs that allow us to interact with our data without actually visiting their sites. The trouble with APIs however, is that unless you’re a programmer, an API is pretty much useless to you. So broad based use of APIs is limited to the ability and creativity of the programmers who use them. Enter Yahoo! Pipes.

Yahoo! Pipes is a unique service that allows someone who isn’t a programmer to take feeds, manipulate them, throw them together and output the result into a new feed of their own–without writing any code! This sort of thing is the future, and whoever pioneers this–and figures out how to monetize it–will have a massive leg up on the competition. Imagine being able to use Flickr, Google Reader, Twitter and a bunch of other services of your choosing in a custom built application that’s tailored to your exact specifications without ever programming one line of code. All talking to each other, all on one page (or device, or platform of your choosing), built for you, by you.

Where reading feeds is unidirectional, APIs are bidirectional. Where Yahoo! Pipes allows you to mash up feeds, the market leader of the future will allow you to mash up APIs.

HTML or XHTML: A purist’s dilemma

Tuesday, November 22nd, 2005

Whenever possible, I like to do things the right way. Proper implementation of anything—though it may take more effort initially—returns dividends in the form of higher performance, reliability, scalability, re-usability, and so on and so forth. This principle applies to life in general and isn’t limited to web development (read: Tacoma Narrows Bridge). It is however at the core of this article and the focus of the issue I am wrestling with.

For some time now, I was under the impression that XHTML was simply “better HTML,” due to its inherent well formedness—what with it being written in XML and all. But it seems I was mistaken (and I’m willing to admit it). Recently I’ve been reading articles by Anne van Kesteren, and it’s gotten me wondering if I didn’t just jump on the XHTML bandwagon without even asking myself that one all-important question: “Do I really need this?” Had I taken the time to explore the issue a little, I would have found out that in order to deliver XHTML to a client properly, I should be doing it via the application/xhtml+xml MIME type. Currently my documents are delivered as text/html, so all I have to do is change the MIME type right? Not really. While Firefox supports it, IE doesn’t. A document delivered to IE using the application/xhtml+xml MIME type causes the browser to display a download window as it doesn’t support it as a known document format. I could rig my web server to deliver the document in text/html for IE, but then I’d have to ask myself: “Is the effort worth it?” In other words, what advantage would XHTML bring me for the effort I’d have to expend in properly implementing it? Not to mention the fact that it would still be delivered in the incorrect MIME type in IE. The answer unfortunately is: none. Though there really aren’t any major semantic differences between HTML and XHTML, I’d really only need to use the latter if I had to extend HTML with MathML or some other custom markup languages. For more on this, read Anne’s post entitled: “MIME types matter; DOCTYPEs don’t

Now, some of you may be thinking “big deal, it still validates as XHTML even if the MIME type says it’s HTML and not XHTML.” Well, that would be a bad assumption to make since according to the W3C HTML WG Chair Steve Pemberton, …documents served as text/html should be treated as HTML and not as XHTML. This means that even though I work very hard at writing properly formed XHTML, in reality what I’ve been doing is exactly what I’ve been trying hard to avoid: I’ve been writing tag soup! That’s right, since in essence I’ve been delivering HTML documents using mal-formed HTML.

My dilemma is the following: Do I switch to HTML 4.01 and get used to uppercase tags that don’t self-close? Do I stay with XHTML 1.0 Strict and keep delivering it with the incorrect MIME type? Do I rig Apache to deliver my XHTML with the application/xhtml+xml MIME type and abandon visitors with older browsers (like IE 6). Or do I find a happy medium that delivers application/xhtml+xml to conforming browsers and text/html to everyone else?

What do you think?

Related Reading

The Case for Semantics

Thursday, October 20th, 2005

Communication, a wonderful tool that enables us to accomplish so much in our daily lives. Yet it’s up there with breathing and electricity as something we take completely for granted. Take speech for example. We communicate via speech by giving meaning to the sounds that we are able to make with our mouths. Each distinct sound is assigned a letter, the sum total of which constitutes our alphabet. We then take these letters and combine them to create words. Those words then are further combined to create sentences which in turn combine to make paragraphs and so on and so forth.

We use words to convey meaning. If the words that we used didn’t sufficiently convey the thoughts that we wanted to express, there would be little reason for us to use them. We’d simply be making noise.

The reason we are able to do this is because somewhere along the way, a group of us agreed to assign a particular letter to a particular sound. Then we grouped those letters and agreed on meanings for them and called them words. Different groups agreed on different letters and different words, which are of course the different languages we have today. (Some of us believe in the Tower of Babel story but that falls outside the scope of this post). But, regardless of choice of language, what’s key is our collective agreement which allows us to communicate complex thoughts and emotions. Without which we’d be reduced to grunting, flailing, disorganized and highly frustrated people.

Semantics is a subfield of linguistics that is traditionally defined as the study of meaning of (parts of) words, phrases, sentences, and texts.

As you are no doubt aware—after all you are reading this online—communication has progressed quite a way beyond simple analog speech. Today we are able to not only speak with others around the planet in real-time, we are also able to transmit volumes of text, images, sounds and video via technologies such as the internet. Just as it was essential to assign meaning to spoken words, so it is the case now with the languages we use on the internet. One of the oldest and most fundamental of which is the HyperText Markup Language, used in the creation of web pages.

When one creates a web page, they do so to share information. But that information can quickly become confusing if not expressed correctly. I’ll use an example from our daily speech to illustrate. Say I want you to get me a can of soda from the refrigerator in the garage. Would you know what I meant if I asked: “can you get me a thing from the thing in the thing?” You would more than likely not know what I meant. That’s because I wasn’t using the correct words to convey the proper meaning of my request. In the context of HTML this principle holds just as true. Headings, lists, paragraphs, tables and other such markup transforms plain, relatively meaningless text into meaningful content.

Often times however, it’s the misuse of this very same markup which is responsible for the mangling of meaning on the internet. For example, because browsers render heading texts of increasing dept in smaller and smaller font sizes, some have taken to using headings representing two or three levels of depth in order to render their text in a particular font size when their text isn’t even a heading! Still others use the convenient grid pattern of tables to lay out their content thus expressing that their page contains tabular data when there isn’t any. Such abuses are rife throughout the internet and should be avoided at all costs if we want people to understand what we are communicating. Otherwise, though the content we see online may seem—at least visually—legible, it is in fact an unintelligible, garbled mess that is of no lasting use.

It may sound harsh of me to say that badly marked up content is of no lasting use but it’s the truth. When a page is visually legible yet improperly marked up, it’s very difficult to maintain and software is unable to understand it. If it’s not understandable by a computer, it can’t be properly indexed by search engines, correctly understood by screen readers, reused as a data source for other applications and put to use in future applications not yet conceived. It may as well be an image because it has about as much semantic meaning.