Creative Deletion

PNG transparency doesn’t work in Internet Explorer 5.5 and 6.0. Fortunately there is a fix from Twin Helix, which essentially a little piece of java script that makes PNGs work on MSIE version 5.5 and 6.0.There used to be a problem with the Rails image_tag because it adds parameters to the URL and the fix-script didn’t handle that. But this has now been fixed in version 1.0 RC5 preview 2.

Here’s a guide on how to make it work in Ruby on Rails.

1) Download the IEPNGFix v1.0 RC5 Preview 2 (iepngfix.zip) file from http://www.twinhelix.com/test/ and extract.
2) Create a directory called “iepngfix” in your rails /public/images directory and place the file blank.gif there
3) Place iepngfix.htc in the /public/javascripts/ directory
4) Add this line to your CSS:

5) Open the /javascripts/iepngfix.htc file and change the line that says

(line 15) to:

That’s it.

Troubleshooting: Make sure that the height and width parameters are not missing from your IMG tags.

My grandfather complained that the weather widget on his Macbook was inaccurate. No wonder - it’s displaying what the weather is on a different continent! Not a good user experience. After setting up the location and timezone of Copenhagen, Mac OS X automatically adds a weather widget for Copenhagen.

The widget on the left in the following picture is what is displayed as default. The one on the right is a widget where I changed “Copenhagen” to “Copenhagen, Denmark” and degrees F to degrees C:

89 degrees on Wednesday, that’s a lot for Denmark. Water boils at 100 degrees. Oh wait, that must be Fahrenheit. Like every other country in the world, except one, Denmark measures temperatures in degrees Celsius. In the widget settings you can change the units to degrees Celsius though. But if you don’t look out the windows to see what the weather is like you might not notice that something is very, very wrong.

There is a small village in the middle of nowhere in upstate New York named Copenhagen after the capital of Denmark. If you don’t change the default “Copenhagen” to “Copenhagen, Denmark”, the weather displayed is from the small NY village. The problem seems to be that AccuWeather, a service that the widgets are using, ranks American locations higher than others. For instance if you type in London, “London, AR” is proposed. I wonder if Londoners have the same problem. Do they get Arkansas weather by default?

There are many other cases of multiple towns or cities with the same name. I’ve lived in Portland, Oregon which is named after Portland, Maine. Today, if you just say “Portland” most would assume Portland, Oregon (the World Clock widget in OS X does). I can see why the people in Portland, Maine might get upset that another city has the same name. But in the case of Copenhagen there should be no contest about which city is the “true” Copenhagen. Most people would assume that when you say Copenhagen you’re talking about the capital, which, among other things, has a bad ass metal named after it (period table 72) - not a tiny village in the boonies.

What if Steve Jobs was going to Copenhagen and he wanted to know what the weather was like? I don’t think he would be happy about getting a weather report from NY instead. (Some might say that he would pack black mock turtlenecks and Levi jeans no matter what the forecast would say, though.)

This is an example of computer systems trying to be clever and helpful, but where the user would be better of without the artificial cleverness. Defaults are great if chosen with care. In this case it would be better if the default city of the weather widget was a foreign city - San Francisco for instance. You would might confuse “Copenhagen” with “Copenhagen” [sic], but not with “San Francisco”. And when changing the widget to display Copenhagen weather instead you would be presented with a choice between the different Copenhagens of the world. Rather that, than to be mislead into thinking that you’re presented with the local weather, when you’re not.

Apple, you should fix this.

On a project I’m working on were are two developers. To keep track of the gems needed, we had a file in the root rails dir called GEMS.txt with a list of gems. Then I thought: verifying if I had the right gems installed is a repetitive task the computer should do for me. So I converted the text file to a YAML file, GEMS.yml, that looked something like this:

# Required gems
#
# Version example: version 0.7.5 or higher: ~>0.7.5
# Version example: exactly version 0.7.5: =0.7.5
-
  name: diff-lcs
-
  name: ZenTest
-
  name: RSpec
  version: =1.0.5

This means that you need any version of “diff-lcs” and “ZenTest” and exactly version 1.0.5 of RSpec. You would probably have more gems in there, but I’ve kept the list short for this blog post. Let’s say that another developer has added a new gem to GEMS.yml or changed the required version. Now you simply run “rake check_for_gems”:

$ rake check_for_gems
Gem found: diff-lcs 1.1.2
Gem found: ZenTest 3.4.2

2 of 3 required gems found.
Warning: Gem not found: RSpec ~>1.0.5

Either you don’t have the gem installed at all or you don’t have the correct version. So you install the correct version of the gem and now when you run “rake check_for_gems”, you get “3 of 3 required gems found.”

This is the source of the rake task: You can copy paste and save as lib/tasks/check_for_gems.rake

It’s just a simple tool, but it scratched an itch and was quickly made. Ruby is not only great for web applications on Rails, but also for small scripts like this.

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”.

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.

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.

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 . 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.