Coffee on the Keyboard

WP Plugin: Better Search Widget

Today I upgraded from WordPress 2.3.3 to 2.6.1. I’m such a late adopter sometimes.

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.

Tags: search, widget
Posted in Back-end, Code, Design, Projects, WordPress

User Interface: Be Nice!

A short post for a busy week.

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.

Tags: interface, messages, spore, ui, ux
Posted in Code, Design, Front-end

Organizing CSS

Looking at WordPress themes usually makes me cringe. It’s as if there was a memo on semantic markup and the community of WP developers didn’t get it.

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?

Tags: organization, readability
Posted in CSS, Code, Design, Front-end, Standards

Do You “Designed By”?

A debate has cropped up over “designed by” links, those (hopefully) little links a designer puts on a page to take credit and get themselves some traffic and customers.

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.

Tags: brand, marketing, search, seo, web design
Posted in Code, Design

Work Pattern: Designing Web Sites

The premise of Design Patterns is that similar problems have similar solutions. In the same vein, I propose this Work Pattern a set of common steps I use when I create a web site, and maybe you can use, too.

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?

Tags: Accessibility, CSS, html, Standards, work pattern, workflow, xhtml
Posted in Articles, Code, Design