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.

Tufte points out iPhone admin debris

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.

My site's navbar, one week ago.

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:

My site's navbar, today.

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:

New Header Navigation

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.

Viewing a Post

Post w/ Revise Button original size

Editing a Post

Posting Interface original size


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.

Discuss

  1. Wow, this is pretty interesting. The new design looks very nice, by the way. I like how it stays out of the way and such. I've been planning on redesigning my own site and I've been thinking about a lot of this stuff too.

    — Adeel Khan on Friday, March 14, 2008 at 02:18 PM #

  2. “It has occurred to me (multiple times) that these ideas might be too simple and obvious to even bother putting down.”

    This was an excellent read and I'd like to see more material with just these sort of ruminations. If you know of anyone else giving serious thought to this kind of material, please share!

    — Jason Perkins on Friday, March 14, 2008 at 02:27 PM #

  3. Good ideas, but I think this can be taken too far. It seems to me that Tufte is arguing from abstract ideals. In a fight between him and Jacob Nielsen, I’ll always bet my money on the latter.

    F.ex. I’m not going to be removing the breadcrumb navigation from the $job app. Also, I added administrative debris (a tool box on every page) based on the fact that users complained when they weren’t sure which links would take them elsewhere and which would let them act on the current location or the change their view of it.

    It’s all well and good to talk about increased usability when it’s yourself who built the interface – the hallmark of usability, though, is how well other people cope with the UI.

    What makes Tufte’s ideas worthwhile is how relentlessly he challenges many ideas that would be taken for granted by most people simply because that’s how every one does it.

    But Tufte is the inspiration; Nielsen is the measuring stick.

    — Aristotle Pagaltzis on Friday, March 14, 2008 at 07:50 PM #

  4. Aristotle: agreed. I'm not sure that things like breadcrumbs and tool boxes necessary == “administrative debris” all the time, though. If you consider how best to fit those functions into the primary content instead of just punting and slopping them onto the page somewhere, then I think you’re fine.

    I'm going through the same thing at work. I can’t really remove the functionality, and its not always obvious how it might be better integrated, but just the fact that I'm developing an eye for things that don’t fit has been really interesting.

    — Ryan Tomayko on Friday, March 14, 2008 at 09:25 PM #

  5. Thanks for another great post. This kind of stuff keeps you at the top of my read list.

    — Vincent Murphy on Saturday, March 15, 2008 at 12:01 AM #

  6. Good work! I've always enjoyed reading this site because of quality content and cleanliness of design, and now it got even better.

    — Mislav on Saturday, March 15, 2008 at 12:52 AM #

  7. Goddamn you, I spent so much time trying to make a simple interface for my blog and now you make me feel like it’s full of cruft :)

    — Leonardo Boiko on Saturday, March 15, 2008 at 05:20 AM #

  8. Great post! I'm not sure I agree that the link at the top “blazes like the sun”. I didn’t pick up on it, but that could be years of web usage that makes me look for a navigation. Still, it’s a good exercise for the brain to try and take a site down to it’s bare interface essentials and integrate those into the actual content.

    — Don on Saturday, March 15, 2008 at 08:01 AM #

  9. hmm, interesting concept… will try to incorporate it in my own stuff..

    — sDf on Saturday, March 15, 2008 at 04:42 PM #

  10. Very interesting. However, agree with Don about the top link – I thought it would link to an email address or contact form so didn’t click on it until I'd read in the article that this was the ‘Home’ link. I think that’s largely because it’s positioned like a byline; feels like it should go above the article title since it’s at the top of the information hierarchy.

    — chu on Sunday, March 16, 2008 at 04:31 AM #

  11. Very nice new design. But i still have to stick with my greasemonkey script that changes the layout to be centered here. Is there a way to make that the default? :D

    — Armin Ronacher on Sunday, March 16, 2008 at 11:58 AM #

  12. Love the new design. Search is lost at the bottom, though. Otherwise, close to perfect. Cheers!

    — Christian Romney on Tuesday, March 18, 2008 at 09:28 AM #

  13. Christian: search should start filling back in once GoogleBot fully assimilates all of the 301s :) Or, did you mean that the box is just kind of out in the middle of nowhere down there?

    Thanks for the feedback, either way.

    — Ryan Tomayko on Tuesday, March 18, 2008 at 09:49 AM #

  14. Awesome post, as usual. Clearly the edit-in-place stuff is a win; I'm not yet sure about the missing navbar.

    — Kragen Javier Sitaker on Tuesday, March 18, 2008 at 03:09 PM #

  15. That inherit+embedded controls approach is really nice. I’m gonna use that one.

    — Bill Burcham on Wednesday, March 19, 2008 at 02:16 AM #

  16. Hmm (me thinking)… You see, I like the idea of the controls for editing the content become part of the content (“edit-in-place”). Sort of. But. For one thing, let’s start with the iPhone screenshot. Given, I haven’t read Tufte’s piece yet, but de facto standardized navigational controls can’t be looked upon as “cruft” or “debris”? I for one wouldn’t want the back/forward button in my browser to be left for customization by the web site I'm viewing.

    Interfaces should be there for a reason. I don’t expect an editing interface on a blog as a reader. But as an editor/writer I might expect something different.

    I realized through comments, but… Yes, having a search interface at the bottom right of your articles really does not encourage people to discover information. If I were looking for something specific on your site without knowing it’s ins and outs I probably wouldn’t have discovered the search interface.

    I should mention, on a positive note, that I haven’t really thought about the positives of “inherit” in this way until now. =)

    — Frode Danielsen on Thursday, March 20, 2008 at 04:29 PM #

  17. I've never been a fan of mixing the administration interface with the front-end interface, having found a properly designed administration interface to be faster to use. In the case of a blog it’s less likely to be a problem (the information you edit is laid out on the page in a similar way) – for data tables it’s a different story :)

    The main problem for me has always been navigation – in the admin I can need to jump quickly between pages/records to make updates. Thinking about it though, that may mean the front-end navigation isn’t up to scratch if it’s quicker in the admin area – but I doubt site visitors need the same navigation paths as would suit an administrator!

    [An aside – being able to subscribe by email for follow-up comments would be great, so I can continue interacting with the website]

    — Peter Bowyer on Thursday, March 20, 2008 at 09:42 PM #

  18. I think this is a great idea, and you've done a good job implementing it on the site. I have to admit it was weird not seeing a nav bar at the top and took me a second to realize that the link with your name wasn’t an emailto (which is usually what you expect when you see a name marked up with a link). It did make perfect sense though when I realized if their was a link to the main page that was the only one it could be.

    A more practical question would be how simple is too simple? Even if you accept that the interface for the iphone has debris, there might not be any good way to remove them and preserve their functionality. You certainly can’t modify the content of the web page. Even at their most unobtrusive, they will still be debris, and they will still be necessary.

    — Jared Lynem on Friday, March 21, 2008 at 03:56 AM #

  19. I like the idea of inheriting style for edit-in-page – it seems like a great substitute for the problematic provision of a rich-text editor and then stripping out much of the formatting that the RTE will let users do by presentation time.

    I note though that the comment box in which I'm typing isn’t inheriting font…

    — Dave on Friday, March 28, 2008 at 03:16 AM #

  20. Dave: good idea! I never considered trying to make the comment form fit the content better but I will when I get a sec.

    — Ryan Tomayko on Friday, March 28, 2008 at 06:05 AM #

  21. Hello, Ryan! This is my first time here — I'm adding it to my reader. I had a surprise about “Administrative Debris” this week.

    I work for the Summit County Engineer. I make browser-based frontends for our databases. In fact, they are mostly administrative. No one looks at them for aesthetic enjoyment, anyway. A user might look at “deer crashes that happened in daylight hours in 2005?” or “how many school zones along Cleveland-Massillon Rd.?” — stuff like that.

    Well, one of my users maintains a database of business travel (who, what, when, where, how much?). She’s not a person that uses her computer, unless it’s unavoidable. She was accustomed to user interfaces written in MS Access. I had a heck of a time getting her to understand that there were “display” and “edit” pages. She asked, “Why have a display page when no one looks at it unless they’re going to edit it?” Good question.

    It was so far from the usual idea that it caught me by surprise. I suppose I could do it, though. Everything would be a form, and the “Submit” button only shows up if you are an editor. Odd, no? I guess I'd be avoiding “Display Debris.” I wonder what Tufte would think of it?

    Ron

    — Ron Phillips on Saturday, March 29, 2008 at 08:45 AM #

  22. Ryan, you've done a great job here pushing the envelope on clean uncluttered pages. They make mine look like the produce section at the supermarket!

    One request: in the TOC pages, could you add the year to the date? On something like http://tomayko.com/topics/python, it’s kind of useless to have the day and month without having the year.

    — Ned Batchelder on Sunday, March 30, 2008 at 02:01 PM #

  23. You got it, Ned. I'm not sure how I missed that in the first place – %Y is the only strftime code I know by heart :)

    — Ryan Tomayko on Wednesday, April 02, 2008 at 12:56 AM #

  24. Ron: First, I live in Summit County and have hit deer while driving on Cleveland-Massillon road, which is freaking me out a little bit. What type of system is this again??? ;)

    I had a heck of a time getting her to understand that there were “display” and “edit” pages. She asked, “Why have a display page when no one looks at it unless they’re going to edit it?” Good question.

    This is exactly the type of jackpot question that most average programmers blow off or joke about with their co-workers. In reality, this type of perspective is a goldmine. And I'd say she’s exactly right.

    I guess I’d be avoiding “Display Debris.” I wonder what Tufte would think of it?

    I can’t speak for Tufte but my take is that getting rid of the “view” pages is probably the right thing to do. IMO, the concept of “administrative debris” is based on the assumption that the primary content you’re interacting with does not flow naturally with generic computer interface components. Generic GUI components become “debris” when they’re used out of convention rather than out of a thought-out need for them. In this case, I'd say that the function provided by a view page doesn’t flow well with the primary function of the application (to edit stuff) and is probably “debris”.

    Here’s a pretty easy test, I think: if you can remove the thing and the result is a more natural interface, then the thing is probably “debris”.

    Thanks for the anecdote, Ron.

    — Ryan Tomayko on Friday, April 04, 2008 at 04:04 AM #

  25. Great post Ryan. Any chance you will release your blog engine code?

    — Rob Sanheim on Tuesday, April 08, 2008 at 01:26 PM #

  26. Rob: Yes, I'd like to if only to show off Rack and Sinatra. It’s small enough that I've considered releasing it and then running a regular column focusing on some different pieces of code.

    It needs quite a bit of work, though.

    — Ryan Tomayko on Tuesday, April 08, 2008 at 03:11 PM #

  27. Thanks for the great post! I'd like to encourage you to release the blog engine code as well, even if it’s not perfect in your eyes yet. Seeing the process you go through to refine the code would also be valuable.

    — James on Friday, April 11, 2008 at 06:20 AM #

  28. I’ll tell you what: once we get the bleeding line of Sinatra stabled up a bit and documented, I’ll seriously consider spending a weekend tidying my weblog code up a bit and putting it out there.

    Thanks for the nudge. I truly appreciate the interest.

    — Ryan Tomayko on Friday, April 11, 2008 at 07:09 AM #

  29. I too am waiting for it anxiously =)

    — Leonardo Boiko on Saturday, April 19, 2008 at 05:55 AM #

  30. Like most virtues, simplicity can be overdone.

    To a visitor who knows nothing about Ryan Tomayko, a visit to his main site perpetuates the mystery. What is this place about? What topics does it address? What are its philosophies on these topics? It seems that the only way to find out is to read a lot of text. Scroll down the long list of articles; the titles are not always informative, and the two-line blurbs (nice concept in general) only marginally more so.

    I see that the now defunct nav bar had an “about” link. I miss it. (If the info is hidden somewhere as a hyperlink “in the content” — sorry, it didn’t blaze for me).

    So the place feels a bit like Flatland — though it’s clear that a lot of good stuff is contained here. Sorry, I would like a bit more structure (yes, of the hierarchical kind), a graphic at the top that might communicate Ryan’s worldview in a non-verbal way, and a navigation bar.

    Ryan might argue, of course, that he does not mind his site does not reveal itself to a casual visitor — he may be addressing it to a dedicated audience which devotes time to reading his writings. If so — fair enough; but we wouldn’t the entire web to be modeled on this principle.

    And speaking of navigation bars, I note that Tufte’s own website still sports one — and it is quite a bit more complex than the one Ryan eliminated in following Tufte’s edicts.

    — CT on Friday, May 02, 2008 at 08:55 PM #

  31. I'm afraid to click on your name at the top in case it tries to email you…

    — astrange on Saturday, May 03, 2008 at 07:14 AM #

  32. CT: I appreciate the critique and would agree that most of the issues you've mentioned are indeed shortcomings. This site is definitely a work in progress and I try to be very liberal with experimentation.

    But I think some of the criticism I've received on this piece could have been avoided (or maybe redirected) if I had explained some of the usage patterns I see on this site and how those usage patterns led to such odd design decisions as entirely removing navigational areas. You've brushed up against some of the reasons in your comment so I’ll take it as an opportunity to expand a bit.

    80%-90% of this site’s page views come via direct external link to a specific article. Google accounts for much of this traffic but I also see decent referral traffic from other blogs and topic sites (e.g., reddit.com, StumbleUpon, del.icio.us, etc). This was the case even when the site had various archives, heavier navigational elements, tag clouds, etc.

    People reaching the site organically care most about reading a single article on a specific topic and are only passingly interested in other stuff contained here. The design decisions I've discussed here that seem to be attracting the most descent (removing navbars and other surrounding artifacts) are a direct result of targeting that 80%-90% usage scenario at the expense of those coming in through the front page (very rare) or wanting to browse around from article to article.

    My theory is that this site’s navigation expands outside its own domain with Google, reddit, and other blog posts becoming the site’s most frequently used navigational devices. The individual “permalink” content page is the single most important aspect to get right. My goal in removing extraneous elements is to give the site a focus that matches its use.

    I've seen multiple references now where someone assumed I universally hate navbars and am advocating removing them in all cases. I'm not. I should have been more clear on this. There are many cases where a site’s navigational elements are vital to the site’s basic functionality. Yahoo! is clearly a good example. Tufte’s site may be another. I imagine he receives many visitors through the front door that are interested in exploring all of his work because, well, he’s Tufte.

    — Ryan Tomayko on Saturday, May 03, 2008 at 09:01 AM #

  33. interesting read. I definitely like your design. A comment….. I think you might want to rethink the link with your name on top. Names that appear as links are pretty much assumed to be email links unless there’s a good reason to think otherwise. Your name in the title looks like a byline, so I wouldn’t really expect it to be the way to get to past articles in your blog. If the blog had a name, it would probably make sense, but since the name is your name, it’s a bit confusing.

    Also having two different link fonts is a bit off putting unless there’s a meaning I'm missing.

    — Lee on Saturday, May 03, 2008 at 11:55 AM #

  34. OK — so, at a minimum, the meaningful amount of “administrative debris” depends on the site’s functionality. I would say that it also depends on the user. I always head for the “site map” when there is one. A page full of debris — and the only place, usually, where you can find what you want quickly. It’s amazing how many sites have useful stuff that is not reachable except through their site map (or Google, if you are lucky enough to put in the keywords the site uses).

    — CT on Sunday, May 04, 2008 at 09:03 AM #

  35. Oh, I would agree that a sitemap is a huge missing piece here. I don’t consider a sitemap to be administrative debris, though. It’s serving a specific purpose and, when done tastefully, can be a huge usability win. What would be debris, IMO, is having a bunch of non-sitemap related stuff on a sitemap page. Like, say, google adwords, your current AIM status, or what’s currently in your record player. Maybe I'm stretching Tufte’s concepts a bit thin…

    Also, there are examples where additional navigational elements and site map like functionality can be made to work quite well on content pages:

    • diveintomark.org – I think the mini sitemap at the bottom of each page works extremely well. It doesn’t take away from the main content and looks/feels very much like the main content display. It’s not a cartoonish separate area but an extension of the content. (BONUS: this is probably my single favorite piece of Mark Pilgrim writing. If you feel like reading it, I'd suggest reading this short anecdote first.)

    • The Hemingway Theme for WordPress is a bit more jarring but uses the same basic technique. I think it works.

    • Textism’s design is largely free of admin debris but uses some interesting techniques for navigational elements — hover over the first level heading. I like this approach because someone wanting to navigate around the site is likely to attempt to click on the heading, at which time they’re presented with additional options.

    — Ryan Tomayko on Sunday, May 04, 2008 at 10:40 PM #

  36. Moving the “debris” to the bottom is fine with me — except that if I am visiting a place for the first time I'm not likely to scroll to the bottom to see if there is good stuff there. Chances are I will leave and never know that there were goodies at the bottom. So it works if you only care about visitors who have somehow been hooked on your site and keep coming back. (Maybe all the bottom-nav sites could agree to use a tiny icon at the top that lets the user know?). Also, as long as new pages show up with the scrollbar at the top, this can be awkward. On Mark’s site, for example, if you want to “browse” his articles without reading them, you’ll have to scroll down on the first one, click Previous or Next (article titles with arrows), get a new page, scroll all the way down again, click, scroll, etc.

    I appreciate the minimalist esthetics , but I still want to have navigation as well as a brief contents of some sort on each page. Maybe the answer is reader customization of websites — choose from let’s say three levels of debris, and where to have it (top, bottom, left, right). But put that choice control at the top!

    Now I think I need a drink. I wonder where I could get one.

    — CT on Monday, May 05, 2008 at 08:01 PM #

  37. The only thing I want to mention related to inline editing that it works only in simple sites. Some users (read admins) need much more options that simple inline Edit – Save articles. Sometimes they even need separate GUI’s for different groups of admins (moderators etc).

    Please, do not blame the main idea of separate admin based on administrating one small blog. For you and your blog – yes, inline editing would be useful, not for the whole world around.

    — Nick on Friday, May 09, 2008 at 08:50 AM #

  38. The only thing I want to mention related to inline editing that it works only in simple sites.

    Inline editing in Plone CMS:

    http://plone.org/products/plone/features/3.0/new/inline-editing

    Seems like not only for simple sites :–)

    — libraM on Saturday, May 10, 2008 at 05:44 AM #

  39. Ryan, “Thus, the navbar under the new design:” shows a blank white box for me. I thought this was a statement about minimalism (who needs one?) until I read a bit further and checked the top of the page, where I see a minimal but usable header.

    Also, I don’t mind that WordPress shows me the Admin UI view through a different page, because I know the site and am not the intended audience. As long as it’s out of the way of a reader, I'm fine with a totally separate Dashboard. For sites with a lot of whitespace and graphic design (which might be a waste of space, or might not), that would all get in the way of presenting more functional content.

    OtOH, I agree about having an Edit link on every article. I work on another WP blog where I have to go the Site Admin and click a couple more links to find the admin view of the page I was just reading, and that’s a PitA.

    Liked the essay, FWIW — got here from Tufte (apparently I'm far behind).

    — Chris Pepper on Monday, May 26, 2008 at 05:26 PM #

  40. I love it. As an artist (mainly theatrical) and a designer of sites for artist (often), there are a few other considerations that make this interesting:

    When is design content? When might we want to give the audience pause, or hit them with something unexpected to make them react in a new way? Suddenly we aren’t just dealing with design as a vehicle for language information, but as a content in it’s own right. Not only that, but an artistic content, not focused solely on information communication, but on aesthetic and emotional communication/association as well – offering it’s own challenges to the intended audience.

    It doesn’t really change anything in the process of simplifying – design/interface cruft can still be a problem: over-design in the name of interface – and this extreme awareness of it is helpful for discovering new approaches. Suddenly I am thinking about my design as art-content, and wanting the interface to develop naturally out of that graphical content (hypergraphics?) as well as the textual content, rather than being controlled by those interface items I have come to assume I need.

    And, of course, there is an artistic aesthetic present on this graphic-less page that offers it’s own interesting challenge to the viewer (and to us as web designers). It’s a beautiful design. Well done.

    Forget Nielson, web design (as with theatre) is only interesting if we approach it as philosophers, artists and idealists as well as researchers. Tuft beats out Nielson by caring about usability without ever sacrificing aesthetic.

    Wonderful stuff. Thanks.

    — eric on Monday, June 16, 2008 at 06:22 AM #

  41. Thanks for the inspiration of a simplified theme, I've just implemented my own interpretation of simple on my own site.

    Thanks!

    — Stewart Johnson on Friday, June 20, 2008 at 06:39 AM #

  42. Stewart: Beautifully done, sir. In fact, I may steal the super simple recent writings section from your front page for mine.

    — Ryan Tomayko on Friday, June 20, 2008 at 07:46 PM #

  43. Thank you, finally … HTML and Hypertext is a representational Medium.

    — ben_ on Monday, June 23, 2008 at 01:56 AM #

  44. HTML and Hypertext is a representational Medium.

    I still think that linking “Ryan Tomayko” to “articles written by Ryan Tomayko”, rather than to a mailto: or OpenID or about-the-author page, is jarring compared with the rest of the design’s purity. Maybe adding a “by… ” in there might make help representation. A small point, but it’s right at the top of the page (and at the heart of the whole premise: paring down to representation requires what’s left to be spot on).

    It’s a lovely premise, though. I wonder how many people use my own voluminous side-bar navigation. I'd hate to lose the blogroll, though: I'd like to think the list of my peers provides context for my content, but mostly I put that there to be chummy.

    — J-P on Tuesday, June 24, 2008 at 10:17 AM #

  45. no images. no css. pages that validate. no static settings on font size. this is the new minimalism in web design. you’re getting there….

    — whoopie on Tuesday, June 24, 2008 at 03:58 PM #

  46. indeed i recently started http://www.txtonly.org to promote text-only versions of news, quotes, driving directions, anything else i might find useful

    — whoopie on Tuesday, June 24, 2008 at 04:06 PM #

  47. One thing that might have helped is the (so-called, in Opera) navigation bar, which seems to be only supported in Opera these days (it used to be in Mozilla, I haven’t seen it in Firefox). This allows for using rel and rev attributes to indicate useful links (Opera allows for Home, Index, Contents, Search, Glossary, Help, First, Previous, Next, Last, Up, Copyright, and Author). An example of it’s use is in my link. (You’ll need Opera, with prefs set to include the ‘navigation bar’, to see these). If you’re serious about relocating some common webpage links to browser chrome, this old idea and functionality should be brought back somehow..

    — mwiik on Thursday, June 26, 2008 at 03:55 AM #

  48. Excellent post. However, there are a couple of things that weren’t immediately obvious that left me scratching my head wondering about your reasoning for doing them.

    First, I found it odd that the h3 elements on posts list pages were a different size from the h3 elements on links list pages. That is until I went to your home page and saw that was the only way to distinguish between the types of links. Makes perfect sense on the home page, but my “gut feeling” is that it’s a bit off on those list pages. Maybe that’s just me.

    Second, I'm still trying to figure out why the chronological ordering on post list pages is different from links list pages. What’s the reasoning behind this?

    — Bryan on Monday, July 07, 2008 at 10:09 PM #

  49. Great post. I am a big fan of the minimalism.

    — Jim on Thursday, July 10, 2008 at 04:46 PM #

  50. Excellent post – very thought provoking. I've always striven for minimalism in my designs, but you've made me realize how much further I can take it without sacrificing anything important. Thanks.

    — nn on Saturday, December 27, 2008 at 08:52 AM #

    51. Sorry, comments are temporarily closed due to a broken spam filter. bbl.