Dates in Tags

Many conferences and events follow a simple principle. They use a short tag for twitter (e.g. #dpc) and a full tag for less real-time content (e.g. dpc09 on Flickr or blogs). It's not a rule that's set in stone, but it kind of emerged as a best practice based on people's experiences. Other conferences stick to one tag, such as "phpuk2009" last friday.

For those that don't adhere to this best practice, here are the most important reasons for doing so:

  • You only have 140 chars on Twitter. The shorter your tag, the more actual content you can add.

  • Many attendees use a phone to tweet, and many phones use a T9 editor. Again, the shorter the better. Also, entering a year such as '2009' not only requires 4 key presses, it requires 4 'hold' keypresses on many phones, or it requires the T9-editor to be set to numeric mode first.
  • Findability. This morning I was trying to find blogs and pictures from #phpuk2009. Because the same tag was used on all media, the blog posts were hard to find between hundreds of tweets in the Google results. While it's interesting to find those as well sometimes, their real-time nature makes it much less interesting as a search result once the event is over (and it's far more easier to use search.twitter.com to view them in the correct order.

To sum up a few counterarguments:

  • When you search it's hard to distinguish between different installments of the event. While I'd say that in blogs and Flickr and other things you would search through Google that is true (I recommend always adding '09' to tags there), for Twitter that is not an issue, because your search is always in order of date anyway.

  • "I have phone X, it's really easy to add the year to any tag." Sure, but not everyone has phone X.
  • For conference organizers, it's harder to scan the web for relevant content if different tags are used. Actually that's not the case: it's easier to find relevant non-realtime content and relevant realtime content when 2 different tags are used. See 'Findability' above.

There is a group of people that takes this a step further; they argue that a date should never be added to any tag, because appending a separate year tag makes it much more flexible (e.g. #dpc #2009). That's an interesting approach too, but makes it slightly less convenient for my taste (and generally requires even more characters), so I'll stick to #short for real-time content and #full09 for normal content.

What do you think?

Tags: , , , ,

11 Responses to “Dates in Tags”

  1. localjoost Says:

    I would definitely say: don´t use a date in the tag. I don’t think you need it because almost every app where you can tag your data like this will also show when it was created so there really is no use adding it.

  2. Nick Belhomme Says:

    Short tags without date have my preference. I only uses them from a client perspective, and for me usability is gold. So every char I do not have to type is a plus.

  3. Tess Says:

    Short and no date for platforms with strong dating models already built in and long with date in such things as blogs and pages where dates are not consistently shown or stored independently of content.

    So basically, I agree.

  4. BinaryKitten Says:

    I think that using a date is good for somethings .. like defining which one you are looking at. But the shorter the better like #phpuk09 is better that #phpuk2009 but #phpuk would still have been as good.

  5. Rick Says:

    I like short tags for twitter, but I really hate ambigious dateless tags when it comes to Flickr, blog posts etcetera. Basically it’s just a Twitter problem.

  6. Matt Raines Says:

    Interesting. I’m reasonably sure you’re right, but… what about the counterargument that by promoting multiple different tags for different uses on your event website you would end up confusing people? Wouldn’t you then have to search for both versions of the tag with or without the date on Flickr to see all the pictures?

  7. Dave Nattriss Says:

    My thoughts:

    a) With the conference on Friday, I chose to ask people to use phpuk2009 because:

    1) it was an annual event, so the year is what sets it apart from other events in the past and future
    2) phpuk is too generic. Without the year, or perhaps ‘con’ or ‘conf’, you wouldn’t know it was an specific event, you could just be referring to something to do with PHP in the UK.

    In hindsight, maybe phpuk09 would have been better, but we’d been using ’2009′ in all the other event branding and it wouldn’t've been consistent.

    b) You can tell Google to exclude a specific site in a search if you want, and usually Google will only ever show 2 pages from one host anyway. So I’m confused how hundreds of tweets were coming up amongst blog posts etc. And in any case, how Google decides to rank results is not the fault of the tag being used.

    You’re right that realtime tweets are less interesting after the event, which is why it was important to have the year in there, so that next year, when you search for phpuk2010, you won’t get all the 2009 tweets!

    c) If you’re tweeting from a device that only has T9 input, you’re going to have loads of problems already. Numbers are standard characters – they’re allowed in URLs, domain names etc. It’s a T9/device fail.

    d) Twitter’s 140 character limit is one of many massive problems the service has. SMS limits (of 160 characters) only exist because of the GSM technology that is 15 years old, and was superceeded by MMS a long time ago. MMS sadly has never really taken off though because the network operators charge a fortune for messages, instead of including them in your standard data quota. In any case, Twitter is rarely used by SMS now, and so the 140 limit has no use. In fact, the 140 doesn’t even make sense – they left 20 spare for the name of the tweeter and a colon and space, but what if their name is longer than 18 chars?!

    So while I agree that tags shouldn’t be ridiculously long, it’s Twitter that needs to be fixed (i.e. longer messages allowed), not the tags.

    Other issues I have with Twitter, by the way, include:

    1) the way that @reply messages rarely make any sense to the people not involved, and it’s very hard to trace the conversations (there isn’t even a way on twitter.com to do an a-to-b conversation display, like you have the wall-to-wall page on Facebook). Although I generally think these are both bad ways to handle a public conversation anyway. Friendfeed, and even good old discussion forums and even the usenet handle this much better.

    2) As more and more people use it, people will have to take longer account names, which again leaves less space for message content, because of the unnecessary limit on tweets. This affects both @replies and ‘d’ direct messages. Why is it if I’m messaging Helgi (@h) I get 137 characters, but if I’m messaging thelondonpaper (@thelondonpaper) I only get 125? Can’t the protocol be updated so that at least the recipient (and whether the message is public or private) can be transmitted separately to the message?

    3) Links have to be shortened using third party services (why does Twitter use ‘tinyurl.com’ when ‘twitter.com’ is the same length?! It would take 30 minutes to set up a URL redirect system on their own domain!), which means that you have no idea what you’re clicking on when you see one in a tweet. Bad UI.

    4) Every other popular social network site has a built-in system for posting images (and usually videos and other content too), yet because Twitter have done nothing to theirs since launch, you have to use something like twitpic.com, which takes extra messing around/config. etc.

    I basically find it quite shocking that Twitter has left its service virtually unchanged since it launched in 2006 (I joined December that year). They’ve still not launched a revenue stream (charging companies for their accounts?), they haven’t touched the system, they’ve fallen over many times when demand has been high, and they pissed off a lot of people who learned to rely on SMS notifications which obviously couldn’t last forever as they cost a lot of money (estimate was $1000 per user per year). I use Twitter these days because it’s becoming de facto for realtime centralised public messaging, with the fundamental notion of one-way following (other networks usually require a two-way connection), but it’s no wonder that so many non-technical folks don’t really like or get it.

    By the way, just in case people didn’t know, you don’t actually have to put a ‘#’ on a tag in order to make it searchable in Twitter (or anything else). The hash is just there to tell Twitter clients, including twitter.com, to make the tag into a link to search.twitter.com (or the client’s own search mechanism). So if you’re precious about characters, don’t bother with a hash! Your tweets will still be found in a search.

    What would really help all this would be partial matching on searches (Twitter search doesn’t support this, surprise surprise) – so your query can be ‘phpukconf’ or whatever and you get all relevant content, or just ‘phpukconf09′ or whatever to just get stuff from this year’s event. Or if you search for just ‘php’, it would come up too. Essentially the issue here is hierarchy. It’s a PHP-related, it’s in the UK, it’s a conference, it’s the one for 2009 – all of those are important attributes.

  8. Chris Shiflett Says:

    Pave the cow paths! :-)

    #phpuk

  9. Cal Evans Says:

    Personally, I think it’s up to the conference organizer and that if they request a specific tag that everyone should honor their request regardless of whether they think it’s stupid or not. If they don’t request a specific tag then yes, #pavethecowpaths.

    As of me, we specified tags for ZC07 & ZC08. In both cases, we specified a separate tag for twitter and blog/flicker, etc. My personal preference is to use a short, generic tag for twitter and a date-inclusive tag for all others. So for DPC, the tags will be:

    * #dpc – twitter
    * dpc09 – everything else.

    The reason is simple, on flick, when I search, I want only this year’s photos, however, for twitter, things get buried in the time line so fast that there is little chance of confusion between yearly events.

    =C=

  10. Chris Shiflett Says:

    Cal, paving the cow paths refers to the tag selection. It means that you should make an effort to select the tag people are likely to use. (It’s fine to be wrong with your prediction, of course.) The end of your first paragraph seems to suggest something different, because not selecting a tag means not paving anything. :-)

    It’s also fine to think people should honor requests to the contrary, but doing so is a lot like complaining about people who ruin the grass in parks by not sticking to the foot paths. If the traffic along a particular path is heavy enough to ruin the grass, it is what it is. No amount of complaining is likely to change everyone’s behavior. It’s much easier to try to predict where people will be inclined to walk, and put the foot paths there.

    Also, tags are tags. If it’s really important to have a lot of meta data attached to something, and that data can only be represented by tags, use multiple tags. That’s the whole idea. Compound tags are never appropriate.

    Twitter and Flickr already keep up with date, and it’s easy to sort by date as well, so the use of a compound tag promotes inconsistency and excludes content from searches and the like.

    I’ll keep walking along the cow paths. Consider it civil disobedience. :-)

  11. Cal Evans Says:

    Hi Chris,

    Actually, #pavethecowpaths was more of a suggest to allow your users/attendees/consumers, to figure out the best tag and then you come in and formalize it after the fact, or just acknowledge it. Otherwise, you really wouldn’t be paving the cow paths, you would be predicting the cow paths.

    From a purely marketing point of view, the reason I suggest specific tags at a conference is so that I can easily identify the content users create. (yes, more of a cattle chute than a cow path)

    If we are honest though, it’s not hard to identify a blog post wrap-up of a conference without tags. Since most blogging platform support practically unlimited tagging, adding a requested tag to a blog is more of a courtesy than a problem.

    Flickr.com also supports multiple tags so as with blogs, it’s easy to be nice and go ahead and tag your content the way you want to and the way that is requested.

    So this really all comes down to twitter. It used to be difficult to search twitter and find how people tagged their content. These days however, with clients like twhirl or using RSS feeds based on search.twitter.com, it’s easy to find out how people tag their content when they don’t like your tag, as long as it’s a recognizable cow path and they’ve not just wandered off on their own.)

    So I stand by my original statement, I find it reasonable in most cases to honor the request to tag content with a specific tag. If they don’t give a tag though, I hope to meet you somewhere along the cow path. :) (Who knows, maybe Ivo will be there too)

    =C=

Leave a Reply