I’d strongly support multi word tags (Long Island, German shepard,…). It is true that lots of us use small tags (gtd like) but sometimes, we simply would prefer 2-3 words.
Tags must not be always obscure, legibility is a good thing. We would have the best!
Moby Dick
Charles Dickens
Autistic unusual behavior Survey…. Etc…

Regards
Tom

How about you or Craig adding this to the ‘Suggestion Box’ in the forum. Thanks.

You will also see a ‘Notes’ column in the Tags table. This lets you add a description for each Tag in its Folder in the content window. So my earlier comment about no description was incorrect. Note however there appears to be a bug in V2.92 and the note isn’t being saved.

This discussion does not relate to the content of this blog post. Please post unrelated discussions on our support forums. Thanks.

Looking at the SQL DB, the link between Tag and Article is expressed by fields TagID and RecID in the link table.

But in the Tag table, there is no TagID field, just a number implied by the Tag’s row counter.

When a Tag’s name is changed, it stays in the same row. But if a tag is merged, its row is deleted and all tags after it get new row numbers. It appears that no history of tag changes is kept. And it seems that the link table must be reconstructed after any merge operation.

A Problem: given that tags don’t have a persistent identify (i.e., TagID), it would be difficult to have an external table with tag descriptions keyed to the tags. Given that for now, no tag description will be included in Surfulator, and that tag identity is not persistent, how could a connection between tags and descriptions be made?

Neville and I very much appreciate your comments. It may or may not surprise you to know that we have discussed this issue ad infinitum (probably ad nauseum!). Getting the user interface to be as efficient and powerful as possible while as clear as possible is the difficult balance to strike, and absolutely critical to making these new features useful.

So, some responses…

The biggest issue here is whether the pop-up is giving you actions (these are the changes that will happen when you click “OK”) or state (this is what all those articles will look like when you click “OK”). The impacts are as follows.

1) One control vs. two: You really do need separate controls, even in the same pane, one for add and one for remove. When you have a small number of tags, then selecting from the list in a properties grid-style works really well. The moment it becomes large, as most Surfulater users tend to do, a text-box with type-ahead/auto-suggest works much better. Do you take the risk of mistyping? Sure, but it is a small price to pay. This is true either way, but especially for state.

2) Keep vs. Remove: As Neville said, we discussed this internally extensively. State: you tend to think of ticks as to which ones to keep; action: you tend to think of which ones you will remove.

3) What to do with those you add: This is one that we also worked on for a while. Let us say that you add those new tags up top, say, Kookaburra (an Australian bird, great laugh, and Neville is Australian). The moment you are done, does it stay in the textfield up top (action) or does it get added to the rows on bottom (state)?

4) Tri-State vs. Bi-State: Again, this comes down to state vs. action. If users are thinking action, then a checkbox for Keep (or Remove, see above), makes the most sense. If users are thinking state (what will this look like after I hit “OK”), then tri-state makes sense. Every row initially has one of two states – Some/Partial or All. This can be easily represented by a check/dash/blank or a pull-down with words, or radiobuttons (though those get busy pretty quickly). As some are changed to remove, they have nothing.

Separately, we have the whitespace issue: Should we allow whitespace in tags? A separate blog post will follow very shortly on this one.

Would it help if live examples of these are posted on a Web page that you can use, representing different styles of usage?

Thanks to all for this great feedback.
Avi