Home | Login | Recent Changes | Search | All Pages | Help

SessId037

Electronic Collaboration
Creators: DaveSmith, JerryWeinberg, BobKing

Presenters: Dave and Bob

ElectronicCollaborationAgenda


Our Electronic Collaboration session explores how to create effective structures for electronic collaboration. Trying to be productive while separated is very difficult. So much of productive work can be found outside of traditional structures - like at the water cooler or in the halls or in body language. Can we be productive in an electronically structured environment? What are the conditions that must exist for this to be true?

We'll explore the specifics of many kinds of experiences with electronic collaboration, including

  • the AYE Conference project
  • the SHAPE forum
  • the AYE forum
  • any experiences the attendees bring

On getting started...

Structure and ownership are important to getting started. An inviting structure must exist initially. A structure which gently guides someone to an appropriate place for their ideas and which does not stifle their ideas is inviting. Enough, but not too much, structure to start with.

Ownership must be instilled in those who are collaborating. This might be obvious - without it there is no collaboration. Collaborators must be able to feel that they own the results of the collaboration and that the results will be important to them. [And their contributions acknowledged if not celebrated. DickKarpinski]

I want to explore notions of structure - what is too much, what is too little. These are both best decided in context - so what is important to observe about the context in which we hope to succeed with electronic collaboration?

Bob


Here's an idea - what if we partitioned the room so that we created some number of separate areas - I don't know how many yet. Each of these separate areas can see a shared working area. The working area might be white board or some other mechanism for posting ideas within some sort mutable structure.

Participants would be grouped to populate each of these separate areas. Locally, they can talk as always, but can only communicate with other groups through the shared working area via messages and commands. Messages are content, commands change the structure of the shared working area.

We, as facilitators, act as the computer to take the messages and commands to do what is required.

The teams would have some task to complete - like scheduling a conference or maybe some task that we have had to do in the course of setting up the conference.

Bob


I like the overall idea. We can work out details. If the group is large, we can have two (or more) competing designs and see what evolves.

If we have the right equipment available, we could run one group on an actual wiki. We should check that in April. [Well, was it checked? Why only one? DickKarpinski] [No, it wasn't checked. We forgot. But we'd need many simultaneous lines out of the meeting area, which I suspect will be very difficult - unless everyone has cell phone connections. Or unless there's something I don't know, which is very likely. - JerryWeinberg]

In the simulation, we could give some people roles, like flamers, novices, too-terse people, too-wordy people, and the various other types that infect any electronic collaboration. - Jerry


I like the notion of having competing designs - maybe there is an another phase to the simulation wherein we allow some merging of the competing designs - or maybe some sort of cross fertilization... Thinking out loud... Bob
What about capturing the dates of the additions? This is being added in late June, but April was in the future for some paragraphs.

What about a bit more structure for these notes? I'd like to have sort of a checklist at the bottom which had places for pending actions, for open questions, and so forth. See below for my first draft of such a template.

Spelling corrected, missing words inserted, missing concepts added by DickKarpinski.

Dick, we can each act as grammar/spelling correctors - editors, I think you call them. In effect, we can have a hundred or more parallel editors working on this wiki, silently. That should be better than any software that I know of today. - JerryWeinberg


Pending action items (with whom to nag, if agreed)
  • Check that we can run a live wiki. Jerry. Dave: yes. see below.
  • [Someone, please] check to see if we can get a projector to plug a laptop into.

Open questions

  • Should paragraphs show dates added or updated?

Context links (back pointers to pages that point here). [Just search for the name of this page. All the links just show up!]

Summary of decisions made (and by whom?)


I can bring enough equipment to set up a small network, provided that a few other people can bring network-capable laptops. --DaveSmith
I am planning to participate in this session and will be bringing a laptop to the conference so I can probably can volunteer it. I also have a Ethernet card for it for network access. However, it only has Windows 98 loaded on it. - JohnSuzuki

That and a browser should suffice. --Dave


I've been mulling over how to approach collaboration, and how to set up the opportunity for some "aha" moments. Here's a half-baked idea:

Many of the collaboration systems that I've seen suffer from being designed by "benevolent planners" who had a vision of how collaboration should happen, and who then designed rigid systems that just didn't "fit" the needs of collaborators. Such systems, if used at all, were used grudgingly.

So for this session, rather than walking people through a few ways to collaborate, how about tightening the feedback loop for prospective designers by doing something like the following:

  • Set up a mythical project that involves a distrubuted team.

  • Divide the participants in half. Half become a collaboration design team, and design a paper mockup of a web-based collaboration system.

  • The other half become customers of the system (i.e., team members). This group brainstorms on what they need from the collaboration system, refining the brainstorm down to a list.

  • Then, the teams come together. The designers present their design, and the customers critique the design, scoring against their needs.

  • Time permitting, the teams switch places and repeat the design/critique process again.

  • Then, to end with constructive momentum, both teams work together to develop a system design that meets joint needs.

What do you think? --DaveSmith


This reminds me a bit of Verseworks, with one team trying to satisfy a customer with their work. I'm wondering if you really need to run three exercises - which I suspect might start feeling a bit redundant, since they've had experience of the one before...

half-baked alternative one: Half the people are the design team, half are the customers. Each team selects one person to interact with the other team on the design (the "Marketer" and the "Representative User.") Of course, this may be simulating something besides electronic collaboration...

half-baked alternative two: The two teams can communicate during the design using the Wiki, but no other mechanism.

half-baked alternative three: (Saw this at a design conference once.) Split into three groups (or more if there are enough people). Two (or more) groups go off and design their system, while the last group - the customers - will evaluate each of the products they come up with. Each design team uses whatever method they want to define the solution (one might suggest customer-centered design methods may work best), and the customers figure out what they want and what criteria they will evaluate by. I like this one because you get multiple ideas concurrently, instead of serially like in your original idea. - JimJarrett


Another model of electronic collaboration is Philip Greenspun�s online communities. A good overview of his ideas is presented in Chapter 3 ofPhilip and Alex�s Guide to Web Publishing. (Available online.) The online version includes some of his tools, including user added comments and links at the bottom of the chapter. Essentially his vision is using web sites for people with like interests to get together and learn together, forming a community. His model includes more web site developer imposed structure than Wiki does. And the nature of the structure is far different than a moderated forum such as SHAPE. To see an example take a look at http://photo.net. (I haven�t looked at photo.net since the redesign and relaunch, so it is possible it is no longer a good example of what Philip is trying to achieve. Hopefully it is even better than it used to be.) And his company has a couple of white papers available from its home page. ShannonSeverance
I'm familiar with Greenspun's stuff. It's very linear. It works for discussions, but not for collaboration (at least not in my opinion). --Dave
Yes, you're right. I was thinking sometimes the appropriate collaboration might discussion. For instance where the goal is to learn more about a narrow subject. But if you are trying to collaborate on something, like, plan a conference, or design a shared piece of software, Greenspun�s ideas won�t help. His ideas are an interesting contrast to the SHAPE forum. Both have similar goals, helping others learn. But the structure Jerry uses in SHAPE and Greenspun uses in Web Tools Review* are very different. It goes back to context. Both "work". At least in my opinion, since I have learned from both sites. ShannonSeverance

Return to NewSessionDescriptions



Updated: Sunday, September 10, 2000