First Look: Orchestra

I met Gentry Underwood last week at the Social Intranets Summit in Vancouver, and took some time later on to take a first look at Orchestra, the task management tool from the company of the same name that he founded. Orchestra is styled ‘The to-do list that’s connected to everyone’, which doesn’t capture its value proposition perfectly, but pretty well, since Orchestra is so well integrated to email.

First Look

Orchestra is a task management tool: the only objects that can be created and shared are tasks, so it doesn’t quite stretch into the work media category. However, with just a small bit of additional effort — like supporting the notion of an activity stream, and plain vanilla text posts — Orchestra could compete with project-oriented work media tools like Yammer, Wrike and Huddle.

The app is very elegant looking, grouping tasks into ‘today’ ‘soon’ and ‘someday’ ranges:

The left column shows the various ‘lists’ — projects — that I created. ‘Work’ is selected, and two of the three tasks in that list are assigned to me, hence the number two. I assigned one task, ‘Write up Orchestra’, to my alter ego stoweboyd@stoweboyd.com.

I selected the ‘Bring tickets monday to Ignite’ task, and you can see the task information to the right. This task was created by forwarding an email to tasks@orchestra.com.

The text of the email is shown in the stream of status updates, along with other state changes. The email isn’t accessible directly, and there is no mechanism to create arbitrary emails from the tool. But it does send emails to those associated with the triggering emails, as a general rule.

The task name was taken from the first line of the email, which I wrote as this:

Bring tickets monday to Ignite !shhh

The ‘!shhh’ microsyntax tells Orchestra not to update the others who might be included on the from:, to:, and cc: lines of the email when the task is updated. Otherwise Orchestra assumes that those people should be notified a/ when the task has been set up, and b/ whenever the task state changes, such as someone completing it or commenting on it. That general rule makes it very simple to share Orchestra tasks with others if they are external users, and if they have accounts they will see the updates on the web or iPhone clients.

And there is a variety of other microsyntax in the triggering email:

Bring tickets monday to #Ignite — would add the task to the Ignite list

Bring tickets !today to Ignite — would timestamp the task for today

In that other task, ‘Write up Orchestra’, the other user does not have an Orchestra account, but can participate through email:

And when the external user agrees to take on the task by clicking on that box, that updates the status on the task, and brings the external user to a page showing the comments and other status updates on the task:

Turns out my comment in the image above was wrong. I did not need an account to fully participate on that one task, and Orchestrate did not give me visibility to other tasks in the project, just the one I was asked to take on. That is a very interesting way to involve outsiders in complex and perhaps confidential projects.

Above is that same task viewed on the iPhone, where Orchestra has obviously invested a great deal of effort getting the form factor right.

Bottom Line

Orchestrate is a stylish, well-designed and email-oriented task manager. AS I said, just a small investment of time would push it squarely in the work media category, which it clearly wants to be in. In fact, merely adding a comment thread to each list would be enough.

The viability of task manager apps on the iPhone platform is very much up in the air, given what Apple will be providing in the iOS 5 Notifications, in just a few weeks, especially in concert with Assistant. Still Orchestra is a solid start, and headed in a good direction.

Stars: How Important Is This Piece Of Info?

I have started to adopt a convention — a tiny bit of microsyntax — across all the streams I am producing or curating. I am adding asterisks — stars — as tags, and the number of stars represents how important I think the material is. Always restricted to the range of [0..3] stars.

The purpose is manifold.

In a tweet — I haven’t used this much, yet, in tweets — my hope is that the number of stars will represent how important the information is that is referenced by a URL. I will only use these on tweets with a URL.

On my blog, people wanting to see those posts that I think are most important can click on any ‘***’ tag, or browse to www.stoweboyd.com/tagged/***. I haven’t gone back very far in time with these tags, but I will over time.

In the future I’d like to create a filter mechanism on my blog so visitors could filter out posts below some level of importance. For example, displaying only posts of two or more stars. (I will confer with the nice folks at Tumblr about how that might be concocted.)

In the long run, if more people were to use this Stars convention, it could be an interesting aid to curation, or just to help filter out the non-essential when you are time constrained. There are times when I want to read every item in my streams, but a lot of the time I would like to just see what others think is critical. As Clay Shirky says, it’s not information overload: It’s filter failure. So if we all were to honestly assist in the filtering it would help everyone.

By the way, this is a bottom-up, distributed take on Google’s +1, and other attempts to corral our social gestures, and make money from them.

[Update: 3 June — I have written a short description of why I decided to collapse this system to just one star for important information, and no stars to everyday communications and reportage. ]

Twitter’s New Retweet

My initial reaction to the announcement that  Twitter was going to implement the retweet (RT) microsyntax as a basic function of the platform was shock (see Project Retweet: When Ultrastructure Becomes Infrastructure). Retweets are created in a variety of ways — most importantly in a vague and imprecise way, with comments added — that I thought that nearly any attempt to pin the semantics of retweeting down would fail.

I am among the folks fooling with the new implementation of RT, and it works as advertised. Which means that I don’t think it adds much to the user experience. And it specifically does not allow me to add a comment to a tweet that I am retweeting, which is bad. Clicking the retweet never leads to a text experience with anything editable, so the richness of the RT experience is being drastically curtailed.

I guess there is some performance rationale for implementing RTs this way, since the initial tweet can’t be altered, and 100 retweets to the same initial tweet don’t create a hundred copies, but just a hundred pointers. This may be an implementation that is inherently better for tracking references, for example, but is also inherently worse with regard to communication between people.

I would like to see Twitter implement the RE microsyntax (see A Useful Bit Of Microsyntax: RE), as part of the RT overhaul. A RE — as implemented currently in Tweetdeck — is like a RT, but doesn’t copy the text of the message. Instead, it has a pointer to the original message (in Tweetdeck this is encoded as a short URL), and then the remaining characters are available for making a comment:

RE http://bit.ly/892d6 I disagree with @gregarious about daylight savings time

Of course, within Twitter, the URL would not have to be exposed and could be part of an internal implementation. But the idea of a RE could be paired with the new retweet as a second tweet, associated with the retweeted message, and then displayed as a pair, like this:

gregarious I really like when the clocks change

about 2 hours ago from Twitter

Retweeted by you

      stoweboyd: I disagree with @gregarious about daylight savings time

Perhaps more interesting would be if a number of other folks retweeted @gregarious’ post as well:

gregarious I really like when the clocks change

about 2 hours ago from Twitter

Retweeted by 3

    stoweboyd: I disagree with @gregarious about daylight savings time

    themaria: he sleeps all day anyway

    brianthatcher: I never come out in the light of day

I don’t hold out much hope that Twitter will be stop, and to take ideas like these and incorporate into the current plans for retweet. They have gone a long way down a cul de sac, I fear, that will in the long run decrease the richness of our interactions on Twitter. Perhaps the howling from the user community when this is rolled out will get them to reconsider it.

My prediction is that people will revert to manually copying and pasting messages when they want to do something more than just a blind retweet. So we will have two contending sorts of RTs — classic RT v new RT — until the Twitter folks get around to implementing something like RE.

Project Retweet: When Ultrastructure Becomes Infrastructure

The Twitter retweet convention — where a user copies the text of another’s tweet, prefixes an ‘RT @another’ on the front, and then posts this amended copy — has become commonplace, widely supported by Twitter clients as a single mouseclick. However, Twitter has resisted making this convention part of the Twitter platform as a core primitive.

Note that ‘@username’ was at one time a convention, used to draw a specific user’s attention to a tweet, but the Twitter folks quickly saw the utility of that as a means of communication, so they rapidly incorporated that into the platform’s design. And retweets are becoming a metric used to determine the relative influence of twitterers, along with follower count, more or less playing the role that links play in the blogosphere.

Now, they have decided it is time for the microsyntactic convention of ‘RT’ to join ‘@’ in the infrastructure:

Project Retweet: Phase One - Biz Stone

Some of Twitter’s best features are emergent: people inventing simple but creative ways to share, discover, and communicate. One such convention is retweeting. When you want to call more attention to a particular tweet, you copy/paste it as your own, reference the original author with an @mention, and finally, indicate that it’s a retweet. The process works although it’s a bit cumbersome and not everyone knows about it.

Retweeting is a great example of Twitter teaching us what it wants to be. The open exchange of information can have a positive global impact and the more efficient dissemination of information across the entire Twitter ecosystem is something we very much want to support. That’s why we’re planning to formalize retweeting by officially adding it to our platform and Twitter.com.

Biz goes on to state that they will begin tooling an API with RT capabilities included, so that developers of Twitter applications can start to think about integration with this new capability.

Most important, Biz spells out how the user experience is supposed to work, and clarifying that RT will continue to work much as it has in the past. In other words, if you are following me and I retweet something from my friend @gregarious then you would see the retweet even if you aren’t following @gregarious yourself.

Why is this important? Because it supports the convention as it has emerged. It would be easy for Twitter to coopt the convention and make it work in a different fashion. In particular, they could have adopted the same model of visibility that they implemented in their last reworking of ‘@’ replies (or mentions), which is widely referred to as #fixreplies. In that case, the Twitter team decided that the way that ‘@’ had been working was annoying. In the older approach, if you were following me and I replied to my friend @gregarious then you would see the comment I made to him even if you weren’t following him. They changed these semantics so that you would only see the comment to @gregarious if you were following him too.

The logic of this is that some part of the Twitter community expressed the view that this was creating a noisy and confusing stream, because a lot of tweets would be directed to people they weren’t following, so they would only see half of these conversations.

Others — me included — suggested that the convention had emerged in the way that it had, organically, and it has many interesting properties, not the least of which is that users would see part of a conversation and then might visit the other half’s Twitter page to see the rest, and then perhaps start following that other person. When the half conversations are taken away, you might never know that the other half was there at all.
Twitter might have made this some sort of opt-in or opt-out feature, but they argued they could not think of a way to do so efficiently. They have waffled, suggesting they might revisit this in the future, but it is all very opaque.

It’s worth commenting that various counter-conventions have emerged to circumvent the restricted semantics of “@’, which is why you see ‘.@’ used widely now. Twitter does not recognize this as a @reply, so if I post ‘.@gregarious wake up!’ all my followers get to see it, and know that @gregarious has overslept.

However, retweets won’t look the same: the ‘RT’ and the ‘@username’ will not appear in the text portion of the retweet. These will become metadata, displayed in some other fashion. On one hand, this helps a great deal with the text squish problem, where adding ‘RT @gregarious’ at the front of a message may lead to the original message no longer fitting. On the other, though, the retweets might not stand out as they do presently. Designers of Twitter clients will simply have this as another design challenge, and I am sure that they will rise to the occasion.

And the last, and most serious issue in this reimplementation of retweets: the comments that people put on retweets won’t be supported. This is a serious shift away from the everyday convention:

RT @gregarious My head is killing me. | Yeah, take an aspirin.

where the text after the ‘|’ is a comment left by me. Other ways of offsetting comments are in use, like ‘<—’, ‘«’, and so on.

Twitter’s aim is architectural in an obvious way: they want to simply point at the original tweet from every retweet instead of creating 5000 slightly mangled copies.
But they are going to have to extend their implementation to allow users to leave an (optional) comment. Perhaps a second 140 character tweet twinned with the retweet? The outcome of this would be interesting since the comments added to the original tweet could be aggregated, like the chat in Friendfeed, although participation in the chat would still be distributed.

At any rate, this is the rub: if Twitter takes away our ability to comment on the retweets, people will start running around outside the implementation to get back the capabilities that have been taken away.

When the company behind a platform decides to take a user convention, like ‘RT’ and implement it as part of the infrastructure it is pulled from the ultrastucture, where the users live and invent. If the implementation doesn’t fit the contours of use that have become convention then there is a misfit. This misfit could be a gap, where less than the convention has been implemented. And a gap like that leads to a thunderclap, just like the vacuum caused by a lightning bolt creates a vacuum in the sky, and the surrounding air moves in to fill it.

I am hoping that the feedback from the community and the client developers will lead them toward a solution to the retweet comment problem before it actually surfaces. Biz stated that this would be phase one of Project Retweet, but I hope they aren’t planning to defer the comment issue to phase two.

[Other analysis: Jennifer Van Grove does a good job laying out a wish list for various sorts of filtered timelines based on a systemic RT, as well as the downsides of the new RT.]

A Useful Bit Of Microsyntax: RE

The new release of Tweedeck was released yesterday, and Iain Dodsworth and crew implemented (along with a long list of other new features and improvements) a small bit of microsyntax that he and I discussed a month or so ago: RE.

RE is based on the everyday notion of a RE — ‘in reference to’, or ‘with regard to’ — that business folks have used for decades in memos and email.
In the Twitter context, RE is similar to and complements RT. RT, as we all know, makes a copy of a tweet, and creates a ‘@username’ reference to the author of the original tweet, and prepends a ‘RT’ indicator at the start. RE, on the other hand, creates a URL that points to the original tweet, and does not copy any of the original tweet, and prepends ‘RE’ at the start.

The idea is that the user creates a RE with the intention of commenting on whatever the original tweet contained. Imagine that my pal @gregarious has tweeted something like this:

I think Jeff Pulver’s #140conf sounds great. Wish I were there.

and I might RE in this way

RE http://bit.ly @gregarious is one of many who wishes they could have attended the #140conf this week

Location, Location, Location: More on /Location and Microsyntax

It has been an interesting few days, since I posted A Modest Proposal For More Microstructure: Twitter /Locations, in which I presented the idea of a new sort of syntax for Twitter (or microsyntax) to represent location. Instead of tweeting this

Just landed at SFO headed downtown ASAP

tweeple could instead post this

Just landed at /SFO headed downtown ASAP

The idea being to have a human- and machine-readable to indicate location. Longer locations involving multiple words would be set off with trailing ‘/’ as well:

Working at /156 South Park, San Francisco CA/ this morning

This proposal has led to a great deal of feedback, ranging from ‘Cool, let’s build an app to try this out’ to ‘You’ve gotta be kidding’ and everything in between.

Perhaps the most organized arguments against the ‘geoslash’ idea (as Ross Mayfield and the WhereCamp folks are now calling it) are those offered by Ralf Rottman, whose post is entitled No additional Twitter meta tags, please!, which gives you a pretty good feel for his position on the subject.

Rottman uses the term ‘meta tag’ to represent what I am calling microsyntax (formerly I called it microstructure, but that is a bit less specific). Meta tags in HTML are various sorts of information buried in specific HTML elements, and these are intended to be machine readable, and not generally to be inspected by people. My goal with /location is to insert a small bit of punctuation in the tweet, which is human readable as well as machine readable.

His primary argument against microsyntax is clutter, which, he says, is already causing readability issues with usernames, shortened URLs and hashtags that are already in wide use. My answer to that is that people are trying to make Twitter workable, and these conventions have arisen to serve a need. Despite what the Sunday supplements are saying, most Twitter messages are not ‘just ate a pickle’, but are more likely to be something like ‘@ross Check this out, and get back to me http://bit.ly/vv1zC #passwords’. People are getting things done, not contemplating their navels, and if that means slightly greater complexity and lumpiness in the twitter stream, so be it.

The rest of his argument is really a tirade against the Twitter architecture. He wants metadata pulled out of the text of Twitter messages and supported in an invisible exterior way by a new Twitter plumbing:

But there is another not so philosophical reason why we should not go further with any of these suggestions: Fundamentally hashtags, @usernames and Stowe’s newly suggested location tags are merely workarounds for limitations of Twitter’s API.

Twitter essentially provides a real-time messaging infrastructure. Not more and not less. Twitter’s attempts to provide additional added value beyond being a free large-scale message pipe have yet to prove successful. The IT folks at Twitter already seem to experience severe technical challenges when it comes to implementing higher value features like conversational tooling and openly admit that it’s getting more and more difficult to address these advanced needs given the large scale user base Twitter has grown to.

Concepts like location, language, keywords and identity are obvious candidates when thinking about messaging and communication in general. It is somewhat astonishing that the Twitter API does not yet provide any good means for third parties to leverage these aspects. Instead we have to use hashtags to mark keywords, might use slashes to tag location and maybe sooner or later somebody will suggest using curly braces to mark products and brands.

As Steve Jobs uses to say: There must be a better solution.

One alternative could be to wait for the folks at Twitter to enhance their API. Developers of Twitter clients could then access a tweet’s meta properties like language, keywords, location, brand and other structured information simply by parsing the JSON or XML returned by calls to Twitter’s REST interfaces. For various reasons I’d not put my money into this one. As Twitter Co-founder Biz Stone stated earlier this week, one way of turning Twitter into a profitable business could be to provide richer tooling.

Combine this with the fact that it will never be in Twitter’s best interest to become a truly open social platform (”open” as described here by Chris Messina) I would rather expext them to make it even more difficult for third parties to easily enhance Twitter based services. Their stupid 100 requests per hour limit is a clear expression of how they plan to keep in charge (though they might continue to claim that technical scalability reasons force them to keep it up).

I suggest that Ralf take these recommendation up with the nice folks at Twitter. In the mean time, bitheads like me will continue to offer up ways to encode intention or meaning into the twitter stream, for any number of reasons. In the case of /location, my goal was simply to make it easy for a relatively dumb Twitter appliance to keep track of users” locations over time, based on the Twitter that exists today.

Other feedback:

• Many asked about the use of ‘/’ and argued for other characters — ‘/’ is an interesting sort of punctuation mark. It is not used in a wide variety of forms likely to be common in Twitter. It is found in URLs, but not as the leading character. It is used in alternatives, like ‘contact me by email/dm’ but again, not as a leading character, in general. It is easily reached on cell phones and other mobile devices because it is needed for URLs. I therefore think it is preferable to parentheses, colons, asterisks, and other suggestions made. In particular, ‘^’ is already in use as a convention for identity — initials of authors in group or corporate Twitter accounts.
• Lat Long — I think lat long is interesting for machines, but I can’t parse it so it’s not in the same category.
• URL — Some have suggested use of a URL like http://sent.fm/san+franciso, which translates to a page at that service, but I am opposed for three reasons. First, I don’t like the idea that some service gets all the links (same argument I had years ago about Technorati and tags, when I argued for Open Tags). Second, the URL takes up a lot more characters than two slashes does. Third, it doesn’t read like everyday speech.
• People have asked about ‘l:’ and other proposed conventions — I don’t like ‘l:’ because it interrupts my scanning of language more than ‘/’ does. I don’t like the notion of taking over alphabetic letters to perform punctuation duties. That’s one of the reasons I dislike ‘RT’. Besides, ‘l:’ has been around and hasn’t caught on: time for another experiment.
• Some have suggested that smart apps should just read everything, scanning for location information. First, that could be very computationally intensive, and second, not all discussions about location mean that the author is asserting actually being there.

  I wish I were in Paris

  is different from

  Just pulled into the train station in /Paris, France/

  It is the latter case that I am interested in. Also, something like this

  Just read that the #WhiteHouse is against sunflower seeds

  is very different from

  Taking the tour of the /White House, Washington DC/. Hope to meet Barack!

Ross Mayfield and some folks at the WhereCamp this last weekend are working on an app to parse /location from tweets. More to follow on that front. I know there are other developments going on in that direction, too.

A Modest Proposal For More Microstructure: Twitter /Locations

[Update 14 December 2009: I have adopted Ross Mayfield’s term ‘geoslash’ in place of ‘location tags’. See Geoslash at Microsyntax.org’s wiki for a fuller explanation.]

Hashtags (Twitter tags) were proposed by Chris Messina, and in use by Chris, me, and others before tools existed to do much with them, aside from search. In similar fashion, I am proposing a new sort of microstructure, just a little bit ahead of tools to support it.

The idea is similar to tags: use a distinctive character to set off some microstructured metadata, although in this case, the metadata is location, and the character is ‘/’, the slash.

Imagine I posted this on Twitter [as I did yesterday]:

stoweboyd Just landed at /JFK

The intention is obvious: to indicate /location. And, of course, imagine that Twitter-smart applications can consume this stream of /locational cues and do interesting things with them. I am involved in the development of one such application, but certainly anyone can exploit this information, if and when the Twittosphere wants to start microstructuring this way.

I also looked and ‘/’ is easily accessible on cell phones, which is an important issue, considering the ‘just arrived in an airport’ or ‘hanging out in a bar’ use cases.

Unlike Messina’s tags, I am proposing that multiword locations be indicated with a closing slash, like this, that I posted yesterday:

stoweboyd hanging at /Starbucks, 93 Greenwich Ave, NYC/

This way we can avoid all the problems with one word indicators. (I wish we could have avoided this with Messina’s tags, too, as I wrote way back when.)

There are other aspects of /locations that I am working on with my partners, about which more to follow. My first hope is to get a basic convention out there, and existing search mechanisms can be tweaked to do the right thing with the format of /locations.

A last note: some people have used tags as stand-in for /locations, but I think that is wrong. Tags are better thought of as concepts, while location is very tangible. More importantly, the use cases — while they may have some overlap — are very different.

For example, If I see a tweet with /White House, Washington DC/ that means the place, and not the conceptual overtones of #WhiteHouse, which probably is part of a political discussion. The same holds with /French Laundry, Napa CA/ (the place) and #FrenchLaundry (the cuisine or experience), or /Evian (the place) and #Evian (the water).

So, I invite everyone to start localizing with /locations. I promise you a Twitter appliance to make sense of them is on the way.