I Just Don’t Blog on Blogger Anymore

Several years ago, when I first decided I needed a blog, I decided to try an experiment: I’d sign up for both Wordpress and Blogger and use both in parallel for a while to see which one I liked better. Eventually, had things gone according to plan, I would have written a post comparing and contrasting the two services. At that point I would have picked whichever one I liked the most, imported all the posts and comments from the loser to the winner, and stuck with a single platform from then on.

Part of the reason that failed was that I just didn’t blog that often. I’ve managed roughly one post every month since May of 2012, but before that, I just didn’t blog enough to be getting useful data about what I liked and didn’t like about each platform. The experiment, if I’d been intent on doing it right, would have required me to produce a lot of content. In reality, though, I generally avoided writing unless I had something I really wanted to get off my chest.

Of course, I did eventually start blogging more or less regularly, so that can’t be the only reason. I can think of a few others.

The primary reason is that I tried to keep similar posts on the same blog. If I wrote a follow-up post, it went on the same blog as the earlier post that inspired it. If I wrote several posts that shared a category, they went on the same blog, so people looking at the category could actually see the whole category, and not miss half of it because they didn’t know they needed to search two different blogs. This tactic, combined with the fact that I don’t write about too many different topics, resulted in my sticking mainly with Wordpress.

This caused a couple of secondary effects. First, when people started finding my posts and following them, it was on the blog where most of the posts actually were. Second, since I was using Wordpress more than Blogger, I wound up getting used to it and became more comfortable with it. These days, on the rare occasions when I log into Blogger, I feel just a bit out of place.

Of course, it isn’t entirely by accident that I went with Wordpress. There are some ways I prefer it over Blogger.

Probably the biggest one is—or was—Blogger’s unfortunate habit of translating paragraph breaks to pairs of line breaks. I could use the <p> tag all I wanted in the editor’s HTML view, but Blogger would strip it out and replace it with <br /><br />. I can be a bit picky about using the right HTML element for the right job, so this was a big annoyance. I just tested it, though, and apparently this is no longer the case. If this change had occurred before I got used to Wordpress, things might have turned out differently. On the other hand, even now it seems to have replaced my <p>s with single <br />s, but that may be a quirk of the WYSIWYG editor. Either way I don't feel like dealing with it.

I also like that Wordpress has syntax highlighting for source code built-in. It’s possible to add it to blogger, but it takes some up-front work and using it isn’t as elegant. (I normally don’t mind a little up-front work, but not if I can get the same or better results without it.)

One more little thing I like about Wordpesss is that it lets me organize posts into categories and subcategories, whereas Blogger only has tags. I don’t really see the need for Wordpress to have categories and tags, but on the other hand it’s nice to have the options.

That’s not to say that Blogger doesn’t have its advantages. For one thing, it’s a lot more customizable. It only has a handful of templates, compared to the hundreds Wordpress has, but there’s a great deal that can be done to customize a Blogger template. Blogger even allows for the addition of custom HTML and CSS to the templates, and it doesn’t charge for it. (As far as I can tell, Wordpress.com charges a fee for custom CSS and doesn’t allow custom HTML at all.)

I also appreciated that Blogger’s HTML view showed me the actual HTML, or at least something a bit closer than Wordpress did. Even though Blogger used to modify my paragraph breaks, it would at least show me the resulting <br /> tags. Wordpress, on the other hand, replaced my <p> tags with a pair of line breaks in the editor, but in the actual post they’d still show up as p elements.

There’s also the fact that Blogger is owned by Google and uses the same unified Gmail/Google+ account used by all Google services. Whether that’s a point in favor of Blogger or against it will depend on your opinion of Google, but there’s something to be said for not having to manage yet another username and password.

I suppose this will have to suffice for that comparison post I said I was going to write.

As for the future of this blog, I’ve decided to bite the bullet and move everything over to Wordpress.com. I’m importing all the posts and comments (or lack thereof) from Blogger to Wordpress. I’ll also be removing the “My other blog” widget from Wordpress and renaming the one on Blogger to indicate that Wordpress is where all the current content is. Once I’m finished, Wordpress will be (for the time being, at least) the canonical home of this blog.

A Year of Monthly Blogging: What Have I Learned?

It was last May that I decided to start blogging on a more-or-less regular basis, and wrote up a post with some modest goals. Now it’s may again, which seems like as good a time as any to take a look back at the last year of blog posts. Even before I started working on this post, I noticed some patterns emerging.
One thing I noticed is that I have a tendency of taking a topic and milking it for multiple posts. Probably the most egregious example was Windows 8, but I did the same thing with Google and one or two others. This isn’t necessarily a bad thing, but since I only post once a month, it means that I can end up spending a big chunk of the year focused on one thing.
Something else I find myself doing, which I’d promised myself I wouldn’t do, is let posts turn into overly long and detailed affairs that I insist on getting perfectly polished before letting them go. Being so much of a perfectionist that I can’t just let things be done is a bad habit of mine. Going on and on because I can’t bear to cut things is another; even when I’m not rambling, my writing still often has way too much going on. I think my posts over the last year have done a better job of dealing with these problems than writing I’ve done in the past, but I still have a long way to go. These bad habits correspond to two of my four stated goals from last May, but I haven’t really fixed them yet.
By the way, I count these two habits as one issue (roughly) because of they way the combine. I can’t kill my darlings, but instead insist on letting them pile up, and then I insist on making them all perfect, which causes me to think of yet more ideas I want to include, and of course those have to be perfect, too… It’s a vicious cycle.
Which brings me to yet another bad habit: Lateness. When I first started, I didn’t have much difficulty cranking out a post in one or two sittings, then maybe making another pass later to take care of rough edges. Now, though, I end up taking so long—both because of the above habits and because of simple procrastination—that the posts are always done much later than I’d intended to finish them. The last post was the worst: It went up less than an hour before midnight on the last day of the month; I almost failed in my goal to publish a post per month (unless you count the April Fools thing, but that was written ages ago and put on a timer). I really need to work on being more timely.
I am pleased, however, that despite my procrastination, I did not fail to make at least one post per month. I tend to work better when I have a deadline, because that way I can’t keep polishing things up forever. I still need to work on this, but I’ve definitely done better this year than previous years.
I also think I’m doing okay with my post titles. I normally have a hard time naming things, which is why my blog just has my own name at the top of it, but the decision to avoid catchy or clever post titles in favor of clear and informative ones seems to be working for me.
Going back over that post from last year, I noticed one last issue: My intention was to follow Jeff Atwood’s approach by making each post just a bit better than the last one. However, I haven’t really been making a conscious effort to improve my writing. Sure, I’ve tried to make each post good, but I haven’t focused on improvement.
So what now? I don’t have a solid plan yet, but I do have some ideas:

• Start planning ahead. This should help with both the length and the lateness.
• Be willing to prune posts to keep them brief and on-point; don’t get caught up in tangents.
• Set intermediate deadlines to counteract procrastination.
• Set a goal for each post. Try improve on something that was lacking in previous posts.
• If recycling topics continues to be a problem, try to have something new to post in addition to the follow-up.

Wish me luck.

Is Nofollow Standard?

For some reason, I recently wondered if I should be annoyed that Web site owners are generally expected to include the non-standard rel="nofollow" attribute in links in their HTML. The problem with this thought is that calling the attribute “non-standard” is not particularly accurate. It depends on exactly what you mean by “non-standard.”

First, to be absolutely clear, adding rel="nofollow" to links is perfectly acceptable according to the HTML 4.01 standard. It passes the W3C’s validator. Frankly, though, I doubt that many people would lose sleep if it didn’t validate.

With that said, let me explain what I mean by “It depends.” When I first turned to the spec to fact-check myself, I came across the list of link types (which are the acceptable values for the rel attribute in a link), and “nofollow” isn't on it. The "nofollow" value does appear in the spec (Scroll to “Robots and the Meta Element”), but in the context of <meta name="robots" content="nofollow">, not the rel attribute. Besides, that section is “informative, not normative.”

On the other hand, there is nothing in the spec that prohibits Web developers from creating their own link types. (Whether it’s actually a good idea is another matter, which isn’t relevant here due to the widespread adoption of nofollow.) So anyone can use rel="nofollow". But there’s a catch. Here's what the section on link types has to say:

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

I have to admit that this is the first I’ve even heard of the profile attribute. Is this just a case of my own ignorance? Well, yes, but then this isn’t the most common attribute. I didn’t see it on Wikipedia, even though Wikipedia uses nofollow. My Blogger blog doesn’t use it, either. (I also didn’t see it on a handful of other high-profile sites I checked, but to my surprise they didn’t use nofollow, either, so I won’t bother listing them.) I did notice it on my Wordpress blog, though. But not so fast: In that last case, the profile attribute points to http://gmpg.org/xfn/11, which does not list nofollow.
This isn’t necessarily a problem. The above quotation from the spec says that authors “should use a profile,” and in this context, “should” has a specific meaning. The spec says:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. However, for readability, these words do not appear in all uppercase letters in this specification.

RFC 2119, in turn, has this to say:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

While I’m skeptical as to whether most site owners have actually “carefully weighed” the “full implications” of using nofollow without an accompanying profile, It’s not really that important in the scheme of things. The point is that there are “valid reasons” to use link types, and that means the spec clearly allows nofollow to be implemented in exactly the way I have observed.

All this is just a long-winded way of saying that nofollow is perfectly acceptable according to the standard, and only “non-standard” in the sense of not being explicitly included in the standard itself. The standard absolutely allows for it.

(It’s also in the W3C’s draft HTML5 spec and in WHATWG’s Living Standard, so if you’re the HTML5 type, rel="nofolow" is definitely standard. For now.)

The moral of the story, if there is one, is “Always check your facts before you complain about something.”

Ultimate Blog Success Without Pollution?

I've recently gotten inspired to start blogging. I don't mean like back in October 2010, when I was inspired to sign up for Wordpress and Blogger accounts and play around with them. I mean I'm inspired to get serious about it. That doesn't mean I'm suddenly going to be able to crank out a few blog posts every day, or even a blog post every few days. But it does mean I'm going to try to stick to a schedule and have something to deliver on a more-or-less regular basis.

What set me on this path was a post I read on Jeff Atwood's blog, Coding Horror, called "How To Achieve Ultimate Blog Success In One Easy Step":

When people ask me for advice on blogging, I always respond with yet another form of the same advice: pick a schedule you can live with, and stick to it. Until you do that, none of the other advice I could give you will matter. I don't care if you suck at writing. I don't care if nobody reads your blog. I don't care if you have nothing interesting to say. If you can demonstrate a willingness to write, and a desire to keep continually improving your writing, you will eventually be successful.

This worked for him because:

Not every post was that great, but I invested a reasonable effort in each one. Every time I wrote, I got a little better at writing. Every time I wrote, I learned a little more about the topic, how to research topics effectively, where the best sources of information were. Every time I wrote, I was slightly more plugged in to the rich software development community all around me. Every time I wrote, I'd get a morsel of feedback or comments that I kept rolling up into future posts. Every time I wrote, I tried to write something just the tiniest bit better than I did last time.

Of course, Atwood's schedule was six posts per week, whereas mine is more like one or two per month. Still, I think the concept still applies: Practice and get better.

So far, so good, until I came across something in Jakob Nielsen's excellent Alertbox column: The "Information Pollution" article contains a bit of advice that seems to run counter to Atwood's:

Let's clean up our information environment. Are you saying something that benefits your customers, or simply spewing word count? If users don't need it, don't write it. Stop polluting now.

What does this mean? Should I follow Atwood's advice and keep posting, even if a given post isn't good, in the hopes of getting better? Or should I follow Nielsen's advice and not write something unless I feel it really needs to be written?

Now, let me qualify that a bit: I realize that since I'm writing a personal blog, I'm not exactly the target audience Nielsen had in mind. In fact, his follow-up on how to avoid information pollution focuses mostly on e-mail and is geared toward workplace behavior.

Even so, it's just as much a concern for me and my blog as it is for someone writing for a corporate Web site. After all, I don't want someone who finds this blog to have to comb through a bunch of useless posts to find something helpful or interesting. I definitely don't want to waste the time of people who find my blog in search results or pingback lists only to find out I'd barely touched on the topic they wanted.

For example, when I posted my piece on SOPA, a link to that post became a response under an article to which I posted a link.When I discovered this, it dawned on me that I hadn't really added anything to the conversation beyond "Look, I'm talking about this, too!" Readers who came via that link probably left with the impression that I have nothing to say, or at least nothing important.

The good news is that Nielsen's follow-up has good advice, and much of it is applicable to everyone, bloggers included. He summarizes it like this:

Better prioritization, fewer interruptions, and concentrated information that's easy to find and manage helps people become more productive and stop wasting their colleagues' time.

The three pieces of advice I think are most applicable to me are "set priorities," Write informative subject lines," and "Write short." I can handle that. Of course, as Atwood says, none of that advice matters if I don't start writing.

So here's my game plan:

1. Commit to writing at least one blog post per month.
2. Focus on the most important things I want to say, and be okay with letting some of the other things be less polished.
3. Worry less about catchy or clever titles, and more about letting readers know what to expect from each post.
4. Know when it's time to finish a post, instead of letting it get so overgrown that even if I ever finish writing it, no one will want to read it.

Wish me luck.

Table-less Forms: A Partial Solition (Source Code)

In my last two posts, I discussed what I want to see in a table-free form and the problems I had with creating one. To recap, here's what I wanted:

• Labels lined up in the same row as form fields
• Label column that stretches/shrinks to the size of the longest label
• As little extra HTML as possible

My solution was to enclose <label>s in a <div> that stretches/shrinks to the width of its contents, and to use absolute positioning to push the <input>s nested in those <label>s outside the <div>. The limitations of that solution are:

• The <label>s' height won't stretch to fit form controls taller than a line of text, such as <textarea>.
• Since <input>s are pushed to the right, you can't put checkboxes and radio buttons before their label text unless they're outside the wrapper <div>.
• Long labels stretch the wrapper <div>.
• Multiple wrapper <div>s in a form won't line up with each other.

So with that in mind, here's my source code. First the CSS:

form { /* Add border to form as visualization aid */
 border: 1px solid darkblue;
}
form * {
 clear: left; /* don't let floated .formlineup break layout. */
}
.formlineup {
 display: inline-block; /* shrink to fit content. */
 float: left; /* Needed for backward-compatibility with IE6 and FF2. */
 background-color: lightblue; /* Visualization aid */
}
.formlineup label {
 display: block;
 position: relative; /* allow absolute positioning of children */
 padding-top: 2px;
 margin-top: 2px;
 padding-right: .5em;
 background: #CEF; /* visualization aid */
}
.formlineup label input {
 position: absolute;
 top: 0px;
 left: 100%; /* Push all the way outside the <label> */
 height: 1em;
}
/* <br> tags are used in case CSS breaks.
They create extra space when CSS is working, so hide them. */
.formlineup br {
 display: none;
}

Next, the HTML. Note that nothing outside of div.formlineup is really important for this demo; I put the extra fields there to show some of the things that need to be outside of the wrapper div in order to work. See the screenshot in my previous post to see what happens when you put them inside.

<form>
<div class="formlineup">
 <label for="name">
  Name:
  <input type="text" name="name" id="name">
 </label><br>
 <label for="address">
  Address:
  <input type="text" name="address" id="address">
 </label><br>
 <label for="stuff" style="clear: left;">
  Stuff:
  <input type="text" name="stuff" id="stuff">
 </label><br>
 <label for="password">
  Password:
  <input type="password" name="password" id="password">
 </label>
</div>
<fieldset><legend>Radio Buttons</legend>
 <label for="thing1">
  <input type="radio" name="thing" value="1" id="thing1">
  Thing 1
 </label><br>
 <label for="thing2">
  <input type="radio" name="thing" value="2" id="thing2">
  Thing 2
 </label><br>
 <label for="voom">
  <input type="radio" name="thing" value="voom" id="voom">
  <em>VOOM!</em>
 </label><br>
 <label for="long">
  <input type="radio" name="thing" value="long" id="long">
  This label is longer than the others.
 </label><br>
</fieldset>
<label for="spam">
 <input type="checkbox" name="spam" id="spam">
 Send Me Spam!
</label><br>
<input type="submit"><input type="reset">
</form>

Addendum: Sorry about the ugliness of the source code; Blogger doesn't feature syntax highlighting out of the box, and there's some investment of effort required to add it. I'm still debating whether I want to add it or just stick to using my Wordpress blog to post source code from now on.

Table-less Forms: They Are Really That Hard.

A couple weeks ago, I posted a list of criteria for what I'd like to see in a CSS-based form that emulated the nifty features that tables provided. To recap, I wanted:

• Labels lined up in the same row as form fields
• Label column that stretches/shrinks to the size of the longest label
• As little extra HTML as possible

The good news: I quickly came up with a solution that met all my criteria. The bad news: It only works with simple forms. ("I quickly came up with a solution" should have been a tip-off!) First, I'll explain what I did, and then I'll explain why it can't handle much complexity.
My solution was to nest the inputs I wanted to align inside a div, style the div so it would shrink to the width of its contents, and then use absolute positioning on the inputs (nested inside relative-positioned <label>s) to push them to the left by 100% of the width of the div.

If it sounds too easy, that's because it is. Here's what doesn't work:

1. It only works with inputs that are the same height as the labels, which means it won't work with <textarea>s, multiple-row <select>s, and probably others I'm forgetting.
2. Checkboxes and radio buttons inside the wrapper div can't be put before their labels because the positioning automatically puts the inputs on the right.
3. Longer labels, such as you might need to ue for checkboxes and radio buttons, will stretch the wrapper <div>'s width.
4. Those last two aren't problematic if you can group all your text inputs together and save everything else for the end. If you want to put anything between two groups of text inputs, though, you'll need two separate wrapper <div>s, which won't line up with each other.

I will post the code as soon as I can get it cleaned up and looking nice. (My test code is embarrassingly messy.) I also plan to revisit this project and see what fixes I can make. The checkbox problem at number 2 shouldn't be too hard to solve. Then again, that's what I said about CSS forms in general.

Table-less Forms: Are They Really That Hard?

I probably don't need to explain the love-hate (and in many cases, just plain hate) relationship Web designers have with tables. If you don't believe me, a Google search turned up this lovely presentation on presentational tables that explains the issues in a much less hot-headed fashion than what I've typically seen before. What I usually read boils down to "Tables are evil, and you should never use them."

Naturally, this presents a few problems: Some things that are easy to do with tables and presentational HTML are much harder to do with CSS and purely semantic markup. For instance, the A List Apart article, Practical CSS Layout Tips, Tricks, & Techniques outlines a few of them and offers some solutions. There's just one thing that I have yet to see done to my satisfaction: Forms.

Every technique I've ever seen for table-less forms has the problem of sacrificing some of the functionality you get with a table. Sure, they can put labels and fields on the same row and even make sure the fields all line up together. However, most of them use either a fixed width or a percentage width for the label column. A table, on the other hand, will resize the columns to fit the content.

Worse still, some of the supposedly more semantic approaches introduce extra markup. The A List Apart article linked above gives us this mess:

<div style="width: 350px; background-color: #cc9;
border: 1px dotted #333; padding: 5px;
margin: 0px auto";>
  <form>
    <div class="row">
      <span class="label">Name:</span><span
class="formw"><input type="text" size="25" /></span>
    </div>
    <div class="row">
      <span class="label">Age:</span><span
class="formw"><input type="text" size="25" /></span>
    </div>
    <div class="row">
      <span class="label">Shoe size:</span><span
class="formw"><input type="text" size="25" /></span>
    </div>
    <div class="row">
      <span class="label">Comments:</span><span
class="formw">
        <textarea cols="25" rows="8">
        Go ahead - write something...
        </textarea>
      </span>
    </div>
  <div class="spacer">
  &nbsp;
  </div>
 </form>

</div>

Admittedly, that article is ten years old, which probably explains why it's a rather extreme example. But come now, <span class="label"> rather than just <label>? Inline styles? More importantly, <div class="row">? Isn't that awfully similar, structurally speaking, to a table? I thought part of the objective was to trim the fat from the code, and this doesn't have too many fewer tags than a table. To be fair, a more recent article from 2006 does a better job (though I'm not sure why the author chose an unordered list), but still doesn't solve the width problem.

Now some people will tell you that there's no problem with using tables to lay out forms. After all, they really are tabular: Labels get one column, form fields get another. The label refers to the form field on the same row. Besides, if you look at a real form, i.e. one made of ink and paper, it looks like a table. Besides, they're quick and simple to create, which is no small consideration when time is a factor.

I agree, to a point. I've certainly used tables to line up forms before, and I feel no remorse. Even so, it's not a perfect solution. For one thing, while you can make a case that forms are tabular enough to excuse the use of tables, that isn't really the most semantic way to do it. For another, you're still stuck with table markup and form markup.

What I really want is a method that will line everything up the way a table does, stretch or shrink the label column to fit the text, and minimize the extra HTML. To reiterate, I have never seen a solution that does this, though that may very well be because I haven't looked very hard. It seems like it shouldn't be too difficult to create such a solution.

So I think I will. Stay tuned.