Archive for May, 2007

The new RSpec format - testing/spec’ing in Ruby

Sunday, May 27th, 2007

The RSpec API has been changed. So some of the documentation on RSpec syntax is now obsolete, including Dave Astel’s cheat sheet.

For instance this doesn’t work in the newest version:

I got an error message saying “undefined method `should_raise’”. It should be changed into:

I looked for documentation of these changes on the RSpec website. They are apparently not that easy to find. Pelle sent me this link to a page in the RDoc that describes the built in Expression Matchers and has examples. I haven’t found a super clear description of what “Expression Matchers” are, but they seem to be what goes after “should” or “should_not”.

Is it working? Did I do something wrong? Why aren’t the doors opening?

Friday, May 18th, 2007

The button to open the doors of a “kystbanen” train I rode today has a very annoying design flaw: lack of feedback. I’ve used this type of train quite a lot, and many times I’ve seen people being confused and pressing the button multiple times to open the doors.

The train door with button.

Now, let’s say that you have used this train before, so you know that the door takes a while to open and that you only need to press the button once. So you wait patiently. They take a while to open you know this. But after a while you will realize that it’s not opening. So you press it again and wait again. Did it work now? Yes. You’re out, 10 seconds later than you could have been and maybe slightly embarrassed that you didn’t know how to operate something as simple as a door and kept the 5 other people behind you waiting as well.

Why didn’t it open upon the first button press? Because button presses are only received after the doors have been unlocked. If you press the button when the train has stopped but before the doors are unlocked, you will have to press to button again.

The problem with this door opening design is lack of feedback. The passenger doesn’t know what’s going on.

Donald A. Norman writes about this in his book “Emotional Design” (my emphasis):

An important concept of understanding comes from feedback: a device has to give continual feedback so that a user knows that it is working, that any commands, button presses, or other requests have actually been received. This feedback can be as simple as the feel of the brake pedal when you depress it and the resultant slowing of the automobile or a brief light or flash or sound when you push something.

Emotional Design

Now the dark ring in the button (as seen in the top picture with the yellow door) has some LEDs that lights up and show a green circle when the doors are “unlocked” and you will hear a beeping sound. So the designers thought of giving the passengers a cue when the button is ready to be pressed. That is at least something. And the button has a tactile feel, so you can feel that you’ve pressed the button. But there’s no feedback telling you if the button press is received and the doors are actually opening.

How could the system give better feedback? How would I have designed it differently? One way would simply have the doors open immediately with a delay of no more than one second. I’m sure that there are good reasons for the doors to take longer to open though, so let’s look at another solution.

A sound or a visual cue could provide feedback when the button press is received. For instance play a sound and let the LEDs light up in an animated circle like an AJAX type spinner Ajax style spinner. Then you would have a clue that the doors were opening and you could relax and wait.

With this small design change, the passengers would be a little less annoyed, wait a little bit less and the trains could leave the stations a little sooner.

So the lesson is: let the user know what’s going on with the system they are using. Provide the necessary feedback.

Creativity destroys… the obsolete

Tuesday, May 15th, 2007

Welcome to my new weblog: Creative Deletion. I expect to write about technology and business. Does the name sound a bit odd? I was inspired by the concept of creative destruction. The process of new, better solutions replacing the old is very interesting to me. The sum of many improvements - big or small - can have a substantial impact on people’s lives. This gradual economic development is what makes the average person of today1 richer in many ways than a king of a few hundred years ago.

Technology is something I also find very interesting. Partly because technology is valuable to people - if it isn’t valuable to people, what’s the point?

An example of creative destruction in technology is the floppy disk. New technology that lead to bigger files and new ways to transfer and store data, such as the Internet, USB flash drives, writable optical media etc., has absolutely destroyed the market for floppy disks. And it’s actually a good thing that resources aren’t put into production and distribution of floppy disks anymore. Destruction like that can be positive. And it happens “automatically” in market economies. The floppy factories are closed or converted to something else. The retailer uses the storage space where the floppies used to be for other products - or closes the shop and makes way for online shopping.

So both business and technology interest me, and so does the intersection of the two. Delivering value to people is something that marketing and usability has in common. And just like a product should be shaped for the customer, a computer interface should be shaped for the user. I consider business and product development as a an activity that is just as creative as developing computer software or anything else.

In addition to writing about business and technology in general terms, I expect to write about some very concrete technology and source code. Mainly Ruby.


1 The average person living in the western world, or rather, in a place with a high degree of economic freedom.