New microsyntax for Twitter: three pointers and the slasher

Slash balloons

Image based on Kevin Van Aelst’s original.
Update: These basic “tags” have been christened “slashtags” by Chris Blow. They are also now supported in Atebit’s popular Twitter client Tweetie 2 on the iPhone.

Since it’s apparently all the rage to design your own features for Twitter now, I figured I’d build on my success with the hashtag and crank out a few more.

All of these are simple conventions for adding more standard metadata to a post in a specific, uniform way.

The Slasher

First, I’ve decided to migrate from encapsulating my metadata in parentheses to using a slash delimiter (“/”), which, for shits and giggles, we’ll call “the slasher”. This saves you ONE character, but hey, those singletons add up!

Now, the pointers. “Pointers” are short words with different intentions. A group of pointers should typically be prefixed by ONE slasher character. You can daisy-chain multiple pointer phrases together, padded on both sides with one whitespace character. There should be NO space following the slasher. Hashtags should be appended to the very end of a tweet, except when they are part of the content of the message itself and indicate some proper name or abbreviation. Normal words that would be part of the content of a tweet anyway SHOULD NOT be hashed.

If this doesn’t make sense yet, don’t worry, just read on.

Via

Let’s start with via, the first “pointer”.

The concept is simple and already widely used: sometimes you want to give credit to someone (as part of the pay-it-forward link economy) for something they said or linked to, without quoting them verbatim (which is what RT or “retweeting” is for, in my estimation and use). Now, a lot of people already use the “via” keyword — in fact, it’s a setting in Tweetie, and looks like this in practice:

Tweetie with via in parens

My proposal is simple, but would look like this instead (note that there’s still no colon):

Tweetie with /via

Saves you one character when used with the slasher delimiter and doesn’t look half bad.

CC

Next is cc — or “carbon copy” — not Creative Commons! Of course, if you ever used email this one should be obvious. The job of the CC is to indicate someone you want to direct a tweet at.

I follow 1600 people — and it’s highly unlikely I’m going to see everyone’s tweets — and I don’t really make an effort to do so. In the off-chance someone specifically wants to get my attention, they can just CC me, like I CC’d my friend Lauren in this tweet:

Twitter / Chris Messina: It's like TripIt for ships ...

You’ll notice how, using the slash notation, you’re able to serially string together several pointer phrases: i.e. “/via @cshirky cc @laurendarby“.

By

The last one I’ll mention is by. As you can imagine, the “by” syntax is similar to “via” and “RT”, but not quite the same. It’s more like the cite or blockquote HTML tags in that they provide a simple way to attribute authorship for a longer-form piece — i.e. not from a status update or spoken utterance (that’s what RT and OH are for respectively).

Here, I’m quoting a passage by Dominiek ter Heide (@dominiek) that I took from a blog post that he wrote:

Twitter / Chris Messina: "Activity is the new oil + ...

So, why bother writing these up? Well, I never expect that anyone will follow my lead, but if they do, I’d like to spell out what I’m doing so they can more or less get it right. It seemed to work with hashtags, and these ideas proposed here are even simpler. Now, you might not expect that, one, two, or three characters in tweets would make that much difference, but when you’re taking about a payload that maxes out at 140, each scintilla must carry its own significance. As such, there is value in coordinating our language, and providing some basic guidelines that emerge based on behavior — so that we can encode more meaning into these little blips of communication.

I’ve started tweeting using these patterns and invite you to do so as well when it makes sense. If you have your own ideas for microsyntax, Stowe Boyd started a wiki a while back to document them, so feel free to contribute your own or improve or use the ones already proposed!

Losing my religion

Last January, writing on the problem of open source design, I said:

I’ve probably said it before, and will say it again, and I’m also sure that I’m not the first, or the last to make this point, but I have yet to see an example of an open source design process that has worked.

Indeed, I’d go so far as to wager that “open source design” is an oxymoron. Design is far too personal, and too subjective, to be given over to the whims and outrageous fancies of anyone with eyeballs in their head.

Lately, I’m feeling the acute reality of this sentiment.

In 2005, I wrote about how I wanted to take an “open source” approach to the design of Flock by posting my mockups to Flickr and soliciting feedback. But that’s more about transparency than “open source”. And I think there’s a big difference between the two that’s often missed, forgotten or ignored altogether: one refers to process, the other refers to governance.

Design can be executed using secretive or transparent processes; it really can’t be “open” because it can’t be evaluated in same way “open source” projects evaluate contributions, where solutions compete on the basis of meritocratic and objective measures. Design is sublime, primal, and intuitive and needs consistency to succeed. Open source code, in contrast, can have many authors and be improved incrementally. Design — visual, interactive or conceptual — requires unity; piecemeal solutions feel disjointed, uncomfortable and obvious when end up in shipping product.

Luke Wroblewski is an interaction designer. He recently made an observation about “openness” that really resonated with me:

I read this quote last week and realized it is symptomatic of a common assertion that in technology (and especially the Web) “completely open” is better than “controlled”.

“But we’ll all know exactly where Apple stands – jealously guarding control of their users […] And that’s not what Apple should be about.” -TechCrunch

Sorry but Apple makes their entire living by tightly controlling the experience of their customers. It’s why everyone praises their designs. From top to bottom, hardware to software -you get an integrated experience. Without this control, Apple could not be what it is today.

He followed up with a post on Facebook’s design process today that I also found exceedingly compelling.

I worry about Mozilla in this respect — and all open source projects that cater to the visible and vocal, ignoring the silent or unengaged majority.

I worry about OpenID similarly — an initiative that will be essential for the future of the social web and yet is hampered by user experience issues because of an attachment to fleeting principles like “freedom” and “individual choice”. Sigh.

I’m not alone in these concerns.

When it comes to open source and design, design — and human factors, more generally — cannot play second fiddle to engineering. But far too often it seems that that’s the case.

And it shouldn’t be.

More often there should be a design dictator that enters into a situation, takes stock of the set of problems that people (read: end users) are facing, and then addresses them through observation, skill, intuition, and drive. You can evaluate their output with surveys, heuristics, and user studies, but without their vision, execution, and insane devotion to see through making it happen, you’ll never see shit get done right.

As Luke says, Most people out there prefer a great experience over complete openness.

I concur. And I think it’s critical that “open source” advocates (myself included) keep that at top of mind.

. . .

I will say this: I’m an advocate for open source and open standards because I believe that open ecosystems — i.e. those with low barriers to entry (low startup costs; low friction to launch; public infrastructure for sustaining productivity) — are essential for competition at the level of user experience.

It may seem paradoxical, but open systems in which secretive design processes are used can result in better solutions, overall.

Thus when I talk about openness, I really mean openness from an economic/competitive perspective.

. . .

Early today I needed access to a client’s internal wiki. Having gone without access for a week, I decided to toss up a project on Basecamp to get things started.

When I presented my solution to the team, I was told that we needed to use something open source that could be hosted on their servers. Somewhat taken aback, I suggested Basecamp was the best tool for the job given our approaching deadline..

“No, no, that won’t do,” was the message I got. “Has to be open source. Self-hosted.”

I asked them for alternatives. “PHProjekt“. Double Choco Latte. I proposed Open Atrium.

Once again, as seems all too common lately, more time was devoted to picking a tool rather than producing solutions. More meta than meat. Worst of all, religion was in the driver’s seat, rather than reality. Where was that open source pragmatism I’d heard so much about?

Anyway, not how I want to begin a design process.

Ultimately, I got the access I needed — to MediaWiki. So, warts and all, we’ll be using that to collaborate. On a closed intranet.

In the back of my head, I can’t help but fear that the tools used for design collaboration bleed into the output. To my eyes, MediaWiki isn’t a flavor that I want stirred into the pot. And it begs the question once and for all: what good can “open source” bring to design if the only result is the product of committee dictate?

Inaugural Jelly! Talk this Friday: OpenID vs Facebook Connect

Jelly TalksThis Friday, I’ll be joined by Dave Morin (my good friend from Facebook) at the first ever Jelly! Talk at Joe and Brian’s loft in San Francisco.

If you’re not familiar with Jelly, you should be. I call it the “gateway drug to coworking” — but it really has its own culture and identity independent of coworking, though both movements are rather complementary. Amit Gupta got Jelly started at House 2.0 in New York City back in 2006 (about two months after I initially expressed my desire to create a coworking space in San Francisco). Since then, like coworking, it’s grown into a self-sustaining movement.

Jelly! Talks is an interesting expansion on the concept — where Jellies distributed throughout the world can tune in to hear interesting and relevant talks and interact with speakers, similar to what the 37 Signals guys do with their “Live” show.

This first show I’ll be talking with Dave Morin about the relationship between OpenID and Facebook Connect — and where the two technologies are headed. This should be a pretty interesting conversation, since I’ve long tried to convince the folks at Facebook to adopt OpenID and other elements of the Open Stack (hey, they’ve got hcard already!).

Apparently the event is physically booked up, but you’ll still be to tune in remotely this Friday at 11am PST.

(Tip: The next Jelly! Talk will feature Guy Kawasaki).