Administrative Debris

Since watching Edward Tufte’s critique of the iPhone a few months ago, I’ve been enamored with his demonstration and description of “computer administrative debris”:

The idea is that the content is the interface, the information is the interface - not computer administrative debris.

The basic concept would seem easy enough to grasp and is something any regular reader of this site will no doubt admire and understand. I nodded violently throughout the video, delighted to see such a clear explanation of what I thought I knew as a fundamental principle of simplicity in design. After thinking about it a bit more, though, I came to the realization that Tufte’s concept of “administrative debris” represents something entirely new for me. Or, at least, it represents a severe sharpening of existing ideas that end up providing an entirely new level clarity.

A Ruthless Definition of Superfluous

Here’s a frame, somewhere near the middle of the video, where Tufte points out an example of administrative debris in the iPhone’s Safari web-browser. He explains that the strips running along the top and bottom of the screen are poorly done because they do not flow with the content, are cartoonish, and take up too much space.

If someone had asked for a critique of this same screen a few months ago, I almost certainly would have described it as “tight design”. The strips seem quite reasonably sized, their appearance clean and non-intrusive. But Tufte is apparently measuring with a less forgiving instrument: anything that exists outside of the content, or that does not fit naturally with the information being presented, is either superfluous or ill considered and must be classified as a failure of design.

This way of considering simplicity in the design of interfaces is an order of magnitude more hardcore than any other I’ve witnessed. I’ve adopted it posthaste.

Implications for Hypertext and The Web

It struck me that Tufte’s description of “administrative debris” and its opposite, which I suppose might be called “proper interface/content integration” or an “information interface,” may finally explain my penchant for hypertext as a user interface medium for many types of information display. HTML, and the web’s basic architecture in general, is designed in such a way that demands that interface elements related to navigation and moving through content – areas especially prone to administrative debris – occur in a way that’s naturally suited to the content.

With hypertext, the information itself is the interface. The content takes center stage while the chrome and tool areas are placed in the back-seat. This inversion of priorities has created as big a leap in interface innovation as the first graphical user interfaces did to the terminal based applications before them.

And yet, these fine attributes of hypertext are regularly subverted. Since the web’s inception and subsequent boom, people have been trying to get around hypertext’s “limitations” as an interface medium: first with Java Applets and Active X controls, later with Flash sites, and today with Rich Internet Application (RIA) platforms. There was a time when sites were authored with the goal of preventing the vertical scroll-bar from ever appearing! The goal is always the same: invert the web’s superior content-oriented interface back to the GUI era and allow for the types of administrative debris so common and accepted in desktop applications.

(I suppose an exception to the generalizations above might be made for the more recent RIA technologies - they seem to be attempting to bring the superior design of the web to the desktop instead of bringing the flawed design of the desktop to the web, which just might work. I have my doubts about the current crop of platforms but the general trend seems positive.)

The Great Reduction

Needless to say, I’ve been experimenting with applying these concepts quite a bit recently (likely to the point of overdoing it) and have taken an axe to the various interfaces under my control. This site, for instance, was completely overhauled a few days ago. Many of the design decisions were based on the goal of reducing administrative debris, integrating various bits of workflow directly into the content as much as possible, and attempting to accentuate the strengths of HTML’s interface capabilities instead of perverting them.

Here is the site’s heading / navigational area before the redesign. Like most weblogs and just about every other kind of modern website, this was displayed on every page with little variation, and helped establish a common identity / theme between pages.

As you can see, I’ve always rocked a minimalist design here; classifying this as “administrative debris” is probably stretching it a bit. Nevertheless, it feels “outside” of the essential information being presented and so I’ve decided to reduce it further and integrate the same functionality more naturally into the content.

Thus, the navbar under the new design:

Beautiful, isn’t it?

This leaves us with the task of somehow integrating the functionality provided by the old navbar into the main content. I’ve moved the date and main index link into the title header of each article and moved the links to other areas into the title header of the main index:

There is now exactly one navigation element in the header area of each page and, although tiny, it blazes like the sun because it has no other navigational elements to contend with. The effect is actually much stronger than I had suspected.

UPDATE: My intention was not to argue that navigation bars / areas are bad in general or that they should always be removed. I’ve tried to elaborate a bit in the comments section.

“/admin” Considered Harmful

Another area I’ve found to be ripe with administrative debris – unsurprisingly – is the admin areas and settings pages of the various sites I operate. In many cases, I’ve convinced myself that a separate admin area or settings page ought not exist at all and that the functionality provided could be integrated more naturally with the site’s primary content. This typically requires using in-place editing techniques, popularized by sites like Flickr and del.icio.us, combined with conditional page generation based on user roles / authorization.

I’ve experimented with removing admin areas on this site and in a few places at work (there is a lot of admin debris at work). I’m typically surprised at the usability gains, especially since they often come with few unexpected or adverse consequences.

My first experiment was very simple: comment moderation. I can edit, delete, or mark as spam all comments anywhere, either in-place on an article or on the recent discussion page. This is probably a basic feature most mainstream weblog packages provide at this point. If not, they ought to.

Next, I decided to take on posting and editing articles. I see basically the same page for weblog posts and articles as non-authenticated people (like you) except mine has a tiny “Revise” link positioned directly above the article title (see Viewing a Post below). When I activate the “Revise” link (by click or via access key “R”), the page flips to the editing interface.

Administrative debris has been reduced using two different techniques:

1. The editing interface is directly and immediately accessible via the main content display instead of through a separate administrative area.

2. The look and feel of the content is integrated into the editing elements (with the exception of the body text, which must be rendered in fixed-width type while editing). Notice that the text input for the post title is apparent due to its appearance and not due to an explicit label.

I’ve picked up a few tricks for applying the second technique that are worth mentioning. Here’s a snippet of HTML from the editing page:

<form id='draft'>
  <div id='header'>
    <h1 id='title'>
      <input type='text' value='Administrative Debris' name='title'>
    </h1>
    <p class='date'>Friday, March 14, 2008</p>
    <p><a class='author' href='/'>Ryan Tomayko</a></p>
  </div>
  ...
</form>

This is identical to the markup structure used in the view page - the only difference being that the editing page has <input>s, <textarea>s, and other form controls where the view page has the content alone. This lets us automatically apply the styling of the view page to the editing controls with only a small bit of CSS:

#draft input[type=text], #draft textarea
{
    font-size:inherit;
    text-align:inherit;
    font-family:inherit;
    color:inherit;
    width:100%;
    border:1px dotted #ddd;
}

Using the attribute value inherit causes the <input>s and <textarea>s to take on the visual appearance of their containing element. A nifty little trick that works surprisingly well in all modern browsers I’ve tested (Firefox 2.0/3.0b4, Safari 3.0.4, and Opera 9.26).

The benefit of this approach is that any changes we make to the main content’s presentation through CSS will now apply to the editing interface automatically, assuming we do not alter the structure and semantics of the markup.

Stating the Obvious

It has occurred to me (multiple times) that these ideas might be too simple and obvious to even bother putting down. It seems that the line between what is and what is not administrative debris exists at one of the subtlest levels of design. As such, many of these arguments have a distinct feel of splitting hairs about them. But I’m convinced that, while each individual tweak may be subtle, reducing administrative debris consistently and properly integrating functionality with content can have an enormous impact on the overall usability of an application interface.