Does your Collaboration Environment “Break the Flow?"

I spent quite a few years of my career designing user interfaces. One of the software tools I developed was a service creation environment (SCE) used to build and deploy applications that presented speech and telephony interfaces. I was lucky enough to be able to study user interfaces from the perspective of the tools that modeled the application (the GUI the developer used) as well as the voice interfaces the design tool modeled (VUI of the application produced by the SCE).

There are some fundamental UI principles that one can glean from literature, research, and of course from actually creating good interfaces, especially when you are working with creative people. There are some really neat techniques specific to the environment you are trying to make effective, usually with the objective of making things so intuitive that, as a user, you don’t even notice them. Like quality service from a good waiter, you get what you need but are not constantly aware of his presence.

In many ways, all these best practices and UI techniques roll up into a very high level guiding principle - and that is to not “break the flow” of the user. What does this mean? According to Wikipedia, “Flow is the mental state of operation in which the person is fully immersed in what he or she is doing, characterized by a feeling of energized focus, full involvement, and success in the process of the activity. Proposed by psychologist Mihaly Csikszentmihalyi, the concept has been widely referenced across a variety of fields.” (http://en.wikipedia.org/wiki/Flow_psychology )

So “breaking the flow” means diluting that immersion, sapping that energized focus, and jeopardizing the “success in the process of the activity” through distractions. Some examples of “breaking the flow” for a computer user include making him stop what he is thinking about or entering into the application to consider where to save a file to disk, needing to search through a list of icons to find the right tool for a task, clicking through many unrelated forms to accomplish a task, or having to read help to find a feature. In short, anything that requires the user to turn his attention away from the task he is trying to accomplish to tend to the needs of the software.

I find myself considering this principle as it applies to a broader set of activities in the collaboration process, especially as this area explodes with opportunity. Working collaboratively can inherently “break the flow.” You need to wait for someone to update their section, review your work, or post comments to a forum which will change you next actions. While everyone recognizes the value collaboration can bring, there is often little attention paid to the additional efforts involved.

But here I want to specifically consider the role that the environment plays to fold these necessary collaboration activities into “the flow.” Does the environment help to minimize the “break in the flow” that is part of collaborating? This is a question I have begun to ask myself as more and more computer-based collaboration tools materialize. Does the supporting software minimize interruptions or make them worse? Are the interruptions constantly diverting attention or are they grouped in a way that minimizes changing the train of thought? Are interruptions necessary to collaboration or missed opportunities for transparency? In short, does the environment “break the flow” or support collaboration through existing work habits.

I find the following activities consistently “break my flow.” Having to find a URL of a portal for one of the many teams I am working with so I can check out and download a document before I can edit it – after I have logged in of course. Having to deal with finding a temporary spot on my disk to make an “interim copy” which I then have to upload and check in later. Discovering that the document I wish to work on remains checked out to a coworker who just left for an undeserved two week vacation to Aruba. Getting emails that tell me someone posted the word “Thanks!” to a forum. Having to cut and paste information such as URLs from one collaboration area to another. Oh yeah, and rummaging through long lists of loosely related documents to find the one I am supposed to comment on.

All of these activities have the characteristic of making me figure out some tangential aspect of the collaboration process, interrupting the flow of the work I am trying to get done. Some of these could and should be solved through better interface design in the collaboration tools. Some can be addressed through better integration of tools (e.g. single sign on, well structured portals, searches, and tools that support how I work today such as integration with email and shared disk drives). Some can only be solved by creating social norms around the collaboration process (use “reply all” sparingly).

This idea of “not breaking the user’s flow” is really very simple but often very hard to achieve. It is frequently overlooked as a design objective, especially amongst the more geekish who understand what is going on behind the scenes. To sponsors of development projects, it can feel like a bit of paradox to invest heavily to make something as simple and transparent as possible. When something is elegantly simple, it’s easy to say “what was so hard about that?” Once you see it, it’s obvious. But this is a hallmark of good design in any discipline. Simplicity can be complex to achieve.

So while it may seem obvious, “don’t break the flow” might be a simple guide to help organizations choose, configure, and integrate collaboration tools. I firmly believe it is the critical element to adoption. Like the waiter who can clear your table without interrupting your conversation with fellow diners, a collaboration environment should enable you to incorporate the additional tasks involved in interacting with others so seamlessly that you are not distracted from actually collaborating!

Loose Coupling – Unraveling that ball of Wires

I was returning from an architectural planning session with a customer who was looking to modernize a very old but very mission-critical application. They had the usual reasons to modernize – hard to leverage newer technologies, hard to find skills to maintain the legacy code, and so on. They also faced a requirement that often times only becomes obvious after some study – both the new and the old applications needed to run in tandem to avoid a “big bang” conversion. This application was so mission-critical, no one could risk that. But the current application is a tightly coupled monolith of processes and data files that has decades of extensions and hand-coded adaptors to make it the mission-critical work-horse that it is. Components would be migrated iteratively, but the tight coupling in the existing system meant the new system had to run in parallel throughout the migration.

As I began to unwind on the plane, I mulled over the complexity of their challenge. You can lay out a general architecture that is based on the lofty SOA principle of loose coupling, but when you get into it, there is a whole lot of unraveling to do before you can really reach that tidy nirvana. My mind wrapped terminal applications, unraveled data files, and created JCA adaptors as the engine noise from my wing seat lulled me to doze back in time…

I was back in my college days, playing in my band. Instead of enjoying the crowd’s appreciation of my solo in “Freebird” I was “reminiscing” about all of the work that went into playing out somewhere. We finished playing a job and the appreciative crowds left behind only the empty beer bottles. We were in the middle of that massive exercise to tear down the equipment. Ah the glamour.

We had to tear down all the equipment where we practiced and set up again to play, and now we were reversing the process to go home. A lot of time went into disconnecting and reconnecting components using the many, many wires. Microphone to PA, PA to stage speakers, PA to monitor speakers, power to PA, amplifiers and lights, tape decks to PA, PA to tape deck for recording…. There are lots of different kinds of cables to connect lots of different kinds of components. Of course a big part of the challenge was to have our equipment work with the resources provided by the place we were playing. I can still picture cords, hoping they would reach where they needed to or that the plugs would match or that the cable still worked after the abuse of moving.

The great nemesis after the jerry-rigging and changes made while we played was the tangled ball of cords at the end of the night – in fact I considered naming my band just that - Tangled Chords – it was the late seventies. Two o’clock in the morning and we can’t go home because the wires are so tangled up, not just with each other, but around the legs of tables, bar stools, microphone stands. No matter how carefully we laid them out when we set up, by the end of the night they were completely entangled. Some form of entropy I suppose.

Turbulence brought me back to my seat on the plane. “The wiring for setting up a band would make an SOA architect blush” I thought. I considered the analogy more deeply because as a band, we put a lot of thought into how to make the moving process “more agile.” The tangle is created by the things in the club you cannot control – if you plug this in here it will only reach to there. The speakers have to be on that shelf. You can’t run wires across where people walk. Or, the power outlet does not accept a ground so you can only plug in over there with an adaptor. Similarly, the entanglements in a would-be SOA architecture are most protracted around the existing concrete things – the way people interact with the system, data that is shared by existing processes, and key processes that are off limits to change.

The lesson? In both situations you can see that, without care, the new system will inherit the tight coupling of the existing system. And the approach to reducing this effect seems quite similar to both worlds:

• Simplify the existing environment (get as many entanglements and obstacles as possible out of the way up front)
• Make the existing resources as easy to use as possible before you start using or integrating them in your new system.
• Create a master plan – a schema of the best layout if you will. Understanding all the connections you need to make helps understand how to keep things separated.
• Use a centralized connection point – in the music world this is a mixer board that allows you to change logical connections without moving wires. In IT this is probably an enterprise service bus.
• Plan for change – there always will be surprises. For the band this involved having a “toolkit” of adaptors, extension cords, extra wires, and so on that helped solve a problem without heading out to the store to buy a widget we did not anticipate needing.
• Coordinate your activities with people responsible for other elements in the system.

A note on how basic the last point is. We played in some old bars where the wall sockets did not allow for a ground. When each band member set up his own equipment we would argue over who got the adaptors and wall sockets which quickly became scarce. The solution was to reshuffle the octopus with each new need to plug something in. With some coordination we realized that setting up a power strip as soon as we got there provided power for all and only required a single ground adaptor if one was needed. This sounds like a pretty obvious solution but its amazing what can happen without some coordinating influence.

Thinking about the migration problem my client was facing in the context of the concrete steps we evolved to facilitate setting up our equipment many years ago brought some clarity in my mind. Considering the steps we evolved, the challenges seemed a bit less daunting. I deplaned feeling confident I could avoid getting tangled up in blue.

I have ideas I haven't even thought of yet!

I have ideas I haven’t even thought of yet. I had a college professor who used this phrase quite negatively. He meant the guy who really had no ideas but considered every thought he had a real jewel. But I love this thought and think it expresses a certain pressure that energetic creative people feel – that in the right situation given the right information they will generate ideas that solve life’s problems. As organizations are turning increasing to collaboration solutions enabled by “web 20” technologies to bring people together, I have great optimism that we will see increased productivity from folks who have ideas they haven’t even thought of yet. Why? Because well-organized collaboration has the potential of fulfilling the predicate in my interpretation - in the right situation given the right information they will generate ideas that solve life’s problems. Collaboration technologies have the potential to create the right situation –the right problem being posed, the right people listening, the right timing, the right community to tackle something. Collaboration technologies have the potential to make the right information available – that’s central to content management systems. The good news is, even if my cynical professor was right, increased collaboration will increase productivity because real collaboration creates a kind of filter for ideas. If these folks really don’t have any ideas they won’t have anything to collaborate about! . But if my optimistic perspective is accurate, better technology applied with the right collaboration principles should enable these frustrated contributors to “maximize their potential” – and we will all benefit from that.