This afternoon I was asked by a friend what I would recommend to an old designer who wants to learn more about web standards, CSS, XML, and XHTML.
This is a perfect example of when an email response is better posted here for a wider audience (and Google). So here's my answer: this is a comprehensive, informal, and somewhat long-winded roadmap for anyone who has heard about web standards, thinks they might want web standards, but doesn't know where to start.Stop! Before you do anything, the most important thing you can do for your learning process is accept that a) it's going to take time, and b) you will be frustrated along the way. But you're not alone. Plenty of us who have taken the plunge into standards went through the same, and there is a growing body of work devoted to helping make your life easier. The old-timers had to figure out the hard way all the tricks and techniques we now take for granted; lucky folks who came in later (myself included) can benefit from their sweat and tears. In the end, when your skill using standard-based design eclipses your skill using old-school table-based methods, you'll look back and marvel at how much more sense it makes to layout a page with CSS. Oh sure, the actual methods used might not make much sense (considering there are better options in the CSS2 spec than what we currently use) but we have a major browser manufacturer to blame for their lack of support. Uh, I seem to have wandered. Sorry, that's another thing you'll have to get used to: unbridled hostility against Internet Explorer. It'll take some experience to understand why, but you'll know exactly what we mean in short order. So. On to the practical information you can start using immediately. First, run and buy Designing With Web Standards . Don't even think about it, just do it. Got it? Good, now don't let it collect dust—read it. Everything I'm about to cover is detailed in DWWS. It's equal parts manifesto (WHY would you want to do this?) and tutorial (HOW do you do this?). You need it. Now. The first thing to do is get into an XHTML mindset. Whether you choose HTML 4.01 or XHTML 1.0 Strict (there are reasons to go with either; ignore them for now, and then ignore them even more, until you're ready for some mind-numbing drudgery), it all begins with a DOCTYPE . Telling a browser which language your document is marked up with isn't only a good idea, it prevents unwanted rendering glitches that will otherwise drive you crazy. Think of it like this: if I want to fly to Chicago, I have to tell my travel agent of choice where I want to go. Sure, it might be fun to take my chances and see where I end up, but it's not exactly practical. Setting a DOCTYPE ensures I get to my destination of choice without unintended side-trips to Vienna. Next goal: well-formed markup. This is pretty easy to grasp, actually. Always quote your attributes (ie. <a href="link"> , and <input type="text" /> ). Don't improperly nest tags; close them in the order you opened them. And if you open a tag, close it again; every tag, or element, requires an opening and a closing correspondent. A quick diversion here: somewhere along the way, tags became 'elements'. Same syntax, different theory. Call them what you will, the proper label is now element; maybe it always has been. I don't know. No one ever explained this to me. So anyway, each element needs to be closed properly. If you're using HTML 4.01, this doesn't include stand-alones like <br> , <hr> , and <input> . With XHTML, it does. There's a hack-ish, but practical syntax that degrades gracefully in older browsers: just add a space and a slash to the end. <br> becomes <br /> , for example. Now there's one more little confusing thing about XHTML attributes: they always need to have a value, even when that value doesn't make sense. Example: <input type="radio" checked="checked" /> . You can get away with just checked in HTML 4.01, but XHTML needs the redundancy. Finally, XHTML requires all your code to be in lowercase. HTML doesn't differentiate, but XHTML uses XML syntax, which is case-sensitive. And the case ends up being lower. That's it for markup! You're done! Take a breather, grab a cerveza, and chill out for the afternoon. Because that's only step number one. Now that we've got you writing proper HTML/XHTML, try running it through the W3's validator . If you've crossed your i's and dotted your t's (or in this case, quoted your attributes and nested your elements) you'll achieve a nice yellow-on-blue success message. Learn to love this colour/text combination, it can be your best friend. Why is validating important, or even relevant? Because poorly-written markup is completely unpredictable; you end up relying on a browser's error-handling, and even though most browsers are very good about this, it's a bad practice to rely on it. Hey, it's what got us into the non-standard, proprietary browser wars in the first place. (Microsoft was able to compete with Netscape in the Netscape-dominated world of 1995 because IE was built to handle errors exactly the same as Netscape.) The single point is, validating helps you spot errors in your code, which in turn ensures more consistent rendering of your page. The very first technique I try when debugging problematic layouts is validating my code. You should too. Yeah, okay, it's tough when you first validate your first site and get back a list of 78 arcane errors. Unfortunately, though the validator helps, it's not perfect. It's run by volunteers who are doing their best, but sometimes the error messages are as helpful as Vogon poetry. The good news is that problems cascade, and if you can find one missing </p> tag, for example, a lot of the time you bump that number down to 24 errors without doing anything else. The short of it: it looks bad, but it's often not. Now that you're validating, you're following the letter of the law. But as with many real-world laws, at this point you're adhering to only the rigid guidelines of the rules and missing the bigger picture about why those guidelines are there in the first place. The next step is to take this well-formed markup structure you've built for your document, strip out the presentational attributes that have been deprecated in some of the more recent DOCTYPES, and move the presentation into a completely separate file. This is the infamous separation of structure and presentation, and this is where CSS comes into the picture. It's like this: your text is content. Content is nice, but without any hints about the content's structure (which includes things like spaces and headers and lists) you end up with a jumbled mess of text. Completely unusable. Structure is an extra layer which breaks down that messy text into logical groupings and organizes them in a way that conveys extra information about individual elements in that document. How that information looks may be implied by the structure (for example, you'll most often find that a primary page heading will be larger than the body text) but it doesn't dictate it any further. That's where presentation comes in. Presentation is the formatting cue that tells the primary page header to be red, italicized, and 150% of the body copy's size. Presentation is an extra layer of information on top of a document's structure, that builds up the (non-visual) structure into something far more appealing to the eye. CSS is the presentational layer, and it can take a very simpy marked up document, and turn it into something amazing—view the css Zen Garden for a live demonstration of this in action. So what's the best way to start separating your presentation out of your structure? Consider any HTML element or attribute that offers a visual cue to be an offending piece of legacy code. It's time to start killing those bgcolor s and <center> tags. Here's a pop quiz: In each of the following examples, which attributes and tags would you remove to eliminate all traces of presentational structure? <center><h1><font face="Verdana">This is my first web site.</font></h1></center> <table border="0" cellpadding="0" cellspacing="0"> <body bgcolor="#ffffff" topmargin="0" leftmargin="0" marginwidth="0" marginheight="0"> <td bgcolor="#ffffff" valign="top" align="center"><p>They're coming to take me away...</p></td> Got your answers ready? Great, compare to the list below. These are proper structural elements without a trace of structural formatting: <h1>This is my first web site.</h1> <table> <body> <td><p>They're coming to take me away...</p></td> That's it? That's it. While it's not explicitly stated in any spec, a further goal of this separation is to use the proper elements for the job. Using a table to layout a page is then, by this definition, an improper use of a table. In the above example, it might have even been prudent to go further and remove the <table> and <td> elements, but it's hard to say without surrounding context. Tables aren't deprecated; they can still be quite useful. But they should be used properly—to contain data that's structurally tabular. So we've stripped the formatting from our page. Hooray. What now? Those are some ugly elements, all Times-New-Romaned and linear. Where's the interest? Where's the compelling visuals we were promised? Head back to the Zen Garden example. See the lovely designs? See how different they are? The key here is that underneath each is the same XHTML, just as bland as your currently-unformatted document. No really, it is . Having a bland and ugly base is a good thing, in fact. What you may have noticed is that this unformatted HTML looks an awful lot like the web of 1994 (if you were around back then). In fact, with a few notable exceptions, that's what it is. This stuff is as old as the web itself. <h2> 's have been around since the days of Mosaic. Which, as you may have guessed by now, will still handle a properly-structured page with surprising fidelity. Try saying that about a late-90's table-fest. The benefits don't end there of course. Accessibility to those with special needs is almost free, search engine optimization is built-in, bandwidth costs go way down (along with development times), and on and on and on. Jeffrey Veen wrote up the Business Value of Web Standards late last year, and Roger Johansson expanded on the benefits and techniques of standards-based design with his recent Developing With Web Standards . CSS is well-supported across all the major browsers today, and there are countless resources for learning the syntax, the basics of CSS layout, and the advanced theory behind high-impact CSS-based design. I'll point you to a few of the better ones: WestCiv offers an ongoing, free CSS course that will help you get started and bring you up to speed in a hurry. Andrew Fernandez has indexed a huge listing of CSS resources that should help you no matter where your skill level is. Eric Meyer has written a bunch of books that you should have on your desk, including the project-based Eric Meyer on CSS and its follow-up More Eric Meyer on CSS (no, really, that's what it's called). His O'Reilly-published reference CSS: The Definitive Guide is in its second edition, and should be on your desk. Also check out Molly Holzschlag's CSS: The Designer's Edge , and Chris Schmitt's Designing CSS Web Pages . Going into the ins and outs of applying CSS and building layouts could take me many times the space I've already used up so far and some financial motivation. We'll cut it short here, considering it's taken a Herculean effort on your part to even get this far... Getting plugged in is probably the single biggest piece of advice I can give anyone looking to get a start with web standards. Through ongoing reading and sharing of what you know, we all grow as a community. There are many of us active in the development community, and there are bound to be many more times coming on board over the next few years. We have a global communication network at our disposal; make sure to use it. And if nothing else, we're here to commiserate when you hit the wall. Hey, it happens to all of us. ]]>
Which brings our household data capacity to a quarter of a terabyte. I've long claimed that 5 petabytes is all I'll ever need, for life. Which provokes bemused expressions on the faces of those around me. No one ever seems to factor in the increasing demand for storage...
My own personal storage history, distributed across drives and systems:
- 1988 - 1994: dual 360k floppies, no hard drive.
- 1994 - 1995: 40MB
- 1995 - 1998: 850MB
- 1998 - 2000: 4,000MB
- 2000 - 2001: 30,000MB
- 2001 - 2003: 70,000MB
- 2003 - 2004: 100,000MB
- 2004: 270,000MB
5 petabytes. It's all I ask.
Fantastic new business model: start a company, but don't bother producing anything. This is the Age of the Lawsuit! Acquire another company's intellectual property and sue the pants off of anyone else using code that even faintly smells of your new patents.
In a lawsuit strikingly reminiscent to the current SCO flap, the JPEG image format is under attack by a 300-person strong scheduling software developer (not that suitability or appropriateness would ever come into play in a patent dispute).
Forgent Networks of Austin, TX announced it was suing 31 major hardware and software vendors, including the likes of Canon, Apple, Adobe and HP. Mentioned in the article but not underlined in big red letters is the fact that since they've started 'licensing' this patent in 2002, over 30 companies have deemed it enough of a threat to pony up a combined $90 million.
Of course, this isn't the first time a popular image format has come under fire. The GIF format was built on top of a patent owned by Unisys, who promised they'd never actually take advantage of that for profit, and naturally went back on their word when it looked like they needed the money.
What does this new dispute mean for us, the users and consumers of JPEG? It's too early to say. If the large companies named in the lawsuit pony up a settlement, what's to stop Forgent from coming after individual users with a new-money afterglow? If the large companies named in the lawsuit fight it and win, what's to stop Forgent from coming after individual users in embittered retaliation? There are a lot of variables here which can go in many different ways, so the only sure thing is that this is one to watch.
After spending weeks on end coding around the quirky demands of today's browser space, occasionally it's nice to design for a completely controlled environment.
Mac OS X is proving more and more useful the further I dig in, and lately I've been playing with the built-in web server. Apache and PHP come pre-installed, you just have to turn them on.
I'm running my localhost web server from 'Diemos', the secondary partition that also stores my project files. Setting up aliases is proving useful, so that while my directory structure looks something like this:
- Projects |- Bright |- web |- mezzoblue |- (Other Projects) - www |- bombay |- delhi |- wiki |- zen - (Other Directories)
…I can point virtual directories outside of the 'www' directory, which serves as my root. So throwing all my Bright Creative .php files in
/Diemos/Bright/web/ is accessible as
http://localhost/bright/. Next step: virtual subdomains so I don't need to keep setting a root addess variable in PHP.
Anyway. The point of all this is that I put together a very basic page to serve as my test site's root index. My primary browser is Safari, so I took the opportunity to play with the new
text-shadow CSS property. (Hit the thumbnail link if you're not using Safari). Combining this with a bit of
opacity (upcoming in CSS3, supported now) a bit of generated content, and some guaranteed, non-standard font choices, I've caught a glimpse of where CSS is going. I like it. A lot.
No images were harmed in the making of this page, it's all pure CSS effects. Here's to 2011, when we might even be able to use this stuff.
There's nothing so tragically interesting as somebody else's train wreck. Cameron Moll asks, "how did you start out?"
Hey, we've all got skeletons. Time to pull 'em out! I present to you, not the first, but one of the first web sites I did for actual money, back in late 1998 (through early 1999): AESP.
It never went live, though I collected a cheque. Comments are open, flood me with your precious eyesores.
I'd better leave this on here for the night so I don't wake up to a deluge of email tomorrow morning. The Zen Garden has been down all day, as has been well reported by now.
A whois comes back saying that the domain csszengarden.com expires today, April 18th 2004. Horribly bad timing, that. I renewed two weeks ago, and while the DNS doesn't appear to have updated, rest assured my credit card has been debited and it's still well within my possession.
The actual reason it's down has nothing to do with the domain: a routine upgrade went wrong, and the Linux kernel on the machine hosting it went up in a puff of smoke. The worker ants are busy bringing the Garden back online. Keep checking back, it's not going anywhere.
Interestingly, it seems that 'brightcreative.com' [which is in fact coming soon, despite the empty promise that particular wording entails] is generic enough a name to warrant mistaken identity.
For example: let's say, hypothetically of course, that my server is configured to forward absolutely anything @ the domain name to my catch-all inbox. Let's say, also theoretically, that earlier in the week a 2MB email landed in my inbox.
Since we're still talking speculatively, imagine that I had instinctively deleted it as a virus. But if something had caught my eye and made me fish it out of my deleted items folder, imagine how surprised I would have been to discover that the email was addressed to a 'Judith' at X Creative, where 'X' has been substituted for an actual business name.
And imagine my amazement to discover the sender had forwarded payroll and expense worksheets for a major TV commercial shoot happening soon. Theoretically.
Is there etiquette for a situation like this? Announcing that the intended recipient didn't receive the email is fine when it's a simple conversation or confirmation or anything else non-confidential. But bring (assumed confidential) financial worksheets into the equation, and the dynamic completely changes.
Well since the cat seems to be out of the bag, More Eric Meyer on CSS is hot off the press and on its way to a bookstore near you. As a technical reviewer of the book (along with Porter Glendinning), I've read it thoroughly a few times, and I can tell you that it's a real treat.
Eric steps you through building 10 projects, and you can't help but come away wondering how he makes it look so easy. The resulting CSS is astoundingly light and straightforward, just the way the W3C intended it. I wish I knew CSS like Eric Meyer knew CSS.
If you loved the last one, there's more to love in this one. If you didn't like the last one, you should give your head a shake and buy it anyway.
(My promo copies arrived the other night and I'll corroborate — it's really tomato-soup-red, not hot pink.)
But the fun doesn't stop there! We planned a special treat.
Chapter 10 deconstructs the building of a css Zen Garden design. Added just now, "15 Petals" is a collaborative effort between Eric and myself, and marks official design #100.
Holy cow. 100! There's something wildly satisfying about having a hundred uniquely incredible submissions to a project which was started not quite a year ago. And there's something supremely felicitous about having Eric Meyer contribute design #100.
Grow, baby, grow! I couldn't be more proud.
Cameron Adams recently posted a link to Adam Greenfield's old ALA article, The Bathing Ape Has No Clothes. I remember well when it was first published two years ago; it has made a tremendous impact on my work since.
While the article is on the older side (I haven't seen a Bathing Ape shirt in quite some time) it has aged well. The issues raised haven't been discussed nearly as deeply as Greenfield wished, and I see arguments on today's weblogs that echo Adam's concern. 'The Bathing Ape…' draws clear lines between those who are designers, and those who are something else. Greenfield labels them 'Stylists' and I'd call that an apt label.
When I started reading the design portals around 2000 something bothered me, and I could never put my finger on why. The sites linked were all very pretty, and very artsy, but aside from functioning as someone's personal portfolio, they didn't do much. Many of them aimed to create a false mystique by using random words and imagery that, when scrutinzed, didn't amount to much meaning or even coherency.
Don't misunderstand me—there was very good work being produced, and most of it was technically astounding and very good looking. But this design work suffered a fundamental problem for me that didn't seem to ever be properly addressed. I could never find much justification for a lot of it to exist. It was there simply to be there, and to demonstrate the talent of the designer.
But that's what a portfolio is all about, in most cases, so was this really a problem? To those looking to advance their careers, not in the least. The work was for a target audience (creative directors, those in charge of hiring) and that the general public couldn't find use in it wasn't something to lose sleep over.
In fact, this is a clear example of successful design—work done for a well-defined target audience, with a specific purpose.
The problem then, which Greenfield has highlighted with breathtaking insight as he compares Nigo's work to that done for British Rail, is when this way of working spills over into design projects that have a totally different target audience. The focus of 'design' is lost, the project ends up becoming a stylistic dream but a usability nightmare.
Design is about assessing a series of visual problems, coming up with the best solution. It's about applying the solution in a way that also lends itself to visual interest. It's about making use of imagery, type, and colour to convey a message. It's about making people feel something. It's about communication.
But that doesn't preclude the function of what's being designed. (This is no form vs. function debate, which has been going on since three years before design itself was invented.) Quite simply, if you're a web designer, you end up designing usability whether you acknowledge it or not (and, unfortunately, whether you're good at it or not). The function of a site or application is increasingly a problem that a designer finds necessary to solve. This is no surprise to those of us doing it, and aligns nicely with Greenfield's point.
It's difficult to face continued dismissal that a designer is either a Picasso or a house painter without acknowledging that there is a far more useful application of design. There are plenty of people making good money as both house painters and Picassos; perhaps even the majority of designers are one or the other. But we're not all easily categorizable into those groupings.
As Jeff Veen stated in his SXSW panel, "Accessibility is for everyone!":
…when Web design is practiced as a craft, and not a consolation, accessibility comes for free.
The same statement can be made for usability, as can be made for content, as can be made for code integrity, as can be made for information architecture, as can be made for design. There are those of us who approach web design as a holistic strategy, and concentrate not just on how a site looks, or what it says, or how it functions. We look at a project from top to bottom, understanding the inter-relatedness of each element along the way, and assess its proper place in the site as a whole.
What is web design? This is. Nothing less.
(For even more classic ALA reading, hit up Curt Cloninger's "Usability experts are from Mars, graphic designers are from Venus".)
Sure, I admit it: there's a glaring IE6 glitch on this site. I've known about it for a while, but I'm not going to fix it. Well, there are two glitches actually, and the second is a little more tricky. But let's talk about the first.
The big red banner is displayed by image replacement on an
h1. Since I built the site, hovering caused the infamous 'flicker' in IE (which is the second problem, but I digress again.) Then I interviewed Ryan Carver for WaSP, and took a look at his IE investigation, after which I applied his method to the banner, thereby eliminating the flicker for good.
Except doing so introduced a brand new bug no one had ever seen before. What it looks like: a piece of the content from the body is being duplicated, and briefly layered over top of the banner itself. It's easier to just see it:
I have no idea what causes it or how I'd go about isolating it, and I'm not even going to bother. Instead, I'm going to point and laugh, and leave it as-is. Just because it's IE. And just because I can.
(because some make disclaimers mandatory: this 'ignore it' approach is to be taken for this site alone. mezzoblue caters to web designers, who should know better than to run IE in the first place. No, you shouldn't penalize users for their choice of browser. No, this isn't an attitude to take when doing commercial work. No, I don't know whether I'll have the fish or the chicken.)
Okay, so the second bug is something more problematic, because it does affect most everyone else. In certain instances, hovering over image-replaced links causes the link to blink out and back in as the image re-loads. Keeping an eye on the IE/globe 'throbber' up in the top right corner shows there's some network activity happening as it does this, albeit very briefly; watching your outgoing packets confirms it. IE isn't caching, but reloading (or at least re-checking) the image every single time, causing the flicker.
There's an easy fix! I wrote about it six months ago! It doesn't actually work!
Well, it does for some. But here's something I'm noticing—even with that generous caching setting turned on, in some instances IE still causes flicker. Like, on this site for one. Like, allegedly, on the Sprites demos at ALA for another. Which really causes me to scratch my head, because I purposefully layered two sets of images over top of each other to eliminate the problem.
But no matter, due to the inconsistency and terrible difficulty in tracking it down I've started to suspect it has to do with a server setting anyhow. Well lo and behold, in the very post referenced above, a link posted by Blake Scarbrough to a discussion which I either never saw or don't remember seeing points out some .htaccess configuration which may yet provide a fix. I haven't touched the code, so I can't vouch for it yet, but you can be sure I'll give it a shot when I have the chance.
update: Since there seems to have been confusion about this, despite the disclaimer, you'll note that the second problem (the one that actually is a real problem that should be fixed) I said just above I would look into and fix. And so I have. Provided you have caching turned on in Internet Explorer, the flashing problem should be alleviated. The .htaccess lines in the css-discuss thread linked above did the trick. IE still flashes if caching is set to 'check every time', but as explained in the entry from six months ago I also linked to, this is a developer setting that has to be manually turned on, so most users will not experience it. Flashing problem: solved. Original IE glitch I decided not to solve: probably solved too. Onwards.
An interesting conversation with Jay Allen the other day got me thinking about how I cope with larger amounts of email. Not well, it turns out.
Despite the plethora of Nigerian scams and email-spread virii floating around at the moment, I've noticed my spam levels are at all-time lows. Which means the signal-to-noise ratio in my inbox is quite high, which also means that waking up to the sack of new mail that came in overnight is a daunting prospect.
It's amazing how the internet is bringing together people who might have not otherwise meet; and there are a hell of a lot of them. It seems the more active you are online, the more people want a moment of your time. A five minute email response, multiplied by 50, equals a whole afternoon spent catching up. Every week. Matt's policy of replying to every email received is admirable, but it doesn't scale. (I tried too.)
Making yourself available for discussion is not a bad thing, it just means that an understanding needs to be reached between you and those wishing to get in touch. It's a two-way road; you need to agree to be as responsive as possible, they need to agree to be selective as possible.
For what it's worth, my strategy of keeping things managable at the moment goes something like this. This all applies exclusively to email coming in off this site and that other one, but not to previously-established communication or work-related email. Your mileage may vary depending on volume.
New email is read (or at the very least, skimmed) as soon as it arrives. If it requires a follow-up, it's either replied to immediately, or marked as unread. (I rely on unread instead of flagged messages, so that my mail folders give me a count of how many outstanding messages I need to get to.)
I don't answer many CSS questions anymore, instead referring the asker on to the excellent css-discuss list. That's what it's there for, and if it were to go around that you could get an answer out of me anytime you ran into a rendering glitch, well you'd certainly hear much less from me on here, for starters.
I start with the low-hanging fruit. Any email that requires a quick line or two in reply will get a response within a day or two, be it "thanks" or any other acknowledgement/question. Those are no problem, and so far I can generally reply to every one, usually quickly.
It gets thorny when email requires either a bit of thinking, a bit of debating, or a bit of digging into archives, Google or elsewhere to formulate a reply. Some of these I get to in short order, others sit for a while. I try not to leave them for over a month, but it happens. The problem with replying to them is that when it comes time to do so, I'll have another new set of email to get to first, and once again the low-hanging fruit principle comes into effect. These can be pushed back rather far.
The worst are essays. I get the occasional email that spans multiple on-screen pages. I absolutely love that someone has taken the time to share that much with me; I feel a message that long deserves a considered response, which can end up being a page or two back. Finding the time to write that page is difficult. Again, low-hanging fruit is picked first most times. I always reply to these essays; I don't always reply to them in a timely manner.
Email that ends up jumping the queue tends to be well thought out and will raise good points that I'd like to address more publicly. I'll follow up with a response, and then post an edited version of that email on here. (No, this isn't one of those.) I'd rather take the time I spend writing to build a publicly-available response for more than a single person.
What keeps me replying instead of just marking them all as read and letting them disappear into the ether? I value the time you spend writing me, and the thought you've put into your query. I'll keep on replying to as many as I can.
Yesterday's little prank seems to have gone over well. Interestingly, I never thought for a second we'd genuinely confuse anyone, but it sounds like a lot of that went around. Hard to say why it worked so well, I guess you take for granted a site's chrome once you've visited enough. Thanks for being good sports about it, it was plenty of fun.
Doug has followed up with a detailed account of the steps we took, so here are a few notes of my own.The Idea We did start discussing this in January. A quick attempt back then showed us that it wasn't impossible, but it would prove a little more difficult than simply swapping CSS files. And so it sat; busy lives, busy people. We were supposed to take it further at SXSW, but between madly preparing for our Monday panels and the subsequent relief and enjoyment immediately following, we lost focus. Cut to this past weekend, where we picked up again. I believe 'down to the wire' was the phrase that Doug originally used to describe our timeline. So true; I spent the past few evenings hacking imagery and swapping markup. How did we go about it? We initially thought about swapping CSS files. The net effect would have been a site-wide redesign for the day. Theoretically possible (you may not have realized it, but we're both big fans of separate structure and presentation), but it proved to be more time-consuming than either of us were prepared for. It's just a joke after all, not a critical business proposition, so we decided to minimize the time involved. Instead we grabbed static archives of our home pages and hacked away. I caught myself modifying the markup structure quite a bit, and at one point almost decided to just drop my content in Doug's structure and be done with it. In the end I ended up with a hybrid mix between my site and his markup-wise, and the CSS files are completely customized for this little project alone. I should note that while our markup structure is different, some of that is because I feel my own structure is inherently wrong in spots. (My heading order in particular: post titles are <h3> 's, which just feels wrong now. Fixing that will have to wait for a redesign.) In other cases, we just have different pieces of content that demand different structure. You can't standardize that which isn't standard, after all. Imagery I had to go back to my original .PSD files to re-create the graphics which was itself a challenge. The files go back to last year and due to gamma corrections and content adjustment along the way, they're terribly out of synch with what's currently on the site. Another problem is my graphic editing policy, in that I have none. Editing one of the striped headers on the right involves opening up a previous one, blanking out the text, overlaying new text, and saving a new GIF. I have no problems with this process because I have a plethora of tricks to combat image degradation, but I know some of my processes are quirky and not conducive to later work by other designers. I ended up sending my original mockup PSD to Doug, for which I apologize: hey, if nothing else you got to see how bad it really is! Setup The home page redirect was easy. I added this to my root .htaccess file: Redirect index.php www.mezzoblue.com/archives/covers/apr01-04/ Which basically directed all requests for the home page on to the permanently archived 'cover' spoof page. Since all the links on that page pointed back to real content on the site, it effectively functioned as this site's home page for the day. This is the way I've done it for past covers on Remembrance Day and Christmas last year. It's how I'll continue to do it for any covers in the future; I like the method because you can be sure as soon as seeing the page/URL that a) it's not the home page, and b) you can link to that page without expecting it'll change. Cool URIs don't change, after all. Customizing We launched about 10:30pm West Coast time on the 30th. Doug had gone quite a bit further than I by spoofing his individual post/comments page too. Jumping from my spoofed home page to my 'real' comments page for the post was disorienting, because two different styles were going on. Doing the same on Doug's site was seamless. And jumping back and forth between two visually identical comments pages was too much. Clearly I had to do something. A mad rush of CSS coding to pull the extra style back in for the forms (I stripped a bunch originally since it wasn't needed), and a ton of Googling to aid with the redirects, and I finally got my own comments page working around 11:30 or midnight or so. Some of you saw the comments page before this happened. Oh well. The Movable Type setup to do that was actually pretty easy. I created a new individual entry archive, and in my weblog config I added it to the existing one—the key here is to realize that even though you only set one default archive template, MT generates all templates you've attached. I didn't know this until Doug told me how he set up his; it's going to come in handy for more than just this one project. So once MT was generating two templates, one for 'regular' posts and one for ‘April Fool's’ posts (yes, this means I now have a second joke file for all 250-odd posts on my site I'll have to clean up), the trick was redirecting just the one post on to the new file. I looked into .htaccess again, which Doug was apparently able to use, but for whatever reason I couldn't get it working. In MT I threw into my standard template a custom PHP script that redirected if and only if the title of the post was 'Sickening'. That did the trick. I considered leaving that one post formatted with the spoof template from now on, but instead we've both archived the post pages . Feeds No doubt what aided the confusion is the RSS variable. Because a lot of people are reading our sites from newsreaders instead of in a browser, we figured the joke would be perpetuated/lost on some if they didn't click through. We both worded the posts as salaciously as we could to encourage clicking. I ended up temporarily rigging MT to stop producing a new feed, and I hacked the URLs to point to the spoofed page as well. Some may not have got the full effect, and I'd hate to think there are some out there who now think Doug is a thief, albeit a highly-capable one, but I'd imagine it's safe to assume most are in on the joke by now. Reverting And the last piece of the puzzle was taking it all down after 24 hours. Easy as anything—I removed the home page redirect, dropped the PHP from my templates, re-established the RSS feeds, and now we're back. It was a fun little experiment, and if nothing else I've taken away the itch to finally finish the redesign I've had brewing for six months or so. We'll see how that goes. Thanks for the laughs, and a big thanks to Doug for playing along. ]]>
If you're really good, I'll tell you how we pulled it off tomorrow. (references to Stopdesign below removed so Google doesn't take this out of context. It's all a joke, after all.)I won’t spare the niceties: what [removed] have done is disgraceful and unprofessional. For a so-called “Design Consultancy” to rip off the work of another for its own site shows a total lack of regard for others in the profession, and undermines — no, cheapens — the industry as a whole. What makes this particularly heinous is that not two weeks ago, [removed] had the audacity to talk about CSS Theft in front of a packed conference room at SXSW2004. In one ear, out the other…? A sad day for those of us working on the web. Please feel free to go over to [removed] and make some noise in protest. ]]>