Skip to content

Twitter Misses the Mark with Mentions

Unmentionable!

Unmentionable!

When Twitter changed their reply functionality, now called mentions, my initial reaction was unmentionable.  After a few weeks to ponder and play with it, I still think they made a big mistake.  A reply was originally a message that began with a twitter username, like this:

@zorak No, really?

Replies were public, but Twitter added a link so you could see just your replies and options to filter other people’s replies out of your friends stream.  According to the Twitter blog, the community came up with the convention that Twitter later embraced and enhanced.  Then Twitter added a separate API call and a “swoosh” button to their web site:

twitterswoosh

Just what I wanted! Twitter added metadata underneath so that a reply remembered which tweet it replies to.  Pretty soon every Twitter client included swoosh buttons and “in reply to” links.  This was a philosophical break for Twitter–whether they know it or not–because there was no way to distinguish swoosh and “@user …” via SMS.  Supporting SMS creates a larger potential user base, but it drastically limits functionality.  Until everybody has an iPhone, fledgling social networks like Brightkite must consider this trade-off.

The original reply syntax is still supported and continued to create confusion as Tweetie developer AteBits explained on his blog.  People put multiple names in the message or put the @ in the body of the message, assuming the right people would see the replies:

@me @myself @I Remember the milk.
Give @me some sugar, @baby!

Only @me sees the first tweet as a reply; nobody sees the second.  Search was already catching on thanks to other community-grown initiatives like hash tags; users and client developers began using search on @user instead of the reply API to catch such grammatically incorrect tweets.  Apparently this is a bad thing, or at least something Twitter discouraged, perhaps because of its impact on Twitter’s call throttling.  That and other scaling problems should make for a few good dissertations; I just hope Twitter is keeping the historical record and will be willing to share it.

This brings us to mentions which are basically just searches on @user.  Although it’s a good thing that Twitter learns from their community, the big mistake here was changing the functionality under the existing API calls.  I agree that instantly supporting new functionality in all Twitter clients is attractive to a provider, but it can–and did–create unintended consequences.  All those clients blessed with catching those malformed reply tweets were also cursed by all those side-bar mentions crowding the replies page.  Twitterati like @wilw get many more mentions than direct replies, and now there’s no easy way to sort out the two.

The lesson here is that it’s safer to create new API and UI elements for new-ish functionality and let the community migrate over than to replace the guts and hope nothing breaks.  As any API designer knows, developers will do all kinds of unexpected things once your API is released into the wild.  The Twitter community’s active, inventive role in shaping Twitter also provides for some real “They did what?” moments.  Tweaking reply functionality to support only swooshes and adding new methods for mentions would have made everybody happy.

There’s one thing I want from Twitter that they promise in the API FAQ; I want to see all replies for a given tweet.  I disagree the assertion in the Twitter blog post above that people don’t want to wander into the middle of an ongoing conversation.  Sometimes that’s the best way to discover new topics and interesting people.  When that happens, there is a need to go back and discover the source and all its tributaries.  Twitter is aware of the need, as this quote from the Twitter API Wiki FAQ shows:

How do I get all replies to a particular status?
For now, there’s not a great way to do this. We’ve heard the requests, though, and we’ll be providing a solution for it before too long.

Conversation functionality is cropping up in Twitter clients like Nambu and the soon-to-be-released Tweetie for Mac (20 April 2009).  Looks like Nambu constructs conversations based on cached tweets, building little trees as it discovers reply pointers to other already-fetched tweets.  This single-linked list structure makes it easy to find your immediate predecessor but difficult to walk up, across, and back down the tree.

Hmm, where have I seen this problem before?  Oh yeah, version trees in Documentum.  Every document remembers its immediate predecessor (i_antecedent_id) and the root of its version tree family (i_chronicle_id).  A single query on i_chronicle_id returns every version of that document.  That’s just what I want Twitter to do!

Twitter already has its own i_antecedent_id–with a better name I hope.  So add an equivalent to i_chronicle_id and a new getAllReplies API call.  I suggest topic_id since that’s what the root tweet of a tree of replies becomes.  It would be nice to go back and stitch up all the previous replies-of-replies, but I would understand if the hit on the database would be too big.  How many tweets are in there anyway?

Posted 19 April 2009 † john.kominetz § Articles ‡ Comments (0) ° Tagged: , , ,

Word to XML, Then and Now

The Scream by Edvard Munch

The Scream by Edvard Munch

I was lucky that last month’s XML Philly meeting didn’t trigger my post-traumatic stress syndrome. Quark’s presentation on their XML Author product took me back to the front lines, having done something similar with Word and SGML over a dozen years ago.  Quark says it always produces valid XML for any schema.  I can testify that it’s no small feat if true:  Although Word now produces XML directly, it’s a generic schema that represents formatting, not semantics.  Wasn’t this the schema Microsoft wanted to patent as a part of their contribution to “Open Standards”?  Anyway, this is still a hard problem with no obvious solution.

Their secret is that the plug-in completely replaces the implementation of the Word data model.  XML is always valid because users are always working in XML; there is no messy conversion between the flat, unstructured Word model and the deep, structured XML model.  What XML Author gets from Word is the familiar GUI and a clear list of features to support, like Track Changes.  In theory, this gets around several common XML acceptance problems:  Users don’t have to learn a new interface, and business owners don’t have to pay for two separate word processors on everybody’s desktop.

Both justifications fall apart under closer scrutiny. Authoring XML changes how users work due to structural requirements; in particular, cut-copy-paste between vanilla Word or different schemas requires skill and patience because of the always-on validation.  Although users won’t have extra icons on their desktops, the business will have to cough up significant licensing fees that will feel like having two separate, high-end products installed.  Quark was also pushing their professional services for getting things up and running–both an added cost and an indication that things aren’t as simple as they seem.

Then there’s the question that always comes up at these meetings:  What if you share XML documents with people outside your company? There might be something webbie in the future, but for now let’s not even go there.

We didn’t get a live demo of the product, and an acquaintance who evaluated it warns that it’s not ready for prime time if your business depends on complex XML or heavy-duty Word features.  I would also be wary of the product constantly lagging behind Word features because it is essentially a reverse-engineered product, and it’s an acquisition that Quark’s still trying to fit into its existing product line.  Still, it’s easier than trying to mimic, maintain, and synchronize XML structures in actual Word documents.  I have the scars to prove it.

Posted 06 April 2009 † john.kominetz § Articles ‡ Comments (0) ° Tagged: , , ,

The Origin of Species of Information

Happy Birthday Chuck! You've given me so much!    Happy Birthday Chuck! You’ve given us so much!

Last night’s Philadelphia XML Users Group was a pleasant mix of the old and the new: Jim Caine of Jaquette Consulting revisited an earlier talk on content reuse that touched on DITA and Documentum among other things.

Named for today’s birthday boy, the Darwin Information Typing Architecture (DITA) is a simple XML application (in the xml sense) that models information around authoring units like topics and references instead of publishing like documents and books.  It’s meant to be extensible (in the OO sense) rather than definitive.  Somehow DITA never crossed my path until a few months ago, but it represents another step towards the Grail of structured authoring/publishing that I worked on 15 years ago.

Jim’s project involved moving an insurance institute’s learning resources into a single repository and allowing them to create a variety of products (real books, eLearning, flash cards, etc.) from the same content.  The project started last year; Jim first presented on the project back then and gave the group a look at how practice deviated from theory.  He did some really smart things to facilitate reuse like referencing XML wrappers for external entities like images. This allows reuse of data and the metadata.  Kudos to WordPress for a similar albeit not XML approach to images and galleries. I’ll post a link to his presentation when it hits the web.

Turns out that authoring structured content is still the hard part.  The original plan involved a Word plug-in to allow authors to create valid structured content at the very beginning.  This good idea hit some bumps because of vendor support issues and was the hardest conceptual change to make in the whole process.  Authors used to writing a single document now wrote up to a dozen separate learning objects, a subtype of topic.  Deja vu all over again.

A very few actors in the content creation process have a very lively editorial cycle.  We’re talking major rewrites, not “you missed a comma here” kinds of things.   This wasn’t a problem back on RDMS: We dealt more with multiple authors and a review process than the more traditional author/editor interaction going on here.  Even in legal review and approval, I’m used to all actors being subject matter experts, often getting more experty the further along in the lifecycle you go.  Not so in this case–and publishing in general I’d guess.

Here comes more deja-vu-all-over-again:  The plugin couldn’t handle the actors’ heavy dependence on Word collaboration features like Track Changes.  It’s easy to get lulled into a false sense of security by an oh-so-pretty model for the final product of the authoring process. That Emerald City architectural view of content hides all the information and processing necessary to get to that end.  This particular problem has sparked some heavy flirtation between authoring, wikis, and DITA happening in my head, just in time for Valentine’s Day.

Jim’s use of XML Applications (in the Documentum sense) worked well with DITA’s topics and maps.  No big surprise there, but the marriage of DITA maps and Documentum virtual documents came with the usual toilet-seat-down relationship problems, especially because of webtop’s weak handling of virtual documents.  A post-editorial staff using XMetaL bears the brunt of the bickering, so authors are  left to worry about intellectual property, not scaffolding, as it should be.

Most of my work lately has centered on document dumping grounds.  Records management, eDiscovery, and transactional content management don’t concern themselves with the processes of actually making content.  It was great to see what’s happening on the other side again, and I’ve been stupid for not attending this group sooner.  Such is the life of a freelance.

One special note: The Users Group had brownies for Valentine’s Day.  Mmm, tasty!  I suggested that publicizing food at meetings might be some great marketing.  It might also require a bigger conference room for several reasons!

800px-brownie8x3

Posted 12 February 2009 † john.kominetz § Journal ‡ Comments (0) °