Marion: the disjointedness of online sociality

Marion recently wondered about the connection between the links pointing to a community web site and the relevancy of those links to the goals of the community. She asks: "Is there really value in establishing links between sources that are inherently unrelated?"

First, I would like to propose that the mere act of linking creates relevancy. Isn't the fact that "the 20 opera singers and 50 ice-cream truck drivers" convene in the West Siders for Responsible Development blog an indication that they are more than disjointed links, but people who share a similar interest?

Second, and following on that, I would say that this is precisely one of the advantages of social software: creating connections that would be much harder to create offline. What we have to keep in mind is that to some extent the formation of these connections follows its own rules. In other words, we delegate some of the control to form those connections to the Code, the social software itself. Where alliances seem natural and we strive hard to create them, they somehow fail to materialize. On the other hand, unexpected alliances emerge out of nowhere, facilitated by the Code! Sometimes you build it and those you expected to come (the opera singers) don't come, and sometimes those you didn't expect to come (the ice-cream truck drivers) crash the party! It's all part of the process of delegating some social agency to the Code.

As facilitators of online sociality, we need to be aware of these dynamics. In any change process, there's going to be few early adopters and a slow increase of adherents until an early majority is reached, and then the rest of the adopters quickly fall into place. Part of the role of the change agent/issue entrepreneur is to plan for these stages. Of course, it's nearly impossible to go through this cycle in less than one semester, but it's something you should consider in your IE projects beyond what you accomplish this term.

Social software tools use survey

Rick Reo, a grad student and a faculty support staff at George Mason University, has developed a short survey to assess the usefulness and learning potential of social software. The survey is part of his practicum project, and he is asking for our help. It only takes a couple of minutes to complete the survey, so if you would like to help Rick, here's the link.

On behalf of Rick, thanks!

The End Is Near!

With a little more than a month left in the semester, I think it is time for a reality check. The structure of this course is meant to accommodate a graduate student's need for flexibility and self-directed learning. Heaven knows we all (self included) have weeks when there is hardly any time to get anything done. But I must say I have recently noticed a troubling decrease in participation in many of your cases, and obviously it is my job to give you a little nudge. So I thought I would remind everyone of your obligations, as specified in the syllabus.

By the end of the semester, those of you taking the course for 3 credits are supposed to have:

• At least 4 individual analysis of readings (originally 5, but I let one pass). The format, if you remember, was to take one of the items from the ccte feed and discuss it in terms of the books you are reading. Later, we agreed that if you want to merely focus on the books, that would be fine too. I am looking for substance, not length.

• At least 4 IE project updates. I am looking for updates that both inform us of your progress as well as reflect your own thinking in applying what you are learning in this course. I *don't* expect you to show that the issue you selected has been neatly resolved, as that would be unrealistic and I am hoping your issue will become a long-term project extending beyond the life of this course.

• Collectively, you are supposed to complete the Design Patterns wiki. Obviously, a wiki is never 'complete,' but I would like to see something that we are proud to invite other people to see, and that they find useful.

Additionally, I expect you to continue to conduct distributed research (post items to the ccte feed) and comment on each other's blog posts (either directly on their blog or in your own blog).

I will also ask you to do a final evaluation of the course, just so you know.

The good news is that you have about 4 weeks to make sure all the work is done ;-) I think you are all doing very interesting work, so let's proceed full speed ahead for this last stretch!

Any questions, let me know.

Molly - Getting communities off the ground

In her latest IE update, Molly informs us about the MySpace community she has helped to set up for her Youth Venture Media project.

A while ago, I started a TC community in Orkut. It's still around, and once in a while someone new joins. But apart from listing members, I didn't see much more utility for the community. In my opinion, it lacks 'activities,' things for members to do that would give them a reason to go back to the community (I tried to start discussion threads on course reviews, etc, but with no success). I guess I am telling you all of this because I feel that relationship management systems (like MySpace, Orkut, Friendster etc.) are not very useful unless a) you have critical mass of users, and b) there is something for members to do besides looking at each others profiles. So my question is: how should Molly address these two challenges (which apply to all of us trying to facilitate online communities)?

Feel free to comment over at Molly's blog, or in your own blog.

Where's Ulises?

Hi folks,

Sorry I have been out of the picture the last few days, but I am in the middle of moving to a new place, and I don't even have internet access yet! I didn't post guidelines for the assignments this week, but I figured between your IE and Design Patterns projects, plus research -- that should keep you busy ;-)

Thank you for your patience.

Michael and object-centered sociality

Michael has been thinking about the 'fractal' nature of networks.

You may want to check out this post, in which the author argues for an object-centered view of networks. In other words, an object like a URL or a photo is what brings people together. This is a characteristic of networks (as opposed to communities) that I have been recently thinking about: in networks, people can form 'impersonal' connections through objects, not through direct communication with each other (although sometimes it is possible to do both, as Michael suggests in his analysis of Flickr). My question is: Is an object-centered relationship less meaningful than an interpersonal relationship, or just valuable in different ways?

Matt and the dark side

Matt writes:

I fear that social capital, like classical capital**, can lead to greater disparity between the "haves" and "have nots". The digital divide provides an easy example of how this might play out. Wealthier citizens have greater access to electronic media and the Internet. Well implemented social software affords these prosperous citizens even larger networks of trust and connections. Poorer citizens, on the other hand, miss out on these opportunities. The digital divide thereby becomes a force for greater social capital and, therefore, economic disparity. Acting in this capacity, social capital becomes an important gatekeeper to maintaining the status quo; the opposite of its touted potential as a force for greater equality.

In many ways you have called the techno-enthusiast's bluff, Matt: the benefits of technology mean little (or in fact, contribute to the divide between the have's and have-not's) if more prevalent forms of oppression (poverty, discrimination, etc.) are not addressed. Like you, I am interested in some of the same issues regarding the uneven distribution of social capital as facilitated by the new social software technologies. Currently, my thinking is that there is a way to use the same technologies that create inequalities to reduce those disparities. The solution involves not universal access to technology (which, realistically, ain't going to happen anytime soon), but the conceptualization of models of social agency and participation that extend the benefits of the new social technologies to spheres of society that do not have access to them, for the reasons you have outlined. In the end, it all boils down to the same old question: how can we use technology to build a better world? Before, the answer used to revolve around the innovativeness of technology itself. Now, it seems to revolve around the social capital that technologies like social software can facilitate. By focusing the objective of the Issue Entrepreneurship project not on the technology but on the social cause, I hope that we as a class make some progress towards figuring out how to do this.

Outcomes of Nov. 1 session

I present the following as a way to summarize what we did during our class session on November 1, and for the benefit of those who could not attend.

We agreed to pursue the Design Patterns of Social Computing (DPSC) project as our final group project for this course (I'm trying to avoid the use of the label 'social software' in the title of the project so as not to tie it to a label that may become obsolete in the future. Feel free to suggest other names for it).

We believe that this project will be of benefit to us (the primary audience) as well as to the larger community of researchers interested in Social Software issues. We recognized the potential for this project to continue to grow in the future (beyond the semester, and beyond the group of people in the class), and to become part of a larger community portal of folks interested in Social Software/Web 2.0 issues.

We will be using the wiki that Jonah has made available for the DPSC project. The 'Course Wiki' (the Seedwiki we have been using as a workspace to brainstorm ideas, and where the blog directory is also located) will remain active for reference purposes, but it will probably not be used much for the remainder of the semester.

We identified a number of problems that social software is addressing, and we started to formulate one or more design patterns for each. I will summarize the problems below (in no particular order) and, where appropriate, I will list the names of the folks in the class who were assigned to begin a Design Pattern page in the wiki for that particular problem.

• Ubiquitous presence / Globalization / Ability to work across space and time
  
• Filtering of information / Archiving / Aggregation of efforts (Jonah and Nabeel)
  
• Wisdom of crowds / Archiving (Molly and Matt)
  
• Collaboration / Mentoring / Tutoring / Apprenticeship
  
• Dissemination / Reaching larger audiences / Distribution / Self-publishing / Decentralization (Robert and Steve)
  
• Opportunities for social discovery / Relationship management / Keeping in touch with existing communities
  
• Trust building
  
• Personalization / Customization
  
• Democratization of production, distribution or decision making / Decentralized knowledge (Marion and Dan -- I think?)
  
• Long tail / Lowering critical mass threshold
  
• Anonymity / Identity / Motivation
  
• Interest-based community building / Connectivity (Anthony and Mariana)
  
• Catalyst for participation
  

This list is by no means inclusive, but it's a start.The problems listed above that do not have names assigned to them are up for grabs. They also need to be incorporated into the DPSC wiki. Please note that while the people identified above are assuming responsibility for the first draft of the Design Pattern page for a particular problem, consequent edits are the domain of the whole group. It's a collaborative project.

As far as the template for each design pattern, we agreed on the following (borrowed from DiGiano et al (2002), Collaboration Design Patterns: Conceptual Tools for Planning for The Wireless Classroom):

1. Name: The name and a short summary of the pattern
   
2. Problem: The problem the pattern addresses, including a discussion of its associated forces
   
3. Example: A real-world example demonstrating the existence of the problem and the need for the pattern
   
4. Context: The situations in which the pattern may apply
   
5. Solution: A resolution of the problem stated in terms that could be applied in many situations
   
6. Implementation: The fundamental solution principle underlying the pattern
   
7. Technological Assumptions: What infrastructure must be in place for the implementation to be practical
   
8. Variants: A brief description of variants or specializations of a pattern
   
9. Consequences: The benefits the pattern provides, and any potential liabilities
   
10. See Also: References to patterns that solve similar problems.
    

We did not discuss any particular structure for the DSPC wiki, but agreed to let the structure emerge as we work.

Per Jonah, remember that you will need to login to the DPSS Wiki in order to make any changes to it (contact him for login information if you don't remember what it is). Also, remember to create a profile page.

p.s. At the end of class I made a comment regarding the allocation of your efforts for the remainder of this course. Between your IE project and the DPSC project you will have plenty to keep you busy. However, I do want you to continue posting your Individual Assignments, even if they become shorter and more informal, as I think it is important for you to keep reading. If it makes it easier, you should focus your Individual Assignments on the class readings (the books), and not necessarily try to link them to the online articles being submitted to the ccte tag.

I'm looking forward to seeing what shape the DPSC project takes. Keep up the good work.