Read/Write Web points to something I find both sad and a little perplexing: del.icio.us, the granddaddy of social bookmarking sites, isn't catching on. They don't really dig into why it isn't catching on. Still, it's a bit disappointing. I ran an Alexa chart and the results were even more disappointing:
Note: I always take in Alexa charts with the proverbial grain of salt.
So what gives? Why is a service that is as cool and useful as del.icio.us not able to catch on? Some theories:
I personally love del.icio.us. I think it's a great service and I don't mind taking the time to evangelize it. However, I think there is a lesson learned here: sympathize with your audience; appreciate what they don't understand (or don't care to understand); and finally...figure out what you're really going after.
It could well be argued that del.icio.us targets a niche need (bullet #1 above) and not much else. I'm skeptical of that excuse though. The needs and wants can get pretty blurry if the value is there. It's more a matter of making that value accessible. And good, thoughtful, empathetic design is the only way to get there.
After all, nobody really needs an iPod. Or do they?
Yahoo! are having their second internal developer conference this week, and they have very kindly invited a few external people to attend. As well as their London front end team, myself, Simon Willison, Natalie Downe, Glenn Jones, Matthew Somerville and a few other folks are in attendance.
First up is Simon Willison talking about Comet. Comet is essentially an old idea that has gained traction recently due to somebody giving it a name. Unlike Ajax, Comet was deliberately named after a cleaning project.
Comet applications keep a connection open and the event gets pushed to the browser. This is the reverse of Ajax clients polling the server every 5 seconds for updates. Sites like Google docs and Meebo currently use Comet. The concept first appeared in Netscape 1.1 as “server push”. The functionality still remains in modern browsers, but their is no notification when the connection is severed. Because of this, most people roll their own.
The current Comet methods are very hacky and usually use 4 or 5 different techniques to cover all the various browser quirks.Use XHR to open up a connection, and then watch for the ready state to change to indicate new data. This works in good browsers but doesn’t work properly in IE.
The other main method involves opening up an iFrame. However every time an update comes through browsers will click and the loading bar will throb. So a lot of Comet hacks involve hiding the throbbing and clicking sounds. Sane developers don’t want to deal with these issues, so it’s good that a lot of the crazy hacking has been done for you.
All these techniques work on the same domain. However you probably want to have cross-domain comet. For instance, you’re only supposed to have two connections open from a domain at the same time.
The most popular method is long polling. You open the connection, wait till something happens and receive the event. Once you’ve got the event the connection is automatically closed so you re-open the connection for the next event.
Client side Comet really sucks. However the big problem is scaling the server as it requires thousands of simultaneous connections. Apache isn’t set up to do this, so it doesn’t scale. What you need is event based IO. Instead of a thread or process per connection, you have one process that loops through hundreds of connections at a time. To do this, you probably need a separate Comet server.
Bayeaux is a protocol for Comet. Any Beueaux client can talk to a Beueaux server. Data is encoded using JSON. Essentially these servers are black boxes, so are interchangeable. Servers include Meteor and Orbited. Jetty is probably the easiest toi set up.
Despite all the crazy stuff you need, Comet apps are actually really easy to build using the Dojo library. Simon spends the next 5 minutes showing us how to build a simple Comet app.
Next up is Norm talking about coding standards. This is a rerun of the talk he did at BarCamp, so I’m sat at the back of the room, plugged into the Internets.
After a catered lunch, a few of us went to stretch our legs and grab a cuppa. On the way we dropped by the Neals Yard cheese sop so Simon and Nat could put their Christmas orders in. Think I’ll pop back at the end of the day to pick up some supplies. Over lunch we have a lively debate about a range of geekey topics. These ranged from how much better Django is than Rails, the benefits of CouchDB, and some obscure programming language used in the telecoms industry.
After lunch saw a talk on event handling and the YUI. Sadly the person giving the talk was very soft spoke, so I only caught every third word. Must move closer for the next session.
The next session is Nicole Sullivan talking about high performance web sites. I’ve been really impressed with the performance stuff Yahoo have been putting out there recently, so this should be good. In fact, Nicole works for a six person Yahoo team called “Exceptional Performance”.
Nicole starts by talking about their team make-up and the fact that they want Yahoo to be seen as a centre of good performance. In fact, one of their team has just published a book on the subject.
About 95% of user response time comes from the front end, so need to start there. This is where the biggest gains can be made, and they are usually much simpler to implement.
Nicole’s team do a lot of experiments. One of the experiments revolved around caching. They looked at the percentage of people who came in with an empty cache versus a full cache, allowing them to test download speeds. Apparently 40-60% of Yahoo users come in with an empty cache.
The next experiment was to look at parallel downloads. The results showed that having two domain aliases helped speed up response times, but any more than four would slow things down.
Yahoo have 14 rules for high performance websites. Not going to cover them all. This looks very similar to the info Nate has presented in the past.
Rule 1: Make fewer http requests by using CSS sprites and combine scripts and stylesheets. Most big sites don’t do this. Using something called the combo handler, which is unfortunately Yahoo only at the moment.
Some discussion about the ideal size of sprites and the maximum pixel size before Opera suffers a buffer overflow. One suggestion is to use rounded corner boxes with a transparent centre, allowing you to use CSS borders. Sprites aren’t always a good idea on page heavy sites as you pay the price on maintenance. Some discussion on whether you should optimise on a page/module basis or a site basis. Apparently Yahoo Europe have developed a public tool for CSS Sprites.
Rule 3: Add an expires header on images, scripts etc.
Rule 4: Gzip HTML, scripts, stylesheets, XML, JSON etc.
Rule 5: Put stylesheets at the top, as per spec. CSS at bottom is actually faster, but nothing renders. Use link, not @import, as this also appears faster.
Rule 6: Put scripts that aren’t crucial to the loading of the page at the bottom of the page to prevent them from blocking the load.
Rule 7: Avoid CSS expressions as they seem to slow the page. I stupidly thought she meant filters. Doh!
Rule 10: Minify JavaScript and CSS, but don’t obsfucate.
Rule 14: Make Ajax cachable.
Discussed Akamai as a content delivery management system. Norm mentioned Amazon.
Now a talk on PHP security. Potentially interesting, but not my domain, so won’t be taking notes.
It's no secret to regular readers that I am not a fan of HTML email. For me it gets in the way of the actual message, and, in the all-too-common scenario when an HTML email is not accompanied by a plain-text version, leads to me indiscriminately deleting email without reading it. Most of the HTML email I get is spam anyway, so I doubt I'm missing much.
Regardless of my personal feelings about HTML email, it isn't going anywhere. And so it would be good to at least enable those who insist on sending HTML email to use web standards by improving support for standards in email clients. It would help everybody if HTML emails could be built with semantic HTML and styled with external CSS. It could actually make me appreciate them.
So despite my dislike of HTML email I think it's a great step forward that The Email Standards Project has now been launched. Perhaps the most important feature of the site is the acid test for email clients, along with a list of standards support in popular clients. It is not surprising to see Lotus Notes and Outlook 2007 getting a "poor" grade, but perhaps a little more so to note that Gmail is also in need of an upgrade. Badly.
Coinciding with the launch of the Email Standards Project is the publication of Ensuring your html emails look great and get delivered, an article in which David Greiner explains what you need to do if you want your HTML email to work in current email clients. It's disheartening reading.
Even more importantly though, he talks about what you should do to ensure that the messages you are sending actually make it to their recipients without getting classified as spam. Apparently it is becoming more common for legitimate email to get caught in various spam filters. Having permission so send emails to someone is no guarantee that it will reach them.
Great initiative, and a very informative article. That said, I think I'll stick to building websites and let others deal with the massive amount of gotchas involved in email marketing.
Visit site to read or post comments…Add 456 Berea Street to your Technorati favorites.
Posted in Web Standards.

aFolio is a project that has been in the pipeline for a good couple of years, if not longer. The initial name was going to be dESIGNREPUBLIK but over time the idea evolved together with the name. aFolio stands for AdriaFolio – Adria is the Adriatic Sea region and ‘folio’ is an abbreviation of ‘portfolio’. Adria is where I’m originally from. By publishing quality content in Serbo-Croat, the local language, this site aims to raise awareness and understanding of the creative arts in the region by promoting the work of young designers, photographers and artists. There’s only a temporary sign-up page in hopefully witty and fun Serbo-Croat at the moment, but more is to come fairly soon …we’re working on it.
What's your town like? I probably know of your online home. Hell, I've probably even viewed your source, but what I don't know is what it's like where you physically live. So, tell me.
First, though, fair is fair, I'll go first. I live and work in Nottingham, New Hampshire (NH). For those who don't know where New Hampshire is, it's in "New England" -- in the northeastern part of the United States. If you still don't know where I'm talking about, here's a site all about New England and another one all about New Hampshire. Okay, now that you know, let's get back to the Town of Nottingham (map).