LarryRoth.net

If you manage an Apache based Web site that requires user authentication you may be familiar with using htaccess and the following in your site configuration file.

<Location /private >

   AuthType Basic

   AuthName “Realm name”

   AuthUserFile /etc/apache2/users

   Require valid-user

</Location>

If you are not familiar with this nomenclature, it will cause a pop-up username/password box to appear and grant access only if the username and password exist in the htaccess file. The downside to this approach is user management. Each user needs to be entered via command line or through one of a few available Web apps that help automate the process. In addition, you don’t have any information about the user except a name.

You can of course use application layer authentication and authorization, but it requires lots of extra code, you need to manage the data yourself, and can’t easily protect all your Web assets such as images.

I have been using a third approach—authentication against an LDAP server. The benefits are:

• More available options and application for account management
• More information available about users
• Standardized account information can be shared with other apps

It was easy to setup. All I had to do was enable the Apache mod_auth_ldap module, and add the following to my configuration file:

<Location /private >

   AuthType Basic

   AuthName “Realm name”

   AuthLDAPURL ldaps://www.foo.com:636/cn=users,dc=foo,dc=com?uid

   Require valid-user

</Location>

Actually, you can see it’s only a one line change over the htaccess approach. I should mention that the above ldap url format works with Open Directory running on Mac OS X server. The ldap url you use will depend on your particular LDAP server and setup. The uid is used by Apache to map to the server variable: username.

For my use—in-house Web apps—it’s been great to start authenticating users against the internal LDAP we use for our mail server. It’s not exactly a single sign-on solution like Kerberos or NTLM—the user still has to enter their username and password for each site—but at least they don’t have to have a separate username for each site.

The hardest part is getting the ldap connection string correct. Once you have that figured out, the rest is easy!

I found this tip: (Two seconds to sleep) on the Apple site. As my new MacBook Pro doesn’t go to sleep when I shut the cover, it is very helpful. Here is the tip:

Want the fastest way to put your Mac right into a deep, sleepy-bear hibernation-like sleep (no whirling fan, no dialogs, no sound — nuthin’ — just fast, glorious sleep). Just press Command-Option and then hold the Eject button for about 2 seconds and Zzzzzzzzzzzzzz. It doesn’t get much faster than that.[1]

meta-footnote-1= Apple – Pro – Tips – Two Seconds to Sleep, http://www.apple.com/pro/tips/quicksleep.html, viewed July 5, 2006

When conducting a usability test, it is common practice to follow a procedure similar to this:

• Create user scenarios
• Prepare tasks
• Observe various users while executing these tasks
• Mark successes and failures
• Look for patterns and areas of concerns and provide feedback to the application owner

I have always found one of the toughest tasks to be defining what is a success and what is a failure—it’s not always cut and dry. And this is defining success/failure from the test perspective. But I recently began to think it is even more difficult to track what is a success/failure from a user’s perspective. Why would that be? Why wouldn’t they be the same? Don’t we ask users if they feel they have completed a task? Well, when we define a success, it is really limited to a task, but the user may see that task as a larger process. Let’s take an example.

I recently booked a room at a national hotel chain using their on-line reservation system. When I arrived at the hotel, I found out that both the rate and the number of guests differed from my confirmation sheet. It turns out that their reservation system faxes the information to the hotel property and that information is then manually keyed in—leaving obvious room for error. In my case, the error was rectified politely and professionally, but it made me think about what makes a usable experience. It made me wonder about a successful task vs. a successful process and what the perception of the user may be.

In the example of a hotel reservation system, if I had been asked to conduct a usability study I would have focused on the reservation form(s) and made sure that users could complete the task of reserving a room for a specific property on a specific day. If they could, I would have thought of it as a success. And that may be fine for the purposes of the usability test. But stepping back and examining the experience from a users perspective, the task may not be a success until they are actually in their room!

I know what your are thinking. First off, there are a lot of “what ifs…” here, and secondly, it certainly isn’t the goal of a usability test to identify such broadly scoped successes or failures. I agree with both of those statements, and I am certainly not proposing larger, more involved testing—unless someone wants to fly me around the country trying out reservations at 5 star hotels!

Seriously, my point is that as usability experts, it’s our goal to remind the client that we are testing very granular tasks to a sometimes much larger process. While we may help to remove all the barriers a users encounters, the user will be judging the process as a whole, and there may be some hidden barriers that can’t easily be tested. Thoughts?