I was reading an article on Foreign Policy, and encountered a lovely little design decision that I thought I’d highlight as something not to do. Their visual cuing for links sets a different color for the text (quite normal) and bolds it (not so normal). This latter change, in my view, breaks the user’s expectations on semantics in some really unfortunate ways.

Here’s what I mean: we expect bold text to indicate increased importance, and with a few decades of experience we expect altered color to indicate a link. The problem here is that both are in play. You can occasionally get away with breaking the user’s expectations, but in this case the result is that every time there’s a link I interpreted the text as being emphasized. It wasn’t; it was just bolded because it was a link.

The lesson here is simple: keep your semantics clean and distinct. If you have a reason to override the user’s normal expectations, that’s okay, but you should have a very good reason for it. The rest of the time, don’t use bold when you really mean link. Similarly, you shouldn’t normally use color or underlines for emphasis; those have established semantic meaning on the web; when you use them to other purposes it’s just confusing.

A friend and fellow web designer and developer (indeed, someone who gets to do a lot more front-end design) recently asked me,

Chris—what do you think of “responsive” layouts? I’m not a big fan. In theory, it’s a good idea. But it makes it difficult for ad placement, and in practice, I don’t know that anyone really needs five different “views” for a site based on browser width/height.

So, some thoughts from a guy who’s done a lot of reading, a lot of watching, and – alas – a lot less actual implementation than he’d like in the last year. (In other words: take these words with a grain of salt; they’re observations on watching others in the process as much as they are born of my own experience.)

I think responsive design is a great idea, but it has to be done carefully and thoughtfully, especially when considering ad placement. Read on, intrepid explorer →

Dear Avid,¹

Monday, after noting that my copy of Sibelius 5 would not install on my new MacBook Pro – no surprise, it is after all 5-year-old software – I looked for some solutions online. It became clear that I wouldn’t be able to get it going, so I started looking at upgrading to Sibelius 7, about which I’ve heard many good things. Upgrading was an easy decision: I’ve had nothing but good experiences with Sibelius since I bought a copy of Sibelius 3 back in 2004.

Along the way, I stumbled on this blog post by Daniel Spreadbury. Curious what he meant by “the recent news about Avid’s corporate restructuring”, I followed the link.

By now, I’m sure you can see where this is going: like many other long-time Sibelius users, I’m more than a bit disgruntled by the news. Read on, intrepid explorer →

In the last few years, I have seen a little great code, some good code, a lot of mediocre code, and overwhelming amounts of bad code. (A shocking amount of my own code from previous years – especially when I was just starting – goes in the last two categories, alas.) The longer I have been at it and the more I have read (whether random articles on the web or the excellent Code Complete), the more I have concluded that good programming is simple. Incredibly hard, but simple. In fact, it is so simple, that you can sum it up in three short, easy to remember rules:

1. Write code for people, not for computers.
2. Don’t repeat yourself.
3. Only do one thing at a time.

Read on, intrepid explorer →

We’re quickly approaching Google+‘s first birthday, and the search giant’s social media platform has found a core audience, but it has never caught on to the extent that Google hoped or the tech media hyped early on. That core group of tech enthusiasts has certainly put it to good use, with voices like Tim O’Reilly finding an even broader audience and a medium that suits him well.

For most of the population, though, Google+ was a novelty that never went anywhere. Read on, intrepid explorer →

One of the joys of corporate IT policies is seeing how things break when you’re in an unusual configuration on the web. Like, say, running Firefox behind a corporate proxy that tells every site out there that you’re actually running IE7. This morning, I paused from other tasks to read an article on a well-known religious commentary website, and saw a message at the top alerting me that I’m using an out-of-date version of Internet Explorer (which I would be if I were running IE… but this is on a relatively up-to-date version of Firefox).

Bad enough that for whatever reason our corporate IT has taken to spoofing outgoing traffic this way when routing through their proxies. (One wonders just how much of the reported IE6 or IE7 traffic on the web comes from this sort of thing.) But the real problem is that the site I visited was broken. Horribly, horribly broken.

That message – “You’re using an outdated version of Internet Explorer” – told me why. Read on, intrepid explorer →

I’ve spent a fair bit of time recently working on a project that, all things considered, really shouldn’t be that difficult. A client wanted a change made to his web application, a change that is simple in concept and – in theory, at least – should be equally simple in execution.

But it isn’t, and it’s not because of any hidden complexity in the task itself. Rather, the problem is that the code base for the web application is, to put it bluntly and without a hint of hyperbole, awful. I’ve worked on a fair amount of legacy code on various projects, in various languages, over the last few years. This one is the worst.

Individual functions hundreds (perhaps thousands) of lines long. No comments. No object orientation to speak of. Hackish solutions to problems all over the place.

But this isn’t a complaint post. It’s a request to the thousands of people in the world who are tempted to say, “Well, this will work for now…” Some of you are developers yourselves; others are simply dabblers. Whoever you are, whatever your context, whatever your project: there is a problem with “This will work for now,” and that problem is called tomorrow. Read on, intrepid explorer →