Ikiru Design

I wrote this back at the end of May 2008 and didn’t publish it. When I thought about posting something similar a few days ago, I was surprised to find this nearly complete set of thoughts. I’ve decided to post this version, and will probably add some further thoughts on the topic soon.

For better or worse, Cascading Style Sheets are meant to cascade. That means if you style an <h1></h1>, all thing elements enclosed in <h1> tags well inherent that h1 style. This is both incredibly useful and incredibly troublesome.

It nice that if you really do want all your <h1>s to look the same. The cascade assures that they do regardless of the <div> they’re under or the classes you’ve given them. It’s a problem because when you absent-mindedly use an <h1> tag without remembering that you’ve styled the attribute, you can get some wonky looking stuff.

There are two basic means to deal with this reality: containment and a laissez-faire “let it cascade” approach. The first has the advantage of meaning that you never accidentally have things cascade, but the disadvantage that your stylesheet may well end up incredibly verbose. The latter has the advantage that when used correctly it can give you surprisingly brief stylesheets, but while composing that sheet you may well fall victim to the aforementioned surprise cascade.

Before we get too far into the analysis of the problem, some basic understanding. A containment strategy will wrap everything in every ancestor class all the way down to the exact element you’re styling. This assures that you never have a single style cascading in an expected way, and will generally yield something like this:

#container #content .post .entry p {
margin: 1em 0;
font-size: 1.2em;
font-face: "Times New Roman", Times, serif;
}

Conversely, a cascaded style you only define what you’re styling in a loose and primarily pragmatic manner. The above might come out simply as:

.entry p {
font size: 1.2em;
}

This obviously assumes that face and margins were defined elsewhere. And though it’s not always going to be true, it’s a realistic possibility with a full-fledged cascade.

From a simple length perspective, there’s reason to assume that the latter method is better. But you never know when you’ll realize that you’ve already styled <p> to include font-size: 5em; or some such nonsense. In this case — and this is a unique problem for those sizing thing in ems — you’ll get a font size of 6ems, or around 60 pixels, certainly not what you wanted.

I’ve got a gut-level aversion to verbosity where it’s not necessary. But I don’t like being surprised by unexpected cascading bits either.

There is, I think, a way to split the difference. A managed cascade can allow for a reasonable number of “presets” while still leaving sufficient room to avoid the accidental cascade. Though I still think that browsers welcome movement away from crude text resizing and toward zoom will eventually render the use of ems for sizing completely obsolete, that day isn’t here yet. (And if it were, not all the issues in the containment versus cascade battle would be resolved.)

So for now, I think it’s best to contain as much styling as you feel is reasonable, while allowing some things to cascade. It’s an unconscious working assumption I’m sure more than a few designers already use, but it’s a conscious one I’m certain I’ll be helped by.

Over the weekend, I decided to finally install a copy of the WordPress trunk — that’s the currently-being-worked-on version for those not familiar with the term. For need of something to write on that new installation, I noted my first impressions of it. It seems relevant to share as the WordPress team is now soliciting advice about its menu structures.

It worth noting that I did this Saturday. Things have changed since. If you’re interested, popularly relevant information about development is at the WordPress Blog. More abbreviated notes, and up-to-the-day changes are tracked here.

Because some of my impressions make little sense without visuals, I’ve included a gallery of the most notable changes that have so far been made in the progress toward 2.7. (Sidenote: first time I’ve used the gallery in WordPress.)

And now my impressions, as originally noted:

I don’t really like how the new version smashes out the horizontal space. Though I doubt the change is nearly as big as it currently seems to me, it’s undeniable that the compose area fits fewer words per line than did previous (2.6-) versions.

The left side navigation has its pluses and minuses. I like that you can get to any page at all from it, but it’s also there even when you aren’t wanting to go to any page.

I think the term Utilities in the sidebar is misguided. “Manage” seemed to make more sense, and still does.

The built-in browse and install feature for plugins is pretty unquestionably cool.

The built-in upgrade to WordPress itself seemed to have failed on my one and only attempt. (It has since worked for me, the failure may have been a fluke.)

I think the ability to drag anything on the write page the sidebar is good, but it’s not as much customizability as I’d like. Will I ever be able to put a custom field on a post, without having to name that field every time? And be able to put that field right under the title field if I so choose? Until then any changes or not to the Write page will seem rather superficial to me.

There appears to have been few or no changes made to the Themes area thus far.

The dashboard has changed, but right now the utility of the “Inbox” and Quick Post sections, both sitting above the news boxes of 2.5+, are open questions.

Clearly there’s no small amount of work left before 2.7 “ships” in November (by current plans). That said, I’m amazed by all the great features slated for inclusion, and I feel so lucky to blog on such a constantly-improving platform.

When WordPress 2.5 came out, I was thinking I’d offer a narrative of “how I stopped worrying and learned to love WordPress 2.5.” That ended up being a little dull. Instead, because we’re always told that the internet loves lists — and at this late date it seems unreasonable to offer something more comprehensive — I’ve got a short enumerations of the good and bad.

Good

• A New Look — Though I wouldn’t say that all aesthetic changes made to WordPress redound to the good, I’m satisfied. The new colors are nice, the dashboard’s been improved, and everything feels better.
• Much Better Tag Integration — This is a direct descendant of the above point. Now a list of entries shows the tags. Now we get tag suggestions. And the ability to edit tags as a group. All of these are big improvements over the piecemeal support for tags that felt tagged on to 2.3.
• Better Media Integration — Though I’ve heard — and share — some discontent with the new Flash uploader, it’s nice that it was rethought. The ability to easily upload many pictures, and to easily create galleries are nice changes.
• Crucial or Trivial Bonus: Plays nice with Safari/WebKit — Anyone who tried using Safari with WordPress before will understand what a nice change this is. Anyone who hasn’t tried will think this is a silly point.

Bad

• The Bugs — This may be based solely on the fact that I use custom fields, but I’ve been having terrible trouble with both scheduling posts and the unnecessary creation of extraneous drafts. These sins can be forgiven, but I am getting rather impatient waiting for a fix.
• The New Look — A lot of changes to the Write page are for the better, but the dearth of white space on the right side confounds me. Catergories were there previously, and I think there was a number of good reasons for that. Tags, I think, should go there as well. But neither’s there. As I sidenote: I’m not really a fan of this Lucidia Grande business in the editor either.
• Change is Hard  — This is more a personal problem, but a lot of people (myself included) have been and slow to accept 2.5. This innate resistance to change is both irrational, and a waste of time.

I’m certainly not going back, and am even less likely to change blogging platforms, so all of this is essentially trivial. But now you know.

The epic showdown. Two titans of free internet content-management will meet in this arena. Only one can emerge victorious.

Two things should be made clear at the outset: (1) I was looking to make a link blog, not a typical tumblelog with multiple kinds of posts, all formatted differently; and (2) I eventually chose (self-hosted) WordPress. Yes, I just killed the drama. But this is about a comparison, and not (as I implied in the last paragraph) about winners or losers.

There were, three battles in this war. The first is the one that only matters to the proprietor: the back-end. This focuses primarily on how easy it is to create and edit entries for such a blog. Second, and what was the deciding factor for me, was archiving. That is: how easy it is to find what you want among the old stuff. The final issue is rather nebulous, but we’ll call it flexibility. That being whether each CMS can do the splits.

The Back

This is, without question, the place where WordPress loses a lot of points. And where Tumblr shines, especially if you’re looking for more than a link blog.

Tumblr’s backend is stylish, as the image at right demonstrates. I could go all the way to elegant and perhaps beautiful. Essentially you select the kind of post you’re going to be making, and then you’re taken to a specific page that’s tailored for making that kind of post. If you haven’t played around with Tumblr, it might be worth signing up just to see this.

WordPress, on the other hand, is a hulking CMS which can do lots of things. But it’s not terribly elegant at any of them. The way I create a post for my link blog demonstrates well. On the top the title, post text, and tags are entered. Then the link is added down at the bottom in the “custom fields” area. In which I’ve had to create a custom field called “link,” in which I put URL I want this entry to point to.

The use of custom fields — by definition separate from WordPress’s normal working — also makes it slightly hard to style entries properly, and harder still to make the feed act correctly (a problem I still haven’t fixed on my blog). I don’t need to go into detail, but suffice it say that it’s a headache.

Advantage Tumbler

The Archives

This is where WordPress, comparatively, shines. And the reason that I decided to throw my lot in with the ugly backend of WordPress, rather than the snazzy ease of Tumblr.

Tumblrs archive (see random example) look nearly as fresh and innovative as Tumblr’s backend. When I first saw one I said: “Wow. This is cool!”

And even though all those statements are true, Tumblr’s Archives are troublesome. For one, I’m not a fan of horizontal scrolling, which any reasonably old blog would have. And the only way to search such archives is with a browser’s built-in search fuction — which works, but is hardly elegant. And the ability to navigate with tags, of which I’m becoming an ever bigger fan, is completely out as well.

By contrast, WordPress is built for archives. The archives page I’ve thrown together for my nascent link blog gives you some ideas. There are tags there, as well as categories and monthly archives. Sure there’s a lot less flash than Tumblr’s page, but this has something else that Tumblr doesn’t. The ability to search. Built-in. And search plus all the ways you can view a WordPress archive means a lot to me.

Advantage WordPress

Flexibility

As I mentioned at the start, this a rather nebulous category. It encompasses most everything that I haven’t mentioned but feel the need to.

Both Tumblr and WordPress have a large array of themes. For the purposes of tumbling or linkblogging, Tumblr’s better in this. As for the novice, some seemingly-complex things have to be done to any WordPress theme to make it work at all.

Both tumblr and WordPress can exist at their own domains (though the tumblr default is X.tumblr.com, it can be easily changed). Having said that, all Tumblr backend work happens at tumblr.com.

Also, if one is reasonably skilled, it should noted that WordPress can do much more than Tumblr. But many, not even myself, are reasonably skilled.

So for the novice Tumblr is probably a wise choice (note that I’m not wise), you can’t do many of the things that WordPress allows you — seperate pages, for example — but the ease-of-use is hard to beat.

This is hard to call, so I’ll go ahead and do it the easy way:

Novice: Advantage Tumblr

Level 3 Nerd: Advantage WordPress

Conclusions

This contest is hard to call. Each CMS got 1.5 points out of three. As I suggested, I would decide this based on nerdiness. If you’re comfortable with CSS, HTML, PHP, and WordPress, I think that’s the obvious choice. If the acronyms in the last sentence confused and disoriented you, Tumblr’s probably a wiser bet.

Forced to choose an overall winner, I think I’d choose Tumblr.

The only reason I’m not currently using it is that dislike it’s archiving system. And that I like the possibility for future improvement when I finally get smart and motivated enough.

I hope I clinched the choice for you, affirmed what you were alreay thinking. Neither system’s terrible. Neither systems perfect. It’s just important to choose the best one for your needs and abilities.

I recently redesigned my non-design blog, Frozen Toothpaste, and did it with a variation of the BWO_one theme. At first I was very hesitant to go with a BWO_one variant because it meant that I’d lose the sidebar which the theme I had been using, Chris Pearson’s Copyblogger had had. It was some of the arguments that I’ll present here that convinced me that that would be OK.

Now, I should be clear that this is not an argument that no blog (or other website) should have a sidebar. I think they’re incredibly useful in a lot of cases. When I surf the blogosphere, I tend to favor the sidebar as a way to get around.

But the sidebar’s usefulness gives way to one of it’s biggest flaws: the clutter problem. Bloggers — who tend to be novice designers — tend to dump anything and everything into the sidebar. Most people probably have seen this problem before, but if you doubt me go spend a little time looking though blogspot.com or wordpress.com, you’ll notice what I’m talking about.

The problem starts benignly when a new blogger will say: “I want a little note to be easily visible,” and they’ll dump it into the sidebar. They’ll say “I want a RSS subscription button (or perhaps one for every feedreader known to man)” and that’ll go in the sidebar. They’ll create multiple blogrolls, and then a few images and maybe some links to their own content. And they’ll ad a last.fm widget, and a flickr widget, and a translations widget, and the “awards” they got from other bloggers. And it’ll all go into the sidebar. By the time they’re done no one wants to see, let alone click on the cluttered mess that resides where a simple sidebar used to.

I’ll readily admit that this story is a slight exaggeration. Many sidebars are manageable while they contain all the desired content. But that doesn’t change the fact that sidebars have latent tendency to become ugly and unmanaged clutter magnets.

Another strong argument for banishing the sidebar is that, especially but no exclusively when weighted down with moving widgets, they’re a hideous distraction from your writing. This may not be a concern for some bloggers, but I’d bet that the vast majority of people who blog do it as a way to practice, polish, and improve their writing. You want readers to look at and comment on what you’re writing, not be whisked off to yet another blog.

It not that a sidebar is an unavoidably bad, or that it shouldn’t be used. The issue is primarily that one must consider if they really need a sidebar. If you don’t it’s far better to use a design without a sidebar than to persist in having one that offers no function you desire.

There are risks in eliminating it certainly. But for every visitor that’ll be turned off by your lack of a sidebar, at least one more will be interested enough to try to see why you’ve eliminated it. It’s not that ever site should either have or not have have one, but every person designing for blogs should think about their merits and problems before making more of them.