twitter

You are currently browsing articles tagged twitter.

@everyword in context

Last week Adrian Chen conducted an e-mail interview with me about @everyword. Here’s the resulting article on Gawker. The @everyword account gained about a thousand new followers as a result of the article—not bad for an account that just tweets word after word every half hour!

It’s been interesting to read people’s reactions to @everyword (and yes, I have the Twitter search for @everyword in my RSS feed reader, because I am hopelessly narcissistic). For the most part, the reactions are positive! It’s satisfying when someone is amused by a word that they didn’t know existed (or that they hadn’t considered to be a “word”) or when someone finds unexpected synergy between a word that just got posted and something that is happening in their lives.

Some of the reactions are more critical. Here’s one reaction in particular that I wanted to respond to, from Twitter user @fran_b__:

@everyword They aren’t words unless they have meaning, which implies context. Stripped of context, they are simply (python) string arguments. (source)

This response baffled me, because in my mind @everyword is all about context. For example, here’s the way that I typically read @everyword:

everywordcontextThis is a screenshot of my Twitter client on a typical morning. You can see the tweets from @everyword interleaved in the feed. I don’t generally read the tweets in my feed like I would paragraphs or sentences in an essay or a piece of fiction (e.g., I skip tweets, I don’t necessarily expect cohesion from one tweet to the next), but I do tend to read them in sequence. It’s undeniable that the tweets exist in the same physical context here. Because of this, some interesting possibilities for creative reading crop up. It’s easy for one tweet to “color” how nearby tweets are read, for example. I’m not saying that @notch is prone to nutations, or that @factoryfactory and @daphaknee are nutcases, but that’s certainly a reading made possible by the tweets’ close proximity.

There’s also the context provided merely by being in sequence with other words in the @everyword feed. Here’s an example:

everywordcontext2

I find this endlessly fascinating. When you see these words juxtaposed like this, you can’t help but try to find some connection between them. In some cases, the connection is grammatical (nunnery is of course morphologically related to the word nuns). But nunsnuptials and nursemaid together like is almost like a little narrative. “Nuns can’t have nuptials, and they certainly can’t be nursemaids.” It seems ironic that the words would be juxtaposed like this, and that perception only emerges from seeing these words in this kind of unusual context.

It’s also a cultural practice of ours to consider individual words in the abstract: we pick out our favorite words, we decide which words are commonly misused, we decry our politicians for making up words or using words with a disagreeable frequency, etc. In some sense, a word carries with it a cultural context, no matter where it occurs. One of the intentions of @everyword was to play with this idea: every word has cultural baggage. What would happen if we systematically exposed ourselves to that baggage?

Even if I concede that the words in @everyword are “simply (python) string arguments,” isn’t that also a context? A computer program is a kind of writing, after all. It means something for a programmer to choose to put one string in a program, instead of some other string, or to feed some set of data to a program instead of some other set. Sure, the Python program that runs @everyword would also work with any other arbitrary data set—@everybaseballplayer, anyone?—but the fact that I chose words, and words in this particular order, is part of the context of the piece.

In the end, I think @fran_b__’s implication is that there are certain kinds of contexts that a word can occur in that “count” as meaningful (such as being in a sentence intentionally composed by an individual) and others that don’t. I suppose that for certain fields of study, this is a valid point of view: if you’re analyzing a novel, for example, you might not want to include in your analysis the novel sitting next to it on the shelf. As a writer and poet, however, I find that limitation pretty dull. There’s never been an era in history with such diverse practices for reading and writing text. Why not have as much fun with that as possible?

Tags: , , ,

Last October I undertook a “lexical analysis” of the Twitter and Facebook APIs. Twitter came out on top in that analysis. I concluded that Twitter’s “simplicity … has been an important factor in [its] widespread growth among both users and developers” while Facebook’s “baroque and insular” API makes it impossible for users and developers to “keep track of how everything works together.” Facebook’s been promising changes for a while, and change has indeed arrived, in the form of the new Graph API. So how does the Graph API compare, lexically, to Twitter? Here’s a revised analysis. (Spoiler: things are looking much better for Facebook.)

Facebook Graph API Twitter
Verbs
get
post
delete

Nouns
album
photo
event
group
link
note
page
photo
post
status message
user
video
comment
feed
noreply
maybe
invited
attending
declined
picture
member
home
tag
activities
interests
friends
music
books
movies
television
likes
inbox
outbox
updates
search

Verbs
get
show
update
destroy
post
put
exists
verify
end
follow
leave
report
request
authorize
authenticate

Nouns
search
trend
status
timeline
mention
retweet
friend
follower
direct message
friendship
id
account
session
delivery device
color
image
profile
favorite
notification
block
spam
search
token
test
place
geocode

The tally: the Twitter API holds steady with 26 nouns and 15 verbs. The Graph API, meanwhile, has 35 nouns* and 3 verbs—a tremendous improvement on Facebook’s old (so-called) REST API, which has 43 nouns and 24 verbs. The Twitter API and Facebook’s REST API average around 1.7 nouns per verb; the Graph API has almost 12 nouns per verb. What’s especially interesting? The Graph API has managed to sidestep any verbs that aren’t HTTP methods.

The Graph API is a big deal, and an important step forward for Facebook. Here are a few reason I think that’s the case.

First of all, the Graph API is dead simple, especially compared to Facebook’s old REST API. Just as an example: the old API has (by my count) seven nearly synonymous verbs (set, create, add, register, upload, send, publish) that all essentially mean “add content for a user.” These verbs aren’t interchangeable; each works with only a subset of nouns (or even just a single noun). Each verb has idiosyncratic behaviors, arguments and error messages. The Facebook REST API is, in short, a mishmash of conflicting conceptual models. It’s tough to get a handle on all of it.

Not so with the Graph API. Every resource has exactly the same interface. Once you understand what each noun is, it’s easy to understand how to manipulate it—there are only three possible verbs, after all!

The complexity of the REST API necessitated a client library to perform even very simple operations. The Graph API, on the other hand, is so simple, I think that most developers won’t even use a library at all—it’s easier to just hit the URLs directly. Simply put: if you know how to make HTTP requests, you know how to use the Graph API.

That’s the second thing that makes the Graph API so important—it’s the web. The Graph API isn’t just a bunch of function calls for retrieving information; it’s a set of URLs to representations of the data itself. The data is all in JSON format, so it’s easy for browsers to consume it directly. Image URLs return the images themselves, so they can be thrown right into img tags without an intermediary API call. Most importantly, the resources returned from the Graph API are hypermedia: they include URLs to related resources. An example (from the documentation):

{
   "name": "Facebook Developer Garage Austin - SXSW Edition",
   "metadata": {
      "connections": {
         "feed": "http://graph.facebook.com/331218348435/feed",
         "picture": "https://graph.facebook.com/331218348435/picture",
         "invited": "https://graph.facebook.com/331218348435/invited",
         "attending": "https://graph.facebook.com/331218348435/attending",
         "maybe": "https://graph.facebook.com/331218348435/maybe",
         "noreply": "https://graph.facebook.com/331218348435/noreply",
         "declined": "https://graph.facebook.com/331218348435/declined"
      }
   }
}

The URLs are right there in the document, meaning that you don’t have to know anything else about how the Graph API works in order to get information related to a resource. Pretty slick. It’s an idea that (I think) every web API should incorporate.

There are, of course, a few factors that mitigate my enthusiasm for the Graph API. First off, it doesn’t quite model the entirety of Facebook’s functionality yet—notably, there aren’t any resources (so far) representing Facebook applications themselves. There are also privacy concerns that need to be addressed (for example, event listings).

Overall, though, the Graph API is beautifully constructed. It’s just as robust as the Facebook’s old API, but simpler, more convenient, and easier to integrate. As a developer (and programming instructor), my opinion has always been that Twitter’s main advantage over Facebook is its developer-friendly API. The Graph API has the potential to erase that advantage.

* There are a number of verb-like words and verb participles in the Facebook “noun” list. I classify them as such because, to my eye, they’re clearly presented in the API documentation as things you can act on, rather than actions you can take. For example, attending means “users who are attending something,” and acting on that resource allows you to fetch or manipulate that list of users.

Tags: , , , ,

Recent projects

Three recent projects which I have so far neglected to post about:

LATE EDIT: Andy Doro is exhibiting the Networked Byte Organ, which we worked on together, at Taller Boricua.

Tags: ,

Facebook Twitter
Verbs
get
set
ban
unban
create
expire
promote
revoke
run
add
remove
register
cancel
edit
invite
rsvp
delete
refresh
query
is/are
upload
send
mark
publish

Nouns
allocation
property
metric
restriction
user
info
token
session
authorization
permission
batch
comment
friend
count
cookie
member
tag
url
handle
group
translation
link
string
message
thread
folder
note
notification
list
e-mail
page
fan
photo
album
profile
sms
stream
option
like
filter
status
video
limit

Verbs
get
show
update
destroy
post
put
exists
verify
end
follow
leave
report
request
authorize
authenticate

Nouns
search
trend
status
timeline
mention
retweet
friend
follower
direct message
friendship
id
account
session
delivery device
color
image
profile
favorite
notification
block
spam
search
token
test

I made this list by combing through both services’ API documentation and extracting noun-like words and verb-like words from the names of resources or methods. Facebook count: 24 verbs, 43 nouns. Twitter count: 15 verbs, 24 nouns.

Here’s what I think these numbers mean.

Facebook manages many different kinds of content, and allows you to perform many different kinds of actions on that content, though the actions that you can perform on one kind of content are inconsistent with the actions you can perform on another. Twitter has fewer types of content, and a more consistent set of HTTP-like actions to perform on that content.

The Facebook API tends toward the baroque and insular, while the Twitter API tries its best to be a part of the web. In general, the Twitter API is much more straightforward.

I think this simplicity—this paucity of nouns and verbs—has been an important factor in Twitter’s widespread growth among both users and developers.

Developers can be confident that—even if Twitter’s API changes—they’ll still be doing mostly the same actions (getting, posting, updating) on mostly the same things (statuses, friendships, direct messages). Users know exactly how all the moving parts of Twitter work together, and are therefore better able to understand how a given application might augment that.

On Facebook, the opposite is true. User statuses, notifications, event invitations, feed stories, photos—they all have different interfaces and behave in different ways. Even long-time developers can’t keep track of how everything works together.

Interestingly, Facebook’s platform roadmap says that one of Facebook’s goals is to “focus [...] communication on the stream and Inbox,” which will make communication on Facebook feel much more like Twitter. I think this is a smart move—anything that simplifies the user’s model of how communication on Facebook works is a good idea, both for users and developers.

Tags: ,

longestpoem

The procedure: scrape Twitter’s public timeline and find rhyming couplets. The effect is striking: even though the juxtaposition of tweets is essentially random, the presence of rhyme gives them a strange cohesion.

The only obvious weirdness comes when the procedure tries to rhyme emoticons, as in the following couplet:

Finished a paper for class and time to relax. Yay me!!
Showered and feeling good :) How are y’all smelling? :b

On second thought, I like that: it’s as though the procedure suggests you read the emoticon aloud in a cutesy way (“time to relax, yay me! / … how are y’all smelling? colon lowercase bee”).

(via)

Tags: , ,

Murmur Study

Murmur Study from Christopher Baker on Vimeo.

Murmur Study is a physicalized reading of Twitter, created by artists Christopher Baker and Márton András Juhász. (More details and photos.) The process, according to the artist’s site:

This installation consists of 30 thermal printers that continuously monitor Twitter for new messages containing variations on common emotional utterances. Messages containing hundreds of variations on words such as argh, meh, grrrr, oooo, ewww, and hmph, are printed as an endless waterfall of text accumulating in tangled piles below.

I’m not quite sure I understand the reason to single out tweets that match those particular text patterns—how is this format more appropriate for illustrating the mass of “emotional” tweets? (as opposed to tweets about kittens, tweet spam, tweets from political figures, tweets about thermal printers, etc.) Stunning in its scale, nevertheless.

See also: bitfall and Simanowski’s keynote from e-poetry 2009 (not linked, because I can’t find a link).

(via rhizome.org)

Tags: , ,

Hulu – The Tonight Show with Conan O’Brien: Shatner Reads Palin’s Tweets.

Here we have an example of politician talk satirically repurposed as poetry. The practice itself is nothing new (see Donald Rumsfeld), but Shatner’s performance here is a cut above.

These tweets form the text as performed: “From sealife…”, “Tourists from across…”, “Awesome Alaska night…”, “Left Unalakleet warmth…”. It’s interesting that Conan claims the text to be “verbatim,” even though it’s a collage of many non-contiguous tweets.

Tags: , ,

(NOTE: This project is currently out of commission as I find a new place to host it and adjust the code to accommodate recent changes in the Twitter API.)

My day 2 project is called twbasic. It’s an implementation of classic, line-numbered, home computer-era BASIC that runs on top of Twitter. You can start using twbasic right now by twittering your program listing to @twbasic. Here’s how to get twenty rolls of a six-sided die:

@twbasic 10 for i = 1 to val(ARG$)
@twbasic 20 print rnd(6) + 1
@twbasic 30 next i
@twbasic run 20

(The above screenshot depicts twbasic providing a listing of the program above, and then the results of running the code.)

A reference for using twbasic can be found after the jump.

Read the rest of this entry »

Tags: , ,