Posted by Kevin D Smith @ 7:29 am on April 22nd 2008

Bad Design Considered Harmful (Seriously)

There is an epidemic of bad design in this world that is more than just annoying, it’s dangerous. I’m not just talking about bad aesthetic quality of devices, obviously. I’m mean that their behaviors are badly designed as well. I think Steve Jobs nails it when he talks about design.

Design is not just what it looks like and feels like. Design is how it works.

So how could this possible lead to “danger?” I’m glad you asked. I’ve been dealing with safety devices in the home lately. Safety has taken on a new meaning to me since I moved to Tornado Alley last year. The weather in this area pretty much mandates that you have a weather alert radio to notify your of impending danger (especially at night). The other badly designed device I’ve dealt with recently is a smoke alarm. Let’s start with the smoke alarm since most people are familiar with them.

There is a smoke alarm installed in my kitchen that was there when I moved in. It works well. Too well. Any hint of smoke in the air from cooking sets it off. What happens when it starts going off for that reason? I get annoyed and remove the battery. This isn’t necessarily dangerous while I’m cooking, but I have to remember to put it back in when I’m done. That doesn’t always happen. To try to remedy this situation, I bought a new smoke alarm made for kitchens that has a “hush” button. This is a button that you press when you get “false alarms” due to cooking. Great idea! Except that it was badly designed.

I was cooking today and created a pretty good amount of smoke (no, I’m not a bad cook, some things just create smoke when you cook them). The new smoke alarm went off, and rightfully so. I pressed the hush button, and it stopped! YEAH!! Then it started to annoy me. Every minute or so, the smoke alarm let out a small chirp (basically like the chirp most smoke alarms let out when the battery is low). After a few chirps, this annoyed me enough to take the battery out. So I’m right back where I started!

If fire isn’t bad enough, weather in Tornado Alley can be even more dangerous. I purchased a weather alert radio to alert us (mainly at night) about severe weather. The first one I purchased in a very simple model and pretty well designed. It has three lights on it to indicate different levels of alert and a screen that displays what type of alert it is. It can be plugged in or can run on batteries. So what’s wrong with it? It’s too dang loud! It has the option to alert you in three different ways: light up the display, voice alert, or siren. Obviously, the light won’t do much at night; it’s not that bright. The siren is absolutely obnoxious and is loud enough to induce a heart attack in the middle of the night, so voice alert was my choice. The problem is that “voice alert” only means “partial voice alert.” Before the voice alert comes, you get about five seconds of the horrendous siren first. I’m a light enough sleeper that the voice is plenty to wake me up. I think the danger of having a heart attack by having the siren go off in the middle of the night is a bigger danger than facing whatever it is that the radio is alerting me to. Here comes weather radio number 2.

The new weather radio was much more technologically advanced. It has base station and a hand-held portion. I liked this feature because it made it handy to take into the storm shelter during an alert. Both the base station and the hand-held portion have a clock on them. Since the hand-held radio is battery operated, it isn’t affected by power outages. However, the base station doesn’t have battery backup, so when the power goes out, the time goes back to 12:00. This wouldn’t be such a big deal if it just took the word of the hand-held portion (which still has the correct time since it’s running on batteries), but the opposite occurs. The hand-held radio takes the bad time from the base station so that they are both wrong! Now I should explain that the base station is supposed to sync with the atomic click in Colorado, so it should always have the right time. But that is only true if it can actually connect to the atomic clock which brings up another design flaw.

The sensor for the atomic clock must be placed outside so that it has a clear shot at Colorado. There are conditions though. It can’t be in direct sunlight, it can’t be subject to direct moisture, it can’t solid objects between it and the atomic clock in Colorado. So it must be installed under something that gives it protection from sun and rain, but that would block the signal to the atomic clock. I give up…

I’ll definitely be sticking with the second weather radio because it has a much more sane alert than the first radio (although it does automatically turn itself to maximum volume when an alert occurs), but it is far from perfect. I haven’t even gone into the other issues that I have with it. The point is that each one of these devices annoys me enough that I consider not using them at all, which puts me in the path of danger whether it is fire, severe thunderstorms, or tornados just because of bad design. While bad aesthetics probably will never cause any real danger except to my sense of taste, design of safety devices that cause you to quit using them is dangerous.

Posted by Kevin D Smith @ 1:17 am on April 4th 2008

My New Favorite Ginger Ale

Growing up in Michigan, the only real choice of ginger ale was Vernor’s. As I would find out later in life, this wasn’t such a bad thing. After moving to North Carolina for graduate school, I discovered that not everyone knew what Vernor’s (or ginger ale in general) was all about. The grocery stores there usually only stocked Seagram’s, Schweppes, Canada Dry, and some store brands. I had never had anything but Vernor’s growing up, so I assumed that they probably all tasted about the same. I couldn’t have been more wrong. All of the other brands that I tried tasted like Sprite with the slightest hint of ginger. This is totally unlike Vernor’s which has a strong ginger flavor and a lot of bite to it. There is even a “You know you might be from Michigan” joke that goes “You know you might be from Michigan if you can drink Vernor’s without coughing.”

I did finally find Vernor’s in North Carolina, but it was very expensive (probably twice what it cost in Michigan). My parent’s would also bring some with them whenever they made a visit to see me, which made it a little expensive as well since Michigan has a 10 cent deposit on all pop cans and bottles. I did come across some other ginger ales in the Whole Foods store in Raleigh by Reed’s. While Reed’s is better than the weak stuff you get in regular grocery stores, it goes a bit overboard. The herbs and spices are too strong for my taste.

I found inexpensive Vernor’s again while living in Colorado, but alas, I was only there for a few months. Now that I’m in Oklahoma, it’s difficult to find again. However, when I discovered Pops on Route 66, I was introduced to a much better selection of ginger ales than I had ever seen before. In my first visit, I selected Dr. Tima’s Honey Ginger Ale as my first ginger ale experiment.

I didn’t hold a lot of hope for Dr. Tima’s Honey Ginger Ale due to my previous experiences with other ginger ales, but I didn’t hold that opinion for long. Dr. Tima’s Ginger Ale not only has honey in it, but that is the only sweetener in it. There are no refined sugars or corn syrups. The first taste was very pleasant. It didn’t have quite the bite that Vernor’s does, but it had a great ginger flavor. The honey introduced a warmness to offset the tang of the ginger. Overall, it’s a great ginger ale and I enjoyed every sip more than the previous one. I’ll have to sample a few more bottles of it (and the other 20 or so brands of ginger ale at Pops) to see how the taste wears on me, but at the moment, it reigns my top choice of ginger ales.

Posted by Kevin D Smith @ 10:44 pm on April 3rd 2008

THE Reason to Visit Oklahoma

I know that nobody thinks there is any reason to go to Oklahoma, and for the most part, you’d be right. Yeah, there is a wicked cool museum of banjos in Guthrie and there is even a canal area of Oklahoma City a lot like the one in San Antonio, but nothing I knew about prepared me for what I came across this weekend. I didn’t even know it, but there are more miles of Route 66 in Oklahoma than any other state. We decided to do a bit of touring around and see what there was to see. For the most part, Route 66 is just a highway like any other, but there are some interesting sites along the way. We went to the Rock Cafe and the round barn, but those were nothing (as far as I’m concerned) compared to a newer attraction: Pops.

The construction of Pops started in 2006. It is a store like nothing I’ve ever seen before. We actually drove by it a couple of times not even realizing what it was, but decided to go back and take a closer look. Boy am I glad we did. Pops is a Route 66 attraction that is basically a gas station and restaurant, but the real feature is pop (that’s coke for the Southerners). They have nearly 500 kinds pops and bottled waters. They don’t stock everything all the time, so you have to come back more than one time to see them all. The entire front of the building is covered in glass and has glass shelves lined with thousands of bottles of pop, just for decoration. Every bottle in the store is glass. If you aren’t a pop connoisseur, this is the only way that pop should be enjoyed. For me, this was a dream come true. They had pops there that I have wanted to try for years, and lots that I had never even heard of. They even had more than one kind of strawberry rhubarb pop! If you are looking for a reason to come to Oklahoma, this is it. But you’ll probably want to stop by and see the banjos too…

Posted by Kevin D Smith @ 10:39 pm on April 3rd 2008

MooTools & Garbage Collection

I’ve been working on a MooTools class for the past couple of days that makes large data tables scrollable. When the page loads, it checks to see if any data tables are larger than the scrollable area of the window. If there are tables like this, it puts the table into a scrolling div and copies the header and footer areas above and below the scrolling div, respectively. It also has the options of making the rows alternate colors and making the table rows sort when the headers or footers are clicked. I had it working quite well, but there were some performance issues.

The table I was testing with had 429 rows of 16 columns. This is a total of 6864 cells. I was taking advantage of MooTools’ getElementBySelector in many places because I needed to find th and td cells within the tbody, thead, and tfoot elements separately. This created some problems when the page unloaded. On Firefox, it was taking over 7 seconds just to leave the page. This obviously was unacceptable.

I was having trouble figuring out what the exact problem was. I’m having done a lot of Javascript debugging, and have done even less performance profiling. Luckily, the Firebug plugin to Firefox was a huge help. In fact, I don’t know how I would have figured out the problem if I hadn’t had it. I turned on profiling then refreshed my page. Firebug told me that the ‘remove’ method of the MooTools Array object was taking up all of the time. I wasn’t using the remove method, so I figured there must be some sort of garbage collecting going on in MooTools. After posting to the MooTools forum, I got the answer. Apparently, whenever you use any of the MooTools that returns a DOM node, it extends those nodes with the special MooTools methods. This means that if you use $, $$, getElementsByClassName, or getElementsBySelector, every node that is returned is extended by MooTools and must be garbage collected.

In my table, I had thousands of cells that I was accessing to implement various features. Every one of those cells was being extended and had to be garbage collected. By the time my script was finished, I had over 7,000 objects to be garbage collected when the page unloaded (as seen in the Garbage.elements object under the DOM tab in Firebug).

While the getElementsBySelector method is very handy, it wasn’t going to work for me because of the extreme number of cells in my table. I ended up rewriting much of my code to use the standard getElementsByTagName method to get around the issue. This made the code quite a bit uglier, but I guess most optimizations do. The lesson today is to be careful when using methods that extend nodes in MooTools. While MooTools is really nice, there can be too much of a good thing. I’ve heard that MooTools 1.2 does memory management in a very different way, so hopefully the severity of this type of situation will be reduced in the future.