I play with Visio way too much. Here’s a neat trick for creating a box with cut corners, like this:

You could just draw four lines that don’t touch at the corners and group them. The problem with this is that when you resize, the gaps at the corners also grow or shrink proportionally. The key is to find a way to ensure that the corners remain consistent no matter what size you make the box.

To solve this problem, I created a line end* that’s just a white circle 1/4 inch in diameter. Draw four lines in a square and assign your new line end. You may have to change the size of the line end to get the look you want. Then group or combine the lines. Now you can resize without the gaps changing size:

Shoppers go digital, U.S. sales data show

The [iPod] has entered that ephemeral world of cool, where its functions often take a back seat to its cachet.

A battle brews over cable boxes

Trying to spur innovation and ensure competition when those who control the plumbing have so much power is no easy matter.

The lawyers and lobbyists, it seems, are the only sure winners.

If you’ve gotten a new cable box in the last year or so, you may have a slot that looks about the right size for a credit card. This is for CableCARD technology, essentially a key to unlock scrambled television signals.

There are several things about this issue (in fact the digital television business as a whole) that fascinate me:

1. The number of players: cable companies, satellite companies, consumer electronics manufacturers, studios (which make television shows), stations (which distribute television shows), and the elephant in the living room — the government.
2. The legacy legislation: even the most recent legislation is from 1996 and obsolete.
3. The silent masses: somehow, customers never make their way into these conversations.

There is a simple, almost Socratic answer to this problem: each entity should handle only one part of the equation, the part their best at. Cable companies have no business deciding what electronic equipment I have in my home. Bring the signal to my front door and I’ll decide what to do with it from there. With cable companies releasing their grip on this part of the equation, consumer electronics manufacturers could innovate and offer the market a wider variety of products. (I’d like my set-top box with a DVR and DVD burner, please, but hold the high-def.)

Like workflow, role is a content management category that exhibits prototype effects. A role is a collection of privileges and responsibilities granted to users of the system. We have convenient labels for different kinds of roles depending on the collection of responsibilities. Author, for example, is a kind of role with content creation privileges.

The prototype effects are clear. Although in implementing content management systems we try to generalize responsibilities, reality indicates that there’s considerable variation among them. The privileges of press release authors may differ from policy authors. A person who authors content once is different from someone who creates it every day. A person’s responsibilities may vary depending on the type of content.

Unlike workflow, however, we do not have metaphors for talking about roles. Although we can say that someone is “in a role,” that is not typical of our conversations about content management. Also, the container metaphor does not appear to extend beyond that usage. In reasoning about roles, we do not think of them as containers (as we do workflow). Therefore, roles must be represented by some other type of cognitive model.

Whatever the model turns out to be, it must account for two things:

1. the central notion of role
2. the types of roles (eg: Author, Editor, etc.)

The metaphors I’ve discussed for workflow provide an example of only one kind of cognitive model. Lakoff indicates that there are four other kinds of cognitive models besides metaphors. The one that appears to form the basis for roles is the propositional model.

Admittedly, to me the propositional model seems like Lakoff’s “junk drawer” for cognitive models — the place to put cognitive models that don’t seem to fit any of the others — but he does describe it pretty well:

Each [propositional cognitive model] has an ontology and a structure. The ontology is the set of elements used in the [cognitive model]. The structure consists of the properties of the elements and the relations obtaining among the elements. (WFDT 285)

Although Lakoff describes five different kinds of propositional models (including conventional taxonomies), I’ll stick with the basic idea: the model consists of a collection of objects and relations between them. (If you’re keeping track, it’s important to note that these are not real objects; they’re mental entities. In other words, they do not represent how the world really works, but how we think it works.)

In this case, the entities in the ontology are:

1. the responsibilities with respect to content management
2. the objects within the content management system (ie: the content)
3. the elements of the CMS interface that allow users to execute commands

The links between the responsibilities form the specific roles and the links between all these entities form the central concept Role. Subsequent posts will describe each of these entities and the relationships between them in greater detail.

Future topics: why isn’t role considered a radial category?

To recap previous posts:

• We use two metaphors — PATH and CONTAINER — to talk about, and therefore reason about, workflow.
• The metaphors provide evidence of cognitive models, which in turn suggests that workflows exhibit prototype effects.
• We can describe the prototypical workflow, and also identify examples of real-world workflows that deviate from the prototype.

The prototype and metaphors have an enormous impact on the software we develop to support workflow. Because we think of workflow as a path, it is typically visualized within the software as a path or flowchart. The tools for developing workflows assume every business process closely resembles the prototype, and therefore they do not accommodate deviations very well.

The metaphors reinforce the separation between workflow and content, and content management software takes a one-size-fits-all attitude toward workflows, assuming that all content of a certain type can follow the same process. Because workflow is conceived as a path, the influence of external events on them is often hidden and not easily represented in the software.

Content management systems also represent content as being in stages, evoking the WORKFLOW IS A CONTAINER metaphor. In a prototypical workflow, content lives in one and only one place at a time, hiding the very real situation of one department beginning their review before another has finished theirs. Even the simplest content management systems (like the software supporting this ‘blog) allow content to have a status of Publish or Draft.

Content management systems are simply building on entrenched cognitive models. If current CMS implementations are insufficient, then we need build them on a new cognitive model.

Sarah and I have a new tradition, and it’s fast becoming my favorite part of the holiday season. On Christmas Eve, we watch It’s a Wonderful Life. As essentially non-observant people, perhaps we feel like this is as close to religious ritual as we get. (Given the amount of time/money/space dedicated to movies in our lives, this is more true than I probably want to admit.)

Capra’s story reminds us of what life, not just Christmas, is about. Distracted by the pressures of gift-giving and family politics, it’s easy to forget what’s important. Despite the insanity of Christmas day, we did have a good time seeing various family members on the Holden side. We spent Boxing Day with friends: coffee with Eric and dinner with James and Becky. All in all, a thoroughly enjoyable Christmas…

With my sister and brother-in-law coming to town, New Year’s is also shaping up to be a good time.

I’ve been spending spare cycles on applying Lakoff’s ideas to Content Management, but Jesse’s recent post implies we do the same to our user research categories. In other words, by creating a persona, we are creating a classical category that does not fully describe the relationship between user and system. That category — the relationship — exhibits prototype effects. In other words, we have a model of how users typically interact with computers. The actual ways people interact with computers is very different, but tend to be variations of the prototype.

I’m not yet sure how this should affect the practice of interface design, but it’s clear that we need to recognize the limitations of our deliverables. In particular, personas. While good ones present a well-rounded view, the current approach does not acknowledge the richness of this category.

The SOURCE-PATH-GOAL metaphor is clearly one source of the prototype for workflow. (See previous post.) Here are some more examples, with the relevant clues highlighted:

• “The content goes to legal review next.”
• “That press release moved through editing quickly!”
• “Security directives can’t go to Legislative Policy until Chief Counsel has reviewed them.”
• “I haven’t published the content because it hasn’t gotten to me yet.”
• “Once the content enters workflow, it must move through five stages.”

Words and phrases like “enter” and “move through” suggest that we might conceive of workflow as a tunnel. Either way, the path metaphor is clear. Lakoff says that applying metaphors to concepts allows us to highlight certain aspects of the concept, while hiding other aspects of the concept. For example, by reasoning about ARGUMENTS as WARS, we highlight the adversarial aspect of heated discussion while concealing the cooperative aspect. Likewise, thinking of workflows as paths highlights the production of content while concealing the iterative creative processes for developing it.

It also conceptually separates content from the process used to create it, allowing us to believe that any content could follow the same path.

There is another metaphor we use for workflow that also separates it from the content itself. The language we use to talk about workflows indicates that we think of it as a container as well. The best evidence of this is the word CONTENT itself. Although there are many containers for the content (primarily the Web page), by already conceiving it as such makes the cognitive connection between workflow and container easy. In other words, since we already think of content as something in a container, we find other containers for the content to appear in. Here’s some evidence from our language that we think of workflows as containers:

• “Your content is in staging.”
• “While in ‘Work in Progress’, the content can not be published.”
• “I can’t find the content. It must have fallen out of workflow.”

(As an aside: the relationship between digital content and it’s primary container, the publication, is also conceived as an ON-OFF relationship. For example, “You’re content isn’t on the site because it hasn’t been published yet.”)

If my understanding of Lakoff is correct, then the point of these metaphors is to show that the category WORKFLOW has an underlying cognitive model that is subject to prototype effects. Although we conceive of workflow as either a PATH or CONTAINER, it is not actually one of these things and therefore workflows in our content management systems do a poor job of supporting real business processes.

Future topics: how these two metaphors intersect; how these metaphors relate to the prototype

Do one thing well or do many things poorly. Is this as true for computers and technology as it is for humans?

Sub-head: Wife says, “Funeral still cheaper than Blockbuster’s late fees.”

The impact of a long user experience became abundantly clear this morning as I stood in front of our local RedBox to return some movies in freezing weather. There are two parts of the user experience that protract it unnecessarily:

1. The amount of time between swiping my card and putting the DVD into the slot is a solid 30 seconds.
2. You have to swipe your card for each video you are returning or renting.

Neither of these make any sense. With the first problem, I could understand needing to check records to confirm that the movie returned is the movie rented, but I’m not sure why it should take so long. There can only be so many movies out, so the recordset should be extremely small.

The second problem is a total mystery. Once the identity of the user has been established, I see no reason why the system couldn’t ask, “Would you like to return your other movies?” Instead, I had to stand outside for twice as long as I perhaps could have.

There is one other major RedBox quirk, during the process for renting a DVD. The kiosk, pictured at right consists of an ATM-like device surrounded by panels of DVD covers. Once you’ve swiped your card, you select the move you want geographically — that is, by selecting which quadrant it appears in. After the interface “zooms” to that quadrant, you select the movie. Until this point, however, the user has no way of knowing whether the movie is in-stock or not. Once zoomed into the quadrant, DVD covers will be blacked out with the words “Already Rented” or some such.

At this point, the user is standing in front of the kiosk, the card still swiped, and they need to decide which movie to get, or to cancel their transaction. Perhaps this is a wise business decision, because it forces users to pick a movie. On the other hand, it can be very frustrating.

On the plus side, for only $1 a night the business model is extremely appealing — even to us Netflix subscribers — and the interface successfully minimizes the interactions. There is no unnecessary button-pushing.

Workflow is a content management category that is subject to prototype effects.

Recall that the purpose of these thoughts is to describe why content management is so hard by providing a unified framework that offers a comprehensive explaination. The framework is based on Lakoff’s work in Women, Fire, and Dangerous Things on categories, in which he provides a critique of linguistic categories in light of the latest cognitive science. This exercise the is the same, but with content management categories — workflow, role, and content.

Classical categories are buckets with a list of criteria determining whether an object is inside or outside the bucket. Our minds, however, do not actually work this way. One way our mind categorizes things is to imagine a prototypical object and estimating how closely other members resemble the prototype.

Business software operates with classical categories, because computers can not account for prototype effects. One of the problems with content management software is that it can not effectively model content production workflows because there is too much variation within the category.

Last week James showed me a workflow he was working on for one of his clients. The workflow represented a fundamental line of business for the government agency, and was very complex and made up of many subflows. Two interesting aspects of the workflow emerged:

1. One of the sub-flows could occur at any point in the overall process.
2. Ownership of the sub-flows would be unclear until they were actually executed.

James’ workflow is recognizable as such, but I would suggest that it deviates from a prototypical workflow. The prototype for workflow is probably based on the SOURCE-PATH-GOAL schema described by Lakoff in Women, Fire, and Dangerous Things. We think about it as if it were a path with a beginning, a series of steps, and an end. Some other aspects of the prototypical workflow:

PROTOTYPE FOR WORKFLOW

1. A workflow has a clear set of inputs.
2. A workflow has a clear set of outputs.
3. There is a discrete series of steps to follow to get from inputs to outputs.
4. There is a clear owner of each step.
5. The steps follow a logical progression, each of which affects the inputs in some way.
6. The workflow has a clear beginning.
7. The workflow has a clear ending.
8. So long as it is in the set of expected inputs, every input will be addressed during the workflow.
9. Each person involved in the workflow knows what comes before his step and what comes after.
10. Each step is supposed to take a certain amount of time.

This list is perhaps not comprehensive, but it gives a good idea of what we expect a workflow to look like. Reality paints a very different picture. James’ workflow deviates from items [c] and [d], above. This isn’t to say it isn’t workflow, just not a prototypical workflow.

Some other examples:

• “We’re working on a paper, but we’re not sure exactly what it’s going to look like.”
• “We need to put the summary together, even if we don’t have all the data.”
• “This briefing needs to be reviewed either by Legislative Affairs or by Chief Council.”
• “We need it by January 1st.”

The question for content management is whether we can design a system that effectively deals with these variations.