Yahoo! Developer Network blog

Grasping Social Patterns

May 11, 2008

Back in April, I gave a five-minute talk to a barful of Web 2.0 conference attendees in San Francisco. An audience member recorded me, and posted it to YouTube:

The event was Ignite at O’Reilly’s Web 2.0 Expo last month. This was the most recent in a series of slideshow “slams” that Brady Forrest has been putting on all around the country, and the second one held at Jamie Zawinski’s DNA Lounge in San Francisco (the first was last fall).

The format is inspired by pecha kucha. Each speaker is limited to 20 slides and five minutes. The slides advance automatically each 15 seconds. Each speaker is encouraged to tell a roomful of geeks how to do something.

The tight strictures of the format force the speaker to get to the point right away and pack as much information as possible into the allotted time. I’ll be honest: it was a bit intimidating.

The format itself turned out to be exhilarating, bringing out great performances from a number of the speakers, notably Kathy Sierra (how to make your users kick ass), Annalee Newitz (why giant monsters rule), and Lane Becker (the gruesome physical consequences of running a marathon).

I discussed some of the social design patterns (and antipatterns) that I’ve been gathering as curator of the Yahoo! Design Pattern Library. You can hear the whole talk, including facetious arena-rock shout-out at the beginning, synched up with the slides (which are harder to read in the video), by watching this slidecast:

Christian Crumlish
Pattern Detective

Comments (0)

oEmbed - Embedding third party media made easy

May 9, 2008

Web 2.0 is all about collaboration, distribution and personal configuration and probably one of the biggest traffic drivers of social networks like Facebook or MySpace are videos and photos being sent to and from your contacts.

The problem for developers of networks is that you don't want people to leave your application to see a photo or a video, which means that you need a way to only get the media and embed that. Normally this happens using the media provider's API or - if they don't offer one - screen scraping (loading the whole document and programatically finding and extracting the media).

oEmbed is a great idea to work around that issue:

oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly.

Flickr, Viddler, Qik, Pownce and Revision3 are the first services to support oEmbed which means you can easily access photos and videos with a simple URL.

Say for example find a nice photo on flickr:

Original URL:

oEmbed URL:

Result:

<oembed>
  <version>1.0</version>
  <type>photo</type>
  <title>? too much myspace error</title>
  <author_name>codepo8</author_name>
  <author_url>http://www.flickr.com/photos/codepo8/</author_url>
  <cache_age>3600</cache_age>
  <provider_name>Flickr</provider_name>
  <provider_url>http://www.flickr.com/</provider_url>
  <width>500</width>
  <height>375</height>
  <url>
    http://farm4.static.flickr.com/3128/2475016321_982666ec95.jpg
  </url>
</oembed>

You can define the output format and the maximum width and height with URL parameters:

oEmbed URL:

Result:

{
  version: '1.0',
  type: 'photo',
  title: '? too much myspace error',
  author_name: 'codepo8',
  author_url: 'http://www.flickr.com/photos/codepo8/',
  cache_age: '3600',
  provider_name: 'Flickr',
  provider_url: 'http://www.flickr.com/',
  width: '100',
  height: '75',
  url: 'http://farm4.static.flickr.com/3128/2475016321_982666ec95_t.jpg'
}

Supported formats for responses so far are photo, video, link and rich.

Christian Heilmann
Yahoo Developer Network

Comments (3)

Party Like a SearchMonkey

May 8, 2008

A few weeks ago, we announced SearchMonkey, an new open platform that lets developers and site owners use semantic markup and structured data to enhance Yahoo! Search results and make them more useful, relevant, and visually appealing.

We wanted to remind you that we're kicking off this launch in true SearchMonkey style with a Developer Launch Party next Thursday, May 15. Come get the inside scoop on SearchMonkey, meet with our product managers and engineers over tasty (read: free!) food and beer, see live demos, and take a closer look at the Developer Tool.

When: May 15, 2008, 5:30 -- 8:30 p.m.

Where: Yahoo! Headquarters @ URL's Cafe

701 First Ave.

Sunnyvale, CA 94089

RSVP: Email your full name and company name directly
to searchmonkeyevent@yahoo-inc.com. Space is limited.

For more information on the agenda and logistics, check out the event page.

Comments (0)

Yahoo! sponsors the kick-off party for London's Web Week

For a whole week in between 26th of May and 1st of June London, England will be a centre for all things web development. The London Web Week is a not-for-profit scheme to boost the development world in the UK and beyond and promote best practice ideas like accessibility and progressive enhancement.

Events include the by now famous @media conference, the fourth London BarCamp, a Microformats vEvent and Web Roots. To learn about all the events, check the schedule on the web week site.

To kick things off in the right fashion, we will sponsor the London Web Week Opening Party on Monday, May 26, located at the Ruby Blue Bar in London's West End.

If you are in the area, or you are coming to @media anyways, make sure to check out the sign-up page on event wax to secure a ticket, as the space is limited to 200 people.

Hope to see you there and have a blast before making this week even more special than it already is.

• Sign up for a party ticket
• Learn more about the event at upcoming

Christian Heilmann
Yahoo Developer Network

Comments (0)

The seven rules of pragmatic progressive enhancement - a brown bag presentation

May 7, 2008

Last week I went to AKQA in London to give a brown-bag presentation on progressive enhancement.

I took this chance to vent some of my ideas on the subject and counteract some of the criticisms I heard about the need for enhancing web solutions progressively.

I've come up with the following "Seven rules of progressive enhancement":

1. Separate as much as possible
2. Build on things that work
3. Generate dependent markup
4. Test for everything before you apply it
5. Explore the environment
6. Load on demand
7. Modularize code

I've explained them in further detail in the slides available on slideshare:

Furthermore I put some more information in an article on the subject: Pragmatic Progressive Enhancement.

The article is licensed with creative commons, so you are very much invited to use and remix it to your needs.

Chris Heilmann
Yahoo Developer Network

Comments (1)

Building a Better Website With Yahoo!

May 6, 2008

Editor's note: This post by Yahoo! front-end developer Tyler Hall originally appeared on his personal blog, Click on Tyler.

It's been a long time coming, but last month I finally pushed out a new design for my personal website, Click on Tyler. I rebuilt it from the ground up using two key tools from the Yahoo! Developer Network:

• YUI Grids and
• YSlow

The new design is really a refresh of the previous look with a focus on readability and speed. I want to take a few minutes and touch on what I learned during this go-round so (hopefully) others might benefit.

Color Scheme

Although I really liked the darker color scheme from before, it was too hard to read. There simply wasn't enough contrast between the body text and the black background. I tried my best to make it work. I searched around for various articles about text legibility on dark backgrounds. I increased the letter spacing, the leading, narrowed the body columns, and everything else I learned in the intro graphic design class I took in college. The results were better, but my gut agreed with all the articles I read online which basically said "don't do it." So I compromised and switched to a white body background, while leaving the header mostly untouched. I find the new look much more readable -- hopefully this will encourage me to begin writing longer posts.

CSS and Semantic Structure

The old site was built piecemeal over a couple months and, quite frankly, turned into a mess font-wise. I had inconsistent headers, font-weights, and anchor styles depending on which section you were viewing. With the new design, I sat down (as I should have before) and decided explicitly on which font family, size, and color to use for each header. I spec'ed out the font sizes using YUI's percent-based scheme which helps ensure a consistent look when users adjust the size. (Go ahead, scale the font size up and down.) An added bonus was that it forced me to think more about the semantic structure of my markup. (If you have Firefox's Web Developer toolbar installed, try viewing the site with stylesheets turned off.) If there's one thing I learned working for Sitening, it's that semantic structure plays a huge part in your SERPs.

Optimizing With YSlow

At OSCON last summer, I attended one of the first talks Steve Souders gave on YSlow -- a Firefox plugin that measures website performance. That, plus working for Yahoo!, has kept the techniques suggested by YSlow in the back of my head with every site I build. But this redesign was the first time I committed to scoring as high as I could.

As usual, I coded everything by hand, paying attention to all the typical SEO rules that I learned at Sitening. Once the initial design was complete and I had a working home page, I ran YSlow.

Ouch. A failing 56 out of 100. What did YSlow suggest I improve? And how did I fix it?

• Make fewer HTTP requests - My site was including too many files. Three CSS stylesheets, four JavaScript files, plus any images on the page. I can't cut down on the amount of images (without resorting to using sprites - which are usually more trouble than they're worth), so I concatenated my CSS and JS into single files. That removed five requests and brought me up to an "A" ranking for that category. (I'm further toying with adding the YUI Compressor into the mix.)
• Use a content delivery network - At Yahoo! we put all static files on Akamai. Other large websites like Facebook, Google, and MySpace push to their own CDNs, too. But what's a single developer to do? Use Amazon S3 of course! I put together a quick PHP script which syncs all of my static content (images, css, js) and stores them on S3. Throughout the site, I prepend each link with a PHP variable that lets me switch the CDN on or off depending on if I'm running locally or on my production server. (And, in the event S3 ever goes down or away, I can quick switch back to serving files off my own domain.)
• Add expiry headers - Expiry headers tell the browser to cache static content and not attempt to reload it on each page view. I didn't want to put a far future header on my PHP files (since they change often), but I did add them to all of the content stored on S3. This is fine for images that should never change, but for my JavaScript and CSS files it means I need to change their filename whenever I push out a new update so the browser knows to re-download the content. It's extra work on my part, but it pays off later on.


• Gzip files - This fix comes in two parts. First, I modified Apache to serve gzipped content if the browser supports it (most do) — not only does this cut down on transfer time, but it also decreases the amount of bandwidth I'm serving. But what about content coming from S3? Amazon doesn't support gzipping content natively. Instead, in addition to the static files stored there, I also uploaded their gzipped counterparts. Then, using PHP, I change the HTML links to reference the gzip versions if I detect the user's browser can handle it.


• Configure ETags - ETags are a hash provided by the webserver that the browser can use to determine if a file has been modified before downloading it. Amazon S3 automatically generates ETags for every file -- it's just a free benefit of using S3 as my CDN.

So, all of the changes above took about three hours to implement. Most of that time was spent writing my S3 deploy script and figuring out how to make Amazon serve gzipped content. Was it worth it? See for yourself.

Wow. Three short hours of work and I jumped to a near perfect 96 out of 100. The only remaining penalty is from not serving an expires header on my Mint JavaScript.

Do these optimization techniques make a difference? I think so. Visually, I can tell there's a huge decrease in page rendering time on both Firefox and Safari. (IE accounts for 6% of my traffic, so I don't bother testing there any longer.) More amazing, perhaps, is the site's performance on iPhone. The page doesn't just load -- it appears.

I've made a bunch of vague references to the S3 deploy script I'm using and how to setup gzip on Amazon. In the interest of space, I've left out the specifics. If you're interested, contact me with any questions and I'll be happy to help.

Tyler Hall
Front-end Engineer

Comments (6)