Technovangelism

When designing a programming language what should evaluate to false? Why not make life easy and only allow the boolean value false to evaluate to false like C#. Or why not make developers write less code by allowing null, 0, and empty lists to evaluate to false? The latter seems like a useful rule because it should allow the developer to save time by writing significantly less code, and less code is always a good thing, right? Why write if (list.Count > 0) when you could just write if (list) ?

I have often been confused by ruby’s decision to evaluate nil as false. Mostly because all objects have the method nil? which allows for a much faster to check then writing if (obj == nil) but of course much slower than writing if (obj). When all objects have the nil? method, why not trade the four extra keystrokes for a little more verbosity to make expressions that much clearer? When I write ruby, I prefer the use of the nil? method to evaluate whether an object is nil. And thanks to the unless conditional, I don’t even have to use the bang operator when I want to know when an object is not nil. This amount of immediate readability might be a little extreme, but I have found it quite helpful.

When do the benefits of saving developer time outweigh the problems caused by lack of verbosity? When you multiply the number of keystrokes saved per expression, by the millions of times if statements and while loops are written every day, a significant amount of time is saved when more things evaluate to false. But what about the amount of developer time that is wasted trying to determine exactly what is supposed to be evaluated? When is it truly worth it to make a developer’s life easier and how can one measure this?

I had an interesting experience last week at a Smithfield’s restaurant. I walked up to the cash register and was asked for my lunch order by the cashier and before I could answer, another employee behind the counter asked me what I wanted to drink. I was a bit confused for a few seconds because I hadn’t made any sort of order yet. How did the other employee know I was going to order a drink or what size I wanted? After being lost for a couple seconds, I turned back to the cashier and ordered the way I order at any other restaurant. While waiting for my food, I watched some local customers handle the same situation much better than I. They managed to order a drink and their lunch in parallel with two different employees without any hesitation.

Of course the first thing this made me think of was software. I can’t stand it when I start using some software for the first time and have no idea what to do. Even though you eventually learn how to use the software, your experience is still tainted from the initial difficulty. If the software is a website, the developer would be lucky if the user stuck around long enough to attempt to learn. Software that caters only to the advanced user is never going to have one. Luckily for Smithfield’s, my experience wasn’t bad (at all) enough prevent me from going back, but it is a potential risk they might not realize they are making.

Another restaurant with a strange user experience is Gates Bar-B-Q. Here cashiers take your order while you are only half way through the line. Normally this would not be a problem, except they do it by yelling to the entire line and not looking directly at the person whose order they are trying to take. So if you were not paying attention to when the people ahead of you ordered, good luck figuring it out.

When trying to advertise your website, particularly on television, how should your url be displayed? There is a big debate about whether or not a site should be accessible without the www subdomain and that should apply to displaying your url as plain text as well. If the homepage of your site is at www.example.com, should you advertise your site exactly as it will be seen in the browser (http:// included), as www.example.com, or can you get away with just example.com? And what about the styling of your url when it is displayed in text? Is it ok to use multiple colors? Will different colors and combinations affect readability or a reader’s ability to recall the url?

I recently saw a commercial advertising the Art Institute of Raleigh-Durham. In the ad, the url was displayed like this aidurham.com. I assume they do this because the red “ai” matches their logo, but at first glance in the commercial, all I saw was durham.com. Only after it flashed on screen a few more times did I notice it was really aidurham.com. I suppose the red “ai” prevents me from thinking I’m visiting “aid ur ham.com,” but the price paid in losing a visitor to the wrong url is not worth having your url match your site logo simply for styling purposes. I’ve never seen a flickr add on television, but do you think it would display the url like this flickr.com? With a different colored “r” it would be far too easy to completely miss it and think the website address is flick.com.

A website address should only be displayed in one color. Even if the address is made of multiple words, it needs to be in one color so parts of it are not lost. If you are worried the words won’t show through and will make memorizing the address difficult, saying the address aloud will let the viewer know how to break up the address properly so he can remember it for later. The aidurham commercial repeatedly said “a-i-durham.com” and this would have been plenty to let the viewer discern the correct url, but using different colors was enough to undo all of the work saying the address aloud did.

When building a web site where each page is roughly mapped to a row in your database, what do you do when the requested row is not found? When using Rails, I found the standard method of handling such a situation is to rescue the ActiveRecord::RecordNotFound exception, and display a flash message explaining what happened to the user. When writing a Django application, I found myself raising the Http404 exception, which would render the 404 page, whenever the requested record could not be found. Of course there is no reason why the Rails approach couldn’t be used in a framework like Django. I just simply found it easiest to raise an exception and let the framework handle the rest of the work.

Which is the better approach? Raising an exception to display the 404 page is certainly easy and it also seems most accurate with regard to the meaning of HTTP error pages. But does it provide the right experience for a user? With the Rails approach, a more useful message error message can be displayed on a page that could help a user try to find what he is looking for. This would also help your application crash responsibly, although a 404 is not exactly the same as a crash. Giving the user more information than simply “not found” should improve the experience of using your website. And although I expect you to code perfectly so that the only way to get a 404 is type manually type a bad url into the browser, a good recovery mechanism is well worth the effort.

And don’t forget the MediaWiki approach to pages that are not found: a page is not found because you have not edited it yet!