Access Control and Controlling Complexity

A few days ago, I prepared a Powerpoint presentation and a demo script for a Webinar. The topic under consideration was Implementing Effective Access Control.

The first thing I did was to look for a good definition of “Access Control.” As usual, Wikipedia did the trick, “Access control is the ability to permit or deny the use of a particular resource by a particular entity.” Pretty straightforward.

After defining the term, I demonstrated several different ways that our product (Likewise) provides to implement access controls. I came up with 4 different mechanisms and I know I skipped at least a couple of variations! Likewise lets you implement access controls by placing restrictions on a user account, by manipulating Cells (groups of computers), through access control lists on resources and by using group policy. There are other ways, too, based on setting ACLs on computers and by directly editing configuration files.

On one hand, we can brag about the power of our software. We’ve got enough mechanisms that we can satisfy anyone. Some customers don’t want to use group policy for non-Windows computers; fine, they can use Cell-based mechanisms. Others want a simple Cell architecture and no GP; fine, they use account restrictions or they can set configuration files manually.

On the other hand, when you step back and note the plethora of access control mechanisms, it’s hard not to think that all this should be easier to accomplish.

The real art in software development is providing power while maintaining usability. “Powerful, yet easy to use” has become such an oft-repeated mantra that it has lost all marketing value. Too many programs have promised such but failed to achieve one of the goals (or both!).

Although Apple has a well-earned reputation for delivering capable-yet-usable products, let me mention a couple of others: cars and cameras.

When I look at the dashboard of my car (one with, admittedly, more doodads than most) I note over 100 different buttons that I can press. Controls for windows, wipers, lights, radio, climate, GPS, traction control, locks, cruise control, turn indicators, telephone, parking radar, heat seaters, rear shade, etc. My car has a button that controls whether my door mirrors stick out, pull in or move in and out automatically. If I include “soft” buttons on the touchscreen GPS device, there’s probably more like 200-300 buttons.

In spite of the complexity, it took me less than one hour to learn 95% of the car’s functionality (I still don’t know how to set Address book entries without a Bluetooth phone).

I had a similar experience when I checked out the Canon 40D and Rebel XSi, recently. I was able to flip through the various exposure modes, figure out how to squeeze off multiple shots, and how to perform several other basic camera features. I dutifully noted the “CF” button on the back, but didn’t press it.

Why is that cameras and cars are easier to manipulate than spreadsheets and word processors? You can argue that the latter offer more features, but I think that 200-300 car features is probably comparable to the number of features I use in office products.

I think the key difference is whether or not people have a good existing mental model of how something is supposed to operate. I know, for example, that pretty much any non-American car is going to turn headlights on and off with some stick on the left side of the steering wheel. I’m probably going to pull it back and forth to activate the high beams. I know that there’s going to be an AM/FM band selector for the radio and that there’s going to be a button (probably, with a red triangle on it) that controls the emergency flashers. Every once in a while, I’ll rent an American car and I’ll have to hunt for a headlight know on the dashboard, to the left of the wheel. Every once in a while, too, I talk to someone old enough to remember the metal “pushbutton” on the floor that controlled the high beams on American cars until about 1970.

I knew how to operate the Canon cameras because I already own a Canon camera. Canon is smart enough to minimize UI differences between cameras. They’re also smart enough to exploit common standards or practices. The exposure mode knob is pretty standard on most cameras (with settings for “P”, “M”, “Av” and “Tv” and a bunch of icons). The “CF” button though is not. “CF” stands for “Custom Function”. This is where Canon “hides” about 25 functions that only advanced (or anally retentive) users need to access.

Cameras are a great example of the need to balance power and complexity. The Canon 40D is a formidable instrument. It provides tremendous flexibility over shutter speed, aperture control, flash synchronization, mirror lockup, picture resolution, etc. Either that or you can just put it on “P” and press the shutter.

“Software”, broadly, has no such well-defined model for how it should operate. There are some standard paradigms (for example: establish a selection and then perform an operation on it), but beyond the basics, there is too much variation between applications. For a while, we could count on “File”, “Edit”, “View” and “Help” menus but now Microsoft has gone and messed that up, too. After months of using the new version of Office, I’m still playing “find where they’ve gone and hidden my favorite operation.”

My only excuse when preparing my talk was that, at least, we only make matters a little more complicated. For the most part, the access control mechanisms that we provide are ones with which our customers should already be familiar (on Windows computers). We extend these mechanisms to work with UNIX, Linux and Mac OS X computers adding “only one” new one: the Cell concept. Here, too, we associate Cells with AD organizational units rather than inventing a parallel administration entity.

By the way, if you want to watch the recorded Webinar, you can see it here.