Inderjeet Singh's Blog

March 2005 Archives

Pulsating LED on a Powerbook: A case of UI Effects Gone Overboard

Apple is usually really good at design and UI effects. A case in point is expose', which is a cool one-key way of arranging all open windows so that you can choose the one you want to work on. When I got my powerbook first, I was in awe with all such cool effects, and attention to the details. But there is one UI effect that I will talk about here: it is the snoozing light that comes off the LED when you close the lid. Let me explain in case you do not own a powerbook. This is one of those cool visual effects that apple is famous for. When you close the lid of a powerbook, the system goes to sleep, and there is an LED that switches on. However, apple designers chose to make this LED really bright, and also made it pulsating. i.e., the lights slowly varies its brightness to its maximum and then lowers itself giving the effect of the computer snoozing. Really neat, especially for the first couple of days.

But slowly you get tired of it. Worse, if you happen to be in a hotel room, your laptop is usually in the same room just suspended. As you might have experienced, the hotel rooms with curtains closed are usually quite dark. In such a room, this light may annoy you to no end.

You might think that there might be a simple setting to switch this effect off. But no, there is none. There is pretty much no way to change this behavior other than opening up the computer and physically removing the LED. A simpler solution is to ensure that the LED is covered (with a book, or with a tape), which can be an annoyance.

Obviously this should be possible hardware-wise. The very fact that the LED can vary its intensity implies that it should be possible to control how bright this LED can get, and to turn this effect off. The electronics must surely be there.

Why am I complaining so much: afterall it is one tiny light, and I own numerous other gadgets which have bright LEDs. I guess the reason is that my expectations are for much higher standards when I am buying Apple products. Afterall, that is why I am willing to pay the premium. So, the UI lesson number one is that for our products we need to be aware of what customers expect from a product that bears our brand. The UI lesson number two is that when we put-in features which serve no useful purpose except as an eye-candy, we should provide a mechanism to disable or bypass them.

Does this light annoy you as well? Have you had similar situations with products where a seemingly well designed and reputed product failed to meet your expectation in some way? Were there any good UI lessons that you learned in the process?

Which do You Prefer: Properties or Environment Entries

J2EE applications, both Web and EJB, often need to set configurable parameters such as a timeout value, retry count, and so on. To avoid hardcoding some arbitrary values for these parameters in code, the applications need to externalize these values so that a deployer can change them without recompiling the code.

The portable solution in J2EE for such configurable parameters is environment entries as specified using env-entry in the deployment descriptors for a Web or EJB module. Here is an example (from Java BluePrints Adventure Builder Reference application):

<env-entry>
    <env-entry-name>param/OrderStatusTimerInitialExpiration</env-entry-name>
    <env-entry-type>java.lang.Integer</env-entry-type>
    <env-entry-value>1</env-entry-value>
</env-entry>
</code>

However, the same can also be achieved by using properties. Essentially, the developer externalizes these values in a property file, and loads up the properties at runtime. There are issues such as how to portably specify the location of the property file. If the property is not expected to be changed much (so a recompile/repackaging is okay) then the property file can be bundled with the classes, and then it can be portable looked up. If the properties are expected to be modified at deployment time (or later), then it gets tricky since then you need to ensure that the property file is available at a certain location in all deployments. This is often an annoyance even while developing the application, when more than one developer are working on the codebase, since the filepaths are often different for different developers.

The big advantage of using env-entries is that they are portable, and can be easily changed at the deployment time using the deployment tool provided by the application server. The main advantage of properties is that they are really simple to write, and avoid dealing with the deployment descriptors. It is also possible to write code such that the properties are allowed to change even at runtime.

So, which do you prefer, properties or enviroment entries?




This work is licensed under a Creative Commons License.