Life With Alacrity

SynchroEdit: Simultaneous Editing for the Web

For the last several months I've been working on a new open source project that I've been calling SynchroEdit. SynchroEdit is a browser-based simultaneous multiuser editor, useful for "same-time" collaboration.

The basic concept is that it allows multiple users to WYSIWYG edit a single web-based document, all at exactly the same time. SynchroEdit continuously synchronizes all changes so that users always see the same version. They can also see each others' changes as they type, see where each user is currently editing, and see each others' changes by color.

SynchroEdit is a tool for "same-time" collaboration, either "same-time, different-place", as in teleconference calls, or "same-time, same-place", during a meeting or a conference. If you've ever used SubEthaEdit on Mac OS X, or MoonEdit for Windows or Linux, or the cross-platform Gobby, this is a similar experience. The difference is that unlike those tools you are not limited to just plain text -- character styles (bold, italic, etc.) and paragraph styles (rulers, headers, blockquotes, etc) are synchronized as well. And of course, it all works inside your browser.

SynchroEdit is inspired by my frustration with the lack of an easily accessible cross-platform simultaneous editor. Many times when I've been on the phone with a colleague discussing a draft blog entry, or demonstrating some code, or on a teleconference call with others to discuss a proposal or a standard, or at a conference taking notes with others, I've wanted to have this tool. The rare occasions that we all have been on the same platform and have been able to use an existing tool have demonstrated to me the value of having a good simultaneous editor. Having SynchroEdit available will make it easier for people to have these positive collaborative experiences. 

I have a long history with "same-time" collaboration tools -- back in 1988 I was briefly executive producer at Broderbund for a same-time groupware product called For Comment. Unfortunately, the success of the Nintendo game console forced Broderbund to drop all of their non-consumer product efforts. In the early 90's I worked on several different "same-time same-place" groupware tools for live meetings. Most recently, my game company Skotos Tech, created several browser-based "enhanced chat" clients for playing in MUSH-like storytelling games, which are also "same-time".

I personally believe that that this capability should be a fundamental feature of the web, sort of the obvious extension of Tim Berners-Lee's vision of the editable web. Thus my desire to offer this tool as open source, allowing anyone to add this capability to their own software (unlike proprietary editor services such as JotLive or Writely).

The challenge with offering SynchroEdit as open source is finding a business model -- unlike an application like SubEthaEdit or a service like JotLive, it is difficult to get revenues from individual users. Instead, we ask for contributions from companies that might find the tool useful, we offer consulting to customize it for specific purposes, and we give these companies public credit for their contributions to the common good.

The first company to step up to the plate is SocialText, an enterprise wiki company. Clearly, being able to offer this capability to their customers will give them added value, and they already have a history of using open source with their support of Kwiki and Wikiwyg.

The second supporter is venture capitalist and blogger Joichi Ito. He is is particularly well known for his own experiments with "same-time" collaboration. He runs a continuous #joiito IRC chat room, active 24 hours a day with hundreds of his friends. He also has done many live "same-time" experiments with chat backchannel during his talks at various conferences.

In addition to to financial support of SocialText and Joichi Ito, I have some offers of help from the Bainbridge Graduate Institute, who plan to use it in its socially responsible and environmentally sustainable MBA program, and we've also taken advantage of some code developed by Skotos.

The development of SynchroEdit is being led by Kalle Alm, a young Swedish coder I met when he was creating an online game at Skotos. Skotos has long had the vision of having games created by its members, and Kalle Alm was the first member to create a game completely from scratch using Skotos' tools.

We are seeking more financial contributions so that we can accelerate development. Currently SynchroEdit only works in Mozilla/Firefox, and I anticipate that making it work with Internet Explorer may be quite difficult, so we'll need more partners to help.

I did a demo of last year's open source project, EditThisPage, and of the SynchroEdit alpha at Web 2.1 BrainJam last week; there are two videos available from Enric Teller's vBlog: Presentation and Q&A. 

If you are interested in learning more, visit the SynchroEdit website. We have additional information on the program, a developers wiki, as well as a sandbox that you can play in to demonstrate SynchroEdit in use.

 

 

 

Extrapolative Hostility in the Online Medium

Extrapolate

To infer an unknown from something that is known; conjecture.
-- The Random House College Dictionary

Mick LaSalle, an acerbic movie reviewer for the San Francisco Chronicle, writes a regular column "Ask Mick LaSalle" in the Sunday paper, where he sometimes allows others to vent their displeasure at his movie reviews. In this week's column he says something that I find very accurate to my experience with the online medium:

As for why people get hostile when they hear a differing opinion, I go back to Spinoza's definition of love and hatred. He says that people love that which they think reinforces their survival and hate that which they think threatens their survival. I believe -- this is just my humble theory, now -- that when people hear an opinion that counters theirs, their minds extrapolate from that one opinion to imagine a whole philosophical system. And then they imagine how they would fare in a world run according to that imagined system. So they go from disagreeing to feeling threatened in a matter of seconds, and they lash out. Often they write letters that begin, "You are obviously," and that's where they identify, not you, but the phantom they feel threatened by.

Over the years, I've been "obviously" liberal, conservative, gay, straight, humorless, frivolous, angry and deeply jealous of Tom Hanks. When I was 30, I remember getting accused of being a 45-year-old former hippie who drove a BMW, wore a Rolex and had done acid in the '60s. I'm not sure if I wrote back, but if I did, I would have said, "Wrong. Wrong. Wrong. Wrong. Wrong." But, of course, that kind of letter is your key to acquiring distance. It lets you know that the person's real quarrel is with some middle-aged former hippie -- probably known as Dad -- and that you're just the vehicle for that day's projection.

I think that Mick LaSalle is exactly right -- I've seen this type of hostility based on extrapolation regularly in online mediums: in emails, newsgroups, wikis, blogs, etc. I've been guilty of it a few times myself, though usually for me the result is that I don't respond at all -- "Oh, he is just a flaming liberal", "She's an arch-conservative" or "He is a just a technophobe." I can then feel comfortable in ignoring the rest of his or her point of view rather then trying to understand it.

I doubt if explaining this theory to someone who writes a hostile message is useful -- they will take it as yet another attack, which will likely contribute to another cycle of flamage. But I do find Mick's theory useful as another way to read and understand hostile messages, and respond more appropriately.

Understanding this lets me add another widget to my social software toolbox: when a group process results in a hostile message, try to determine if the author is actually reacting to what you said or if their hostility is based on extrapolating to "obvious" generalities. This may not allow you to directly address the hostility, but it may help you better understand it and thus not contribute to the cycle of flames.

Future Topics

I've been working on an ambitious list of topics that I'd like to cover over the next year. I offer them to you here so you can have some idea the areas that I am thinking about.

Office Architecture for Innovation -- Over the years I've built or converted three offices to my specifications. From this I have learned a number of things about about how to create a productive environment innovation-oriented businesses. These include some of the obvious suggestions such as fresh air and natural light, but also include not so obvious ideas such as using magnetic paint and providing a small washer-dryer.

Requisite Variety -- This concept from cybernetics applies to social systems as well. "The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate." More people, as well as a diversity of thinking styles and experience, give social software more "variety of actions", thus this is part of the reason why social software can be so effective.

The Art and Craft of Meme Design -- We are learning more about how to create an effective meme. Creating memes has always been an art performed by publicists, marketers, politicians, the press, and to a lesser extent by scientists and other academics. Have we learned enough to turn this art into an explicit craft?

Wiki Editing Dichotomy -- One interesting possible barrier of entry to active participation in a wiki is what I call the "wiki editing dichotomy". You have to be proud enough to believe what you are contributing is generally worthwhile to others (or at least worth your effort), but you also have to be humble enough to understand that others can improve it. I don't know of many other collaborative media that requires both pride and humility.

Choice & Neuroeconomics -- There are some that say at the root of every decision is emotion. Even a 'rational' decision appeals to a sense of balance or beauty. Recent studies using PET are establishing a neurological basis for emotions, and some reveal interesting facts about how we make choices.

Assessing Risk -- There are a variety of areas where we as humans have a difficult time being completely rational. One of these is risk assessment. It turns out we may be hard-wired to not be able toeasily understand risk that is greater then one in a hundred or so. Thus a very rare risk, say one in a thousand, will often be emotionally interpreted as having a much higher risk.

Persuasive Computing -- BJ Fogg's group at Stanford has done some interesting research on how computers can persuade you to do something. There are a number of useful ideas that come from this research. There are also some ethical considerations that should be discussed.

Cognitive Dissonance -- This technique is central to many forms of persuasion intended to change beliefs, values, attitudes and behaviors. It is used by facilitators, businesses, military organizations, and even cults. It can be used positively or negatively. How might it be used in social software?

The Dark Side of the Force -- The same social tools that we use for good, can also be used for harm. How do we ethically use what we are learning about social software? Some say that almost by definition social software attracts spammers, trolls, and innappropriate sexuality. What can we do to prevent these misuses of social software?

Conversation vs Communication -- Update and rewrite of my 1990 essay on how social software design needs to balance conversation vs communication.

Social Emotions -- We appear to have evolved a number of emotions that appear primarily to exist to support a common good, rather then to ensure our individual success. These include schadenfreude, mirth, naches, revenge, shame, pride, outrage, approbation, admiration, elevation, etc. Studies by Eckman on unconscious facial gestures, studies on the neurological basis for emotions, and studies on emotions in games, are proving that these social emotions exist. A number of them have interesting implications on social software.

Glances & Strokes -- There is some old work on the amount of eye contact we make with others in small groups, as well as some research from transactional analysis on strokes, which are the amount of recognition given to others through words and deeds. Is there a neurological basis for needing a certain number of glances and strokes each day? How does this concept apply to social software?

Weak Links -- There are some interesting social implications behind what we've learned about weak links in social networks. How do we identify and encourage weak links in our social software systems?

Negativity vs Positivity -- It is far easier for someone to respond negativel than positively. In political systems it is far easier to say no rather then yes. What social software encourages positivity, and is it possible to design social software to do so?

Time Economy -- Our ultimate most unrenewable resource is time. How time and attention are a basic economic unit that should be considered when looking at social software.

Group Life Cycle -- We often focus on how groups form, emerge, and grow. Yet there are many lessons to be learned from how groups die, including that it isn't necessarily a bad thing and that keeping a group from death can be dysfunctional.

Groupthink -- What causes groupthink? When is it good and when is it bad?

Two Thresholds in the Value of Knowledge -- In order for knowledge to be valuable, it must at minimum be more valuable then the costs to find and absorb it (costs which include bandwidth and attention). Tools like Google have tremendously increased the amount of knowledge that is worth the time and attention to find it. What types of knowledge fall below this threshold of value? Is there a limit to how much we can lower this line? Furthermore, there is another threshold where the knowledge is significantly more valuable than only bandwidth and attention. How much have internet tools impacted this second threshold? Many internet business models, in particular content models, require some ability to offer value in this upper threshold -- can they survive as this upper threshold changes?

Intimacy and Social Networks -- Social Networks Analysis tends to focus on the connections between people, either explicitly through acknowledgement of connections (LinkedIn, Friendster) or implicitly through analysis of your communication (Spoke). None are able to measure intimacy. Yet our intimate social networks are an important component of our overall happiness and contentment within both our professional and personal lives. How does intimacy work in social networks? Also there are some concepts in psychology known as communal vs exchange relationships by Clark & Mills from late 70's that may apply here.

Social Games -- A recap of Shannon Appelcline's and my analysis of the basic forms of social games types. These include relatively well understood ones like majority control, voting, meta-voting (Nomic), auctioning, etc., but also include less well understood games like playing of roles, dominance and submission, etc. There are also links to social emotions, such as mirth and schadenfraude.

Lessons from Castle Marrach -- We released the Castle Marrach online game in September of 2000, and it was designed from the beginning to be a game for the Bartle-type known as "the socializer". What lessons did we learn in the five years since the release of the game? What tools are in my social software toolbox today that might have helped with the design?

Lessons from F2F Facilitation -- There are many skilled practitioners of face-to-face facilitation, some of which are paid very high fees for their skills. What lessons can we learn from their experience that we can apply to social software? Why have so many of these facilitators failed to have success online?

More Human vs More Than Human -- Many futurists seek to offer us augmentation of our minds and bodies through technology. Many of these ideas may fundamentally change what it is to be human, and may even have unforeseen complications unanticipated by their creators. One interesting approach to looking at these technologies is to examine which make us "more human", rather then "more than human".

Lessons from Mental Disorders -- Most, if not all, mental disorders have their roots in survival strategies; however, they are over-expressed because of genetic or other causes. Examining the healthy behaviors hiding behind depression, autism, mania, schizophrenia, paranoia, etc. offer a number of insights on how we think.

Joy of being a Primate -- If you scan the surface of my writing, you may observe that I have a strong belief that our animal nature and genetics form an essential and often unconscious part of what it is to be human. You could interpret these "nature" over "nurture" ideas as limiting us to being just animals. Instead, I believe that by becoming aware of our primate nature, and choosing to leverage it or suppress it by conscious choice rather then letting it drive us unaware, is what makes us more powerful.

Smart Contracts -- Nick Szabo popularized the idea of using some of the primitives of cryptography in unique ways to create what he calls "smart contracts". He hypothesized approaches to cryptographic handling of collateral, bonding, delineation of property, bearer certificates, and much more. Others have proposed various auction protocols using these concepts. One of the fundamental atomic elements of many of these smart contracts is something called a "reusable proof of work", which Hal Finney recently demoed a version of at CodeCon 2005. What are the possibilities offered by smart contracts? What are the barriers to implementation?

Club System -- In the 80's, development of Ted Nelson's Xanadu vision was being financed by Autodesk. Unfortunately, for a variety of reasons Xanadu failed to deliver any technology. However, a couple of their ideas could be valuable today, one of which is the concept of an alternative to the "user and groups" metaphor for computer security. Xanadu turned that idea upside down and called the result the "club system". The club system approach is particularly suited to the internet based collaboration tools, in particular wikis. I also have some insights to offer a cryptographic approach to the club system, which might allow P2P distribution of collaborative documents, while preserving group privileges.

Edges of Cryptographic Security -- The SSL cryptographic protocol offers a choice of a number of security properties: integrity, confidentiality, encryption, one-party authentication, and two-party authentication. But there are a number of security properties that very few deployed cryptographic protocols offer. These include perfect forward secrecy, undeniability, deniability, authorization, delegation, multi-party authentication, shared secrets, etc. What are these security properties and how are they useful? Why have they not been successfully broadly deployed?

The SSL Story -- When SSL was first proposed it was broken within an hour. Even when Netscape fixed those problems, it wasn't clear that SSL was going to win the battle of security protocols. SSL was competing against SHTTP which had backing of RSA and an industry consortium. The credit card companies merged their standards and were backing SET. The internet community was moving toward SSH. Microsoft was doing its own embrace and extend protocol PCT. So how did SSL win to become the broadest deployed cryptographic security protocol? The answers may surprise you.

I welcome any comments or suggestions for links on these topics, or any new topics that you feel are closely related.

Voluntary Health Associations & Social Software

I'm a keynote speaker for the FVHA (Future of Voluntary Health Associations) Conference in Atlanta today. My job is to give to this community a gentle introduction and overview of concepts and products related to Social Software and Social Networking. (My slides are here - 6.6MB .pdf)

In my research about this community, I find that they have some unique and interesting problems.

The attendees of this conference are a collection of VPs and national directors from major Voluntary Health Associations such as American Cancer Society, American Heart Association, American Diabetes Association, March of Dimes, etc. In turn, these Voluntary Health Associations organize communities in order to raise funds for, and inform the public about the medical implications for the different health problems that each are concerned with. These associations have an organized volunteer base of over five million people and raise in excess of two billion dollars annually. They all have dedicated and diverse volunteer communities which include practicing MDs, scientific researchers, health educators, business executives, and working and nonworking mothers.

I think it is the quantity of people served, the diversity of their communities, and in particular, the need to dive deep into information that makes these Voluntary Health Associations interesting. A women diagnosed with breast cancer will need to make educated decisions about her own health care in order to give informed consent. Yet she may not have the education experience or background to understand the care decisions she must make. She may not even have a current era computer. There are few other online communities that need their members to understand so deeply such difficult problems.

Thus the desire of these associations to look deeper in to Social Software. Of course, their key interest is in better understanding, motivating, and expanding their volunteer networks. They are already experts in the business of organizing traditional communities, but now they have to deal with the changing nature of communities as their members are now using the internet as the primary source of information.

Ideally Social Software can help increase their sense of touch with their volunteers, it can empower volunteers to collaborate and work harder and in new ways, it can increase information sharing and innovation, and it can help drive fund-raising numbers higher.

But the openness of social software comes with a price. For instance, many of these associations are afraid of enabling even simple unmoderated discussion lists, in fear that bad or inappropriate information would be shared. There are also legitimate concerns about the quality, audience level, and attributation for even correct information. In the Q&A after my presentation I tried to explain how, when looking at individual blogs, or individual events of info vandalism, it is not really relevant if the communities and processes behind the Social Software are able to correct or filter those events. This is a difficult point to get across, as it requires people to learn to trust a system where the squeaky wheels and trolls are the loudest.

One particular interesting thing about this conference is that it is one of the first between multiple associations. I know from some other non-profits that I'm working with that they often feel in competition for funds and resources from other non-profits, so I applaud the American Cancer Society for sponsoring this cross-pollination effort.

Tracing the Evolution of Social Software

The term 'social software', which is now used to define software that supports group interaction, has only become relatively popular within the last two or more years. However, the core ideas of social software itself enjoy a much longer history, running back to Vannevar Bush's ideas about 'memex' in 1945, and traveling through terms such as Augmentation, Groupware, and CSCW in the 1960s, 70s, 80s, and 90s.

By examining the many terms used to describe today's 'social software' we can also explore the origins of social software itself, and see how there exists a very real life cycle concerning the use of technical terminology.

1940s — Memex

The earliest reference that I can find to people using computers to collaborate with one another is from the 1940s.

Near the end of World War II, in 1945, Vannevar Bush wrote a seminal article on the future of computing in As We May Think. In it, he conceived of a device he called the 'memex', which today we might call the personal computer:

"A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory."

Later on, the article discusses Memex's further benefits to groups:

"And his trails do not fade. Several years later, his talk with a friend turns to the queer ways in which a people resist innovations, even of vital interest. He has an example, in the fact that the outranged Europeans still failed to adopt the Turkish bow. In fact he has a trail on it. A touch brings up the code book. Tapping a few keys projects the head of the trail. A lever runs through it at will, stopping at interesting items, going off on side excursions. It is an interesting trail, pertinent to the discussion. So he sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex, there to be linked into the more general trail.

Wholly new forms of encyclopedias will appear, ready-made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified. The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities. The patent attorney has on call the millions of issued patents, with familiar trails to every point of his client's interest. The physician, puzzled by its patient's reactions, strikes the trail established in studying an earlier similar case, and runs rapidly through analogous case histories, with side references to the classics for the pertinent anatomy and histology. The chemist, struggling with the synthesis of an organic compound, has all the chemical literature before him in his laboratory, with trails following the analogies of compounds, and side trails to their physical and chemical behavior."

As far as I can tell, this is also the first mention in literature of what will eventually be called hypertext. However, the term 'memex' never caught on - - Vannevar's ideas were way before their time.

1960's — ARPA and Licklider

It wasn't until the early 1960s that I find the idea of using computers to collaborate came up again.

As a response to the USSR launching Sputnik, the US formed the Advanced Research Projects Agency (ARPA) in 1958. In l8 months, ARPA has developed the first successful satellite. In 1962 Dr. J.C.R. Licklider was appointed to head ARPA, and changed ARPA to offer more research grants to universities. In fact, it was due to his efforts that universities offered their first Ph.D.'s in computer science. It was this research that ultimately led to ARPANET, commercial time-sharing systems, and ultimately to the Internet.

Licklider wrote in 1968 in The Computer as a Communication Device:

"To appreciate the importance the new computer-aided communication can have, one must consider the dynamics of 'critical mass,' as it applies to cooperation in creative endeavor. Take any problem worthy of the name, and you find only a few people who can contribute effectively to its solution. Those people must be brought into close intellectual partnership so that their ideas can come into contact with one another. But bring these people together physically in one place to form a team, and you have trouble, for the most creative people are often not the best team players, and there are not enough top positions in a single organization to keep them all happy. Let them go their separate ways, and each creates his own empire, large or small, and devotes more time to the role of emperor than to the role of problem solver. The principals still get together at meetings. They still visit one another. But the time scale of their communication stretches out, and the correlations among mental models degenerate between meetings so that it may take a year to do a week’s communicating. There has to be some way of facilitating communication among people without bringing them together in one place."

Here you see Licklider really speaking of more than just communication. He also describes about methods of collaboration and how people function in groups.

1960s — Augmentation

One of the early ARPA research projects was at SRI, where Doug Englebart, inspired by Vannevar Bush's vision, set up a research lab that created an elaborate hypermedia system called NLS (oNLine System). This was the first successful implementation of hypertext (though that term was not invented until later), and it was here that the mouse was invented as well as the first on-screen video teleconference.

Engelbart's seminal work was Augmenting Human Intellect: A Conceptual Framework, which he wrote in 1962. In it he set out his basic idea of augmentation:

"By 'augmenting human intellect' we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. And by 'complex situations' we include the professional problems of diplomats, executives, social scientists, life scientists, physical scientists, attorneys, designers—whether the problem situation exists for twenty minutes or twenty years. We do not speak of isolated clever tricks that help in particular situations. We refer to a way of life in an integrated domain where hunches, cut-and-try, intangibles, and the human 'feel for a situation' usefully co-exist with powerful concepts, streamlined terminology and notation, sophisticated methods, and high-powered electronic aids."

He was also among the first to say that in order to design such tools, we must:

"integrate psychology and organizational development with all of these advances in computing technology."

Over time this term evolved to become called 'office augmentation' -- Englebart preferred the term 'augmentation' over almost anywhere that 'automation' was used, as automation seem de-personalizing. However, Englebart's work was ultimately sold by SRI to Tymshare, where they commercialized it under their newly formed "Office Automation Division". Thus it appears that term 'automation' won over the term 'augmentation', and Englebart's ideas of integrating psychology and organization development were lost.

1970s — Office Automation

IBM coined the term 'word processing' in the 1960s, which originally encompassed all business equipment -- including manually operated typewriters -- that was concerned with the handling of text, as opposed to data. By the 70s they were attempting to broaden the scope of their products to all aspects of the office, so they coined the term 'office automation'.

The use of this term swiftly become quite generic, and was used by all the major computer companies of the time. However, any ideas of collaboration become lost in the ideas of process and automation.

1970s — Electronic Information Exchange System (EIES)

Yet the number of successful product lines bearing the tag 'office automation' did mean that there was increased research money for creating new tools. One of the most important was a project called Electronic Information Exchange System (EIES), which had funding from for-profit companies like IBM and AT&T, non-profit foundations like the Annenberg Trust, and governmental agencies like NSF and the New Jersey Commission of Science and Technology.

EIES was the first major implementation of collaborative software. In a paper from 1972, EIES founder Murray Turoff describes an early version of EIES:

"Basically the Delphi Conference appears to have utility when one or more of the following conditions were met:

the group cannot meet often enough in committee to give adequate timely consideration to the topic because of time or distance constraints

there is a specific reason to preserve the anonymity of the conferees (e.g., refereeing of position papers or a free exchange among different levels in an organizational structure)

the group is too large for an effective conference telephone call or committee exchange

the group is interdisciplinary to the extent that a structured or refereed communication mode as opposed to a committee or panel approach is more desirable in promoting an efficient exchange of information

telephone and letter communications, on a one-to-one basis, are insufficient or too cumbersome to augment the particular committee activity

disagreement among members of the group are too severe for a meaningful committee of face-to-face process for the exchange of views and information.

You can see from this list that EIES pioneered many of the concepts of BBS- style community software that we see today. Ultimately EIES featured threaded-replies, anonymous messages, polling, etc. Also, note the early importance of trying to understand groups so that you can optimize for the best group process.

However, as a generic term, EIES was too cumbersome. I see references from that period to terms like 'decision support system', 'computer-mediated communications', and 'collective intelligence', but none of these were broadly adopted either.

1980s — Groupware (Part 1)

Peter and Trudy Johnson-Lenz are credited by many as coining the term 'groupware' in 1978, after experiencing EIES for the first time. They defined groupware as:

"intentional group processes plus software to support them."

I have long preferred this definition for two reasons -- first, the word intentional implies conscious design. Second, this definition also contains the important distinction that group processes come before the software. I felt that this definition properly excluded multi-user databases and electronic mail that are not designed specifically to enhance the group process. (I wrote about this in an 1990 article called Definitions of Groupware.)

There were a number of other definitions during that period:

   

Doug Engelbart — "A co-evolving human-tool system."

       

David Coleman — "Computer-mediated collaboration that increases the productivity or functionality of person-to-person processes."

       

C.A. 'Skip' Ellis - - "Computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment."

Very swiftly, the term 'groupware' was adopted by the EIES community, as well as many of the spinoff software that was developed in the early 80's. However, the term was not broadly adopted outside of this community for some time.

1980s — Computer-Supported Collaborative (or sometimes Cooperative) Work (CSCW)

Meanwhile, the academic community was not happy with either the term 'office automation' or 'groupware' for research into how groups use computers to collaborate.

After the failure of an ACM conference on Office Automation, MIT's Irene Greif and DEC's Paul Cashman coined the term CSCW for a workshop held in 1984, which was followed by the first CSCW conference in 1986. There is still an annual CSCW Conference, which this year is being held in Chicago on November 6-10th.

The people initially involved with this conference came from either Human Computer Interaction (HCI) background or Information Systems (IS) background, thus the different definitions for the second 'C' in 'CSCW'; the HCI people preferred the small team focused 'cooperative', whereas the IS people chose the broader 'collaborative'. Scott Schopieray has a nice diagram about this on the right.

The Digital Media Laboratory defines CSCW as:

"a multidisciplinary research field including computer science, economics, sociology, and psychology. CSCW research focuses on developing new theories and technologies for coordination of groups of people who work together."

Brian Wilson defined it as:

"CSCW is a generic term which combines the understanding of the way people work in groups with the enabling technologies of computer networking, and associated hardware, software, services and techniques."

However, most definitions I've seen compare it to groupware:

   

Applied Informatics and Distributed Systems Group at Technische Universitat Munchen — "While Groupware refers to the real computer-based systems, the notion CSCW means the study of tools and techniques of Groupware as well as their psychological, social and organizational effects."

       

Tom Brink — "Groupware is often used to specifically denote the technology that people use to work together, whereas CSCW refers to the field that studies the use of that technology."

This term never really was adopted by anyone except the academic community, and even now, there are many that prefer different terms, such as 'social computing' or 'coordination science'. danah boyd offered this comment to me in an email:

"In the Computer Supported Cooperative Work (CSCW) space (those who address this area in academia), one switch has been to 'social computing' and the move was far more intentional. CSCW comes out of Human-Computer Interaction (HCI) paradigm.  By and large, HCI has been strongly associated with quantitative psychology in terms of methods.

 

Groupware and collaborative software have a heavy handed connotation of 'work' (deeply connected to HCI's emphasis on activity theory).  While CSCW has the term work directly embedded in it, there's a strong push towards other aspects of social life.  Qualitative approaches have been infused into HCI and HCI practitioners are drawing heavily from sociology and anthropology, focusing directly on everyday social life. [This move may also be a purposeful move towards Marx, but maybe i'm reading too far into things.]"

1990's — Groupware (Part 2)

Meanwhile, the term 'groupware' hit the mainstream in 1988, when Robert Johansen wrote the best-selling business book Groupware: Computer Support for Business Teams. One unique contribution that Johansen's book offered was a distinction between time and place for different types of collaboration. See the diagram on the right for some detail.

Unfortunately, it was this success that was also the downfall of the term 'groupware', for it got co-opted by marketing. Initially the co-opting was done by Lotus Notes, which I personally didn't feel deserved to be called groupware, as it was really more of a multi-user database that could be used to make groupware, but wasn't actually groupware. Then Microsoft further corrupted the term when they released Microsoft Exchange Server and Outlook with calendaring features to compete with Lotus Notes, and called that groupware as well.

Chip Morningstar, an early pioneer in collaboration software and virtual worlds, comments:

"(in the 1990's) I know that we (the Xanadu/AMIX community) hated the term 'groupware', as would anyone who has any respect for the English language. Also, at the time, the term was generally applied to things like Lotus Notes, which we felt was in a category distinct from what we were doing."

Currently Wikipedia defines groupware as:

"software that integrates work on a single project by several concurrent users at separated workstations"

Thus today almost any software that supports multiple users can somewhat legitimately say that they are 'groupware'.

1990s — Origin of Social Software

While the term 'groupware' was slowly losing its meaning, a new phrase, 'social software' was beginning to coming into vogue. However, for the first 15 years of its existence, mostly in the 1990s, the term was rarely used outside of very specialized groups.

One of the best ways I've found to see how words, terms, phrases, and memes spread through culture is looking through Google's marvelous archive of usenet newsgroups. Searching by date, the earliest reference I can find to the term 'social software' is a posting in 1990 -- in this newsgroup posting it isn't really clear what the definition of social software is, only that it is associated with 'open hypertext' and a committee in Japan to study 'social-hyper computing'. The next mention of social software is in 1992 in which Ted Nelson's Xanadu and Phil Salin's AMIX are called social software.

The next couple of years of usage of the term social software appear to be largely associated with the nanotechnology community and those influenced by them, or by the diaspora of people who left Xanadu and AMIX when they were both closed by Autodesk. Given these references, my first guess was that the term originated within Xanadu/AMIX communities, as they had close connections with many of the people involved with nanotechnology.

However, after contacting some of my collegues that used to work for Xanadu or AMIX, they say the term probably came from K. Eric Drexler, founder of the Foresight Institute. Drexler is best known for coining the term nanotechnology, and his interest in hypertext and group augmentation comes from his desire to make sure that we think critically about the technology before we develop it.

The earliest reference that I can find to term 'social software' in his writings is in Hypertext Publishing and the Evolution of Knowledge, originally published at the Hypertext '87 Conference, but updated online though 1997), where the term is used three times, in the following contexts:

KINDS OF HYPERTEXT
...
Filtered vs. bare hypertext: A system that shows users all local links (no matter how numerous or irrelevant) is bare hypertext. A system that enables users to automatically display some links and hide others (based on user-selected criteria) is filtered hypertext. This implies support for what may be termed social software, including voting and evaluation schemes that provide criteria for later filtering.
...
AGENT LEVELS
...
Agents can also implement social software functions - for example, applying voting-and-rating algorithms to sets of reader evaluations and publishing the results.
...
IMPROVING PROBLEM SOLVING
...
A hypertext publishing medium will have abilities beyond supporting improved critical discussion. Since it is computer-based, it can naturally support software for collaborative development of modeling games and simulations [29] (and enable effective criticism of published model structures and parameters). Social software could facilitate group commitment and action: individuals could take unpublicized positions of the form I will publicly commit to X if Y other people do so at the same time. Once Y people take a compatible position, everyone's commitment (to making a statement, forming a group, making a contribution, etc.) could be automatically published. The possibilities for hypertext-based social software seem broad.

I wrote Eric to find out why he used the term, and this was his reply:

"I don't recall when I began using it (it wasn't in Engines of Creation), but it does seem to me, as best I can recall, that I coined it.

I used the term 'social software' because I am concerned with communication and collaboration on all scales, including the whole of society. Thus, I see media at the scale of the World Wide Web as forms of social software.

We need to make society-scale conflict -- not just group-scale cooperation -- more productive. Better media, better social software, can help.

I'd rather see an emphasis on this dimension of social software than on the origin of the name itself."

Drexler's term 'social software' didn't initially take off. There do not appear to be many consistent mentions of the term in the late 90's. There continue to be references that I attribute to the term spreading out from the nanotechnology community, but also I see references to the 'social software' of the brain. There also seem to be a few consulting companies named Social Software but none appear to have had much success. Wiki was invented in 1995, but I don't see it, or any of the subsequent wikis defining themselves as social software for a number of years.

2000s — Evolution of Social Software

It isn't until late 2002 that the term 'social software' came into more common usage, probably due to the efforts of Clay Shirky who organized a "Social Software Summit" in November of 2002. He recalls his first usage of the term to be from approximately April of 2002.

I asked Clay if it was the loss of meaning in the terms 'groupware' that made him choose the term 'social software', and he replied:

"I was looking for something that gathered together all uses of software that supported interacting groups, even if the interaction was offline, e.g. Meetup, nTag, etc. Groupware was the obvious choice, but had become horribly polluted by enterprise groupware work."

I asked him why he didn't use the term 'collaborative software' and he commented:

"...because that seems a sub-set of groupware, leaving out other kinds of group processes such as discussion, mutual advice or favors, and play.

The broader issue is that there was no word or phrase that grouped the CSCW and online community currents together without also including a lot of non-group oriented stuff. CMC (Computer-Mediated Communication) for example, includes broadcast outlets like C|Net, two-person email exchanges, and spam -- much too broad. There was also no word or phrase that called attention to the explosion of interesting software for group activities that fell outside online communities and CSCW, things like Bass-Station (which is for offline community) or "Uncle Roy is All Around You" (which is computer-supported collaborative play.)"

Clay also offered me some interesting commentary on the term 'social computing':

"On a side note, there is in the research community a similar phrase, 'social computing', that both MSFT and IBM use. I think this phrase also doesn't fit the domain well. It seems to suffer from Shannon Envy, where the researchers interested in social effects are trying to convince their colleagues that what they are working on is also computing.

I think the 'social computing' phrase is a shame for two reasons. First, there's no need to apologize for studying social effects by pretending that they are a form of computing (the old argument about computers as computing vs communicating devices goes back to Licklider in the early 60s, and its disheartening to see the communications people agonizing over it 40 years on).

Second, the phrase social computing could describe a really interesting domain, where groups are used to find approximately optimal solutions to hard combinatorial problems."

2000s — Changing Definitions of Social Software

An early definition by Clay for the definition of social software was:

"1. Social software treats triads of people differently than pairs.
2. Social software treats groups as first-class objects in the system."

However, Clay more recently prefers the simpler:

"software that supports group interaction"

I note that this is quite a bit closer to the Johnson-Lenz definition of groupware.

One of areas of disagreement about the definition of social software is one of scope. Sunir Shah host of MeatballWiki conceives of social software as being mainly about support for online communities, whereas Clay Shirky desires for it to also:

"explicitly try to include online support for both lightweight social value (e.g. del.icio.us) and offline interaction (e.g. Dodgeball, PacManhattan) in the definition."

There is a long discussion on Meatball Wiki at SocialSoftware on this topic. One of the more interesting definitions comes from Tom Coates:

"augmentation of human's socializing and networking abilities by software, complete with ways of compensating for the overloads this might engender"

I asked Adina Levin, of SocialText, about her thoughts on why we are now using the term 'social software' and not some other term. She said:

"I believe that there are new things in social software, but we're also compelled to use new words instead of building on the old ones because of the way the discourse works.

When you talk about 'groupware', people think of the hard-to-use, under-adopted Lotus Notes category. In the mid-90s, groupware and knowledge management were used for software that represented the taylorization of knowledge work – the idea that you can automate knowledge work into pre-defined workflows and "capture the assets" in people's brains. Often, the ideas sound good to managers, but the tools did little for the people using them. There were fancy schemes intended to "incent participation" because the tools didn't do much for the people using them without lollipops. Email had massive adoption, and more complex tools often gathered dust.

Meanwhile, the term 'virtual community' became associated with discredited ideas about cyberspace as an independent polity, and failed dotcom ideas about assembling community in the shadow of a mass-market brand such as forums on the Coca Cola site.

Several years ago, in the depths of the tech recession, there were signs of creative life in weblog and journal communities, conversation discovery with daypop and then technorati, the growth curve of wikipedia, mobile games, photo and playlist sharing. The liveliness was about the communities, and also about the culture of tool mix'n'match bricolage. Many of the attributes of social software -– hyperlinks for naming and reference, weblog conversation discovery, standards-based aggregation -– build on older forms. But the difference in scale, standardization, simplicity, and social incentives provided by web access turn a difference in degree to a difference in kind.

These forms grew without any forced discussion "how to incent participation". People are compelled to write blogs and journals to show off and to share, to contribute to wikipedia and open source software projects for the joy of building things with other people. There are some lessons about social patterns and social affordances that this generation of social software communities and tools get right, are worth understanding and building on.

We might be better off as a culture if we used rhetorical techniques from traditional cultures to appropriate the words of the previous generation, but deepen them with new insights from the current generation. But we're children of the enlightenment, we want progress, and in order to get the (deserved) attention for new generations of real innovation, we need to use new terms."

2010 — Future Thoughts on Social Software

In examining the origins of 'social software' we can see the terminology for the field has moved through a sort of life cycle. There have been many terms for this type of software, some of which have taken off, and some of which have not.

Typically, a visionary originates a term, and a community around that visionary may (or may not) adopt it. The diaspora of the term from that point can be slow, with 10 or 15 years passing before a term is more generally adopted. Once a term is more broadly adopted, it faces the risk of becoming a marketing term, corrupted into differentiating products rather than explaining ideas.

Is 'social software', which just now gaining wide acceptance, destined for the same trash heap of uselessness as groupware? And, if so, what impact does the changing of this terminology have on the field of social software itself? Only the future holds those answers ...

JotSpot: Application Wiki

Joe Kraus, one of the co-founders of Excite, and new blogger has long been rumored to be working on a new wiki tool. Today at the Web 2.0 conference Joe finally unveiled JotSpot, a new type of wiki that they have named an "Application Wiki". JotSpot appears to be not only an advanced wiki, but it also moves the predominantly text-based wiki toward being able to handle structured data and web application development.

At the JotSpot website there is an page on How JotSpot is Different and an Advanced Tour of this wiki's database capabilities.

Better, however, is a demonstration that Joe Kraus and Graham Spencer gave InfoWorld reporter Jon Udell an early demo of JotSpot, which Jon screen-captured and has released as a 23-minute, 32MB Flash presentation. This demo is very impressive: in addition to incremental improvements to wiki, such as WYSIWYG editing, email support, indexed attachments, RSS and web page importing, etc. Kraus and Spencer also demonstrate a very powerful forms templating interface that is very much like creating HTML forms with Javascript, and demonstrated integration with a SalesForce.com web application using SOAP. It appears that JotSpot leverages the unstructured and adhoc advantages that are a strength of wiki, yet allows structure to be added later such that the data in the wiki can be integrated with other non-wiki applications.

The discussion during the demo is also very interesting. Jon Udell made an observation about JotSpot entering into Lotus Notes territory, and Kraus and Spencer discuss how JotSpot makes web application development more accessible, and expressed their desire to create a marketplace for small developers to create tools using JotSpot.

From what I've seen so far, JotSpot looks like it may the first of a third-generation of wikis, the first being the very simple wikis such as Ward Cunningham's C2 Wiki, and second generation being database-backed wikis such as Wikipedia and SocialText. If you are serious about wiki, I highly recommend you take a look at this demo.

Joe Kraus also announced today that they have received a $5.2M funding round from Redpoint and Mayfield, both top VC firms.

More information:

Press Release: JotSpot Launches, Unveils Application Wiki

Article: Business Week: Do-It-Yourself Software for All?

Article: CBS MarketWatch: Excite founders unveil JotSpot

Article: Mercury News: Palo Alto start-up enhances `Wiki' sites

Blog posting: JotSpot: The Application Wiki by Jeff Clavier

Blog posting: Joe Kraus talks about Jotspot by Scott Rosenberg

Blog posting: WikiWiki Warfare In The Enterprise Leading To Situational Software? by David Mattison

Blog posting: JotSpot - Lego Style Wiki? by Judith Meskill

Blog posting: Jot Wiki kicks ass… (Live from Web 2.0 conference in San Fran) - by Jason Calacanis

Audio: Audio archive of JotSpot demo at Web 2.0 Conference recorded by Jason Calacanis

Posted on October 7, 2004 at 12:39 AM in Social Software, User Interface, Web/Tech, Wiki | Permalink | Comments (4) | TrackBack

TiddlyWiki

I keep an eye out for new ideas in Wiki technology (see my post from February Looking at Wiki), and I recently became fascinated by TiddlyWiki. It is sort of a one-page client-only Wiki written completely in Javascript and HTML. Like my EditThisPagePHP, it appears to be an elegant experiment to look into the future of this medium of user-editable content.

The key feature of TiddlyWiki is that instead of WikiName links leading to new pages, it displays a new set of microcontent at the top of the current page, pushing your previous content toward the bottom of the page. Thus your link history is all on a single page rather then through your browser's back button. You really need to try it out to understand it.

In its current form, TiddlyWiki is still really more a technology demonstration than a useful tool, as you can't save the changes you make. However, there are people that are creating a PHP TiddlyWink based on it.

There are a number of things about TiddlyWiki that interest me. One is that it is more microcontent focused, rather then page focused. I've seen a few attempts to do blogs in Wikis and to date I have been unsatisfied -- part of the reason is that most blogs consist primarily of a chronological series of microcontent, whereas Wikis tend to be more oriented around pages. The ideas in TiddlyWiki may offer an alternative.

Another unique aspect of TiddlyWiki is its approach to link history. I'm not sure if new microcontent should appear at the top, as it does in TiddlyWiki, or at the bottom, but it certainly is an useful experiment.

TiddlyWiki also seems to also be an interesting way to create hypertext stories -- see for instance see the interactive fiction Baby Dog Sitter.

Finally, I see TiddlyWiki as an encouragement to other Wiki designers to see what can be done with client-side Javascripts. One of the reasons that Orkut feels so responsive is due to its use of Javascript, and OddPost does some amazing things emulating the Outlook mail client exclusively using Javascript inside a web page. FlexWiki is one of the few other Wikis that use Javascript in novel ways; however, they are Microsoft-centric rather than standards-centric, so I've heard that some of their features don't work on Mozilla-family browsers. I'd like to see more experimentation combining Javascript and Wiki.

I look forward to seeing what shakes out as this tool matures.

Posted on September 27, 2004 at 08:28 PM in Social Software, User Interface, Web/Tech, Wiki | Permalink | Comments (3) | TrackBack

Intimacy Gradient and Other Lessons from Architecture

A number of my posts have been about integrating different domains of knowledge in order to better understand how human behavior should be incorporated in the design of social software. I found The Dunbar Number in sociology, and both Four Kinds of Privacy and Progressive Trust come from my work in the cryptography field. The topic of this post comes from the field of architecture.

In order to provide for Progressive Trust, you need to establish what is known as an "Intimacy Gradient".

The concept of Intimacy Gradient comes from architect Christopher Alexander, in his book A Pattern Language: Towns, Buildings, Construction. (Oxford University Press, 1977):

Pattern #127 - Intimacy Gradient:

Conflict: Unless the spaces in a building are arranged in a sequence which corresponds to their degrees of privateness, the visits made by strangers, friends, guests, clients, family, will always be a little awkward.

Resolution: Lay out the spaces of a building so that they create a sequence which begins with the entrance and the most public parts of the building, then leads into the slightly more private areas, and finally to the most private domains.

In architecture there are always some areas of the house or building that are more public -- the entry, the living room, the atrium, etc., and areas that are more private such as bathrooms, bedrooms, and offices. In a good design there is some marker of change between these different areas -- it might be a difference in ceiling height, a stairway leading to a different floor, or a narrow entrance. As an example, in the classical Japanese tea house, you have to bow low before entering.

Failure to respect the Intimacy Gradient results in uncomfortable buildings. Tom Munnecke reported about a Frank Gehry building at Case Western Reserve University:

I asked many of the graduate students how they felt about their new environment. "Horrible," said one. "Like living in a refrigerator" said another. "We used to have comfortable offices and gathering places, and had the most wonderful conversations. Now everything is so sterile, and the acoustics so bad, that we can't do anything together. I have to go outside if I want any privacy."

The Intimacy Gradient is also used in other media. As I noted in my review of Seven Fingers of the Hand Circus:

When we arrived, we were led down the side of the theatre and all of a sudden I noticed that it looked like we were all being led backstage. We curve around and all of a sudden see an entrance -- maybe 5 foot tall requiring most of us to duck. We duck through and to our surprise, we are have walked through a fridgerator, and we are on the stage!

One of the 7 players welcomes us, and another offers random people a glass of tea as we walk across the stage to our seats. The stage is set like a city loft, with a tv, some couches, a bed, a bathtub and shower, a kitchen, and of course the fridgerator we entered through. On the stage, and chatting to members of the audience are the 7 cast members, all wearing comfortable looking white shorts or athletic and white t-shirts.

The audience arrives over 30 minutes and the 7 players act as if we are guests of their loft, serving some of us tea, chatting, sweeping the floor, etc.

Entering through the refrigerator door raised the intimacy of the experience for the audience of that circus. Thus in spite of it being produced in a large auditorium it felt as up-close and personal as did the much smaller Circus Contraption.

The Intimacy Gradient exists in movies as well -- anywhere you see a scene taking place in a public space that transitions down through smaller and tighter shots ultimately to a closeup of a face it is much more intimate then just cutting to the closeup.

In social software design, there also needs to be an Intimacy Gradient. One of the problems with Wikis is that there is often very little transition between public and intimate, and doing so can be quite jarring. SocialText, a Wiki service vendor, is aware of this problem and is "seeking to add more layers to the 'intimacy gradient', without recreating the highly structured collaboration tools that exist today". Ross Mayfield outlines this possible future Intimacy Gradient for SocialText:

• The broadest tier is a guest space, available to all
• The second tier is a knowledgebase, accessible to all employees and contractors
• The third tier is product development, for employees and contractors bound by a confidentiality agreement
• The fourth tier is for the core management team to share confidential financial and HR information.

These thoughts from an earlier post by Ross are also thoughtful:

He is right that groupthink is avoided by a social network structure that allows a dynamic and diverse periphery to provide new ideas, but the core of the network needs to be tightly bound to be able to take action.

That's the main point of Building Sustainable Communities through Network Building by Valdis Krebs and June Holley. When studying a community over time, they suggest a vibrant community is made up of four stages:

1. Scattered Clusters
2. Single Hub-and-Spoke
3. Multi-Hub Small-World Network
4. Core/Periphery

The ideal core/periphery structure affords a densely linked core and a dynamic periphery. One pattern for social software that supports this is an intimacy gradient (privacy/openness), to allow the core some privacy for backchannelling. But this requires ridiculously easy group forming, as the more hardened the space the more hard-nosed its occupants become.

This is not just a problem for Wiki. There is an excellent paper on the web called Design Patterns for Private and Public Digital Spaces in the Home Environment where they explore how people used VNC (video-mediated communications, or more colloquially video-chat). They state:

The earlier "public" character of a traditional farmer's house or bourgeois flat (in Sweden) has disappeared with the modern housing planning. Instead, distinguishing the public from the private has become central during the industrial age, with the dwelling as an exclusively private place. Now, with the transition to an information society, it seems as if the concept of public space in the private dwelling has to be reconsidered, which also means that the borders between the private and the public at home have to be opened up.

The need to provide for an Intimacy Gradient in social software is clear; however, the techniques for showing the transitions between the gradients are not. For instance, in the original Netscape Communicator, when you connected with a secure SSL connection, the border around the edge of the window would turn blue, and a solid blue key would show up. However, most people didn't notice this change and no current browser does this; even the little locked icon at the bottom of Internet Explorer and often isn't visible if you have the status bar turned off or if you are using frames.

Flemming Funch (and mirror) notes part of the difficulty is:

As long as a certain chat room or Wiki page is accessible directly with a deep link, it is going to be very hard to make it feel more intimate than any other place I can reach with similar ease. So a hierarchical structure of links doesn't do it. On the web you can't force people to accept your hierarchy if it is all just links.

Part of the solution might come from the architecture world as well -- here are some other Patterns by Christopher Alexander (see the link for Alexander's resolutions for each):

• Pattern #31 - Promenade: Each subculture needs a center for its public life: a place where you can go to see people, and to be seen.

• Pattern #61 - Small Public Squares: A town needs public squares; they are the largest, most public rooms, that a town has. but when they are too large, they look and feel deserted.

• Pattern #69 - Public Outdoor Room: There are very few spots along the streets of modern towns and neighborhoods where people can hang out, comfortably, for hours at a time.

• Pattern #42 - Sequence of Sitting Spaces: Every corner of a building is a potential sitting space. But each sitting space has different needs for comfort and enclosure according to its position in the intimacy gradient.

• Pattern #147 - Communal Eating": Without communal eating, no human group can hold together.

Other lessons for social software from the architecture world are the concepts of "refuge and prospect", the "savanna theory", and "defensible space".

Refuge and prospect come from the landscape architect Jay Appleton. Prospect is a place where we can see others, and refuge is a place were we can retreat and conceal ourselves. A specific prediction of his theory is that people prefer the edges of a space more then the middle. Often prospect and refuge are in conflict, as a prospect tends to be expansive and bright whereas a refuge is small and dark, but there are cases where they are combined in one place; this is why we value private homes with a spectacular view so much, and why we pay so much to stay at scenic retreats. So what are the edges of our social spaces? Are there ways that we can signal either prospect and refuge?

The savanna theory comes from a hypothesis by Richard Coss and Gordon Orians that we should be most comfortable with those landscapes where humans spent most of their evolutionary past. Thus supposedly the ideal landscape design has the same proportionality of trees, grass, and brush as the African savanna; parks and golf clubs are shown as evidence of this theory. An alternate to this theory is that we desire a certain amount of visual complexity. Either theory raises this question: what are the evolutionary markers regarding groups that our human ancestors needed? This question fits well with my thoughts regarding the Dunbar Number.

The defensible space concept comes from the idea that anonymous spaces lead to problems because of vandalism, incivility, and crime, and to eliminate those problems requires the residents to mark their "territories" and "take possession" of their areas. We have similar problems in the online world. So maybe the answer is similar -- allow more ways for groups of people to mark up and take possession of their own virtual spaces.

There are a couple of links that integrate these ideas in architecture that you might find useful:

• Psychosocial Value of Space


• Building Biophilia: Connecting People to Nature in Building Design


• Bio-Inspired Design: What Can We Learn from Nature?


• Evolutionary Architecture: A Field Course


• Why We Say It With Flowers


• Evolutionary Psychology and Workplace Design (pdf)

We are still breaking ground and exploring new ideas in the world of social software. However, there are already extant fields of study which may give us insight into this new venue. Architecture is one of them. By better understanding ideas of intimacy gradients, pattern language, refuge and prospect, savannas, and defensible spaces, we may gain new understandings of how to build social environments which are attractive and enjoyable to more people.

Posted on August 26, 2004 at 04:56 PM in Social Software, Web/Tech, Wiki | Permalink | Comments (3) | TrackBack

Looking at Wiki

I've not just been spending time looking at social networking services, I've also been digging deeper into wiki. I've still got more to go, but some of these will be of interest to you if you are considering implementing a wiki for your community, or if you are a wiki developer.

Zwiki is based on Zope, and thus has a very interesting feature set. One of the more popular features is the topic mappings that it creates. When combined with the CMS features of Plone, it becomes even more interesting -- one of the best Zwiki/Plone communities to look at as an example is Hurricane Audio. Unfortunately Zwiki only works on the Zope web platform, which is not as popular as Apache.

FlexWiki is a very innovative wiki that is being developed by some Microsoft engineers and is ASP.NET based for Windows. I in particular like the property page features which are an elegant way to handle meta-data, and also how it handles diffs.

ProjectForum and courseforum are both fairly simple but elegant commercially supported wiki. Of particular note is that both are very easy to install, even on a Windows 2000 system or Macintosh, as well as on Linux. I was able to get a test ProjectForum up on my Windows PC in about 5 minutes, including downloading. It also has some nice "skins" available. I also like how private areas are created for each -- this is the basic difference between the two products, and a rare wiki feature.

WikidPad is interesting because it is not a public service, but a shareware single-user "notepad" for Windows that supports wiki-style TextFormattingRules and WikiWords. If you have been using wiki a lot like I have, sometimes you catch yourself using wiki-style text everywhere, and I guess this product is for people who do that like me.

SocialText is another commercially supported wiki, but is sold as a service not a product. They are very carefully added features while keeping things elegant and simple for less sophisticated business customers. They also host a number of public wikis, so if you want to see the current feature set see RSS-Winterfest which also shows off their newest RSS support.

SeedWiki is another wiki service rather then product (sometimes called a WikiFarm), and is interesting because it doesn't use Wiki style TextFormattingRules -- instead, it has several WYSIWYG editors that allow you to directly edit the underlying HTML. This gives a huge amount of flexibility for some of the communities that use it, such as WikiFish.

I also have heard good things about PHPWiki and MoinMoin, but I haven't had a chance to dig into those very much yet.

I personally have been using TWiki for 4+ years at several of my businesses. Its strength is that it is oriented toward allowing private groups who can manage their own access privileges. It also has one of the most active 'plugins' developer areas with lots of ways to modify your TWiki to do different things (one of the plugins I'm investigating now is GnuSkin, but read the docs very carefully as you have to chmod a module if you install it.)

Although it uses a fairly primitive wiki, I highly recommend the Meatball Wiki site for people very interested in wikis. It is a meta-wiki discussion community. It has some great pages on the life-cycle of wikis, on various design patterns and features of wikis, and of various other consequences of the medium. If you look at CategoryWikiEngine it has one of the more complete lists of Wiki engines out there.

I will be reporting more on various wikis and wiki technology that I discover in the upcoming weeks.

Posted on February 2, 2004 at 05:57 AM in Social Software, User Interface, Web/Tech, Wiki | Permalink | Comments (10) | TrackBack

Working on Wiki Design Patterns

I've been working today on understand the Design Pattern Language behind the Wiki concept. I've been making some postings at the Meatball Wiki site on this topic. These are the new topics that I have finished today.

Category of Wiki Design Patterns

Pattern: Cheap and Easy Collaboration

Pattern: Simple Text Formatting

Pattern: Character Formatting Rules

Pattern: Paragraph Formatting Rules

Wiki Design Patterns Meta Commentary

I've also been doing a survey of the features of various versions of Wiki that have evolved over the years, and have started posting some of them at the bottom of the pattern documents.

More to come...