Intuitive user interface design failure… when a doorknob isn’t.

Sometimes, designing an intuitive user interface takes only stepping away from the project, and trying to think about how someone else might try to use an object. Most of the time though, you really need to see how the interface is used in the real world. The very best example I can think of this involved a so-called “inactive” doorknob. It was the door to a closet in an apartment that I rented.

For nearly two months, I was unable to open the door, instead thinking that perhaps management had located a hot water heater or some similar utility behind the door, locking it away from tenants. Inactive Doorknob

It looked like a doorknob, but it didn’t act like one. It didn’t turn, and it didn’t latch. Instead, I found the doorknob worked like a handle on a cabinet rather than the usual doorknob. One needed only to give the knob a firm tug and the door would open.

On paper, and to those that installed the knob, it probably made perfect sense. But to me, who had never seen that kind of doorknob, it was not an intuitive interface.

These are the kinds of things that can be easily worked out through user testing.

Windows 8-bit 256 color palette

Some people like to say the internet is forever. Unfortunately, it’s not. I recently needed to track down a 256 color Windows system palettes from the Windows 95/98 era. In less than 20 years, the internet has all but forgotten what the color palette might have been.

This is my best attempt at reconstructing it from various pieces of information I was able to find around the web. This is a true-to-color gif image, so the color values haven’t been corrupted by downsampling.

The actual color values can be downloaded here.

256 color 8-bit Windows system palette

JAVA Diamond Square Generator

For a proof-of-concept GLSL shader I’ve been working on, I needed a random Diamond Square texture as input; a little bit of work yielded me this JAVA applet, which I then was able to easily fine-tune for my needs: Source Code: (Download)

Magic Triangle w/Kerberos in OS X 10.6

I was recently handed the task of integrating Mac OS X 10.6 into our so-called Magic Triangle authentication environment. To make things more interesting, Macs here are treated as UNIX workstations, and thus not bound to AD.

A quick search on Google yielded a long discussion on Kerberos support (or not) in Mac OS X 10.6 on RedHat Engineer Vincent Danen’s blog, and eventually to a his Wiki discussing Kerberos on Mac OS X

I’ll summarize the relevant tips here:

  • /etc/krb5.conf is /Library/Preferences/ on Mac OS X
  • /System/Library/LaunchAgents/ should use -R instead of -B (to auto-renew tickets)

Thanks to Apple’s support of Open Source, I was able to check out the source code for the module that they use in OS X 10.6. With this, I was enable to enable debugging in a custom application and determine how to get authentication working.

Apple has some additional tips here:

Distributing a single screen saver for 10.4, 10.5 and 10.6

In an earlier post, I discussed some Xcode settings that would simplify creating a Universal Binary screensaver that would run on all three versions of Mac OS X. Since that post, I’ve run into some problems and had some feedback, and discovered additional possible problems and solutions.

First off, there are a confusing number of settings related to architecture and SDK selection:

    Settings in the pop-up in the upper-left of the Xcode window:

  • Active SDK – affects the -isysroot argument to gcc
  • Active Architecture – affects the -arch argument to gcc
  • *above ONLY if the “Build Active Architecture Only” box is Unchecked in the Project Info
  • Settings in the Project Info, under the Build tab

  • Base SDK (SDKROOT variable)
  • Mac OS X Deployment Target (MACOSX_DEPLOYMENT_TARGET)

Further, within your code, you may reference the following two macros:


Through reading Apple’s documentation and a process of trial and error, I have come to the following conclusions:

  • MAC_OS_X_VERSION_MIN_REQUIRED is based on MACOSX_DEPLOYMENT_TARGET, and is the minimum version of OS X which you can expect your code to run on. This is generally based on the Base SDK setting above.
  • MAC_OS_X_VERSION_MAX_ALLOWED is the latest version of the Mac OS X API that you code uses native APIs from. This is generally based on the Mac OS X Deployment Target setting above, unless the Active SDK setting is less than the Mac OS X Deployment Target.
  • Because of the above side-effect, it seems the best practice is to leave the Active SDK setting to the latest version of the Mac OS X SDK your program will run on, regardless of architecture.
  • APIs between MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED will be weak linked.
  • For more complete documentation, read up on Apple’s Technote TN2064

Here’s an example of the settings that I now use: