Monday, March 23, 2009
Is social media an industry? Sometimes yes, but mostly no
This is an edit of my response to “Is Social Media an Industry?” on mashable
I was surprised to see that nearly 70% of people who voted in an online poll believed that social media was an industry. To my mind, the answer is both yes and no, depending on how you conceptualize “industry” and “social media.” First, there is the issue of the impetus for the question. Just because many people are interested in it, that doesn’t mean it is an industry. There is no established measure of how Google search terms relate to the size of industries, although increased searches do correlate with general interest by individuals.
Social media could be considered an industry for non-market information economies, of the type Yochai Benkler identifies as being critical for the success of the Internet and vastly different from market economies. For instance, social network sites could be considered an industry, as they quite literally build on and trade in social interactions. However, they are poorly, if at all, monetized.
More generally speaking, in market economies, I would argue that the vast majority of applications for social media are not related to a specific industry, but instead are tools used by various industries. Social media (plural: blogs, Twitter, SNSs, etc.) are not an industry. Also, industries are not defined just by popularity, but by the products they create and professionals they involve. "Social media" is a rather ambiguous term used to describe a collection of (mostly) online technologies that rely on connections between people to operate. These technologies are quite disparate, and often individuals and companies use them for entirely different purposes.
In this sense, social media are a vehicle for other industries, such as advertising, journalism, and software development. Each of these industries has very specific products and practices. Social media are integrated on various levels across these industries, but alone, they don’t amount to very much. Social media are tools for various industries, but are typically not their own industry.
I was surprised to see that nearly 70% of people who voted in an online poll believed that social media was an industry. To my mind, the answer is both yes and no, depending on how you conceptualize “industry” and “social media.” First, there is the issue of the impetus for the question. Just because many people are interested in it, that doesn’t mean it is an industry. There is no established measure of how Google search terms relate to the size of industries, although increased searches do correlate with general interest by individuals.
Social media could be considered an industry for non-market information economies, of the type Yochai Benkler identifies as being critical for the success of the Internet and vastly different from market economies. For instance, social network sites could be considered an industry, as they quite literally build on and trade in social interactions. However, they are poorly, if at all, monetized.
More generally speaking, in market economies, I would argue that the vast majority of applications for social media are not related to a specific industry, but instead are tools used by various industries. Social media (plural: blogs, Twitter, SNSs, etc.) are not an industry. Also, industries are not defined just by popularity, but by the products they create and professionals they involve. "Social media" is a rather ambiguous term used to describe a collection of (mostly) online technologies that rely on connections between people to operate. These technologies are quite disparate, and often individuals and companies use them for entirely different purposes.
In this sense, social media are a vehicle for other industries, such as advertising, journalism, and software development. Each of these industries has very specific products and practices. Social media are integrated on various levels across these industries, but alone, they don’t amount to very much. Social media are tools for various industries, but are typically not their own industry.
Labels: facebook, MySpace, SNS, social media, social networking
Tuesday, March 10, 2009
Reaction to "Dunbar number" hype
The recent finding that Facebook members communicate regularly with a very small group is not surprising. Sites such as Facebook exist to keep track of a range of friendships, which some have taken to be a test of an online Dunbar Number. There are number of reasons why this is a difficult comparison to make. As danah boyd succinctly discusses, there are a number of reasons why the “Dunbar number” simply does not apply to online relationships. It is a theoretical number based in the real world, describes “grooming” activities by primates, and was developed from observations by anthropologists in non-first-world countries. And, of course, Facebook connections do not capture the entire range of social connections of an individual, just the connections on a single site. Even if you accept that a “Dunbar number” exists online (to play devil's advocate), this does not disprove the utility of these sites.
Many SNS connections are ultra “loose ties” that would seem to fall outside of the purview of a Dunbar number, while others are connections with close friends or family. My personal feeling is that even loose ties can come into more central play in a person’s life through these sites over time, regardless of whether these friendships began online or offline. There are a number of reasons that people may productively use SNSs to maintain large groups of extremely loose ties. These are friends from work or around town that may emerge as close ties at a point in the future, business “contacts” that are not friendship-related but need to be maintained, and individuals who used to be close ties but now have fallen out of favor due to geographic limitations (such as the classic old school buddies).
People gain personal satisfaction, financial security, and community benefit from online socialization with online groups. These groups have very tangible beneficial effects, and tie groups of close-tie groups together, providing valuable “bridging” that facilitates propagation of ideas. These sites are also increasingly a platform for other activities, including bona fide applications that expand the reach of SNSs beyond text and images, a convergence of activities as well as socializations.
Why individuals only interact consistently with a small number of friends can be explained, in part, by Facebook's filtering. Filtering is a key part of social promotion, without which it would be difficult to harness the “wisdom of crowds.” Facebook recognizes the people you communicate the most with, and promote their news feed items above those of others. This is completely natural utility – why would you want to have daily updates from someone you haven’t spoken with in ten years? Unless of course, you renew your friendship and start to interact more with them, at which point Facebook would recognize the increased activity. And you are always free to select “I want to see less from [user]” in the feeds. Even if people are exposed to an over abundance of messages from online “friends,” I doubt this can be shown to contribute to a meaningful negative effect. This “overload hypothesis” is frequently promoted by the media as a death by distraction (so to speak), making bugaboos of everything from cell phones to email. Never mind that if you show someone too much information, they simply do not retain everything, only what they frequently access or are useful in their life. Excess information is not retained, mentally urinated out like an excess of water-soluble vitamins.
Many SNS connections are ultra “loose ties” that would seem to fall outside of the purview of a Dunbar number, while others are connections with close friends or family. My personal feeling is that even loose ties can come into more central play in a person’s life through these sites over time, regardless of whether these friendships began online or offline. There are a number of reasons that people may productively use SNSs to maintain large groups of extremely loose ties. These are friends from work or around town that may emerge as close ties at a point in the future, business “contacts” that are not friendship-related but need to be maintained, and individuals who used to be close ties but now have fallen out of favor due to geographic limitations (such as the classic old school buddies).
People gain personal satisfaction, financial security, and community benefit from online socialization with online groups. These groups have very tangible beneficial effects, and tie groups of close-tie groups together, providing valuable “bridging” that facilitates propagation of ideas. These sites are also increasingly a platform for other activities, including bona fide applications that expand the reach of SNSs beyond text and images, a convergence of activities as well as socializations.
Why individuals only interact consistently with a small number of friends can be explained, in part, by Facebook's filtering. Filtering is a key part of social promotion, without which it would be difficult to harness the “wisdom of crowds.” Facebook recognizes the people you communicate the most with, and promote their news feed items above those of others. This is completely natural utility – why would you want to have daily updates from someone you haven’t spoken with in ten years? Unless of course, you renew your friendship and start to interact more with them, at which point Facebook would recognize the increased activity. And you are always free to select “I want to see less from [user]” in the feeds. Even if people are exposed to an over abundance of messages from online “friends,” I doubt this can be shown to contribute to a meaningful negative effect. This “overload hypothesis” is frequently promoted by the media as a death by distraction (so to speak), making bugaboos of everything from cell phones to email. Never mind that if you show someone too much information, they simply do not retain everything, only what they frequently access or are useful in their life. Excess information is not retained, mentally urinated out like an excess of water-soluble vitamins.
Labels: anthropology, communication, facebook, SNS, social networking, socialnetworking
Wednesday, July 23, 2008
Quarterlife.com in freefall
A year ago I started consulting for Quarterlife.com, and helped with the initial sourcing of talent and getting the project off the ground. I haven’t kept track of the site since I started teaching, but did wonder what its fate would be after the television series went the way of the dodo.
In the month of June, the site’s reach dropped from .006 to .001. Admittedly, the most drastic part of the plummet is with reach and rank, but clearly it’s not a healthy social network site. I’m not sure why the drop - it’s too late for it to be due to college students leaving for the summer - but certainly new users aren’t coming to the site like they once were. There’s nothing that says “crash” more than Google adsense advertisements for incontinence showing up on a site’s main page. People notice when you’re selling out the most prominent area on the site for a low CPM rate. It screams desperation.
The whole Quarterlife story is tragic, because if it were successful, it might have ushered in new opportunities for those in the entertainment industry. Chalk it up to short-lived buzz not lending itself to a long-term business. The idea was to get the buzz around the show to feed into a social network, but the may just not be enough opportunities on the site to fill in the gaps between the peaks in popularity. Although promised, the contests have yet to appear. To my mind, this would be the “killer app” of Quarterlife, which would retain users with other activities, similar to OurStage.
In the month of June, the site’s reach dropped from .006 to .001. Admittedly, the most drastic part of the plummet is with reach and rank, but clearly it’s not a healthy social network site. I’m not sure why the drop - it’s too late for it to be due to college students leaving for the summer - but certainly new users aren’t coming to the site like they once were. There’s nothing that says “crash” more than Google adsense advertisements for incontinence showing up on a site’s main page. People notice when you’re selling out the most prominent area on the site for a low CPM rate. It screams desperation.
The whole Quarterlife story is tragic, because if it were successful, it might have ushered in new opportunities for those in the entertainment industry. Chalk it up to short-lived buzz not lending itself to a long-term business. The idea was to get the buzz around the show to feed into a social network, but the may just not be enough opportunities on the site to fill in the gaps between the peaks in popularity. Although promised, the contests have yet to appear. To my mind, this would be the “killer app” of Quarterlife, which would retain users with other activities, similar to OurStage.
Labels: facebook, MySpace, quarterlife, quarterlife.com, SNS, social networking
Sunday, June 01, 2008
How dangerous is posting personal information on Social Networking Sites?
The most recent findings by Ybarra and Mitchell (2008) address the assumption the posting of personal information on social network websites (SNSs) is dangerous. Their results show that when other factors are accounted for, a young person’s posting of personal information online does not significantly increase the likelihood that he or she will be harassed or solicited.
While much more research needs to be done on the topic, it is apparent that other communication mediums are far riskier. Namely, chat rooms and instant messaging (IM) are particularly problematic for adolescents. In the last year, 43% of youth stated they had been solicited over IM, 32% by chat rooms, and 4% by SNS. In the last year, 55% of youth stated they had been harassed over IM, compared with 4% by SNS.
Also, the posting of personal information may be a lesser risk factor when compared with behaviors such as talking with strangers online. Factors in family life also have a strong correlation with likelihood of harassment, such as whether the young individual in question has been abused. This refocusing of concepts is in-line with the ongoing efforts of the CCRC, which in recent years has illuminated why certain young individuals are more vulnerable than others.
For a broad overview on the state of research on cyber-predation, see Wolak, Finkelhor, Mitchell, and Ybarra (2008). Also see: Hinduja and Patchin (2008) regarding their analysis of the rate of disclosure of information on one particular SNS, MySpace.
While much more research needs to be done on the topic, it is apparent that other communication mediums are far riskier. Namely, chat rooms and instant messaging (IM) are particularly problematic for adolescents. In the last year, 43% of youth stated they had been solicited over IM, 32% by chat rooms, and 4% by SNS. In the last year, 55% of youth stated they had been harassed over IM, compared with 4% by SNS.
Also, the posting of personal information may be a lesser risk factor when compared with behaviors such as talking with strangers online. Factors in family life also have a strong correlation with likelihood of harassment, such as whether the young individual in question has been abused. This refocusing of concepts is in-line with the ongoing efforts of the CCRC, which in recent years has illuminated why certain young individuals are more vulnerable than others.
For a broad overview on the state of research on cyber-predation, see Wolak, Finkelhor, Mitchell, and Ybarra (2008). Also see: Hinduja and Patchin (2008) regarding their analysis of the rate of disclosure of information on one particular SNS, MySpace.
Labels: disclosure, facebook, harassment, MySpace, online, predation, safety, SNS, social networking
Sunday, May 25, 2008
Lessons learned from teaching “Technologies for Online Communities” - a new course on creating “social networking” websites at APOC
Last semester I taught a groundbreaking course in the Annenberg Program on Online Communities at USC’s Annenberg School for Communication. It’s the first (and as far as I know, the only) one-year MA program that focuses exclusively on building and cultivating online communities. Titled “Technologies for Online Communities,” it’s a grad-level introduction to technical concepts and managerial/collaborative methodologies. Now that the semester has ended, I have a short bit of time to reflect before I start the next course in the program sequence - a research methodologies course led by Mathew Curtis in the psychology department, where I’ll be teaching online-specific research concepts and tools.
The goal of the course was to create product developers and project managers for “social networking” websites. Half (50%) of the surveyed class described their experience with technical concepts at the start of the class as “novice.” This was a pretty tall order: bring the class from novices to managers with a strong understanding of core concepts in 16 weeks. The course was a success, but as always, teaching is also a learning experience. Here I present a few takeaway lessons for instructors or professors considering similar courses or approaches.
1. Teach concepts as they are encountered, not how you learned them
I introduced concepts in a top-down fashion, because it’s how I was taught and how I best understand the material. By top-down I mean bringing in technologies and collaborative methodologies as they exist structurally: start with the client side, talk about HTML and web browsers, then move on to the server side, and talk about databases and client-side development.
The sequencing of materials will definitely be altered to better reflect how they are encountered during the design and development process, particularly how product design integrates with technical development. On the last day of class, Karen North, the director of APOC, handed me a syllabus for a similar course in online development. This course sequenced material in order of how it would be used to create a website. The course was basically one large problem-solving activity strongly connected to real-life, similar to a semester-long PBL exercise. Concepts were introduced based on how they are encountered in the development process. For instance, at the start of the development process, a server would need to be secured, which would also entail discussion of how servers work. This altered sequence would address requests throughout the semester for more examples and provide an ongoing, coherent narrative with real-life applications.
2. Splitting your brain is okay, to a point
The course material was split thematically into technologies (programming languages, client-server development, APIs) and collaborative/managerial methodologies (agile, recruiting talent, writing specifications). Students completed the same coursework, with the exception of the final project. The final project, which was among the highest-reviewed course components, was to create a presentation on either technical or managerial concepts. Most of surveyed participants found the technical portions of the course “beneficial” (averaging a 4.0 out of 5) while slightly fewer positively responded to the managerial portions of the course. While students generally found the two sections of the class to be overall beneficial to their learning, several offered suggestions on how course material was sequenced. These suggestions were mixed, and included a reversal of the order of material presented, de-emphasizing coding, and separating this single course into two courses.
I’m sticking to my guns here; I would like to preserve the ability for students to focus on either technical or managerial concepts in the final project, while encountering in all the class material through discussions, readings, and homework. While I think two separate courses would be appropriate, it’s unlikely that the program can support both. Throughout the semester I found students either naturally gravitated to either programming or managerial concepts. Students will naturally end up being professionals that accentuate either one or the other, depending on their personality and interests. By the end of the course, students should have a much better idea of the type of role they will play upon graduation. So it makes sense there is no “one size fits all” solution for students, and they will become more specialized.
3. Create managers who develop sites, not programmers who develop sites
Deciding how technical to get in an introductory skills course is a risky balancing act. Too much technical focus may lead to confusion, while too little technical information may not give students the core understandings they require. One of the decisions I made early on was to not turn the course into simply a raw programming course in, say, javascript. Students in a one-year MA program on online communities aren’t going to become software engineers over the span of one semester. Even if they did become wizzes in javascript, they wouldn’t receive enough tangible benefits to the larger picture: creating living, breathing, online communities.
So, from the start I was aware that the course could not create software engineers. Even aware as I was, I went a little too far; one place the class stumbled was in understanding object-oriented programming (OOP). This core concept could have been introduced more coherently, more slowly, or omitted entirely. I’m going to go out on a limb here and say meta-programming packages might be a more approachable alternative to “true” programming for novices. Drupal, for example, while esoteric in setup, allows students to get a social networking site up and running immediately. Being able to quickly create and modify a site in real-time offers both technical and attitudinal benefits.
Technically, students would encounter concepts such as PHP and database design within a safe framework. They would get the thrill of quickly creating and taking ownership of a database-driven website, which would be otherwise impossible for novices to accomplish in a single semester. The big downside to closer incorporation of a package like Drupal is that its inner workings (PHP, databases) would need to be appropriately described, otherwise its value as a teaching tool would be diminished. For instance, AJAX requires a solid understanding of javascript (client-end dev), client-server networking, and remote APIs (e.g. REST). Even if AJAX somehow went away in 2 years time or was replaced by Flash or Flex, the remaining concepts would still be valuable. If all students learn is how to use a particular type of CMS or templating system, which doesn’t exist in a few years, they may not have these valuable core concepts to fall back on.
4. Jettison components that aren’t accomplishing what you hoped, add new ones
Quizzes were the lowest-reviewed course component (which were: homework, readings, quizzes, in-class exercises, lectures, and final project). Ideally, viewed through Bloom’s taxonomy, quizzes help retention of low-level cognitive concepts, leading into higher-level understanding and application. But if students aren’t finding this part of the course beneficial, I may reduce it or cut it out entirely in future years. Quizzes are useful in undergrad courses as, frankly, a salient threat to do the reading and pay attention. For a grad-level course they may not be necessary, as grad students are more involved, driven and attentive. As long as students are involved with the course, low-level knowledge acquisition may better occur through small group activities or lab exercises.
Even though the course was paired with another course, which had industry speakers every week, the connection with industry needed to be stronger in this class in particular. I’m taking time over the summer to collect first-person reports from industry to roll in with next year’s course, particularly as concerns APIs (such as OpenSocial), monetizing contextualized data (directed marketing), and more freeform collaboration in the building process (e.g. Google-style project development).
5. Encourage direct and immediate classroom responses
This isn’t so much related to this course as teaching as a whole. As much as we talk about listening to our users, the same mantra applies to students. There is no substitute for an aware and receptive instructor. The semester is rather short, and the material is at times imposing and demanding of students, particularly novices. The overview skills course should be an agile u-boat that can turn at a moment’s notice, not an overgrown tanker that takes time to alter course. Noticing immediately where students are encountering difficulties is absolutely necessary to adapt the material to their needs. Additionally, paying close attention to them may offer perspectives that are more likely to reach fellow students than your own. In the case of this course, many students were well-versed in one or more topics, even if they didn’t have a grasp of all areas. For instance, one student had a deep knowledge of widgets, and was helpful in contributing practical examples of how her work life centered on interacting with developers to create widgets. It’s even possible to get students to focus their questions on each other, as well; peer learning is vital to the grad school experience, and was entirely appropriate for the online communities theme.
The goal of the course was to create product developers and project managers for “social networking” websites. Half (50%) of the surveyed class described their experience with technical concepts at the start of the class as “novice.” This was a pretty tall order: bring the class from novices to managers with a strong understanding of core concepts in 16 weeks. The course was a success, but as always, teaching is also a learning experience. Here I present a few takeaway lessons for instructors or professors considering similar courses or approaches.
1. Teach concepts as they are encountered, not how you learned them
I introduced concepts in a top-down fashion, because it’s how I was taught and how I best understand the material. By top-down I mean bringing in technologies and collaborative methodologies as they exist structurally: start with the client side, talk about HTML and web browsers, then move on to the server side, and talk about databases and client-side development.
The sequencing of materials will definitely be altered to better reflect how they are encountered during the design and development process, particularly how product design integrates with technical development. On the last day of class, Karen North, the director of APOC, handed me a syllabus for a similar course in online development. This course sequenced material in order of how it would be used to create a website. The course was basically one large problem-solving activity strongly connected to real-life, similar to a semester-long PBL exercise. Concepts were introduced based on how they are encountered in the development process. For instance, at the start of the development process, a server would need to be secured, which would also entail discussion of how servers work. This altered sequence would address requests throughout the semester for more examples and provide an ongoing, coherent narrative with real-life applications.
2. Splitting your brain is okay, to a point
The course material was split thematically into technologies (programming languages, client-server development, APIs) and collaborative/managerial methodologies (agile, recruiting talent, writing specifications). Students completed the same coursework, with the exception of the final project. The final project, which was among the highest-reviewed course components, was to create a presentation on either technical or managerial concepts. Most of surveyed participants found the technical portions of the course “beneficial” (averaging a 4.0 out of 5) while slightly fewer positively responded to the managerial portions of the course. While students generally found the two sections of the class to be overall beneficial to their learning, several offered suggestions on how course material was sequenced. These suggestions were mixed, and included a reversal of the order of material presented, de-emphasizing coding, and separating this single course into two courses.
I’m sticking to my guns here; I would like to preserve the ability for students to focus on either technical or managerial concepts in the final project, while encountering in all the class material through discussions, readings, and homework. While I think two separate courses would be appropriate, it’s unlikely that the program can support both. Throughout the semester I found students either naturally gravitated to either programming or managerial concepts. Students will naturally end up being professionals that accentuate either one or the other, depending on their personality and interests. By the end of the course, students should have a much better idea of the type of role they will play upon graduation. So it makes sense there is no “one size fits all” solution for students, and they will become more specialized.
3. Create managers who develop sites, not programmers who develop sites
Deciding how technical to get in an introductory skills course is a risky balancing act. Too much technical focus may lead to confusion, while too little technical information may not give students the core understandings they require. One of the decisions I made early on was to not turn the course into simply a raw programming course in, say, javascript. Students in a one-year MA program on online communities aren’t going to become software engineers over the span of one semester. Even if they did become wizzes in javascript, they wouldn’t receive enough tangible benefits to the larger picture: creating living, breathing, online communities.
So, from the start I was aware that the course could not create software engineers. Even aware as I was, I went a little too far; one place the class stumbled was in understanding object-oriented programming (OOP). This core concept could have been introduced more coherently, more slowly, or omitted entirely. I’m going to go out on a limb here and say meta-programming packages might be a more approachable alternative to “true” programming for novices. Drupal, for example, while esoteric in setup, allows students to get a social networking site up and running immediately. Being able to quickly create and modify a site in real-time offers both technical and attitudinal benefits.
Technically, students would encounter concepts such as PHP and database design within a safe framework. They would get the thrill of quickly creating and taking ownership of a database-driven website, which would be otherwise impossible for novices to accomplish in a single semester. The big downside to closer incorporation of a package like Drupal is that its inner workings (PHP, databases) would need to be appropriately described, otherwise its value as a teaching tool would be diminished. For instance, AJAX requires a solid understanding of javascript (client-end dev), client-server networking, and remote APIs (e.g. REST). Even if AJAX somehow went away in 2 years time or was replaced by Flash or Flex, the remaining concepts would still be valuable. If all students learn is how to use a particular type of CMS or templating system, which doesn’t exist in a few years, they may not have these valuable core concepts to fall back on.
4. Jettison components that aren’t accomplishing what you hoped, add new ones
Quizzes were the lowest-reviewed course component (which were: homework, readings, quizzes, in-class exercises, lectures, and final project). Ideally, viewed through Bloom’s taxonomy, quizzes help retention of low-level cognitive concepts, leading into higher-level understanding and application. But if students aren’t finding this part of the course beneficial, I may reduce it or cut it out entirely in future years. Quizzes are useful in undergrad courses as, frankly, a salient threat to do the reading and pay attention. For a grad-level course they may not be necessary, as grad students are more involved, driven and attentive. As long as students are involved with the course, low-level knowledge acquisition may better occur through small group activities or lab exercises.
Even though the course was paired with another course, which had industry speakers every week, the connection with industry needed to be stronger in this class in particular. I’m taking time over the summer to collect first-person reports from industry to roll in with next year’s course, particularly as concerns APIs (such as OpenSocial), monetizing contextualized data (directed marketing), and more freeform collaboration in the building process (e.g. Google-style project development).
5. Encourage direct and immediate classroom responses
This isn’t so much related to this course as teaching as a whole. As much as we talk about listening to our users, the same mantra applies to students. There is no substitute for an aware and receptive instructor. The semester is rather short, and the material is at times imposing and demanding of students, particularly novices. The overview skills course should be an agile u-boat that can turn at a moment’s notice, not an overgrown tanker that takes time to alter course. Noticing immediately where students are encountering difficulties is absolutely necessary to adapt the material to their needs. Additionally, paying close attention to them may offer perspectives that are more likely to reach fellow students than your own. In the case of this course, many students were well-versed in one or more topics, even if they didn’t have a grasp of all areas. For instance, one student had a deep knowledge of widgets, and was helpful in contributing practical examples of how her work life centered on interacting with developers to create widgets. It’s even possible to get students to focus their questions on each other, as well; peer learning is vital to the grad school experience, and was entirely appropriate for the online communities theme.
Labels: 4-year, apoc, MA, online communities, online networking social communitynext, social networking, teaching
