Tuesday, July 13, 2004

I remember back in the late '90s seeing a bunch of people working on mechanisms so that when you go to a Web page -- like this one -- you could see who else was visiting the same Web page, and perhaps start a chat with them. Fast Company did an article comparing four of them that happened to be trying to commercialize the concept. In addition there were papers and academic or research programs, such as the Sociable Web project.

What happened to these? There were some technical issues (performance, bandwidth, client deployment and server deployment barriers) but I don't think those were paramount. I think it was the social and infrastructure barriers combined with a simple model mismatch. First I'll explain the model mismatch.

The Web is a client-server, or request-response medium. A client requests a page, the server responds with the page, done. The connection closes. The client has the page and can display it for the user as long as needed, can cache it for reference later. In what sense is that "visiting" a Web page? How can you say that two users are "on" the same Web page at the same time? They're each viewing local copies of the same page, copies which were obtained independently and at two different times. Even if users loosely think of this as "visiting" a Web page, the protocol model doesn't support that user model very directly. So you have to extend the Web with non-Web-like logic in order to allow people to hook up on a Web page, and that's just harder due to the infrastructure.

The infrastructure around the Web makes all Web extensions more difficult. Groups like XCAP (part of the SIMPLE WG) and Atom are trying to extend the Web in rather Web-like ways and they have lots of trouble dealing with infrastructure like proxies. It's even harder to extend the Web in non-Web-like ways like shared presence on Web pages. For example, caches don't work at all with shared presence systems -- the cache returns the Web page without asking the original source server for the page, so it's impossible for the source server to know everybody looking at the page without disabling caching (which doesn't entirely work). Clients which automatically download Web pages (like syndication browsers) or download through a proxy (like anonymizers or clients behind corporate firewalls) naturally mask the user's identity and time of access.

In addition to the intermediaries, there's the end points -- clients and servers. Client software is sometimes built to allow add-ons (IE and ActiveX, Firefox and all its plugins) but most users don't use them and are trained to distrust extensions. Client-side scripting languages are implemented differently on each platform so many sites support IE only for rich interactions. Server administrators also hate installing new software or new add-ons, particularly ones which allow users interacting with each other -- partly for the scaling and social discord reasons I cover next.

So finally, if all these model, infrastructure, software and technology issues are overcome, there's the social issues.


  • People protect their identities and hate cases of mistaken identity or identity deception.

  • People like anonymity and being hidden viewers, when it comes to themselves.

  • People resent anonymity in others and like to have an accurate idea who else can "see" them.

  • People protect their own privacy -- they don't like to be seen online without warning. Many Mac users turn Rendezvous off when they're not using it.

  • People don't take active steps to become visible online unless they have something they want to get out of it. Many Mac users don't turn Rendezvous on unless they are reminded of it somehow *and* can think of a good reason why to turn it on.

  • Social sites are prone to spam, and people are really sick of spam and don't tolerate many new sources of spam.

  • Social interactions can get nasty either intentionally or accidentally. Trolls have been around as long as there have been public newsgroups and probably longer. Long-lived chat sites may require moderators, a combination of good technical "fixes" and volunteers, or may be restricted to a small sub-community that tolerates flames, trolls and spam. Ed Krol's Hitchhiker's Guide to the Internet tried to address some of these issues back in '89.



So with all these problems and stresses, social groups online have a tendency to burn out. There's been papers and even a whole course on virtual community design, mechanics and governance.

I am guessing that in part, simple Web-page presence tools are just too lightweight to reasonably deal with (or provide the subtle cues and tools humans need to deal with) these social issues. Once you build a system that can really sustain any kind of interactive community and identity, it's gone far beyond the Web request/response architecture (even if it's loosely built on that) and involved many sophisticated features. It seems so tempting to build something simple and Web-like but human models and interactions don't simplify that well.

1 comment:

Anonymous said...

Lisa:

I am not sure if you are the same Lisa Dusseault mentioned here:
http://blogs.osafoundation.org/mitch/
and this is off topic but if you are the same Lisa, I would like to pick your brain about the project management scaffolding mentioned in the blog. We have been trying to use Bugzilla as well for Project management after not finding something suitable elsewhere, and its not meeting our needs either.

Can you share some information about your solution? We are a human rights non-profit managing projects in over a dozen countries, with each country having 2-3 sub-projects, both with code development and process developement for the work we do.

you can reach me at michelle.d@benetech.org

If you are not the right Lisa, please forgive the interruption, but the blog here shows you are a techie so I am hoping I hit the right blog.

Michelle

Blog Archive

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.