Larry Cannell pointed me to a good posting by Daniel Tunkelang called “You Can’t Hurry Relevance“. Mr. Tunkelang obviously believes in the idea of attention management. I especially like the way he states the holy grail of attention management: a system that understands what is important to the user and dispositions messages accordingly. Well, I’ll let his own words shine here:
As an information consumer, I’d appreciate an interface that explicitly and transparently adapts to my priorities, and that manages interruption of my workflow accordingly
Here’s what I commented back on his entry regarding the statement above:
There will not be one tangible “thing” that manages interruptions based on priorities. But there will be a collection of technologies and capabilities that, taken together, can be used to manage attention. I call this collection of technologies and capabilities that manage attention the Enterprise Attention Management conceptual architecture. I posted this architectural model on the KnowledgeForward blog in 2006. You can find it here:
Since it is not one, purpose-built, tightly integrated set of pieces, it takes a walk-through to apply it to any particular problem. The problem you mention in this posting is e-mail, and you’ve provided 3 good suggestions on how to take advantage of urgency. I applied the EAM model to e-mail as an example and yielded 15 examples where technology could help, many of which are indeed available in some e-mail systems (although often buried or cludgy). You can see my list and how the EAM architecture helped derive it here:
I really like your thought that urgency should be taken into account in the e-mail process. You have some good ideas for the receiving end of e-mail. I still wouldn’t give up on the sender’s side too. When sending letters and packages, people don’t mind picking between a number of options (ground, express, signature required, etc.) that indicate urgency. If we can do a bit of behavior change (or possible force people via a token system), it’s interesting to think about how much e-mail could be improved. Easier said than done though.
Jacob Ukelson of Actionbase recently had some good comments on my posting “Information Overload as Evolutionary Maladaptation“:
Clay Shirky’s take on it is that the information overload problem (at least as it pertains to email) is an email filtering problem, not an information overload problem. His video can be seen here:
I hadn’t seen that video before, so I watched it and think it’s very good. In particular, the parts that stuck with me from Clay’s presentation were:
- We’ve lost our filter for quality. It used to be book publishers. Not anymore. So how will we now design the filters (rather than thinking about how to control the flow of content from the source)?
- Solutions are temporary and need to be continually adapted
- He applied a great quote to information overload. It’s from Yitzak Rabin: “If you have the same problem for a long time, maybe it’s not a problem – it’s a fact.”
- When you think about information overload, think instead about what changed – where the filter broke
I think he’s half right with his thesis. Defining information overload as a filter issue captures half the problem according to my Enterprise Attention Management model. It captures the “pushing information back” (attention shielding) part, but not the “pulling information forward” part. Unless he means the filter is applied in both directions, which didn’t come out in this speech.
I recently posted a set of ideas for improving e-mail from the point of view of enterprise attention management. It listed 15 ideas that would help e-mail users (which is pretty much everybody these days) to allocate their attention more efficiently to their daily tasks, whether that means more attention to some e-mails or less.
One of the items I listed on was this:
Remind sender if no reply
Avoid “dropping the ball” with e-mails by adding a simple checkbox indicating if an e-mail being sent should alert the sender if no reply is received within a given time (like 3 days). Too often post mortems indicate that a message was never replied to, the sender forgot about it (“fire and forget”), and the task was therefore left in limbo.
I cannot overstate the importance of closing the loop on communications between senders and receivers. Especially when you combine important messages with “weak” connections (meaning they are unlikely to speak often and are unlikely to have other chances to reiterate the information and check up to see if a message was delivered). Getting medical test results fits this pattern to a tee. In fact, when I added this item as one of the 15 ideas, I did so knowing that it had a very personal connection to my life. Today’s WSJ described why (6/23/09, pD4, “Make Sure You Get Test Results”). I can’t find the exact article online, but here’s a summary from the USA Today:
No news isn’t necessarily good news for patients waiting for the results of medical tests. The first study of its kind finds doctors failed to inform patients of abnormal cancer screenings and other test results 1 out of 14 times.
The failure rate was higher at some doctors’ offices, as high as 26% at one office. Few medical practices had explicit methods for how to tell patients, leaving each doctor to come up with a system. In some offices, patients were told if they didn’t hear anything, they could assume their test results were normal.
… “If bad things happen to patients that could have been prevented, that will lead to higher costs and in some cases considerably higher costs,” Casalino said.
I can vouch for “considerably higher costs.” At the risk of being overly personal or melodramatic, the issue mentioned in the study was the primary likely contributor of the death of an immediate family member of mine last year. When the “fire and forget” mechanism I describe involves a communication from a lab to a physician, that message can be important indeed. In the case I mention, a message indicating a negative result and recommending more tests was sent, but the recipient claimed to have not gotten the message. By the time the proper tests were run a few years later, the condition had progressed from highly curable (85% chance of survival past 5 years) to terminal (15% chance).
The “confirmed delivery” features of e-mail programs may be of some assistance, although in my experience recipients often do not acknowledge receipt and I’m not sure how consistent implementation is between e-mail systems. Besides, what I’m recommending is the opposite – a “delivery wasn’t confirmed” response. In cases like those described in the cancer screening study, “fire and forget” messaging can have very serious consequences.
In my last posting I listed 15 ideas for improving the attentional characteristics of e-mail (in other words, addressing “email overload” or “inbox overload”). There are now a couple of efforts underway to describe how these ideas are currently or can be applied to popular e-mail clients.
First, Ed Brill of IBM picked up the gauntlet and summoned Lotus users to describe “which of these attention management issues you’ve addressed in your e-mail environment.” I’ve been both a Notes and Outlook user and suspect Notes will fare a bit better when measured against an enterprise attention management yardstick. I’m interested to see what Ed’s readers can tell about their environments.
And Jack Vinson of the Knowledge Jolt blog has created a wiki to track which e-mail products can meet these requirements and which cannot. I encourage any and all e-mail experts to peruse the table and update it with information on how to accomplish these attention shielding tasks in each e-mail client.
BTW – I think it’s important to note how difficult it would be to accomplish these modifications: default, one-click (contextual option the user can easily find and select), multiple clicks (buried in option lists; requires some assembly), third party solution, or programmatic.
The most popular “overload” topic in offices today is e-mail. But after all these years of incremental improvement to IBM Lotus Notes and Microsoft Exchange, surely there can’t be any low-hanging fruit left to pick to help people manage inbox overload. Or is there?
The Enterprise Attention Management Conceptual Architecture to the rescue! Rather than relying on a set of personal pet peeves or specific annoyances that have happened in recent memory, a model such as the EAM conceptual architecture provides a systematic approach for analyzing the attentional characteristics of a system.
The EAM architecture is intended for use by organizations to examine individual technologies or whole systems (such as the information worker desktop) that are suspected of causing explicit (information stress) or implicit (poor decision making, slow reaction to new information) information handling problems. With systems it can be used for gap analysis. Here I use it as an intuition pump to reveal a set of potential enhancements to e-mail software that would improve its attentional characteristics.
Click on the thumbnail below and scroll around to see the ideas that came out of my informal analysis of e-mail. Also, here is a quick summary of the recommended improvements (going clockwise from the upper-left of the diagram):
- Scheduled delivery
- Maintain whitelists to bypass blocks and delays
- “Move to discussion” greys out “reply”
- Automated routing and prioritizing? Not yet
- Un-bury turning off or freezing of “toasts” (alerts)
- Enable e-mail hyperlinking
- Enable role-based profiles
- Enable sender tagged e-mails
- Stop attachment abuse
- Presence-enable recipient lists
- Enable group-based rules
- Turn e-mail into generic small-content tool
- Manage multiple inboxes
- Provide inbox analytics
- Token systems
- Remind sender if no reply
Caveat: I’m not an e-mail expert. It’s possible that some e-mail systems can already do these things outright, with some configuration, or with simple coding. If so, great, although they should be no more than one click away. In the meantime, my inbox is filling up as I wait for these capabilities in the next version of e-mail programs.
Google announced Wave at its conference on Thursday, resulting in some bubbly coverage by the IT press. Check out the video from Google’s conference where they announced Wave (although allow 1 hr 20 min).
I watched the announcement and sometimes during effusive vendor presentations I feel like the guy at magic shows trying to get past what the magician wants you to focus on to reveal how the tricks are done. That’s how I felt watching the video of the presentation where Google Wave was introduced.
For example, the story accompanying Google Wave includes some magician’s hand-waving about eliminating e-mail and reinventing communication (“e-mail was invented 40 years ago before the internet … instead of point-to-point like e-mail, there’s a server-hosted conversation that participants connect to …”) as he slips a collaborative workspace into your pocket. Boil this down and it’s a workspace instead of channel. Workspaces have been around 40 years too and also pre-date the internet as bulletin boards, usenet, etc.
The spell checker (an applause line brought up at least 3 times in the presentation) is contextual which is neat, but I don’t think the technology was created by Wave. While they didn’t mention its origins, I suspect it comes from the work done in Google Translate that implements statistical translation (one of two machine translation methods with the other being rule-based). By analyzing a truly enormous amount of text that is deemed to be accurately translated (one blog reported that Google used 200 billion words from United Nations documents as input), a learning system can develop inferences about how words are to be used and, given a new piece of text to translate, the highest probability of proper translation based upon past experience.
The presenter demos real-time editing with color highlighting and cursors for different editors. When the presenter asked if we could picture students taking notes in a class together, I thought “Yes, I can picture it very easily because I’ve seen SubEthaEdit.” Real-time collaboration editors have been around for a while. What’s cool is not that you can do that at all (“Imagine …”), but that it’s working in a browser and has an open API.
Beyond the re-purposing and re-skinning there are some advances:
- You can respond to parts of messages, which should be handy for those people that include several points in a message that you want to break apart. This also works in larger pieces of content so it acts as a larger content review process (comments are inline instead of in bullets to the side like Word)
- Google made the decision to have text entry be synchronous (you can check an async box to turn that off) so people can see what’s being typed as its typed.
- There’s a playback mechanism. Wikis inherently have logging, so it seems an obvious but fun next step to play through the changes.
The audience seemed happy. There were applause lines for dragging and dropping photos into a discussion, wiki-like changing of other people’s text and markup, drag and dropping a link to a collaboration space.
To me the upside is not the new invention (or re-invention) of capabilities. Think about Google Maps. The cool thing about Google Maps wasn’t that a programmer could overlay data on maps and scroll/zoom around it. That had existed for quite some time. What was cool is that the API made it so easy and embeddable that great applications (“Mapsups” as one client of mine called them) started showing up everywhere.
Well, Wave was created by the Google Maps team. If they can do the same thing with collaboration spaces and synchronous collab that they did with the Maps API we could see much better use of web-based collaboration. Too often collaboration tools have been modal rather than blending contextually into other apps. Hopefully Wave can make some inroads here. And that was, indeed, the point of the presentation which was to get developers excited about using the APIs to get the snowball rolling. It would have been useful to get past the presdigitation and instead of pretending this is all new or the “e-mail killer” to point more to the APIs as the real value.