If things have been quiet here, it’s because they’re busy elsewhere. I can point you to a couple blogs, however, that may be of interest. As Sarah and I prepare for parenthood, we set up a site to capture our thoughts.

Strangely enough, as we were poking around blogger.com, we found an old account of mine that contained the remnants of a blog I maintained in 2001 and 2002, during the height of my interest in interactive television. The blog was called primetime and it was mostly a collection of links to articles about the interactive television business. For those interested, I wrote an article for Interactive Television Today covering the Broadband Outlook conference in 2002. One more little thing, and then I’ll let the iTV thing rest, really. As I was exploring the industry, I put together a diagram explaining my understanding of the politics and players. You can find it on flickr.

I’ve upgraded WordPress and I’m trying out some new themes, including Hemingway and Squible. (Coincidentally, these are both words I would expect to have double-letters, but don’t.) If you notice anything quirky, please let me know…

Through some weird coincidence, my last three projects were all inboxes–web-based systems to allow our client to manage incoming information. Generally speaking, an inbox takes items submitted from outside the client and displays them for people in the organization. They then have to do something with the item–dispose of it in some way. For your email inbox, the incoming items are messages, and you can reply, forward, archive, delete, etc. For these three inboxes, the items were (in no particular order): applications to qualify for an auction, petitions, and referrals.

Although all of these systems are “inboxes” in the general sense of the terms, they were radically different in their approach to managing the incoming items. Lest you think we were irresponsible in our consulting, each inbox served a completely different set of users and had to be compatible with different legacy systems, so there was no opportunity to consolidate. Still, working on three inboxes in a row got me thinking about Inbox as a design pattern, and the associated object models and interactions.

The People

• Sender: In every inbox, there are people who send in the items. They usually supply a bit of data and occasionally some metadata about the item. In some applications of the Inbox pattern, the sender knows the identity of the recipient and in others simply submits the item.
• Recipient: At the other end of the line are the recipients. These are the people who have to acknowledge they got the item and do something with it.
• Administrator: In some cases, directing items to specific recipients is a decision made by someone other than the sender. Administrators can set assignment rules, defining how incoming items are routed to recipients.
• Stakeholders: For business applications, there may be other people who have a vested interest in the incoming items. The recipients may, for example, have responsibilities to report to managers about different items. Stakeholders may never access the inbox themselves, or they may have their own version of the inbox for performing different tasks or monitoring progress.

The Objects

• The Item: The item is the main unit of currency in an inbox. Items have their own line in the inbox. For email programs, the item is the message, but the item can be just about anything. There are three parts to the item: the sender, the content, and the context. The content is the information consciously supplied by the sender. The context is a little more subtle and may be defined explicitly by the sender or may be inherent in the item itself. For example, in one of our inboxes, senders belonged to different groups and organizations. By submitting an item, the sender was doing so in the context of their group or organization.
• The Inbox: The container that displays the incoming items. Inboxes come in all shapes and sizes and how they display the information depends on the items and the recipients. One inbox I worked on had tabs to allow users to sort through the items quickly. Another grouped the items by date. The last had no grouping or sorting. One size does not fit all.
• The Archive: Where items go to die. At some point, an item loses its significance and the reasons vary by application. The extent to which an item needs to live on in the archive, to be found again, also depends on business rules. (In the US Federal Government, this is called records management.)

The Lifecycle

• Create: The sender creates the item. Some systems allow users to create the item in the system itself without submitting it, like a mortgage application, for example, that might require multiple sessions to complete.
• Submit: The sender releases the item, triggering it to appear in the recipient’s inbox. During the Submit phase, the system applies business rules to direct the item to the appropriate recipient. The system may also add data–for example, the date submitted.
• Receive: The item appears in the inbox, the recipient gets the item and acknowledges it.
• Act: The recipient performs some action on the item, either marking it read, or adding some content.
• Dispose: The receipient performs the final action, triggering the rule to mark the item disposed.

The Interactions

• Assigning items to people: Unless the system requires that senders specify a recipient, it needs some rule to determine who gets incoming items. The rules can be simple–everyone sees every incoming item–or very complex, assigning items based on a variety of metadata. All three of the inboxes I worked on has some kind of assignment component, whereby administrators or managers could assign items one-by-one to specific people or could assign people based on a specific rule. Two of the projects required that we make it easy to reassign people, in case one of the recipients is out of the office. Even for inboxes where the sender specifies the recipient, you may need to think about rules to address scenarios where the recipient is unable to dispose of the item.
• Disposing an item: Items can’t stay in the inbox for ever. They’re there for a reason, and the recipient needs to do something with an item in order to get rid of it. Just like the One Ring wants to return to Sauron, the inbox wants to be empty. Every inbox needs a mechanism for disposing of items, which can be as simple as the recipient indicating “done” or as involved as assigning a status or redirecting the item to someone else.
• Archiving an item: Disposing an item and archiving it are different things. In one of my inbox projects, items do not get archived until a certain date as passed, but until then, they could be disposed of in different ways by different people. Archiving can be manual (as in Gmail) or based on a rule, like the items that go into an archive when a date has passed.
• Distinguishing content: In all three of these inbox projects, the recipient had to add information to the item. In the simplest inbox, the recipient simply indicated disposition, but in the more complex ones, the recipient was required to make comments on the items. The item remains a distinct object in the system, but it grows over time, layers of information being added throughout the lifecycle. Distinguishing these layers, and their source, is a crucial pattern for the Inbox.

There may be other elements to the pattern, but those are the ones I noticed. I don’t have a lot of experience with design patterns, but I’ve never seen them defined at this level–always at lower levels of interaction. Your thoughts are always welcome!