Category Archives: Design

Web design, typography, user experience, and visual aesthetics.

News.com Leads Blog Communication

Design, Microsoft, Spam,

This is the coolest thing I’ve seen all year. Check out the HTML of this article I linked a few days ago. Notice anything at the top?

<link rel="pingback" href="http://tb.news.com/p2t.cgi/2100-1032-5368454" />

Houston, we have Pingback support! Let’s dig deeper:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
<rdf:Description
rdf:about="http://news.com.com/2100-1032-5368454.html"
dc:title="Microsoft flip-flop may signal blog clog"
dc:identifier="http://news.com.com/2100-1032-5368454.html" />
trackback:ping="http://tb.news.com/tb.cgi/2100-1032-5368454"
</rdf:RDF>

Ugly as sin, but that’s trackback. It gets better…

A little URI hacking takes us to this page which lists all trackbacks and pingbacks the article recieved. How cool is that?

It’s my understanding that even though they’ve had the trackback autodiscovery code for a while they’ve been recieving mostly pingbacks, which makes sense given that it’s more fully and elegantly automatic. It would be cool if they could add support for the nascent rel="trackback" discovery method and save themselves the trouble of the RDF hack. Hopefully spammers won’t exploit their trackback server too soon and they can support legacy systems that don’t implement Pingback yet.

The implications of this are fairly large. News.com is obviously bootstrapping code that will involve their readers with the blog conversation surrounding their articles. How long for other sites to catch up? Will they plug into Technorati or Pubsub next? As far as I know this is the first major media organization to implement Trackback and Pingback. The team at News.com should be commended for their effort and leadership in this area.

RSS Bandwidth Usage

Design, Music

Robert Scoble looks at RSS bandwidth usage but unfortunately doesn’t give real numbers. There are a couple of important points in looking at HTML vs. RSS bandwidth usage, some brought up in his comments but I’ll review here:

  1. RSS is not a transport mechanism, and these problems should be handled on the HTTP level. This is faster, better tested, works with caches and proxies, et cetera.
  2. I don’t care if an aggregator checks my feed every 5 minutes, if they support HTTP properly (last-modified headers) the load is neglible for me and them. The bandwidth used each time is around 250 bytes.
  3. Speaking of HTTP, gzip encoding works just as well for RSS feeds.
  4. Bloated HTML in full content feeds will make for bloated feeds. We’ve upped our standards, up yours.
  5. Adjust your number of items to match your posting schedule. If you update two or three times a week, you don’t need 20 items in your news feed, try five. If you update a lot like myself or Robert you run the opposite risk: people who don’t check your feed for a while might actually miss content. I talked to aggregator developers a few months ago about a way to address this, perhaps we need to look at this again.
  6. A visit to a homepage like this generates a lot of requests. First you get the HTML, then your browser requests the CSS files, then it gets all the images, probably about a dozen of them. RSS is generally a single request, and then images embedded in posts may be requested later if that entry is viewed.

That out of the way, how about some real numbers? I can give the best stats for photomatt.net because my RSS feed is on a separate subdomain. Here’s bandwidth usage for August:

photomatt.net – HTML and images, et cetera
56.0 GB
xml.photomatt.net – RSS and other variants
1.7 GB

The ratio for July was similar, 77.6/2.0 GB, I guess I lost some readers in the summer slowdown.

My front page is an average of 17K HTML and about 30K of images, so lets say 50K. The images and CSS are all cached, but I don’t output the proper headers on the HTML because it would be a pain. I would have to check the time of the latest post, check the latest updated link, make sure there’s not a random photo, basically go through a lot of trouble that isn’t really worth it. (When I was caching everything with Staticize the page was stored in its entirety so I sent correct headers, but I don’t bother with that anymore because everything is so fast it doesn’t really make a difference.) All that said, I’m happy with the level of optimization, my HTML and CSS is as streamlined as I want it to be.

My feed, on the other hand, is completely self-contained. I can send headers with confidence because I know everything in that file and can say authoritively when it was last changed. (Actually WordPress handles it all automatically, I don’t worry about it.) Most of the aggregators that hit my site support this. I don’t think about it and they don’t think about it, HTTP just works. My feed has 25 items because of my posting frequency, more than twice the number of items most feeds have. The feed is usually around 10K, and as I already mentioned it’s only one request.

Here’s the kicker: my RSS feed is requested 3 times for every time my front page is loaded. So a HTML page with 1/3 the traffic is using over 30 times the bandwidth. What was that about scalability again?

The Trouble With WordPress

Design, Ideas, WordPress

Recently it leaked on a blog (there are few secrets in Open Source) that elements from a design known as “Kubrick” by Michael Heilemann would be incorporated into the default template for the next version of WordPress. Kubrick is many things: a design, a set of templates, some plugins, and a removal of a lot of cruft currently in the default template. It makes things much friendlier for readers. Best of all Michael released everything under the GPL and submitted it to WordPress for inclusion. After it had had several iterations I checked it out and saw a lot of great ideas that would make WordPress a better product, especially for new users. Even though no decisions had been made and no code had been committed, a number of questions were raised in people’s minds. A thread was started in the forums that I’m not even going to link to because it’s not worth reading past the first page, if that. Many people seemed to misunderstand what was going to be incorporated and what wasn’t, even though that was stated pretty clearly in the original blog post.

Michael is primarily a designer, not a coder, and coding things in a way that works on the variety of platforms and setups that WordPress itself does is hard, so there are issues with that in the templates Michael has released. WordPress devs have a lot of experience with those issues, however, and anything added to the core will work just as well (if not better) than WordPress does now. Several others questioned the inclusion of graphics in a template. If graphics were included, how would people be able to edit it? We can’t expect people to have graphics editors, so if graphics are included in the final template (that hasn’t been determined yet) I’ve committed to providing an online interface on wordpress.org for people to customize the graphics to match their color choices without needing any software beyond a web browser. There were some questions about the CSS being used in Kubrick, but the CSS used for it in WordPress won’t be the same and will be treated like any change to the WordPress code, that is it will go through the normal QA process and be tested across platforms by the developers and the few dozen or so people who keep up with the nightly builds, and then extensively tested by the hundreds that use the beta releases once we enter that phase for 1.3. Any problems will be treated as bugs and fixed as such. Watching trends on the forums and continuing a high level of support is very important to everyone.

The problem was after all this was explained the thread continued long after all these questions had been answered with everyone talking past each other. If it shows anything it’s that people can be very passionate about the smallest of things. It’s interesting to note that while this all was occuring what has actually happened in WordPress development in the last week: Dougal wrote a plugin to slow down spambots, literally; Alex made a new style for the styles page; Kitten sent in another comment moderation plugin that’s going to be included in the core; Craig Hartel and Kevin Francis (amoung many others) did some great work on the new wiki; Michel is refactoring the XML-RPC code; we started the process of moving to a better source control system; Ryan is coding too much cool stuff to mention, but the next version of WP be the easiest to customize and template ever. That’s just off the top of my head, there’s lots of other exciting developments happening.

In other words, life moved on. It showed up on a few blogs, but that’s a price of popularity: bad news gets more buzz than good. Numerous examples are in the checkout line of every supermarket. (Not to mention the blogosphere.)

So what’s the state of the WordPress community today? I’d say it’s better. The number of people who actually got out-of-hand was only a handful, and personally I’m ready to apologize and move on. I’ve never been good at holding grudges. The things that make the WordPress community great haven’t changed, and several lessons have been learned. Hundreds of new WordPress blogs have been started, testimonials and donations keep coming in, I’ve noticed more people helping out on the forums, and best of all there’s a healthy amount of disagreement keeping the project young.

Search Engine Markshowdown

Design, Google, Search, Software, Web Standards, Yahoo

I decided to run the web page analyzer (excellent tool) against the front pages of a few of the latest and greatest search engines and also do a little analysis of my own. Here are some of the results in one of the only tables you’ll ever see on this site:

  Feedster Technorati Google Yahoo Search
HTML 6.11 3.72 1.18 7.82
Ext. CSS 11.47 11.63 0 1.45
Other 9.10 6.70 15.10 1.72
Total 26.70 22.05 16.27 11.00
Compressed No No Yes No

Numbers are kilobytes, and may not add up exactly due to rounding. CSS is external, linked files. “Other” includes images and javascript.

Yahoo was the surprise winner here. Their HTML was alright but I think could be reduced quite a bit without losing anything. You’ll note they have the heaviest HTML of the bunch, heavier than other sites showing quite a bit more on their front page. They should probably talk to Doug. Overall though I think Yahoo has consistently been doing great nearly-standards-compliant work in their new designs. Yahoo could save about 67% of their HTML size with compression. Interestingly, Yahoo was the only site to specify ISO-8859-1 encoding, all the others claimed UTF-8.

Google was optimized to the hilt, but it’s kind of silly that they put so much effort into their markup but couldn’t go the last inch and make it valid HTML 4. They could probably make it a bit smaller with some more intelligent CSS usage. At least they don’t have font tags anymore. I think under normal circumstances they would have won but they have an olympic logo right now that’s pretty heavy. Google was the only site that used gzip compression for their HTML, but even uncompressed they only weighed in at about 2.4 kilobytes, still the lightest of the group.

Technorati clearly had the smartest markup of the group, and was the only one that validated. (An impressive feat for any website in this day and age.) Their markup is clean as a whistle with excellent structure and logic, and their numbers aren’t bad when you consider that they have a lot of stuff on their front page. This isn’t too surprising since Tantek did it. Their CSS, however, is pretty heavy. It’s strange because it’s very optimized in some ways but bloated in others, I think they could cut a few K from it pretty easily. One smart thing they did is have the CSS named with the date, so it’s name versioned and they can update it monthly without caching issues. All that said, they’re so far ahead of everything else they don’t need to worry about much. Technorati could save about 53% of their XHTML size with compression.

Feedster has its heart in the right place, but the implementation falls far short. For example it has a XHTML 1.1 doctype but then has the needless XML declaration at the top throwing IE into quirks mode. They use CSS in places, but then they have a table with 75 non-breaking spaces in it for positioning. There’s a ton needless markup, including a full kilobyte of HTML comments. On the bright side, they have the most room to improve. Feedster could save about 61% of their XHTML size with compression.

Zoto

Apple, Design, Linux, Open Source, WordPress

Zoto looks pretty neat. I signed up earlier and also set up an account for my Mom. But why isn’t WordPress a “supported blog”? Only a 136 users so far as I write this. Go sign up and try it out. They’ve done some interesting things with the interface and they have an open source photo client available for Windows, OS X, and Linux. I couldn’t get the Linux client working on my Mom’s computer, had no trouble at home on Gentoo though. I think it was an old version of Python.

I uploaded a few not-yet-on-the-photolog photos to my Zoto page to get the party started. (The fact that some of those are from Christmas and New Year’s means I really need to catch up.)