pet peeves with modern web design: design reboot (Part 4)

Wrapping up the series with some thoughts on two things that bug me about modern standards-based Web design / CMS:

Why is Base HREF dead?

This probably reveals just how old-school a HTML coder I am, but I can still remember the days when Base HREF was a Big Thing. Here’s an obligatory link with more details for the young whipper-snappers out there.

When I initially created a development environment locally, I had to spend a lot of time fixing broken links to images as well as cross-links between posts. As I struggled in my text editor to fix all these links, I had this bright idea “Hey! I should just use BASE HREF – that way I won’t have to fix URLs every time I move between development & the live site”.

I happily coded in a Base HREF tag using the wpurl() function and at first, everything seemed to be fine. But once I switched to viewing the site through RSS, things started to break. First, the feed would not pass validation and second, an important plugin stopped working.

A little bit of research showed that the W3C standards for XML documents allowed for a BASE entity, but further digging on Base HREF support in RSS revealed this dead end. The only way to get Base HREF in RSS it seems, is to hack the core CMS files and once I did that, there would be no easy upgrades for me.

I gave up and went back to fixing URLs by hand1, but I’m still puzzled by why such a useful feature fell out of favor with the powers-that-be.

The spread of no-follow

Ever since Google launched no-follow as a way to control link spam, it has found it’s way into all the major CMS software – WordPress, MovableType, MediaWiki etc.

I understand the purpose of having no-follow to defeat spammers, but what gets me is the fact that most CMS software today offer no way to switch this off. No-follow implemented this way really annoys me – you encourage people to contribute to the content on your site and boost your popularity, yet you do not repay the favor in any way.

A recent example – Miyagi.sg blogs about a website called Million Blog List, an experiment to see how quickly a million blogs can be found. The site asks you to:

1. Blog about adding yourself to the list

2. Add the site to your blogroll; and

3. Add a badge promoting the site.

What do you get in return you might ask? This -

mbl

I’m giving the benefit of the people behind the idea here – maybe they thought the site would link back to anyone who participated2 and have no idea that most CMS software does not by default3.

Here’s what I think – no-follow should be opt-in, not opt-out and I certainly shouldn’t have to install a plugin to fix what is considered basic good manners on the Web.

That’s the end of this little series, folks. We now return to our regularly programmed silence on this blog :-) .

  1. although I am now aware of a plugin and a technique that might make this process easier []
  2. as it seems to any human visiting the site []
  3. the alternative is quite depressing to contemplate []

The Long Road to Web Standards: Design Reboot (Part 3)

In the weeks leading up to the launch of this blog, I had a single colour in mind – a particular shade of green that proved surprisingly fickle to catch and indeed, I was envious of those who had found it.

In case you were wondering, here is that colour – w3c-green-favicon Doesn’t look that important does it? But if you are interested in web design, that colour is a holy grail – for it means a page you created is Valid XHTML. And yes, I have reached this hallowed place as well. I flaunt this badge of honour elsewhere on this blog. Several factors combined to make this journey a remarkable difficult one, but let’s start at the beginning.

When I finally decided that I needed to radically overhaul my blog, I realized I needed something to hold as a standard for each design decision – what would be the basis by which I would add or remove content? The easiest answer was Web Standards – the promise of a website that would remain usable and accessible in the years to come. That decision was quickly ratified when I realized my old blog had a staggering 91 errors – and they started right from the meta-information.

I read the books, subscribed to the right blogs and was a believer – but almost right away, the first problem appeared.

Strict XHTML is well too strict.

When you install WordPress for the first time, the default look of your blog is based on a theme called “Kubrick“. Typically your next step is to get on the WordPress Theme Browser and find a replacement because quite frankly Kubrick is boring. Once you find a theme that catches your eye, you activate a theme and everything is fine and dandy. Well not quite – you see, most themes approved by WordPress start with this line:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

See that bit that says XHTML 1.0 Strict? – that’s sort of the Greek God of Web Standards for HTML: pure and perfect. Which as it turns it out is not so great for us clumsy mortals. XHTML 1.0 Strict frowns on the use of presentational elements – for example, the fact that I used italics for the words presentational elements is frowned upon under XHTML 1.0 Strict. XHTML 1.0 Strict essentially implies that the document contains only content – the rules on how that content is to be presented are controlled through the use of CSS. So the sentence at the beginning of this part of the post?

Strict XHTML is well too strict

The HTML for that sentence goes like this:

<strong>Strict XHTML is well <u>too</u> strict.</strong>

The fact that I underlined the word “too” makes it an invalid XHTML 1.0 Strict document. Don’t believe me? Look at these two pages – Page 1, Page 2. They look identical, but Page 1 fails validation – You can verify that statement by clicking on the link that says “Check Validity” at the end of each page. So, it’s very likely that if you use a lot of formatting in your blog posts and are using a off the shelf theme, your site would fail validation.

Am I saying that XHTML 1.0 Strict doesn’t make sense? No – if a website has a lot of static content, or content that’s served progamatically, XHTML 1.0 Strict is the way to go.

For content that’s written by humans though, XHTML 1.0 Transitional makes a lot more sense. It’s a lot more forgiving that XHTML 1.0 Strict, but it still keeps you on the high road when it comes to web standards. It worries me therefore, that XHTML 1.0 Transitional is seen as a deprecated standard – future standards such as XHTML 2.0 and HTML5 are even more unforgiving. Is allowing 5 formatting elements and about 20 attributes to remain such a significant issue?

Just because it looks right, doesn’t mean it is right

Remember those two pages I had linked above as examples for the XHTML 1.0 Strict discussion and then said “They look identical, but one isn’t valid”? No? Well now that I’ve told you, you should :) . This really was the biggest source of frustration for me when trying to get my site validated – HTML as a language, and the programs that “compile it” (browsers, search engine robots etc.) are far too forgiving when it comes to errors.

Let’s look at some more example pages – shall we? This page shows a heading, then a list of items using the following bit of HTML:

   1:  <ol>
   2:  <li>
   3:  <h3>The Gnome Plan</h3>
   4:  <ul>
   5:      <li>Collect Underpants</li>
   6:      <li>???</li>
   7:      <li>Profit!</li>
   8:  </ul>
   9:  </li>
  10:  </ol>

A quick breakdown – there’s a numbered list (the ol-li code at the top), Inside this numbered list, there’s a bulleted list (the ul-li code starting from line 4). Happily, this page is Valid XHTML 1.0 Strict. Now let’s look at another chunk of code:

   1:  <ol>
   2:  <li>
   3:  <h3>The Gnome Plan</h3>
   4:  <ul>
   5:      <li>Collect Underpants</li>
   6:      <li>???</li>
   7:      <li>Profit!</li>
   8:  </ul>
   9:  </ol>

This code fails validation – catastrophically. Try validating this page for proof.

Now if you are a web designer or HTML programmer, you already know why the second chunk of code is crap. But for those of you who aren’t (like me) here’s the answer – Code Example #2 is missing the li from Code Example #1 at line 9.

But what if this example was nested inside HTML that was 200 lines long, how easy do you think it would be to spot? Even more frustrating, unlike regular programming code this bit of code would compile (display) properly! It’s enough to drive non programmers like me to drink ( as I did many times :P )

The reason for this is because browsers follow Postel’s Law, which states in part “Be Liberal in what you accept from others”. As Mark Pilgrim so beautifully demonstrates in his “Thought Experiment“, the alternative is far worse. But what if you wanted your browser to be unforgiving and point out every error you make? After all Postel’s Law also states “Be conservative in what you do”. Sadly, there is no easy way to achieve this. As John Gruber points out in this article, snippets of HTML cannot be validated as HTML is a document format (emphasis Gruber’s). In other words, you would have to build a complete document with all the nessecary header and DOCTYPE information and only then could you determine whether you have valid markup in your pages.

Browsers can give you more immediate feedback though – you see, most CMS software (and other packages) serve your document as “text/html” document and this tells the browser “Hey! Go easy on this page – it’s probably not semantic”. If on the other hand you could get your software to serve those same pages as “xhtml+xml”, any error would result in the Yellow screen of death. Unfortunately, making that change is non-trivial and so we must rely frustratingly, on writing complete pages and then hoping it works.

Getting CSS right is easy, so why do so many websites get it wrong?

The next part of Web Standards that I had to worry about was CSS Validation. This as it turns out, is relatively trivial to accomplish. CSS validation really is more about grammar than anything else – close your brackets, don’t forget the semi-colons and you’re done. Of course, one could argue that HTML validation is also grammar – closing your tags and so on. The difference is – most of the HTML content that’s generated is dynamic and constantly changing, CSS on the other hand is almost carved in stone.

That’s understandable – after all, in the world of web standards, CSS alone defines what your site looks like and how often do you change that? Sure you make tweaks here and there, but radical overhauls are few and far between. So it’s surprising then how often I see this in my browser window:

css-error

That little red exclamation mark comes from a Firefox extension called the “Web Developer Toolbar” and it’s telling me there’s a CSS error in the site I’m visiting. The usual culprit? Typing errors – forgetting a semicolon or a closing bracket, “buttom” instead of “bottom” (tee-hee) and so on. Occasionally though, I do see errors because CSS hacks for one browser (coughIEcough) make their way into the main stylesheet. When there exists a simple way to serve different stylesheets for different browsers, why would you opt for the more confusing choice? Um I do know the answer to this one.

It doesn’t end on Day One

Think it’s over because your site validated when you first launched? Ha. Have I got news for you. If you weren’t paying attention, your site is probably rife with errors by now. The culprit – code from other websites that you embed.

Case in point – Let’s say you wanted to embed a slideshow of your photos on Flickr in your blog. You go to this page, follow the instructions and the end you get a big chunk of code to put into your blog template. Plug that in and you can wave your green signal (this one – w3c-green-favicon) goodbye. The problem comes from the fact that the code that Flickr provides ships with angle brackets by default instead of the HTML entity for angle brackets (this page explains it in more detail) and since this is being embedded in the body of the page, it breaks the validation.

Moral of the story? Be careful about the code you include. As I blogged about earlier, treating your blog as a clearing-house for your online identity is probably not a good idea – from a design and standards perspective.

Can your site take a bullet?

Obviously, if someone actually tried to shoot the server where your site was hosted, bad things would happen. No, I’m taking about what happens when the people who visit your site do unexpected things – like turn off all images, or block javascript. Is your site still functional? For example, if you have white text for your navigation links on a black image background, your navigation links might disappear into the background if the visitor has blocked all images!

Or your page navigation is fancy AJAX refreshes using Javascript – what happens if the user blocks javascript? Clicking on a button does nothing!

This to me is the hardest part of the journey because you have to think of all the things that can go wrong. Thankfully, there is some help in the form of Dan Cederholm’s book. Again, the Web Developer Toolbar is of tremendous help here. No matter how much you test, the reality is that even now, there are visitors to your site who have given up because something went wrong. So it goes.

Your point being…?

Talk about something being TL;DR eh. The payoff of Web Standards is “findability”. Your content is accessible and understandable to all the visitors to your site – humans, search engine robots, site-scrapers the whole lot. I’m not advocating focussing on standards above content. Content is king yes, but if your content is buried in a mass of impenetrable markup – it may as well be 100 monkeys banging on typewriters.

PS: I know that XHTML validation for the blog fails right know, thanks to some of the embedded formatting in this post. I’m treating it as a temporary problem :) Fixed! I’ve stripped out the custom styling for the code samples for now as that was causing the problem. Custom styles will be back once the WLW plugin I’m using gets a new build that fixed these problems.

Low impact Link-blogging: Design Reboot (Part 2)

I have always had mixed feelings about linkblogging – on one hand, I read a lot and it seems natural that I would come across interesting articles that other folks might enjoy. In the back of my mind however, I think of linkblogging as slagging off from the more "real" task of writing something (semi-)coherent.

A reflection of that conflict has been how my own style of linkblogging has gone through a few iterations.

One of the very first questions I was asked shortly after I twittered about the new linkblog was simply "Why not use del.icio.us?". The answer dear reader, is that I actually was using del.icio.us for linkblogging.

It’s well hidden now, with no obvious way of getting at it, but there are over 50 posts on this blog that are just links with a little commentary – here’s the first one, and this one’s the last.

del.icio.us did seem like the answer at first – as I was browsing, I hit a button whenever I came across a link; filled in some text and by some magic it appeared on the blog.

The infatuation disappeared pretty quickly though – at first, it was just the frustration of the 255 character limit for descriptions. But on reflection, it was something deeper than that – I resented the interruption that posting to del.icio.us represented.

Skimming through the never-ending stream of info that the Web can throw at you and picking out something interesting is an art form – when you are reading north of 200 feeds as I am today, it’s pretty much a survival skill. Yet every time I found something useful, I would have to drop everything and focus on writing something meaningful about why I found this link useful – after all what use is a link without context? Do this context switch 20+ times a day and you start to feel a little ragged.

Foolhardily, I decided the answer was to hand-code a daily link dump. I would open links in individual tabs as I came across them, cull them down to a few interesting links at the end of the day and then using a combination of two firefox extensions and some Autohotkey magic, kludge together the HTML required to format the post appropriately. Not unexpectedly, this experiment didn’t last very long – I made exactly 6 linkblog-style posts using this technique before I gave up all-together.

It was only when I made the switch to RSS that I began to consider how best to start linkblogging again. My requirement was simple – I wanted a way to hit a button and share a link; no comments, no tagging, nothing. I knew right away that FeedDemon supported this through "shared clippings" but I balked at paying for a feed reader and tried to postpone the inevitable by using GreatNews.

In the end however, I switched to FeedDemon and that was when the real power of using RSS feeds for linkblogging hit me – I no longer had to provide a context. The author of each individual article had taken the time to craft an introductory paragraph that explained the article better than I ever could. If you wanted to read further, you kept scrolling or you just switched to the next article – a homage to the low-impact way in which the link itself was blogged.

Is this method without flaws? From an attention perspective – I think no, there aren’t any. I can share links with minimum effort, folks who subscribe to the linkblog feed can skim through the links easily as well.

The real problems lie in usability – HTML is being converted into RSS, back into HTML (on the blog) and finally into RSS (in the blog feed). Validation is a pipe-dream, the visual layout of the blog is often broken and some functionality simply does not work1.

The other problem is the possibility of ads slipping into the blog – I don’t have any ads running and don’t intend to either. I worry that someday, I might share an article that comes with advertising attached and make a mockery of that claim.

Is that risk worth the reward of sharing interesting ideas quickly and without friction? My answer is a cautious yes.

  1. I cannot for example, get a feed for a single category to validate and I have no way of fixing it []

Back to the Basics – Design Reboot (part 1)

I think I’ve worked out most of the kinks in moving the blog to it’s new home, so I thought I would spend a little time talking about some of the challenges and ideas behind this shift.

But first a little bit of history – I originally started blogging on a free service provided a site called myblogsite.com. Since this was a hosted service, there was tremendous restrictions placed on what you could and could not do in terms of look and feel. A few months in, the site abruptly shut down and I lost my backup of the posts1

Smarting from that loss, I did a little bit of searching and came across Weblogs. It almost was too good to be true – 2 GB storage, full wordpress hosting, FTP access; the works – and all this for free! I shamelessly begged JD for an account and he was kind enough to let me in. Obviously moving from an completely locked down service to Weblogs was like letting a kid loose in a candy store.

I wound up choosing a 3 column theme – strike 1 for visual overload. Next I installed 30-something plugins in my WordPress install – visual overload, strike 2. I then started adding all sorts of “flair” – Flickr photos, feed subscribe widgets, page ranking widgets on and on and on – visual overload, strike 3.

Now in my defence, I should say that alteast initially there was a method to this madness. I saw the blog as a “portal” to my life – a clearing-house if you will, about my online life. You could come here and find out what I was doing (hence a status page). You could look at interesting (ahem) things I had seen. Why you could even find out what the weather outside my window was!

But over time that message got a little muddied – I didn’t update the status page often enough. The blog itself wasn’t updated frequently. And my online “life” was spread far too wide to integrate in any reasonable way into this one page.

It was around this time that two things happened:

1. I actually went and bought this domain name, figuring a guy with some income and a reasonable amount of computer-savvy should really have his own website.

2. I read an article on the Coding Horror on the worst blog cliches – and realized I was guilty of more than half!

It was time to make a clean break with the past. What could I do? I knew I wouldn’t be moving away from WordPress as a platform – it was the only platform I really understood in any way. So that left the look, i.e. the theme and the feel, i.e what content was displayed on the blog.

For the look, I realized the 3 column theme simply did not make sense given the blog is not part of a network of blogs where the 3rd column might display other content. Further, 3 columns just didn’t work well with the way most people read, so it was time to switch to something simpler. A little bit of searching on WordPress Extend yielded the Web2.0 theme that I’m using now.

Reworking how content appears on the blog was two-fold: One, getting rid of the clunky HTML I had wedged into the blog as part of the “flair”2. Two, KISS – no extraneous cute stuff like widgets or geo-tagging. My plugin list would be more focused on making the back-end more useful. A plugin would either help people find content in the blog (hence, Simple Tags and Popularity Contest) or help with the flow of the post (hence WP Footnotes) or provide missing functionality (Contact Forms etc.)3

The final piece of this puzzle was making sure I actually built up the blog the right way instead of constantly editing and adding on a live install. This way, if I screwed up (and there were quite a few restarts) or changed my mind, a do-over was simply a question of restoring a backup. The answer to this came in the form of WAMP Server – which made the otherwise nightmarish process of getting Apache-MySQL-PHP running on Windows4 a simple, push-the-button affair.

There were some difficult choices along the way – for example, do I put in the Flickr photos widget or not? My stats tracking on the old blog revealed there was a decent amount of click-through from the blog to some of the photos. Why lose that traffic? The answer to that goes back to the original idea – can my blog be a portal? My own experience says no – our online lives are now too widespread, too entrenched in each of the websites we frequent to easily co-exist. It could be made to work – if you were willing to live with a page that a lot of competing visual elements. But few things are more attractive than a website that does one thing – and does it well :-) .

  1. though a partial version can still be found on Bloglines []
  2. A difficult and educational experience as it turned out, and the subject of the next post in the series []
  3. I remember reading somewhere that a lot of programmers think parenthetically – which comes out a lot when they write :-) []
  4. The instructions for getting Apache running on Windows on the Apache site just don’t work []

del.icio.us redesign

It looks like del.icio.us has gone through a small redesign – the top header is now a gray background and the fonts for the entire site have changed (looks like a common serif font, but I can’t place it).

I personally think the new look is easier on the eyes.

PS: Edit – My bad. The new look was actually on account of the greasemonkey script I’m using – del.icio.us prettifier. Though irritatingly, it’s not working today. Updated the technorati tags as well