No street signs. No crosswalks. No accidents. A fantastic Wired article about how removing the artificial safety nets we set up for ourself actually makes us safer. The illusion of safety is a very dangerous thing. This is totally applicable to software design too. If you put up a big notice saying “Don’t do this” people won’t read it, you have to design the interaction to encourage people in the right direction.

The Best and Brightest, Glamorous Life #33. Who says Zeldman gets linked less?

Zeldman has had a profound influence on the way I think about the web. I started taking web craft seriously because of Zeldman. WordPress exists because of Zeldman. I am where I am today because of Jeffrey Zeldman. This isn’t hyperbole, just statement of fact.

I think now is an excellent time for people to take a walk through his archives and highlight their favorite articles, something I’ll do myself at least once a day every day this week. If you’re doing something similar leave a comment so I can follow along. It’ll be interesting to see what people were most influenced by from one of the most influential fathers of today’s web.

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?

I’ve ripped out the guts and redone the search on the WordPress.org support forums in the hopes of making it something more people will use. Try it out! The new system searches the wiki (hosted on a different machine), thread titles, recent posts, and does a FULLTEXT post search for the most relevant posts. It has contextual search highlighting (like Google).

When I have some time to get back to this every section will have a “more of this” link to take you to more results (paged). It does this currently with the wiki search, counting the total results and linking to the wiki search directly if there are more than 5 results. Probably still a few bugs to work out. The fulltext query was taking over two seconds to run until I tweaked the JOIN type to get the MySQL optimizer to use the proper index and join order. Everything should validate as XHTML.

A new system is also in place to inject custom results at the top of the page. We’ve been logging searches for the last few months (over a 129,000 so far, about 43,000 unique searches) and I’m going to be working closely with the documentation team to identify which searches are most common and what tailored information would be best to present the user with when they search for targetted terms, be it a blog post, an external resource, someplace on WordPress.org itself, a wiki page, or a specific thread. We can watch trends and spikes in searches to identify any problems in the application itself or features that may be insufficently documented or hard to use.

The work is far from finished, but I think it’s a strong first step into fully integrating search as a support mechanism and bringing the WordPress team even closer to the pulse of the users.

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.)

Version 2.5 of the Staticize Reloaded plugin is now available for download. Installation instructions are included in the archive. What does Staticize Reloaded do? It is a highly advanced caching engine that dynamically and automatically caches pages on your site that need to be cached, when they need to be cached. It also allows for some parts of a page to be cached and others not to be, so for example your menu could always be dynamically included from a single file while your main blog content was cached. With Staticize Reloaded you don’t have to worry about rebuilding, stale caches, slow posting times, or any of that. It works silently, efficiently, and trasparently to both the end user and the author.

This version adds the ability to have dynamic functions on a page in addition to dynamic includes. It also adds full support for etags and last modified headers, though you must turn it on in the plugin file. My one tip is that when you redesign or tweak your template temporarily deactivate the plugin. Staticize Reloaded is well-suited for sites on older servers or that receive more than twenty thousand visitors per day. WordPress is so fast anyway I find it’s not worth caching on lower-traffic sites.

Update: The zip archive had a slightly older version of the plugin than the final 2.5 release. Please re-download to get the latest and greatest and fastest.

In Joining the Dark Side -OR- Is Mac IE 5 Support Worth $1,500, Scott responds to Tantek’s calling out of the new Feedster’s lack of support for Mac IE. Personally I’m sympathetic to Feedster’s case because I’ve had to spend hours talking to someone with a Mac trying to debug Mac IE issues with this site and wordpress.org and ended up having to change my favorite list menu technique from using floats to display: inline, which meant changing all the other menu styles to compensate. It was a pain.

I know that when I’m tweaking and checking things in different browsers, the number of my audience who uses that browser isn’t always the most important thing. In the previous case the only Mac IE I had heard anything from since both of the sites started was Tantek, and that was important enough to spend a couple hours of my time on. Imagine if you’re doing a job and the client’s boss uses Netscape 4, (god help you and) suddenly that browser becomes much more important in your testing, and you should triple your rate.

However, is this something the Web Standards Project should be interested in the same way we have been All Music or Odeon? I don’t speak for anyone but myself, but in my opinion it’s not the same at all. Feedster’s pages are a few trivial mistakes away from valid XHTML 1.1 and valid CSS, which is no easy task. (MIME issues aside.) Of course they should fix those mistakes, but it is a matter of a few minutes rather than 1-1.5 days. They aren’t writing to one browser or propietary technologies, they’re writing to modern standards and excluding browsers that have serious flaws in that area. Is that so different from the browser upgrade campaign?

From a user experience point of view, excluding Mac IE users might be a good idea as well. If Feedster allowed Mac IE users to visit and they saw a messed up layout (or no layout at all), as Tantek has suggested, then their perception of the Feedster brand, reliability, and image would be negative. I bet Keith would have some great thoughts on this. If they’re given a message that the site doesn’t support Mac IE, (honestly) they’ve probably seen this before and will just switch to another browser for that site. In my experience Mac users tend to be total browser flirts, and have every browser you’ve ever heard of installed. I would rather they open up my site in Safari or Firefox.

If Tantek was here I imagine he would counter that those browser options are really only valid for users on OS X, and that ignores hundreds of iMacs and such in libraries and such. Of course the question that a site owner needs to ask himself then is that in terms of costs and benefits, does that half of a single percent audience in libraries on older computers overlap with the audience you’re targetting with your site? If I was doing an ecommerce selling something like BMW accessories, I wouldn’t even give it a second thought. This isn’t about the many innovations that Mac IE introduced or its excellent standards support for its time, the issue is where Mac IE stands today.

On the bright side, Feedster has characterized this as a business cost/benefit decision and said if anyone sends them Mac IE CSS they’ll use it, which seems like a good concession. Of course I think Feedster should support Mac IE, and a day and a half to add support seems a little high, but if they choose not to I can understand.

I’m doing some code cleanup around here, and I came to a line in my <head> that is soley to work around an Internet Explorer feature I don’t want on my site.

Here is the standard way to remove it:

<meta http-equiv="imagetoolbar" content="no" />

Since the http-equiv attribute is meant to be simply a document-level replacement for real HTTP headers, and I have the ability to send out real HTTP headers, I decided to try out removing this line and replacing it with this bit of PHP, which according to the spec is functionally equivilent:

<?php header ('imagetoolbar: no'); ?>

Looks funky, but according to the HTTP 1.1 specification user agents should ignore headers they don’t recognize, so there’s no harm. However in my testing I was disappointed (though not terribly surprised) to find that Internet Explorer did not respect the header. I have trimmed other parts of my markup quite a bit though, and I’m willing to sacrifice this one line.

Now I’m seeing the Googlebot request /about/ pages relative to known blogs that don’t have any links to any /about/ URI. The last time the Googlebot flailed around like this it was fun to watch for a little bit and wonder what they had cooking in the labs, but then it got annoying. I don’t know if there are rules of bot etiquette, but requesting imagined unlinked resources while spidering can’t be a best practice.

There is of course one blog vendor who consistently has about pages at /about/ URIs, and that’s Typepad. Now my question Google is: what should the rest of us do if we want our about pages indexed by this new system? Mine happens to be in the about subdirectory of my blog, but what about people who have about.html or about-me.php? Should I set up a permanent redirect for every blog I have redirecting to the real about page?

(Note: That’s faux indignation. I don’t have any juicy conspiracy theories, and I’m not really that peeved, mostly I’m just curious what they’re up to. However juicy conspiracy theories are welcome in the comments. [As long as they don’t make fun of me for noticing these things.] )

UPDATE: It just requested a non-existent non-linked /contact/ URI.

UPDATE: It just requested a non-existent non-linked /stats/ URI.

DEVELOPING . . .

Loïc Le Meur Blog: MT and WordPress meet :=) I didn’t get to see Loïc again on Friday like we originally planned, but in the short time we met I got a good impression. People assume that behind the scenes we’re all at each other’s throats, that it’s all WordPress vs. MT vs. Drupal vs. TextPattern vs. Blogger vs. whatever, but it’s actually the opposite. Though there may be some professional differences (you say po-tah-to, I say PHP) everyone is genuinely friendly. Behind the tools are normal people, not super-villians. While meeting with a large potential WordPress user I suggested they also check out Typepad and Blogware because I’ve personally used each and they seem like solid platforms worthy of investigation. I hung out with Anil half of the days I was in San Francisco. Life is too short to waste karma on blogging, and while I get as passionate about the issues as anyone, at the end of the day we’re all contributing something positive to the medium. Of course, Mingus would say “They’re singing your praises while stealing your phrases.”

The caching plugin I pointed to the other day was very well-executed but it didn’t meet my needs for several reasons, mainly that it cached every bit of output, which wouldn’t be appropiate for things like my random photo. (Or my non-rotating photo formerly known as the random photo in the header. It’s on break right now.) My site is a pretty neat system of PHP includes, and I want to preserve that because it makes my life easy and doesn’t slow anything down any perceptable amount.

So I took the Staticize plugin and added support for dynamic non-cached sections, cleaned up the code a bit, fixed a weird problem where it would just show a blank page if it couldn’t write the file, fixed the problem with edit links and the comment form, and made it fit with the WordPress code a little smoother. Full instructions are included with the plugin, but to install just make sure your wp-content folder is writable (you may have already done that when setting up WP) and activate the plugin, and it will start working immediately.

I have a couple more improvements in mind for it already, but it’s fully functional and I’m running it right now.

Download Staticize Reloaded 2.0.

So it wasn’t even the first day of the bug tracker’s existence when bug notes got rowdy and prompted Shelley to write a post lamenting WordPress developer communication and more. I started to write a reply in the comments, but it got pretty long so I decided to post it here.

Shelley: Different people particpate with the development process at different levels. While I appreciate the point you were trying to communicate, it seems like an inappropiate place to role play a clueless user. (Particularly posting under your own account.) Ryan and I fully realize that the reply would mean very little to someone who didn’t know PHP or diff, but it was a dialogue between you—Shelley Powers the bug reporter who has written several advanced hacks and plugins for WordPress—and a developer who wants to address the problem. Someone else probably would have been treated differently. In the past you have been very indignant when someone assumed you didn’t know something and addressed you at a level you deemed patronizing. In that situation, how is anybunny supposed to respond?

It’s silly for it to come up in the first place. Communication is much more than 50% of successful application, it’s 100% essential because without it the code doesn’t really matter. The project falls in the forest without making any sound. However the bug tracker doesn’t seem like the best place to make this point. If you really feel strongly about this, why not write some guidelines or best practices in the wiki and send a note to the documentation list.

There a thread on the forums which addresses some of this.

The Standards Police, I think Keith is totally off here, as I began to express in Dave’s comments. A laissez-faire approach to compliance isn’t helping anyone. Someone needs to set an example, and if it’s not these guys who will? Jeffrey and Doug, each with no small amount of content on their site, seem to have no problem keeping things compliant. Neither does Eric, Tantek, Joe, Lars, Anne, Mark, just to name a few. Don’t tell me “validation is very hard and takes quite a bit of effort.” That’s a weak cop-out. Accessibility is very hard, design is very hard, music is very hard, driving in between the lines is very hard. If you don’t want to make the effort, then don’t dabble and make flippant comments that hurt the field as a whole and insult the people who work “very hard.”

I’m coming out. This site is to the best of my ability valid XHTML 1.1 sent with the proper MIME to browser that can handle it. Even the photolog, which took me hours and hours of work to get to the point where it is now, and for a long time was far from decent markup. However I am fairly certain that there are some comments (particularly on the mosaic thread, which now has almost a thousand replies) that have broken validation, and though I am very busy I will personally check each of these. WordPress helps a lot. The WordPress site is also XHTML 1.1 with the exception of the forums, which are compliant by default (more hours of work) but which could do a much better job of validation input. These are my weaknesses, out for the world to see. Even though the sites work just fine, and “validation doesn’t pay the bills,” I’m going to devote my time to fixing these problems because how can I presume to be a member of an organization devoted to standards without following them myself?

Update: Pulled and republished.