Category: Social Software

Benjamin Reitzammer wrote in about another aggregator cuisinart project using Atom to gain more control of feed processing.

If you dont already know about it, you may find dbagg3 from Leslie Orchard interesting too. Right now it seems like “yet another aggregator”, but from what he outlined in his early posts about dbagg3, the aggregating feature is only one of many, and easy searching/processing of Atom feeds/entries is another. You can find Leslie’s latest post about dbagg3 at http://www.decafbad.com/blog/2004/09/13/dbagg3alive

The comments feature on this blog is now fixed, which is a mixed blessing. Good comments as above posted directly to the site. The morning comment despam routine.

At Foo Camp over the weekend, Ingy paired with Ben Trott to enable Atom posting from Kwiki to Movable Type. Their work complements the work of Autrijus Tang, who added Atom feeds and Atom posting to Kwiki using Ben’s XML::Atom perl module.
We’re following Joe Gregorio’s experiments a year ago, adding Atom support to PikiPiki, a python based wiki that’s the parent of MoinMoin.
For newcomers to the world of blog and wiki, Atom is both an API that lets you read from and write to websites from other websites, and a web content syndication format that’s intended to be more tightly standardized than RSS, to support more aspects of web content, including images and videos.
The initial impulse to do at Atom to a wiki is to enable offline editing. It’s good to be able to use desktop clients like Ecto to post to a wiki. That’s helpful if you want to compose or edit when you’re offline, and synch when you’re back online.
The second drive is publishing collaborative work. Many people want to develop content in an an open and collaborative process, and once it’s ready, to publish it to a wider audience. Atom lets you develop collaboratively in a wiki and publish out to a weblog or public website.
Things get interesting when you consider combining with other applications. Autrijus added Atom support to RT, an open source trouble ticket system. Think about posting problem log information to a wiki, to use in developing an FAQ.
Ben Hammersley brainstorms about creating a web-based proxy that will post to the community website of your choice. “I want to be able to choose multiple endpoints for a post, and publish to all of them with a single button click.”
Grant Young brainstorms about using feeds to “present issue-based portals very quickly and cheaply, drawing from news sources both within the organisations themselves, but also from external sources like local, national and international newspapers, online news sites and other topical weblogs.”
Things get even more intertwingled when you add Atom feeds into the mix. RSS syndication already lets you pull wiki updates into feed readers and search engines. In the workplace, this lets the collaborative work and expertise of the organization be available, in native context, to many more people without drowning people in a flood of email.
Services like Feedburner and QuantumArts have tools that parse RSS feeds and recombine them by date, author, category. Because an Atom entry is defined as standalone, and the elements are more tightly defined, it should be easier to splice and recombine feeds. Diego Doval’s AtomFlow is a set of Java-based command line tools to receive, store, search and then output Atom based content (Hammersley’s description, unfortunately, Diego’s site is down at this posting.
It’s fun doing R&D experimentation open source. No service level commitments, no paperwork, lots of people to try things with. When we find things that work, we can package, and polish, improve, service and support. Participate in the ecosystem, and serve customers.

One of the members of the Wikipedia technical team writes about the techniques Wikipedia uses to detect vandalism and fix mistakes.

Each contributor has a personal watchlist which will inform them of changes made to articles which they have registered an interest in. On average, each article is on the watchlist of two accounts. Relatively mainstream topics usually have more watchers, obscure trivia fewer or none (a hint to those who want to try circumventing this tool…). These watchlists are often checked several times a day, most within a week or so. Since these are usually topic experts, they are likely to detect any subtle changes which the RC patrol misses.

In a physical neighborhood, people watch out for their neigbhors houses and kids. A couple of weeks ago, a burglar taking electronics from my next-door neighbor’s home was foiled by a passerby, who nodded hello to a man walking down the street on the way out for breakfast tacos. On the way back, he saw the same man, leaving my neighbor’s home with a duffel-bag full of rectangular objects. He called the cops. My neighbor got her home electronics back.
Wikipedia’s alert system turns the 300,000+ article peer encyclopedia into a warren of virtual neighborhoods. People who have a common interest in a topic keep an eye out for problems and fix them as they happen. (The article also describes more hard-core techniques to block systematic vandalism)
Alex Halevais decided to test Wikipedia’s peer editing by inserting small errors into thirteen articles. The errors were caught and fixed within hours.

Chris Allen adds to the discussion of the intimacy gradient, design patterns that support different levels of privacy and access.
Chris muses that “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.” Chris quotes Fleming Funch about how links can’t signify levels of intimacy. “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.”
I suspect that the design principles for intimacy gradient are going to be different online than in 3d, and efforts to mirror 3d privacy patterns literally will be ineffective, just as interfaces mimicking 3d stores and offices don’t work.
In 3d, the markers of privacy relate to
* property markers: my lawn vs. public sidewalk and street
* physical access: door and gate; bedrooms in back or upstairs
* visual and auditory access: conversation areas around a corner, with an insulating wall.
These design patterns designate ownership/membership, and different levels of physical access.
Online, there are different design patterns for signifying intimacy. Physical interference is less of a problem, while social accessibility takes some consideration.
Groupforming is a distinctive property of the online intimacy gradient. Decent software design makes it trivially easy to create a new private space – no contractors or sawdust needed.
We’re evolving new conventions for showing group membership and “ownership”, even in publicly accessible areas.
* in more intimate spaces, like small-group chatrooms, and livejournal comments, names and pictures are reminders of the small community.
* in shared spaces, it’s good to be able to share pictures and music (which oughta be legal).
Online, we need better tools for vistas, entryways, and entrances.
For example, a technorati sidebar of related discussion shows the vista surrounding the private home or small community on blog.
The “recent changes” in a wiki provides this window for cogniscenti — you can see what folks have been thinking about lately.
The “jibot” on the #joiito IRC channel announces visitors with a few words of background. This creates a social protocol where newcomers are expected to introduce themselves, and there’s a bit of banter where the social tone is established.
Forum portals try to do this with snippets of high-volume conversations or high-rated posts. For experienced community members, portals can help reduce overload and highlight hot topics. But these busy streetscapes can be cluttered, overwhelming, and discouraging for newcomers.
More inviting, I think, is the style on PerlMonks, where the home page consists of selected questions and responses, and deeper sections include discussion, tutorials, reviews, and reference material.
What the jibot and PerlMonks conventions have in common are ways of gradually entering a conversation. Well-designed entranceways are social as much as they are architectural. They provide ways for people to meet others and introduce themselves, and get involved in more extended conversation and deeper collaboration over time.

In the middle of interesting article about criminal misbehavior by a participant in an online game, Clay Shirky has an intriguing insight about online interaction.
MUDs and MOOs — text-based virtual worlds — were common early genres of online interaction. Prophets and business people extrapolated that future online interaction would be much like these virtual worlds, but with sound and color and 3D. It wasn’t that long ago. Remember the early online malls with pictures of buildings and streets?

My label for this was the Whole Worlds hypothesis

Share this:

• Share

• Twitter
• Facebook
• LinkedIn
• Pocket
• Email

In the last airplane trip (love plane rides for reading), I read Shared Minds by Michael Shrage. The 1990 book, borrowed from Chris Allen, is delightfully prescient in a number of ways.
Going on fifteen years ago, when tools to collaborate electronically were just emerging: gestating in the the research lab, Lotus Notes was just coming to market, and Tim Berners Lee was inventing the web, Shrage described some of the very familiar uses of social software:
* holding a meeting with a digital whiteboard to capture and shape ideas in a meeting, complete with backchannel
* collaborative writing, as we do now with SubEthaEdit and Wiki
* the citation and deep collaboration culture of scientific research
* the metaphor of “shared space” to describe digital tools supporting collaboration
The book also articulates an important distinction between communication and collaboration. Shrage critiques the ideas of Marshall McLuhan and advocates of business communication for focusing on one-way transmission of thoughts and feelings. Somehow, if the speaker can only “communicate” clearly and powerfully enough, the message will get through, and the recipient will follow.
Instead, Shrage describes collaboration as a shared and deeply interactive process of discovering and creating meaning together. Individualistic modern western culture wants to see discovery and achievement as the product of a lone hero, but innovation in science, art and business is a collaborative process.
Perhaps this is what Sunir means by blogging is sadness: the impression that bloggers are each in their own little world, making speeches at each other. (Although this perspective misses the distributed conversation of the blog communities.
Shrage captures the joy of collaboration — elaborating an idea, creating something new, getting something done — when the contributions of the participants are intertwingled.
Given the state of the art at the time, Shrage’s perception of tools was skewed toward the sharing of personal artifacts (shared access to documents), and elaborate research prototypes (wall systems with voice and video). Today, we have the ubiquitous net, and a wide range of tools, build for shared use, to knit together in a situated manner.
It’s really fun to work on bringing more of these ideas into common use, in a culture based on the values that Shrage describes.

Ross Mayfield draws a useful distinction, responding to Fredrik Wack’s taxonomy of enterprise weblogs

Instead of the next six types Fredrik offers, I’d suggest the simple categorization of if the blog has a single or multiple authors. Inside the enterprise group blogs are more common and oriented towards collaboration. The topic or objective of a blog can change over time, as most things do, and most individual blogs defy categorization.

Building on these points: knowledge and collaboration aren’t different kinds of blogs — they are different stages in the lifecycle of the same post.
For example, at Socialtext, we use a team weblog to collaborate on the release process, logging process steps, and keeping the team up to date. Once the release is done, the posts serve as an archive. Because Socialtext uses a wiki repository, blog posts can be linked to by name, and updated later.
A post starts as live collaboration, and turns into a knowledge base over time.
Also, today’s technology is blurring the distinction between individual and group blogs in a corporate and community settings. Aggregators, portals, and metablogs pull together individual blogs into combined views of the conversation in the community.

Neural implants are a science fiction cliche — folks in the future have the net wired into their brains.
Leave off the wetware, and the experience is here today.
In his write-up about blogon,Jerry Michalski comments on the discomfort of not having meetings augmented by Social Software:

It’s a slightly spooky scenario, but I’ll confess to having wished for a heads-up display that projects inside a pair of glasses who’s who at a cocktail party, including who used to work with whom, who’s friends with whom (hey, orkut) and who’s dating whom.

.
Ross Mayfield adds,

At Socialtext, our meetings are augmented by voice, IRC (with a bot to post to the wiki) and Workspace. By the end of each meeting, enough artifacts are captured in a social context to enable group memory. Similar to using an Eventspace at a conference. When we meet in person we find it to be terribly inefficient. But that said, there is no such thing as virtual beer, the kind of schmooze we go to events for anyway.

Perhaps the the meaning time spent together in person has already changed without us knowing it. One of my favorite Pete Kaminski quotes — time together in person is too important to spend working.

Wrote a little Technorati plugin in Kwiki, running here, and in Socialtext Will put it up on a public ST wiki in the next few days, too. All the better to keep track of the blogging of OSCON.
It’s a proof of concept on the ease of moving plugins between Kwiki, a super-modular geek-friendly wiki, and Socialtext, the business-friendly workspace application build on Kwiki. The core object model and formatter are identical, so migration was easy.

An impromptu discussion group gathered in Ed Felten’s blog comments as the Senate Judiciary Committee discussed the INDUCE act, another bill that bans innovative technology in the guise of protecting copyright.
I picked up a link to the hearing from a blog, discussed on #joiito at the time, and found the Felten conversation yesterday, through a Technorati search.
Technology vendors and tech activists were able to swarm and organize strong, cohesive opposition to the bill, which was submitted close to a deadline.
Unlike the DMCA a decade ago, technology vendors and public interest groups like EFF and Public Knowledge are sticking together, and acting cohesively to fight threats to innovation and creativity.
It’s incredibly cool for interested citizens to be able to organize an ad-hoc crowd to watch the hearings. I can’t wait for the day when the senate committee will use Technorati and its cousins, and the virtual gallery will be visible to the government.