Close enough

The issue of designing a collaborative task manager needs to also take into account real data from previous experiments where collaborative behavior took place. One of the issue is the sizing of the application. Soon into our experiment (in 2002), we jokingly came up with the DC law that stated that the size of the conversation threads between collaborating parties was 1/1000 th the size of the documents attached to these conversation threads. As of today, four years later, the size of the "library" of documents is 22.17 GB. The size of the conversation threads is 18.66 MB. Close enough. This is somewhat amazing that the "law" still holds. Indeed, in a matter of four years, new formats have appeared in the archives: MPEGs or very large JPEGs, yet the scaling still holds.

Designing a Collaborative Task Manager

I mentionned before the fact that multitaskers could not be more efficient than single minded people because there was a cognitive cost associated with having to upload their memory of the previous tasks. In a remarkable study, Gloria Mark goes farther and notes:

What we found is that the average amount of time that people spent on any single event before being interrupted or before switching was about three minutes. Actually, three minutes and five seconds, on average. That does not include formal meetings, because we figured if they were in a formal meeting, they were prisoners at the meeting, right? They couldn't leave or switch activities. So we didn't count that. Then we looked at [use of] devices, working on a PC, the desk phone, using any kind of paper document, using a cell phone. We found the average amount of time that people spent working on a device before switching was 2 minutes and 11 seconds.

But we called it a "working sphere" because "project" has a limited connotation, and a working sphere is a broader idea. Anything where there's a common goal, there's a certain group of people involved with it, there are certain resources attached to it, it has its own time framework and its own deadline, is a working sphere

So even when we took out what we call "non-significant" interruptions, we find that people still worked 12 minutes and 18 seconds in a working sphere before switching.

But there are also internal interruptions; for whatever reason, people interrupt themselves of their own volition and switch to something else. And what fascinates me is that people interrupted themselves almost as much as they were interrupted by external sources. They interrupted themselves about 44% of the time. The rest of the interruptions were from external sources.

GMJ: How long does it take to get back to work after an interruption?

Mark: There's good news and bad news. To have a uniform comparison, we looked at all work that was interrupted and resumed on the same day. The good news is that most interrupted work was resumed on the same day -- 81.9 percent -- and it was resumed, on average, in 23 minutes and 15 seconds, which I guess is not so long.

But the bad news is, when you're interrupted, you don't immediately go back to the task you were doing before you were interrupted. There are about two intervening tasks before you go back to your original task, so it takes more effort to reorient back to the original task. Also, interruptions change the physical environment. For example, someone has asked you for information and you have opened new windows on your desktop, or people have given you papers that are now arranged on your desk. So often the physical layout of your environment has changed, and it's harder to reconstruct where you were. So there's a cognitive cost to an interruption.

The designers of a task manager for a small business could learn a lot from these results. For instance, in my case, the application we developed at my workplace was aimed at handling the communication load of about 60 people with many different schedules, projects and from different functional groups. After some time, we noticed certain behaviors. First, we found out that if the application was not used by everybody uniformly, sooner rather than later, an assymetry of the information stream helped people who were least likely to contribute/use the system. In effect, cooperation between users was less effective over time. The second finding was a little more subtle. The application was written in PHP but did not use AJAX. Every time the page would load with new information, it took the new page about 10 seconds to refresh. In light of the study by Mark, it seems that this is enough of a burden that this cost of "waiting" for the refresh would have people drift into other applications and other "working spheres". For participants, the time spent in updating knowledge in the application felt like "feeding the beast" as opposed to being part of a normal cognitive process.

Another Sisyphus Job

In this entry I was talking about the mechanics of why multitaskers don't do things faster, nor that they seem to do things better. This interesting article seem to be saying the same. On top of the parallel computing idea that in order to multitask you need to constantly switch between different tasks, you also need to reinitialize your RAM everytime (by no means a simple process), it seems that humans are not efficient at constantly switching their RAMs. In other words, the constant RAM loading process seems less efficient as the day go by. Knowing that we seem to learn things after having been exposed to it only if we let six to eight hours to the brain to sleep on it, it would seem that most of us are condemned to relearn the same thing everyday...

Hypertaskers don't do things faster

In this article, people seem to say that hypertaskers do things faster but not better. I would not be so sure about that. When you read the convincing argument of Joel on multitasking and parallel processing (which seems to be the process identified in the Harvard study), you realize that for tasks that are supposed to last about equal time, you will not do things faster for any of the two tasks.

At long last the browser is the GUI

What a great way to do some rapid prototyping on a software GUI: Use the browser as Desktop UI. Everytime I want to go into GUI design I either rely on Matlab or Python, both of them have interesting approaches (WxPython) but generally too complex for a week end project, especially when you are not a programmer by trade.

On ISO and how do you implement a "lessons learned" process in a very large R&D organization ?

I just came across the following tidbit: an internal document produced at the Mashall Space Flight Center as a result of a stand down week at NASA. The purpose was for NASA to look into the recommendations of the Columbia Accident Investigation Board. Nasa Watch has the full document here:

"One facet of this program is Retaining Knowledge."

"The ISO process, in its entirety may not be applicable to the continuous R&D efforts within the payload area."

"NASA processes are not well documented, and too many of them are labeled out of scope� under ISO9000, the only quality assurance program in use. ISO 9000 was designed to require documentation of all processes, and yet as implemented at NASA and MSFC it is hoop-jumping paperwork that simply adds to the confusion. Where processes are documented, the reasons behind these processes are often obscured and difficult to find, as may be the full documentation on the proper way to proceed."

" ISO 9000 has absolutely nothing to do with real safety, it just generates paperwork. Lack of technical safety expertise of safety personnel. Not enough engineering test and inspection; generally reviews are handled as just a review of paper. Lack of priority on safety issues; all safety issues are treated equally. Safety training is more bureaucratic and not related to practical knowledge of safety in a laboratory environment. Lessons learned are not incorporated from missions or programs. Each person is the bottom line of safety. Need double-checking by technical personnel"

"I don't think that we in MSAD have a useful, relevant database that can easily be referenced by PMs, LSEs, PI/PSs, Managers, or our support contractors. We don't take advantage of our organizational experience to increase our chances of future success."

" We are being engrained with the need to provide the elevator speech - the problem is that very often the elevator speech is all that we learn - and obviously all that we are able to communicate. As a leading edge community we should and must do better. ". . . impatience, the mother of stupidity, praises brevity . . ." Leonardo da Vinci, 1513. This is also spreading to the need for numerous dry runs prior to the visit of dignitaries. Knowing one's subject beyond the elevator speech level and the Powerpoint chart will led to refreshing spontaneity. This will probably be more appreciated."

"There seems to exist a lack of understanding by managers of probability theory governing events that had occurred during previous flights, events that seemingly did not produce serious consequences. This lack of understanding or misinterpretation led these managers to assume that future similar events would not produce serious flight safety issues or conditions "

At some point, NASA will be able to solve these problems. The issue remains though, is an ISO process needed for organizations that are in the business of cranking out single items or prototypes ? How does one keep knowledge in an organization that spread over several states and decades ? Can a large task manager of some kind do the job ? If so, how does one go about extracting the knowledge from different performances ? NASA has a lessons learned program, but how does one make sure that the task performed by somebody within the organization has a "link" of some kind to a particular past incident ? Maybe a Bayesian filter combining the tasks listed in the task manager with the appropriate lessons learned database entries could do the trick?

What makes an application go supercritical ?

When Mark Shuttleworth talks about his thoughts of building up an Open Source application, it reminded me of a previous similar experience. My own experience is really that one can fall very easily into the problem of having a technical solution/framework/language running the functional requirements. What happens is that one waits so long for some features to be implemented that the developer feels that he/she has invested too much that she/he cannot turn back. The longer the time people wait for a functionality to show up, the longer the developer is cornered into the framework/language he/she has already used. In the end, the list of needed functionalities builds up and the user's interest winds down. It is therefore all the more important to have both a person involved in the day-to-day use of this application be the project manager and have developers use a language/framework that is responsive to the speed at which the project manager and other alpha-users can produce new functionality requirements. In our case, the initial use of Java brought the former item to light, we had to switch to PHP. Evidently, the ideal case would be to have a developer on the end of the line of a call center a la Paul Graham ( check for "while the user was still on the phone"). Lisp anybody ?

On the complexity of small businesses

I work for an outfit that deals with about 60-70 people ranging from full time staff to hourly undergraduates. We started five and the level of communication could be handled very nicely with E-mail. But with 60 people and the outset of spam, E-mail was just not a feasible solution anymore. So we developed an internal solution using PHP and MySQL and found out several things:

• the system was not working until group leaders would ask the people working for them to use it instead of E-mail
• it was important the application yielded improvement to people's daily work with only a small amount of people adhering to the system.
• the application was initially designed as a Task Manager but very small increment beyond that basic application brought new people to use it.
• after a year and half, last month, we had about 6 Gbytes of data uploaded/downloaded from the application. The library module of that application holds less than that. We also had more than 170000 hits that same month.

I'll post some other data later but what we probably need is to have some type of framework to develop such an application in the future. This approach looks quite interesting:
http://tmitwww.tm.tue.nl/staff/wvdaalst/Publications/p17.pdf

One wonders why it looks like business modeling seems targeted only to very large outfits. Even small businesses need these, especially in France with their 35 hour week. It is also very obvious that the flexibility in the modeling is essential in these small businesses. Indeed, generally these processes there are not very well defined in the first place. A killer app should be able to deal with the growth of the company/business while being reasonably priced.