That is the plan. Avi and I discussed all of your feedback at length yesterday and decided to change to multi-word comma separated tags.

The only question was when to do it, and in the end we decided it needs to be in the V3.0 release, else some folks get too used to space as a separator.

Neville

The sentiments expressed by you here and most of the others, seem pretty strongly in favour of natural language, i.e. space is a valid character within a tag, and commas are natural separators.

The *only* reasons to keep whitespace as a separator are:
- cross-compatibility with other systems that might not allow whitespace
- user experience with other systems that use whitespace as a delimiter

Neither of these seems sufficient to override the natural language and ability to use compound words that users want.

In other words: we agree with you, and intend to keep whitespace as a valid character within the tag, not as a separator.

Avi

The conclusion last expressed in @12 doesn’t seem to make sense.

It suggests that people don’t effectively use punctuation ["when you *look* at a text field full of tags (as in Surfulater) to my eyes each word looks like a separate tag"].

It will seem to keep us from using natural multi-word terms for tagging.

It will force us to use awkward and unnatural work-arounds like making the single-word tags from multiple words connected with some “special” characters (like the “_”, “-”, “.”, or capitalization shifts) that most everyone indicated they didn’t like.

Why not just take the tags to be whatever people enter between commas? Then no changes are needed to shift to multi-word tags later!

For folks addressing me (Neville) here, note that Avi wrote this blog post, hopefully the first of many.

Before I started work on Tags I did a lot of research on tagging systems and how people use tags. You will find that I’ve written more posts on the blog on tagging than on any other subject.

The bad news is there are no standard use cases for tags. Some allow single words, others multiple words. Some get you to enclose multiple words in quotes, others use a comma separator. Some only let you pick pre-defined tags from a list, others let you type them in and create new tags on the fly.

Rightly or wrongly most tagging systems only allow single words. Delicious is a stand-out example of this. My decision was therefore to start off with single words, and treat space as a separator, as this fitted in with popular use.

Further when you are *typing* in tags, space sort of makes sense as a separator. The other comment I’d make is when you *look* at a text field full of tags (as in Surfulater) to my eyes each word looks like a separate tag, versus words grouped by a comma separator. Finally as Avi wrote there are issues of compatibility with other tagging systems as we move forward.

Note that I said “start” with single words. If I’d started with allowing multiple words and folks didn’t want that, then going backwards to single word tags would have been troublesome.

My personal preference aligns with most of you here and that is to allow multiple words and don’t treat space as anything special. Further I would use comma as a separator as we do now, and not make this configurable. Blog followers will know I hate options.

Having said that, there remains a strong case for single word, space separated tags. There are no outright winners here.

PS. I loath the notion of auto-converting whitespace. Folks will think their keyboard is acting up and want to throw it against the wall.

I would ask: why does the conceptual differnce (between white space as separator vs non-separator) really matter? Arent separators conceptually kind of irrelevant when it comes to tags?

Lets say I typed in “sierra leone”.

scenario 1: White space is separator, and it goes in as two tags. Later on, I search for ‘sierra leone’, and it shows all results that have both sierra “and” leone, and thus the article i want is in the results list. (articles that only have ‘sierra’ or only have ‘leone’ as tags can perhaps show up in the results in a section called ‘close matches’, if they show up at all).

Scenario 2: white space is not a separator, and it goes in as one tag, ‘sierra leone’. Later I do a search for ‘sierra leone’, and the article i want shows up in the results page.

In either scenario, the article i’m looking for shows up in the results page. What am I missing? Is it a question of being able to prioritize the search results?

well, If the white space question really does matter, then I for one would vote against either camelcase or underscores (or anything that moves TOO far away from natural language). Simpy.com for instance does tag separators with commas, which feels natural and is easy to type rapidly. I think metafilter does the same.

But again, it seems to me that white space could just be a separator and the idea of linking ‘sierra’ with ‘leone’ is maybe less of an issue than it seems? Again, maybe i’m missing something…

We agree wholeheartedly with the option comment. We do not want additional options, as it both violates KISS from a user perspective, but also greatly increases our support burden.

Avi

Yes, you could offer a configurable tag separator but why? All touch typists create lists separated by commas, tabs, or carriage returns. Surfulater doesn’t need to be any fancier than that, in my humble opinion (BTW, I don’t like acronyms either, ergo, no IMHO).

And auto-convert can be done but “auto” anything is always fraught with peril. Most of the time “auto” is acceptable. But when I don’t want something to “auto” I must have a way to either prevent it or revert it. In the absence of a prevent or revert option I suggest avoiding “auto”. Besides, Sierra Leone is the country, not Sierra_Leone or SierraLeone. So my tags will be words/phrases I don’t use in everyday life (“natural language”)? I don’t think so. I agree with David Laing comment re: del.icio.us and with everything John Hanna wrote.

Start with the KISS principle before adding complexity. And multiple options is an absolute no-no.

Craig

My take would be to allow any character in a tag, including whitespace embedded in a tag, except for a nominated separation character, such as a comma. You should also strip whitespace from the start/end of tags to avoid confusion.

New questions: should tags be case-sensitive? what about other character sets?

I’m not sure where the compatibility issue comes into play, but there are already numerous other standards out there and Surfulater can’t be compliant with all of them. So maybe the best approach is to have a utility to convert tags to other formats as required, e.g. convert all white space between delimiters to an underscore or convert the first character of any term following a white space to upper case and delete the white space (wiki-ize).