Unfortunately, I don’t give TodaysMeet the attention it, and more importantly its users, deserve. This is because TodaysMeet has two fatal flaws that, if they haven’t crippled it yet, will someday.

• The UI is based on proof-of-concept JavaScript.
• The back-end is based on my own framework.

What follows is the sad history of TodaysMeet development.

Origin Story

TodaysMeet came out of a conversation between my father and I, but it’s origins are slightly older. In some downtime in late 2007 I was trying to familiarize myself with various JavaScript frameworks by writing a UI for the same back-end in each of them. It was a pretty basic Ajax comment system. I believe it polled the server every minute. If I remember correctly, I got busy and abandoned it after creating Prototype and jQuery versions.

Around the same time I was enamored of Rails, and trying to round out Maveric into a decent Rails-inspired PHP framework.

So when my father said he wanted something like Twitter for a single classroom, that he could project on a wall, and wouldn’t require signing up, I put these things together in my head. TodaysMeet is basically the proof-of-concept Prototype JS running on top of an old version of Maveric.

The Situation Now

Every developer should write a framework, I think it’s a fantastic learning experience. But they should never build a production website out of it.

Even though Maveric got a little better after I created TodaysMeet, it’s still based on an untested, unsupported framework with no support for basic things like storage back-ends or caching.

The UI is still based on Prototype, which I haven’t used in years, and the fundamental client-server interactions are still that original “learning the library” code.

Essentially, TodaysMeet is a prototype masquerading as a production-ready product.

The result is that working on it is slow, difficult, and frankly unpleasant. Adding features—like the long-promised password protected rooms—is painful and, with no test suite, dangerous. The one real feature I added, Twitter integration, barely works when it works at all.

But users don’t care about any of that. They see that it works, mostly. They might see that it doesn’t get much attention and the UI feels three years old (because it is, of course).

Where Do We Go From Here?

TodaysMeet could be awesome, but it needs to go all the way down to the basic stack and get rebuilt. TodaysMeet is an absolutely perfect candidate for all sorts of new, exciting tools and techniques. To use any of them means starting over.

This is the first of a two-part post. In the next part, I’m going to outline the architecture I want, instead of the architecture I have.

Hopefully, some social aspect of talking about this will lead to me actually doing something about it.

I’ve been thinking a lot about browser compatibility as I’ve been working on Today’s Meet. My CSS is valid, but it doesn’t work quite right in IE6. The interface is completely JavaScript-based, and will only become moreso in the future. How much time should I put into making it all work with IE6?

None.

I know lots of people, usually in government offices or schools, who are stuck with IE6. For some reason, their IT departments have neglected to update their systems for over two years.

(Sure, some of these systems are running Windows 2000. This is a real minority at this point, though, and the rest have no excuse. If you’re running Windows 2000, and absolutely cannot afford to get new systems, get Firefox.)

I used to think I needed to support IE6 because this group is frighteningly large. But now I’ve come to realize—especially in the wake of this week’s news—that by supporting IE6, all I’m really doing is enabling these lazy IT departments to keep running dangerously out-of-date software.

IE6 is the Vicodin to lazy IT’s Dr. House. As developers we’re Drs. Wilson and Cuddy. Just keep handing it out.

How up-to-date is the rest of the software on a system that (apparently) hasn’t run Windows Update in 2 years? What other major security holes, accessibility issues, and compatibility problems would be solved by updating?

Not only is supporting IE6 annoying, it enables people to run software that is out-of-date and easily exploited. Are we really helping users, or are we just helping them get hacked?

So from now on, no more.

My personal projects will no longer support IE6. I won’t test in IE6.

IE7, Firefox 3, Safari 3, provisionally Opera (really, if it works in the first 3, it should work in Opera).  Keep your software up-to-date.

If you’re still using IE6, go get 7. (Then don’t use it until after the Windows Update patch.)

If you can’t run updates, but can install software, go get Firefox.

If you can’t do any of that, tell your IT department that running software 2 years out of date is unacceptable. Tell your boss to tell them. It’s a performance/security/accessibility/compatibility/etc issue.

And if you’re a developer, stop and think. Are you actually doing your visitors any good by supporting IE6? Or should you take all the time and effort you put into backwards compatibility and put it someplace more valuable?

I had to go through and repeat a few hacks. For example, 2.3.x didn’t allow you to do get_sidebar($name), so I’d hacked the “get_sidebar()” function. And I replaced the still-broken Atom feed reading widget with James Wilson’s Google Reader Widget.

Then I finally got fed up with the default “Search” widget, which doesn’t look like the other widgets at all (no title), so I started hacking into that one. Then I realized “why hack, when I can extend?”

So, here it is, Better Search Widget.

All it does is add a search widget with a customizable title, submit button, and field size. Quick-and-useful. You can see the results in the sidebar.

If you decide to use it, leave a comment and I’ll check out your blog.

I just downloaded the Spore Creature Creator, and this file showed up on my desktop: 792248d6ad421d577132c2b648bbed45_scc_trial_na.exe.

Why not “Spore Creature Creator Trial Install.exe”, or, if spaces aren’t your thing, “SporeCreatureCreatorTrialInstall.exe”? Either would be infinitely more meaningful than an MD5 hash followed by an acronym and a region code.

While the developers may have had a reason (though I can’t imagine it’s a good enough reason) to use this file name, the web team has no excuse.

There’s a lesson here: be nice to users. Whether it’s just a file name or helpful error messages or designing a user interface/experience, don’t treat your users like machines that parse your (bizarre) internal formats.

And Will Wright, if you’re listening, ask someone to rename that file.

Some themes waste kilobytes of HTML source on something that could be achieved with 75% less markup. Some use blatantly non-compliant code. Almost none use semantic names.

But what really irks me—I’ll cop to using meaningless code to make it look good—is the style of CSS that seems to be spreading: breaking up definitions into a half-dozen chunks, no line breaks, lack of organization. I think their heart is in the right place (a section for colors, so don’t have to worry about layout; a section for typography, so the precious padding is protected) but the result is a horrid mess.

I blame Michael Heilemann, the designer behind the bland and semantic-free default WordPress theme. I imagine theme developers, many just starting with HTML and CSS, started by looking at his code, and thought that was the way to do it. Then it spread like a virus.

Here’s an example from “Autumn Concept 1.0″:

#topbar {background-color: #4b7c44;}
#footer {background-color: #4b7c44;}
#mainpicinner {height: 250px; background: «
  url(images/mainpic01.jpg) top left «
  no-repeat #fff; border: 1px solid #fff;}
/* typography */
#logo a {color: #3a4032;}
.textbkg {border-left: 4px solid #ebf0cf;}

(« is an inserted linebreak.)

Wow. Line breaks? Readability? Was this passed through a bad version of JSMin?

This is from the “Color Scheme” section, but the first directive for #mainpicinner is height. It also has a border, not just border-color but the whole thing. What’s the point of having sections if you proceed to ignore them immediately?

The rest is filled with classes like cols01 and box01 (while there are other cols##, there is no box02).

But that isn’t my real problem. My real problem is about 20 lines further down:

body {position: relative; background: #1f1f1f; «
  font: 70% Verdana, Arial, Helvetica, «
  sans-serif; text-align: center; letter-spacing: 0;}
#container {float: left; display: block; width: 100%;}
#topbar {float: left; display: block; width: «
  100%; background-image: url(images/topbar.png); «
  background-position: top; background-repeat: «
  repeat-x; text-align: left; padding: 13px 0 6px 0;}
#topbar div {padding-bottom: 0;}

#container is back. (As are backgrounds. Pick a spot, already!)

This kind of CSS is hard to read, hard to maintain, and hard to customize. Even if the initial version is perfect—which doesn’t exist—things will start to break as soon as someone opens the file. Even in this published style sheet, the author couldn’t decide if background images and borders belonged in “Color Scheme” or “General Styles.” What chance does a maintainer have?

I am, admittedly, obsessively strict with my style sheets. I like to make very sure that every style affects only what I intend it to affect. But I never let the styles for one element single get broken into two places. Instead, what I try to do is keep similar styles in a similar order inside those blocks:

blockquote.dropquote {
  float: right;  font-family: Arial, «
    Helvetica, sans-serif;
  font-size: 130%;

color: #662020;
  background-color: #ddd;
}

div.login {
  position: absolute;
  top: 0;
  left: 0;

  font-size: 80%;

  color: #fff;
}

Get the idea? Within each selector, I try to keep things in the same order. I almost always keep positioning styles first and then do either typography or color. To me, this is much more readable and maintainable. If my header div is 3 pixels too wide, I don’t have to comb through all the #header sections. I go to one place and fix it.

I like to extract the CSS order from the document order. This doesn’t necessarily stay complete or strict, especially when you have classes that can be used anywhere or you’re controlling tags directly. The header styles do come before the content styles, though, which come before the footer styles. That just makes sense.

Am I the only one who can’t stand this “style” of CSS? Do you use it? Why?

On the one side, Pat Dryburgh argues word-of-mouth is superior to self-advertising: “If the design is good enough, they will ask my clients, and if they like me enough, then they will tell people about me.”

In rebuttal, Sophia Lucero at wisdump.com claims your “designed by” link should be like a Louis Vuitton logo: “Your brand should never hurt your creations, it should enhance them”.

To me, there is an issue of “ownership” to consider. If I put my name on something, I take responsibility for it as much as credit. My name means “I did this, I’m proud of it, and I want to be associated with it.” I think we’ve all done work we’ve left our names off, because we were rushed or a client demanded changes in spite of our best advice or… well, you get the idea: we weren’t proud of it.

So what do you do? Are you a “designed by” designer? Do you stick to code comments? What if you’re a back-end developer?

Edit: I should link Chris Brogan’s series on personal branding. It definitely applies to this question.

Elements and Outline

My first step is usually to create an un-styled outline of a “typical” page. I fire up my editor, fill in the basic XHTML, and then go to work inside the <body> tag.

Most sites have this fairly common structure: header, content, footer. And just for fun, let’s throw in navigation between the header and the content. It’s pretty easy to represent this in XHTML:

<div id="header">
</div>

<div id="navigation">
</div>

<div id="content">
</div>

<div id="footer">
</div>

This is my first skeleton for >90% of the sites I design. It’s a very standard document. Sometimes navigation will be inside the header, but most often it goes like this.

Now you have to start thinking about what elements will be on the page. On this site, a blog, I used “articles” instead of “content” for the main div. I also added two side bars, and I knew that inside the articles div I’d want, well, articles.

<div id="header">
  <h1>Page Title</h1>
</div>

<div id="navigation">
  <ul>
    <li>Link 1</li>
    <li>Link 2</li>
  </ul>
</div>

<div id="articles">
  <h2>Recent Articles</h2>
  <div class="article">
    <h3>Article Title</h3>
  </div>
</div>

<div id="theblog">
  <h2>Sidebar heading</h2>
  <p>Sidebar paragraph</p>
</div>

<div id="theworld">
  <h2>Sidebar heading</h2>
  <ul>
    <li>Sidebar</li>
    <li>list</li>
  </ul>
</div>

<div id="footer">
</div>

I won’t bore you with more code examples; I think you get the idea. I make an outline. I know at this point that my source is nice and valid, and that it will make sense when I turn off the stylesheet. I use semantic names for everything.

It’s not very pretty, but I now have a workable XHTML document, with a properly-nested outline, and most of the important elements. Good for me, because now I can start to style them.

Layout and Style

Now, I know what visual elements will need to go on the page. I know what page elements I need to style. Now I’ll start creating a style sheet.

My first style sheet will contain a few basic HTML tags and the elements of my document. I could probably write an XML-to-CSS generator with how strict I am with this step.

Ok, one more code example:

body {}

h1,
h2,
h3,
h4,
h5,
h6 {}

a:link {}
a:visited {}
a:hover {}

#header {}
#header h1 {}

#navigation {}
#navigation ul {}
#navigation ul li {}

#articles {}
#articles h2 {}
#articles div.article {}
#articles div.article h2 {}

#theblog {}
#theblog h2 {}

#theworld {}
#theworld h2 {}
#theworld ul {}
#theworld ul li {}

#footer {}

One of my favorite things about this is it’s almost impossible for a mistake in one section to mess up anything else.

But obviously there’s a lot in there I can combine, can shorten. Almost anything that’s true for #theblog will also be true for #theworld in this case, so DRY, and keep things together as much as you can. But, when you’re just starting the style sheet, this is a good place to start.

As I’m going, I add a lot to the style sheet. I also add a lot to the XHTML template. Pixels get tweaked left and right and I swear at IE6, of course.

Building Templates

Once I have a complete, or near-complete, mock up, it’s time to start building templates for your CMS of choice. This is mostly copy-and-paste work at this point. Your #header and #navigation go into the header template. #footer goes into footer. #content goes in the content template.

See how easy that is?

Then you get to go through and actually add the template mark up. Whether it’s Smarty or PHP or ASP doesn’t really matter, you just replace your dummy text with the right tags.

Starting Out

I love this process, but there is one thing you really need for it to go smoothly:

You need to know what kind of content you’ll have. When you’re redesigning your blog, or building an in-house site, it’s pretty easy to know. When you’re working for a client, you may need to twist some arms to get this information. (I love this A List Apart article for advice on communicating with clients.)

One final thought: use comments. Any time I create a div, I wrap it in comments like this:

<!--begin #articles -->
<div id="articles">
</div>
<!-- end #articles -->

I usually use the CSS selector because it’s specific, so #articles, .article, and so on. These comments—which I left out here to save space—have saved me so much time and effort compared to relying on indentation that I can’t imagine working without them.

I didn’t set out this process as a way to streamline my work, but rather, as I started noticing patterns that worked well, I started thinking about the process. Much like Rails, which was already running Basecamp before it was a framework, I’ve been using more-and-more-polished versions of this work flow for months.

Maybe you’ll find it helpful, maybe not. Maybe you already have a “system” in place. If you do, what is it?

If you want to remain the standard-setting body for the web, promise new recommendations, never deliver.

A decade ago, the W3C was actively working to improve the standards we designers and developers use every day. Sure there were some controversial things (HTML 3.0, XML 1.1) that never caught on, but at least there was discussion, thought, and sometimes even action.

The W3C started work on the CSS3 specification the same year they published CSS2—1998. Ten years later, CSS2.1 is still not technically a published recommendation.

Between 1995, when the W3C was founded, and 1999, HTML went from version 2, an RFC, to version 4.01. Where is 5? In January of this year it became a Working Draft.

When was XHTML last updated? 2001. The DOM? 2004. MathML? 2003.

What happened?

When did “do nothing group” replace “working group” over there? (Probably around 2004.)

I realize that implementing new standards is not trivial. I also realize that standards are crucial to the continued growth of the web—this site is valid XHTML and uses valid CSS.

However, without updates, these “standards” will get old and die. Something else, or someone else, will replace them. We’ve already used CSS2 for a decade. Will we use it for another? (I want my drop shadows! I want my opacity! I want my rounded corners!)

I lead with a quote from Napoleon, so I’ll finish with the French Revolution: Off with their heads. The W3C needs a change in leadership or a vigorous shakedown to get off their asses and do something.

If they’re not willing to put forth the effort, then let them eat cake while someone else does.

This design is a hybrid, pulling elements from some of better-looking sites and blogs. The three-column layout was inspired by Felicia Day’s “Flog” and Problogger, the thin header comes from a post on Chris Brogan’s blog, the heading style is cribbed from The Guardian.

There are two things I learned here that I want to pass along.

Theft is not wrong. Just because a design element exists on another site does not mean you can’t use it. I don’t mean you should steal the entire layout, images and all, or steal code (unless it’s under a free license, then steal away). But if you like the way your favorite blog does headings, there’s no shame in modeling your headings the same way.

Unfinished is wrong. I regret leaving the blog unfinished for so long. I would have been better served by using the Kubrick theme until I was really ready to switch. If you’re starting a blog and want to get to writing right away, go ahead and use some free templates. It’s much better than starting a theme and leaving it unfinished.

A corollary to that is “while incremental changes are fine in testing, only big, complete changes are OK in production.” In other words, don’t edit your live site, except small tweaks and bug fixes. When you upload new templates they should be tested and ready to deploy.

That being said, there are a few small things that aren’t quite finished. I need to write a short paragraph about myself and decide if I want to add a Problogger-/Chris Brogan-style link to the feed right at the top.

Well, what do you think?

I’m starting with the default WordPress theme by Michael Heilemann. I’m not going to lie: I really dislike this particular theme.

The look, though bland, is fine. What bothers me is how disorganized and really horrid some of the code is, in particular the CSS. The text is realigned several times (center, no left, no center! Ah, you said center! But I meant left. Well… very well, we are Church of… Sorry, off to see Izzard in a few weeks). Everything is done in pixels, except randomly things are in ems or percents. Many things are changed from defaults only to be changed back later.

In general, the idea of cascading seems to have been missed.

I wonder, how much of this is one person (Mr. Heilemann) and how much is hacks by committee. There is a definite feeling of “too many chefs” here.

And yet, here I am, using it anyway. As I work through my changes I’m doing a bit of Spring Cleaning, aptly enough in Spring, but it slows down the process.

Mad props to Firebug, and its brilliant style inspector which shows you not only computed styles, but the whole CSS ancestry of any element.