A notch above a monkey

Website soundtrack

I’m not ashamed to admit, although I maybe should be, that Thursday evenings are reserved for TV. I’m a sucker for good detective series and it’s then when most of them are on. I haven’t really noticed until recently how important a theme song is to set the mood and I got to think more about it yesterday, while watching CSI: NY (by the way, CSI: Miami is just crap and should be scrapped).

Shouldn’t every website and program have its own soundtrack?

I’m not talking about annoying muzak of flash intros. I despise them as much as the next person and much good would be done if they all disappeared tomorrow. I’m thinking of soundtracks more as a development tool. When we are building stuff (websites, programs or whatever), we try to imagine things like who our typical user will be and what kind of mood or feeling are we trying to provoke, which is not always easy. It’s easy to create a bland descriptions alright, but I find them of limited help when trying to really imagine, to connect with what they’ll experience.

We all listen to music that talks to us. And it also talks about us. Isn’t it sometimes just easier to describe what we are trying to do with a song or two?

If we did that, what would happen when listening to them while using the website?

I think a good website would blend with a soundtrack previously made to capture its emotional experience. If it doesn’t, then there’s a problem and if I’m sure that soundtrack is just right, then I should change my website until I don’t feel a dichotomy anymore.

We got a winner...

Quirksmode blog has announced the winner of addEvent competition. Announcement was immediately followed by a lively discussion and it seems javascript community is not persuaded. Neither am I.

I’m not happy with the code I’m using right now and I was hoping to replace it with the winner. However, I do believe there are real problems with winning entry, so I won’t be using it quite yet.

When to use degradable Javascript

Justin Palmer wrote about myths of Javascript degradation and Jeremy Keith has written a response. This is just the lastest, but certainly not last exchange on this topic and I think we’ll continue to talk about it for some time to come.

I think I find myself somewhere in the middle. Part of our service follows Jeremy’s school of thought and part of it is firmly on Justin’s side. I think Jeremy’s argument that the problem is due lack of planning is just wrong. I spent literally months contemplating and trying different things before I finally accepted that not everything can be done in nicely degradable manner without making sacrifices.

Or to use a misplaced example. You can start with a bicycle that more or less everyone can use and try to add features, that will enable it to go faster and with less physical strain, but you’ll never produce a Ducati . At most you’ll finish with something like:

Electric bicycle
I’m not saying electric bike is bad. In fact it has many features that Ducati will never have. They are just different and what’s better depends on what you want and who you want to serve.

I believe the same applies to Javascript degradation. You have to decide what you’re building and for whom. When developing our service, I probably haven’t thought about anything more than this issue and the choices I made were certainly not done lightly. I did discover a simple question, that often makes such decisions easier:

“Would anyone ever want to bookmark this?”

If yes, then degradable javascript is the only acceptable solution. If no, then there MIGHT be a case for non-degradable solution, but it certainly doesn’t immediately justify it.