FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

Hungary, National Day

SmallGroupsFirst

Wiki is a kind of software that went through small growth when WikiWikiWeb, MeatballWiki, and many others started growing, then it leapt in huge steps as WikiWikiWeb grew incredibly big, when WikiPedia grew and grew and grew. Designing for small groups first comes naturally.

Most people write SocialSoftware for themselves and their friends. And then it just keeps growing. Growth leads to problems of scale, and they in turn are usually solved in time. Some are never solved (eg. spam on UseNet). Natural growth from small groups to larger groups.

To design for small groups first on purpose, however, has its benefits:

When would you not design for small groups first?

Discussion

I think this is one of the reasons I want to think of wikis are ideal for small groups of people, something between five and twenty-five. It works well for small groups (like this one), and it breaks down (in my experience) on wikis with a gazillion contributors (like WikiWikiWeb). So what about WikiPedia or even small examples like EmacsWiki? I guess in these cases, the group is not really the center of attention. It is the content. The group that supports EmacsWiki are the small number of friends on #emacs.

Hm, I don't know. I would die without InterLink and NearLink. It's just so damn useful.

And, I question the generality of the principle: The original SocialBookmarking site, Delicious, is pretty much size-unaware.

Perhaps we should say, more specificly:

SmallGroupsFirst, when you're making a site that people meet at regularly.

People don't meet at a SocialBookmarking site, but they do meet at a wiki. SocialBookmarking is for IncidentalCollaboration, and WikiPedia has an IncidentalCollaboration aspect to it as well.

Perhaps FormsOfCollaboration can help us gather more specific ideas about where SmallGroupsFirst means more?

Good points. I worked them into the text.

Thank you. :) Now, some other things:

Why is "Don't try to solve big problems such as the unequal attention distribution in the BlogoSphere. Did we really create a mass experience for bloggers?" …in here? I'm trying to imagine what such a software would look like: What would be something that makes blogs change, themselves? I know that the Planets have affected the use patterns of blogs, and it has made participating blogs operate in a way that distributes attention more. But I don't think we're criticizing the existance of Planet software here. And we could also say that bulletin boards and wiki still follow SmallGroupsFirst, but also distribute attention more evenly (SpokeVsCircleCommunications.) So, I'm not really sure I understand what this clause is all about here.

If we want to make a page called NaturalHierarchy?, saying: "We think that the hierarchy of blogs is natural and good," that's one thing. But if that's something that you want to talk about, then I think we should talk about it on another page. I'm not sure if that's what you meant to talk about, but if it were, I would think that we should talk about it on another page.

I'm also unsure of why we have: "Don't worry about interlinking at the beginning. This is particularly interesting in the context of wikis: Did we really achieve much when we started working on mechanisms to bring wikis closer together (NearLink, InterLink, SisterSite)? Did we really manage to get HubAndSpokeWikis working?"

It starts off talking about technology (NearLink, InterLink, SisterSite,) coming up with an implication that I disagree with: That it's not worth it to implement NearLink (disagree), InterLink (strongly disagree), and then SisterSite (mildly agree.)

I disagree with this, because linking does not violate the SmallGroupsFirst rule. Just because you can link to something, doesn't mean that you are forcing intimate interaction with the people you are linking.

We may as well huck normal hyperlinks (spelled out, such as: http://www.example.com/) as well, and say to only use links into the wiki itself, on the wiki, on the basis that we don't want to violate SmallGroupsFirst.

But then it goes to a more radical end, and brings up HubAndSpokeWikis, which, as far as I understand it, more of an InterCommunityCooperation or even just way of arranging pages, than something that is in the actual technology itself. Condemning a way of socially arranging ourselves on the basis of a page that is about software development and design seems to me incorrect. (Point of reference: WikiFeatures:MobileContent would be a technology that hepled people do the process of HubAndSpokeWikis.)

Are we criticizing pre-mature implementation of technologies that assist InterCommunityCooperation, (which would belong on this page,) or pre-mature InterCommunityCooperation itself (which it seems to me would not belong on this page, as it stands)?

I am criticizing pre-mature implementation of technologies that assist InterCommunityCooperation. When these technologies do not exist, a lot of energy is spent (it seems) in developping features that are part of a vision. And the important thing about it being part of a vision is that the vision is not where we are but where we want to go.

They way I see it, some wikis are failing where I think they should not, eg. the Sawfish Wiki. It seems like these guys need some social engineering to help them along. But instead, people like me have worried a whole lot about connecting wikis to each other. What good does connecting a dead wiki to anything do? So here we are with people needing social engineering and we're giving them software engineering.

While having a vision and building the tools is important (and I obviously share some of that enthusiasm), I felt it was important to write down somewhere that those things are not what people really need. Those things are what we are good at doing, which is not the same thing.

I put this page up as a reminder to myself: Am I really investing energy into the right projects? Are recent developments such as tagging and flickr really big leaps forward or are they just good looking toys? The phrase "small groups first" is a reminder of what human life is mostly about: An intimate circle of friends. So if some technology comes along that connects billions of people but doesn't significantly improve my social life, I can think of this page, remember the title, and I'll know what's wrong: Here is technology that connects billions of people but this is not what billions of people need. They need better friends.

Therefore, a simple technology such as a list of links to your circle of friends does much more for us than any fancy Technorati search feature, and global or national feed aggregator, GeoUrl, Flickr, etc. Because that technology does in fact improve how my small group of friends interact. I get to know my friends' friends. Not because of FOAF, not because of Linked In, and not because of Orkut.

I think I'm rambling. I'm not sure I want to delve into the various things we worked on and thought about, and evaluate them with "small groups first" in mind. Or maybe I should.

Anyway, according to the motto "small groups first", the goal of "distributing attention more evenly" is a vision, a strange thing that most people do not need. Similarly, eventhough I was working on various linking technologies to bring wikis together, I kept wondering why most people where not enthusiastic about it. And now I know: "Small groups first" – people don't need this. There's plenty of other stuff they need for their small circle of friends online.

"Small groups first" is a reminder to get my priorities right.

Strange to read about Wiki:MoreAboutCodes in this context:

Our code word policy is to not have a policy. […] When no code word is given, you may use an alternative code word that floats among trusted users. There is no way to apply for this code. Try your friends-of-friends network. Remember that this code and the mechanism itself will change when abused.

This kind of very simple mechanism seems to be ideal for small group of friends. A crude web of trust.

It does not scale well when the secret code changes, as all the network start asking each other whether they know the new code. But if you assume that most friendly contributors in times of need belong to a small group of trusted friends, this emergency system makes sense.

Define external redirect: NaturalHierarchy MassAdoption

EditNearLinks: FormsOfCollaboration IncidentalCollaboration SisterSite MeatballWiki EmacsWiki UseNet BlogoSphere WikiWikiWeb GeoUrl

Languages: