In June, Google announced an “Email addict” feature that was kind of a gag response to people complaining about email overload. When you press a “take a break” button, the screen turns gray and locked the user out of email until you clicked again. I had posted my own suggestions of how an email tool could help with email overload at https://knowledgeforward.wordpress.com/2008/06/08/google-lands-crushing-blow-to-email-addiction-with-new-feature/.
I was just turned on to Email Prioritizer from Office Labs which seems like a nice (and real) response to Google’s gag approach with its “Email Addict” feature. It hits on one of the features I wrote about: mail arrival schedules. I’d also recommend that Microsoft add automated scheduling options (hourly, morning/noon/evening, etc) to the manual option provided. This would simulate the cycle of the postman coming to deliver the mail, and leave your brain free outside those times to concentrate.
One nit: the description of the tool on their website annoyingly equated “do not disturb” as allowing you to “work without interruptions”. Unless you have toasts turned on email doesn’t interrupt you. And if that bothers you, the feature is already there to turn them off. I’d say email is a distraction or a temptation, not an interruption. The reason I’m picky is that there is a lot of great research around “interruption science” (for example, see interruptions.net) that mostly can’t help or doesn’t apply to this situation. One needs different approaches and has different goals and metrics when dealing with distractions versus interruptions.
A quick update to my entry from last week called “Where Did All The Collaborative Authoring Researchers Go?” where I hunted down a few collaborative authoring researchers to find out why all the research seemed to stop in 2000. I posted my summaries of our email exchanges, but they have since both posted their own enlightening entries on the matter.
Dr. Sylvie Noël’s entry is at “Is collaborative authoring research dead?“. She makes the argument “would it really be a very efficient method to have two people editing the same bit of text at the same time? Personally, I think the answer is no.”
Dr. Michael Spring posted two entries at his mBsLOG : “The research on collaborative authoring” and “What we still don’t do in collaborative authoring”. In the latter he gives the following list of features still not found in collaborative authoring tools (read his blog for more details on each):
1. Document locking
2. Document access controls
3. User and group awareness
4. Wow tools
5. Enhanced Communication
6. Lost in space
I’ve heard marketing folks in the IT space use the term pain points for years. According to the Buzzword Compliant Dictionary “Business consultants use ‘pain points’ as a term to describe the places where a business feels the ‘pain’ due to poor operational structure, bad software or good, old-fashioned inefficiencies.” If you’re in marketing for a software, hardware, or services firm or in IT and trying to secure budget or resources to address a problem, it’s a good idea to isolate the pain points and then describe how your recommended solution will ease the pain.
But I noticed today that many of the IT issues I’ve been writing about lately don’t lend themselves to pain points. It’s more like they are numb points. Users don’t think day-to-day about the symptoms of the underlying problem because they’ve been there so long and are so difficult to put your finger on, that they have become numb to it and just treat any resulting inefficiency as business-as-usual. For example, in my report on Enterprise Attention Management I wrote:
Most people treat attention management problems like e-mail overload and interruptions from IM and phone calls like they do the weather. Everyone complains about it but no one does anything about it.
That’s what I mean by a numb point. A second example I’ve run across is the cost and expense of translating and localizing content that was created for one language without regard to how easy it will be to localize later. A third is collaborative authoring.
But trying to get people to address a numb point is not easy, despite the criticality of the issue. For a parallel, think about the human body. Both pain and numbness can indicate very serious problems. A host of dreaded conditions involving circulation or damaged nerves can lead to parts of the body going numb, signaling major trouble. While the human body is wired to respond instantly to pain and force you to attend to the problem, numbness is more sneaky. It can go unnoticed at first. And once it is noticed, the numbness can be scary and lead to dread, but doesn’t inspire the same quick reaction as pain.
To get someone to address a numb point you have to first make them aware of the numbness, the nature of the efficiency loss it is causing, and how it is a symptom that is likely to get worse. You have to tap that numb part, show how that isn’t normal, and shake them awake into dealing with it rather than accepting a slow decline in function. That’s what I and others in the attention management / information overload space are trying to do in different ways. That’s what I hope to do with collaborative authoring and other content authoring trends in my current research. And I hope that over time, IT and business executives become more sensitive and aware that sometimes numbness, not just pain, demands immediate attention.
My job as an industry analyst sometimes requires me to be a detective. I’m in the midst of researching my upcoming document on “Content Authoring in the Enterprise 2.0 Age” and uncovered an interesting mystery.
Most of my day-to-day interactions are with end user clients, with a smattering of vendor conversations thrown in. But when researching a new topic I like to see what research is going on in academia, which is where I noticed an interesting phenomenon. One of the trends in content creation I’ll be writing about is “collaborative authoring”. This is the idea that more and more documents are being created as a collaboration between many authors, which introduces procedural and technical challenges. My research uncovered quite a bit of academic work in this area, but the lists of papers I found all mysteriously stopped around 2000. It’s as if an academic meteorite hit the earth at the end of 2000, wiping out all the collaborative authoring researchers without a trace!
Did humanity solve the collaborative authoring problem rendering further research unnecessary? Or was a more nefarious hand at play? I had some theories, but this was just too curious to ignore, so I contacted some of the academics who were involved in this space in the late ’90s to find out what happened. I’m happy to say they are still alive and well.
Dr. Sylvie Noël, an HCI research scientist for the government of Canada, fingered “free collaborative authoring tools such as Wikipedia” as a culprit. And since quite a few commercial products offering collaboration started coming out after 2000, researchers weren’t as interested. Dr. Noël did point out that work continues under the rubric of “collaborative editing” (more encompassing than just authoring). Regarding collaborative authoring, she still hopes for “a popular product that meets the large corporations’ needs and is as simple to use as email.” Me too.
Dr. Michael Spring, Associate Professor of Information Science at the University of Pittsburgh, pointed out that while the research assumed people author content together, in reality there is generally one owner with others just commenting. And getting information workers to be a bit more structured and maybe – gasp! – look beyond Microsoft Word is often futile. Like Dr. Noël he points out a profusion of “good enough” tools like wikis and better reviewing features in Word. Once theory starts showing up in real, commercial products like word processors and wikis the grants and academic interest dries up pretty quick.
Dr. Spring had another observation that carries over into my research on attention management and improving employee productivity. After exploring the potential time and cost savings that technology could yield for distributed collaborative authoring for engineering standards, he wonders if “the senior engineers really didn’t want to be that efficient.” They liked getting together in first-class global cities to hang out together rather than efficiently exchanging snippets of content using web-based collaboration. In fact, these efficiencies could threaten the staff and budgets of their departments.
To me, it’s unfortunate that this research has died down. Even if the theoretical level is now understood, it hasn’t all been turned into practice and technology yet. Large vendors like IBM and Microsoft do have research groups, but I haven’t confirmed they have picked up the research now that academia has handed it off. It’s clear there is still more than enough room for some good ideas.
Note: This is a cross-posting from the Collaboration and Content Strategies Blog
My last posting (“I’m a Conscientious Objector in the War on Interruptions“) was about how, despite my belief that information overload and interruptions are a real issue, some pundits go too far in lumping all sorts of issues in with it and propagating potentially misleading statistics on the problem. I just found a blog posting from Vaughan Merlyn that summarizes this issue beautifully:
if you pick the wrong label, you might misunderstand the problem, and thus come up with the wrong solution (or at least, come up with a solution that generates all sorts of undesirable, unintended consequences!) If you think of the problem as information overload you might look for a solution that cuts back on the information, and that would be a crime!
There is indeed danger in misdiagnosing this problem. I had an exchange with one information overload pundit (a group I’ll include myself in as well). We agree it’s a problem, but I disagree when he lumps all sorts of inefficiencies like socializing, distractions, and a one-sided view of interruptions into the IO bucket. When I pointed out how much of that isn’t strictly an IO problem and that there’s danger of overmedicating for this problem, his answer was effectively “So what? We all know the amount of IO is so high there’s no chance of cutting into good interruptions and information flows anyways”
Despite the “myth” statement in Vaughn’s title, he did say later that he thinks information overload is a real problem. It’s just that “my assertion [is that] that coming at this as an “information overload” issue presumes some things about the problem that are misleading and potentially dangerous”.
Agreed. It’s worth focusing on the real issues of enterprise attention management – how to pull important messages forward and push less important messages back. Even if you strip out the junk that gets incorrectly tossed in the “information overload”, like socializing and bad management practices and distractions, there is still enough real inefficiency left that can be addressed. Leave the crackdown on time-wasting distractions, socialization, and general corporate inefficiencies to the culture police – I don’t want any part of that.
There is a lot of conversation about information stress and overload that I can fully get behind, but sometimes it’s taken in a direction that can be counterproductive. First some things I do agree with:
People feeling deluged by the increasing amount of email, blogs, websites, etc. would generally benefit from stepping back and thinking hard about what they are doing and come up with processes and systems (personal attention management) to deal with it?
The amount of information and the number of channels it is used to launch at people are on a hyperbolic increase?
Many people have fallen down a slippery slope of e-mail, IM, or texting habits that are causing stress and counterproductive behaviors?
Organizations need to do more to understand how they use attentional technologies and capabilities and optimize them where it makes sense?
Many people are finding it more difficult to sort through all the noise to find important information and make good decisions in a timely manner?
Yes, yes, say it again!
I buy into all of that – I really do. I’m not a member of Stowe Boyd’s “overload, schmoverload” club. But it seems like at the other extreme a “war on interruptions” was declared somewhere along the way that I just don’t buy into (for a typical example, see here). How can I not be on that bandwagon when it seems like common sense? While I believe information overload and information stress are under-diagnosed issues, an easily quotable number incorrectly pinning this problem on one specific cause (unnecessary interruptions) can overmedicate for one symptom while ignoring a more holistic approach.
Let me step back for a minute and explain why I disagree with statements like “The cost of unnecessary interruptions plus recovery time (time spent getting back to where you were, if indeed you do get back there) to the U.S. economy is $650 billion as of 2007. Most interruptions are neither urgent nor important. The above represents 28% of the knowledge worker’s day.” (This comes from a Basex newsletter).
First, everything seems to count as an interruption, from socializing to e-mail (e-mail just sits there until you check it – how is that an interruption? It’s a “distraction” like having a TV in your office. Turn off alerts if they annoy you). Second, the time eaten up by interruptions is touted but not the time saved for those who felt impelled to interrupt. Third, before the word “interruption” I’ve noticed the modifier “unnecessary” casually flickers in and out (such as when the cost figure was $588 billion and didn’t mention “unnecessary”) despite the complexity involved in making a such a value judgement about each interruption.
I think it’s important to have realistic goals about how much fat is there to be cut. If 20% of that 28% really can’t be touched, then someone proposing a project to tackle info-stress or interruptions should make clear they are going after 8%, not 28%. The dangers of pumping up the inefficiency being tackled are:
- There’s danger in promising more than they can fix (you’re setting yourself up for failure).
- There’s danger of causing a net loss by cutting beneficial (to the organization) interactions. This must be tied to optimizing enterprise productivity – not the productivity of one worker at the expense of others.
- There are negative cultural impacts that could result if one thinks there is 28% waste out there and a major crackdown is needed. Extreme problems tend to lead to extreme actions.
- There’s a danger in proposing a number that is so uncredible that an executive decision maker dismisses the bearer of the information (article, consultant, internal employee asking for a mandate to address the issue). Executives are used to squeezing out a few percentage points of inefficiency. Being told there’s 28% sitting around just causes eye-rolling – I’ve seen it myself.
I wonder if these 28% and $650bn stats would stand a reversal test. If totally unnecessary interruptions are costing this much, does that mean eliminating them would save 28% of time and $650bn? If not, what’s going unsaid? If you lump distractions and socializing with interruptions or play loose with “unnecessary” then you’re implying a payoff that is an order of magnitude more than what is really achievable. There’s a base level of inefficiency to all human work that won’t be eliminated unless you get rid of the humans, so understand how much you really stand to gain as you tackle this problem. Dividing the two terms out (and literally meaning “interruptions” when using that term) allows creation of metrics, ROI, and strategies to address that can be applied to interruptions but would be useless against distractions and socializing. I would focus on how to improve the effectiveness of information workers by pulling more important information forward and pushing less important information back rather than sending in an exterminator to blast all the (unnecessary) interruptions.
A belated congratulations to the JSR 286 group, which went into final release in June. You can get the details here. Good job to Stefan Hepper of IBM, the specification lead, who must have had a tough time herding the cats on this one. Right out of the gate it’s good to see JSR 286 getting some attention from the portal vendors.
Of course it’s been in development for quite some time. When JSR 168 was being created a number of enhancements were shifted to JSR 286 to keep from slowing down the original portal spec’s ratification. The most important features of JSR 286 are inter-portlet communication (IPC) and alignment with the ongoing work on Web Services for Remote Portlets 2.0 (WSRP 2.0).
Vendor support has been promised soon as well (or is already here in the case of IBM).
- IBM quickly announced support in for WebSphere Portal 6.1 (as well as for WSRP 2.0). Way to track the standards guys!
- Oracle’s ALUI and Oracle Portal don’t have support yet. I’m told Oracle Portal may get it in 11gR1 release or later
- JBoss (Red Hat ditched its own portal in favor of the JBoss portal after acquiring JBoss) is promising support in Version 2.7, due out in Q3 2008 according to CMS Watch.
- A document from someone at SAP coldly stated that “SAP supports and actively participates in this new standard as EG member. As this specification is in draft version, it is not supported in NW CE.” I checked with my contacts at SAP and was told that JSR 286 is currently in scope for NetWeaver 7.0 Enhancement Pack 2, which is expected around October. I also noticed they did not vote on the standard. I wondered if this was a sign of lack of interest or a passive way to vote “no”, but their analyst relations staff said it was in fact because their committee representative was in the hospital.
My guidance to portal architects though is to consider bypassing JSR 168 or 286 portlets and even WSRP and focus on creating web services for information that they want to expose. Once the data portion is available as a web service, any decent portal product can create a quickie portlet (maybe in JSR 168 or some proprietary format) from the WSDL of the web service so it can be used in a portal. And then you have the option of leveraging that interface through non-portal mechanisms as well.
I should mention JSR 301 here as well. Presentation models have changed since the original JSR 168 specification was created. JavaServer Faces (JSF), the most significant of the presentation models for Java and has spawned many proprietary and open source attempts to transform JSF interfaces into JSR 168 portlets. The JSR 301 specification is only in its early stages, but promises to standardize these bridging mechanisms. No solid word yet on what that’s coming though.