Specific genres of social media may come and go, but these underlying properties are here to stay. We won’t turn the clock back on these. Social network sites may end up being a fad from the first decade of the 21st century, but new forms of technology will continue to leverage social network as we go forward. If we get away from thinking about the specific technologies and focus on the properties and dynamics, we can see how change is unfolding before our eyes. One of the key challenges is learning how to adapt to an environment in which these properties and dynamics play a key role. This is a systems problem. We are all implicated in it – as developers and policy makers, as parents and friends, as individuals and as citizens.
Read the full version (will there be video?) on danah’s site.
If you’re interested in checking out the syllabus from my spring Online Social Networks class, you can find HTML and PDF versions linked from my teaching page. This course is a little bit of a departure from the previous two versions; I’m focusing a little more on practice-oriented challenges (OSN’s and LIS, OSN and Education, etc). This is made possible by the large volume of literature that has come to press in recent years. It is also due to the fact that LIS grads are being asked to explore/research/manage social web applications in their jobs, and I hope to provide some of the tools and familiarity necessary for them to do so.
As always, if you’d like to follow along you can find lecture notes and slides linked from our course webpage. Feedback, paper recommendations, etc. are always welcome – either send them to me or tag them in delicious with inls490.
When describing Twitter, I use a number of analogies. Most commonly, I think of Twitter as something like a slow-motion chatroom, or even a collection of away messages. I’ve got another one to add to this list: subject-only email.
This new analogy actually comes from my use of the iPhone, where the Twitter interface isn’t all that different from the mail interface. Twitter displays a sender and a brief message, which mirrors the sender and subject elements that you’d see in an email inbox. The main conceptual leap is that with email, there’s often a payload of information, tasks or spam waiting for you. With Twitter, you’ve only got the message (an an occasional URL as payload). This very fact is why I enjoy checking Twitter, and detest my inbox.
Thinking about Twitter this way helped me imagine enterprise integration of a Twitter-like service. I envisioned adding a “Twitter pane” to email clients – a pane for Twitter-like communication aside the inbox. This Twitter pane would act as an ongoing message thread away from the inbox, and its uses would be more conversational, informal and informative.
Imagine the scenario of a guest lecture. Let’s say you’re bringing in a friend to give a talk at your company. You send out the detailed email notice, and maybe a few follow ups. To attend this talk, your coworker must process the email, calendar it, and remember. If the talk is fairly last-minute, that coworker needs to be attentive to email information coming in just-in-time. In these models there’s no space for casual prompting – replying-all to mailing list to say you’re “going to hear Sally’s talk” is generally outside of norms. However, the enterprise Twitter affords a communicative third space – a place for coworkers to discuss, remember and remind one another of the lecture, by virtue of their discussion (and perhaps live-Twittering) of the event. In this sense, the enterprise Twitter surfaces the collective, prompting observers to action.
The enterprise Twitter gives rise to a new channel of communication that offloads from the inbox, and introduces new forms of communication. In offloading the inbox, one can imagine common/frequent para-social tasks like casual lunch invites moving to the Twitter channel. In fact, the public nature of Twitter might provide unique opportunities to meet others – it might be a little strange to invite a stranger lunch, but a “who is hungry?” message to the public might allow an ad hoc group to form. In new forms of communication, one can imagine messages that might not pass the listserv test (“Can someone help me with this Perl?”) getting passed to the semi-public of the enterprise Twitter. This presents the opportunity for new connections, more efficient work, etc.
The enterprise Twitter is most interesting for its potential vibrancy. Corporations have adopted internal social networks, and while these networks represent a more robust directory, I doubt many would qualify as particularly vibrant. This may be because corporate social networks don’t really address employee needs, rather addressing the needs of management in analyzing and diagnosing the “structural holes” of the organizations. An enterprise Twitter does address a very real problem – our ever-overstuffed, mismanaged inboxes – and it introduces a vibrant and relevant communication channel to the enterprise. The enterprise Twitter might just be the electronic, distributed water cooler of lore.
In implementing an enterprise Twitter, I’d argue that one would certainly want to follow the 140-character limit, allow private, public, and semi-public (conversant) threads. The enterprise Twitter would be inside-the-firewall, and would also follow the limited profiling pattern of Twitter (Name, Bio, Link). Political considerations should be addressed. Perhaps an arbitrary follow limit of 100 would be useful – this would prevent everyone from simply following upper management out of “respect.” Other potential benefits would include the enterprise Twitter as a news or safety channel (posts could go out regarding severe weather and so forth).
Although I’ve used the brand name Twitter thoughout this post, there’s nothing Twitter-specific about the practices I’m discussing. The enterprise Twitter is just a directory, sets of permissions, a messaging protocol and integration into the messaging client. If it sounds like a replication of email, the key differences are only the social affordances and the mental model.
This scheme is not without drawbacks. Primarily, the cost of designing and integrating messaging system is not trivial. I would respond that Twitter has introduced a new type of message, one that our systems and devices should support – therefore this integration is inevitable. Another drawback is distraction. Twitter is a notorious time waster, it is addictive, and it is always on. To this I would drawn an analogy of the modern inbox – it is never off, more corporations expect you to carry mobile devices – so a Twitter management strategy should fit into larger communications-management strategies.
Inside the enterprise, individuals rely on a variety of tools and strategies to stay in communication. None have the unique affordances of the enterprise Twitter, and few offer the common social bridging role of an enterprise Twitter. My thoughts are obviously preliminary, but if anyone is working on such a project or thinking of beginning one, I’d be very interested in your thoughts/feedback.
I’ve been meaning to write this post for a while, and thanks to Techcrunch, I’ve finally got my excuse. TC describes a scheme for making Twitter “portable”, with a goal of solving the service’s technical problems. According to the post, if you glue enough “standards” together, a Twitter-killing Phoenix just might rise from the ashes, and service outages will be a thing of the past.
Part I: Economies of Cooperation
As someone who spent almost seven years working in open source, I’m the last person who will argue against openness, but there are a few things wrong with TC’s notion. Most important, “open standards” have to work in cooperation with business, not in fierce competition. As anyone who has worked in the industry knows, free software is anything but free. Both the cathedral and the bazaar have extensive present and built-in costs.
So what does this have to do with Twitter? The idea of the “open Twitter killer” is built on an open service model. Open services are the Web 2.0 version of open source software. Just like open source software, open services have built-in and present costs: hardware, data centers, staff and developers. Because open services are standards-based, there is implied future-protection justifying the provisioning costs. Putting it more bluntly, open services can’t exist without business, especially at Twitter-scale.
When the founder of DataPortability.org publicly brainstorms ways to kill Twitter on Techcrunch, he’s taking the movement backwards. Anyone with engineering skill can dream up a way to “open” a service; the real challenge is bringing companies in to the fold to support open services. Talking about how to kill them is not a good way to do this.
Part II: Interaction and Next-Gen Social Networks
This brings us to our second point: does an open Twitter work? Even if some large companies stepped up to support the cost of an open Twitter, one that never suffered downtime, would we migrate to it? Barring a complete failure by Twitter, the answer is an obvious no. Why? While the DataPortability folks and TechCrunch think Twitter is just a messaging service, the other 99.9 percent of us see Twitter for what it is – a social network service.
I’ve always had a big-tent approach when it comes to social networks; a social network is something you feel, rather than something born from a set of features. Twitter only marginally stands up to the boyd/Ellison definition: Is Twitter bound? Does a 140-character bio really count as a profile? I believe that Twitter forces us to rethink some of the assumptions around social networks. Here’s how Twitter pushes thinking on the subject forward:
Twitter isn’t a platform, it is a unique social network. It is a social network stripped to its most essential elements. Twitter provides social network designers a roadmap forward, a way of thinking about social networks more fundamentally. An “open” clone offers very little by way of competition. Further, an open clone that lacks the design or interaction aspects of Twitter would actually feel very different. Twitter is really about the user experience – something that simply can’t be replicated via an open standard.
Via Techcrunch’s Erich Schonfeld, Google appears to be moving towards turning iGoogle into its own social network. As Google is notoriously ham-fisted in this space, I worry that a move to appease a VP may undermine the well-executed and popular iGoogle product.
Before you write this off as another Google rant, lets step back for a second. Google, for all its success, is constrained in the social space by a unique problem: its success. There is no entity more central on the web, and as a result of that, Google touches almost all of us. You might think this makes for the ultimate social opportunity, but experience teaches us differently.
On the web, our favorite social spaces are cultivated. We enter new social places with expectations of social interaction, understanding that we’ll have to build a network. We “train” – learning the network with a small cluster of trusted friends, and as norms evolve and culture sets, we expand and integrate into the network. This is a critical learning process, one that can’t be taught after the fact.
Google faces two problems socializing their properties. First, Google owns enormous contact lists. Google has our emails, our hyperlinks, our readers, our clickstreams: they know who we’re close to more than anyone else. Therefore, they’re uniquely able to pre-populate our contact lists and incite sociality. Of course, pre-populated contact lists are the death of meaningful social experience, but that will be a hard sell to a VP sitting on petabytes of mined social network data. This echoes my critique of the ideology of “social network portability”.
Second, we’ve established boundaries with Google properties. While Google knows that Gmail and Search and Reader are all the same thing, we don’t. These products aren’t social; when our friends are revealed and behavior shared, this will change how we feel about these products. Identical to Facebook’s Beacon, Google faces a terrible tradeoff in unifying users across properties; while the move will provide fuel for the social experience, it will also drastically change our sense of boundaries and privacy in Google properties.
At present, Google has only rolled out built-in networking in development mode; this is a wise choice. They must now decide what they want from their efforts. If they want real sociality, they must make a hard decision to only provide tools and let the networks grow organically. If they simply want to introduce social features for publicity, they stand to poison a key product.