Building Levels and Websites

Stewart Brand, the author of "How Buildings Learn" is a proponent of the layered theory of time and space. In buildings, for example, he identifies six levels: site, structure, services, skin, space plan, and stuff. The site is the basis for everything else. It's the lot, the foundation, the ground underneath. It sets limits for everything else. The structure is then the load-bearing part of the building, and sets still more limits for further construction. The skin is the outer covering, and services are the functional parts of the building, the electrical, water, heat, elevators, and so forth. Space plan is the movable walls within, and stuff is people, furniture, and other readily-moved items.

In this view, each layer has its own time cycle, and woe betide the building owner who ties them together or makes them move too quickly. The stuff can change daily, while the space plan typically changes in two or three years, or perhaps more. The skin may change only once a decade. Services longer than that, and the site almost never. He counsels strongly against tying the various levels together, such as built-in furniture, because it forces levels with inherently different time-scales to stick together, creating (in the case of built-in sofas, tables, or chairs, for example) either radical surgery on the space plan or tolerance of out-of-date furniture.

I think this structural metaphor can be applied to portals and websites, and it can help us understand why some sites always seem to give us trouble. Of course, the absolute time-scale has to be reduced for the IT world, but the relative splits in levels seems to hold.

Try these equivalents:

Site = Server hardware and underlying base code, such as portal
Structure = Information architecture
Services = App code (portlets, Javascript, etc.)
Space plan = Links, portlets, pages, actual "places" that are delineated from one another
Skin = Appearance (CSS, colors, layout)
Stuff = Content (text, news items, and so on)

From this perspective, it can be seen why CSS is such a good idea -- it isolates the skin from the space plan and the stuff, giving us distinctly different time-scales for them. But there is also a caution here, that changing a space plan too often, for example, because the stuff changes, is a mistake. And in the Web world, the skin is generally replaced more often than the space plan, but they are often replaced together, too. Is this a mistake? Is novelty so important that we have to mess with the user's comfort levels?

I may not have the right Web components identified with the right building metaphors, or the whole comparison may be futile. Look through Brand's book and tell me what you think.

At Last I'm a Lert

As the saying goes, "Be alert...the world needs more lerts!" I'm contributing my share.

I've discovered Google Alerts, and I'm using it to watch for some terms. Google Alerts lets you know when something is published on the Web that matches your keyword in the Alert. I, for example, am using three alerts: my name, "usability", and "information architecture".

So far the results have been mixed. I've caught a couple of references to my old books, which is exceedingly gratifying. And I've caught a few good blog entries here and there about my professional subjects. But a good many notifications are less than intriguing. Signal-to-noise definitely trending toward noise, but infinitely easier than doing tedious, full-out Google searches to stay current.

A REAL Man-Machine Interface

I see they're shutting down the PEAR, the Princeton Engineering Anomalies Research laboratory. After some 30 years of generating controversy and reams of odd data about telekinesis, the PEAR is closing up shop, done in by exhaustion and time. Opened in 1979, the lab explored whether humans could change physical events with just the power of mind. Turns out, as the lab concludes, they can, but only very slightly, something like 2 or 3 events out of 10,000.

Research into the paranormal isn't what it once was. The Psychophysical Research Laboratories (PRL), also located in Princeton, shut down. Duke University's Parapsychology Laboratory, perhaps the most famous of them all, spun off its parapsychology work into the now-independent Rhine Research Center. It's named after Dr. Joseph Banks Rhine who invented those famous cards while at Duke. Interest in the paranormal appears to have peaked many years ago, and now even the scientists who had high hopes for actual results may be drifting away.

But the PEAR was interesting to HCI'ers because it focused on telekinesis, controlling things with thoughts. If telekinesis could be shown, then it might be possible to change the TV channel just by projecting a thought in that direction. Sadly, the prospect now looks bleak.

Usability in Disaster Relief

Just as I published a self-congratulatory posting about my own article in ACM's Interactions magazine, I got to read several articles in the March issue of Communications of the ACM about the HCI of disaster relief. Fascinating stuff. You can see the TOC on the site, although you can't read the articles unless you're an ACM member.

The technical challenges of breakdowns, weather, and moving to stay safe and dry are joined by the problems of designing exceedingly hardened systems ahead of time that will function when the hammer falls. Interactivity is a big issue, of course, but so are the human frailties that kick in during disasters. Reading about the work being done makes me feel a little sad that I'm not involved in such noble work.

Usability as Risk Management

Keep an eye out for the March edition of ACM's Interactions. I'm supposed to be in it. Pays to be humble, no?

The article deals with a mechanism I developed when I worked for a consulting company. We constantly have problems convincing our employers and clients to use usability techniques. But why force the issue? Why not let the brass decide by putting the decision in their language? That's when I started doing risk analysis of new online efforts, using usability factors. I get the business stakeholders of a new website, intranet, portal, or whatnot into a room together and spend some time quantifying how bad things could get if the initiative fails, and then out of that comes an index of risk. Using usability techniques can reduce the risk, but they're expensive. The use of techniques must be matched to a risk level, because otherwise usability won't be included in the project plan.

If you can lay your hands on a copy, let me know your opinion.

Portals Will Forever Suck for Usability

In the past few years I've spent a lot of time working with portal software. I was involved for half a year with the design of Sakai, which you may know as Oncourse CL. For those of you who want to flail me about its usability flaws, be assured that we refugees from the Tools Team, who were the usability voices, are not too happy about them either. I've since become even more deeply involved in Websphere Portal and its evil little sidekick LWCM, the web content management part of the team. In between, I've been a user of one or two other portal packages. Believe me, they all stink from a usability perspective.

First let's get together on terminology. A "portal" in the old sense is just a website with a bunch of collected links that send you elsewhere. Yahoo pioneered this interface. The newer sense of "portal" is actually a software package that specializes in showing various systems to a user all at once, and supposedly giving the user the ability to customize his own interface (although no one ever does). Portal pages can have different "windows" on a page. For example, one place on the page permits Google searching, another one gives the weather, another one shows your stock market portfolio, and yet another has corporate news from your employer's PR machine. These various "windows" are actually known as "portlets", "applets", "gadgets", or "tools". Oncourse CL is an example. There, it's "tools". You can write a tool. Anybody can. It's completely open, and that's what Sakai's creators are most happy about.

But that's Sakai's Achilles heel, too. Tools don't talk well with one another, because they're designed to be secure and happy living alone. Navigation and other usability factors vary from tool to tool, so you can never just settle down to one consistent interface.

Major portal makers, like IBM and its Websphere Portal, suffer similar problems, except in greater profusion. A typical Websphere portal page may have a dozen "portlets" on a single page, all doing something different, and all potentially with a different "skin". If nothing else, they don't always fit thematically together. They're like jet cockpits. Over there is the flaps indicator, while over here is the oil pressure indicator. Just a flock of barely connected different things. There's no flow to the page, few cues, and little uniformity. And it's designed to be just that way, as if the business and computer science communities conspired in smoke-filled rooms to stick it to both users and usability professionals. Portal proponents claim that users can overcome this madness by customizing their pages, but that's just crazy talk. Users won't do it. They suffer in silence instead. In a portal, there's almost no room for conventional user testing or interface design. There is no "interface" as such, merely pages with things that do stuff. This is great for developers and business types, because portal architecture makes it much, much easier to incorporate in one place functions as diverse as weather announcements, time reporting, and CRM applications.

If you want to see examples, check out the NCAA (www.ncaa.org/wps/portal) or IBM (www.ibm.com).

Gender-Designed OS

Now that we know there are some generalized gender differences between male and female brains, what does that mean for design? We know, for example, that women tend to see color better, and to appreciate its use more. But we also know there are functional differences. For example, women seem to keep more browser windows open, and switch between them more frequently, than men. I haven't considered this in my designs, I have to admit. Yet a high capable female consultant of my acquaintance confirms it from her experience.

My curiosity about this phenomenon went all the way into operating system design. Men are well-known for being more spatially-oriented than women, which often gives them an advantage in fields like mechanical engineering. It occurs to me that operating systems are by and large spatial metaphors. We don't just use folders, but folder locations, relative to other locations. We refer to files as being "in folders" in the OS, when in reality they are nothing of the kind. There are just pointers to sectors on hard drives. Even in this age of objects, the objects are thought of as spatial entities, like appliances with plumbing outlets. But then, the vast majority of workers in this field are male. Is it possible that the metaphors we've all come to accept are just male representations, and that there's another way?

What would an OS look like designed completely by women? I put this question to one of my students, who derisively responded "I guess you'd just make everything pink". But after some discussion she came to see my point. If females are more relationship-oriented, as many researchers now maintain, would a truly female-centric OS dispense with most of the location-heavy metaphor and emphasize file relationships? How might such an OS work? What would it look like? I'm too male to guess. Maybe it would look more like the Web. I don't know, but I'd like to find out.