We are currently working on the next part of the new Surfulater Tagging capability and would like some guidance from you, our users. We are working on two new and related features that revolve around letting you add and remove tags from a group of selected articles. For example you might select six articles and then want to add one or more tags to these articles. Or you might want to delete a tag or two from them. To do this now you would have to select each article in turn and edit its Tags field, to add or remove the tags, which is cumbersome to say the least.Â
There are ways to make this task a lot quicker and easier, which is the focus of this post. How are we proposing to do this? Lets start with adding tags. First you select all of the articles in the Knowledge Tree that you want to add some tags to, then right click on one and select Add Tags… from the context menu, which opens this dialog.
You can type in one or more tags, and auto-suggest lets you choose from the list of existing tags. When you press Save, the Tags you entered are added to the selected articles. Any tags already present in an article will not be added again, so you don’t end up with duplicates. This process works just like the Tags field in your Surfulater Articles.
Some tagging systems let you add tags by displaying a list of all available tags and getting you to tick a checkbox for each tag you want to add. This is simple, intuitive and works very well when you have a smallish number of tags. However as the number of tags you add grows, this quickly gets unwieldy and you spend more and more time scrolling back and forth through the list to locate and choose the tags you want.
Our approach of quickly locating tags using auto-suggest, and of adding new tags to the tags database at the same time, delivers a much better user experience, especially as the number of tags you use grows, which it will.
Now lets talk about removing tags from articles. Assume we have three articles with the following tags:
- Cat, Pet
- Dog, Pet
- Cow, Herbivore
As before we’ll select all of the articles of interest, right click and choose Remove Tags… from the context menu which will open this dialog.
This shows a list of all of the tags in the selected articles, with duplicates removed. In this example Pet is in two articles, but only appears once in the list. Beside each tag is a checkbox, with the heading Keep? and all checkboxs are checked. To remove the tag Pet from the selected articles it is in, you uncheck its checkbox and then press Save. If you wanted to remove other tags at the same time, you would uncheck those as well, before pressing Save.
So far so good, or at least I hope so.
Our next step in evolving these designs was to look at a further simplification which would enable you to both Add and Remove Tags within the one dialog, starting from a single context menu selection Tags…. Most of the time you want to either Add or Remove, but there are times when you want to do both. The new combined dialog looks like this.
When Save is pressed in this example animal and herbivore will be added to the selected articles and pet will be removed. If the New tags field had been empty, no new tags would have been added. Likewise of no tags were unchecked in the list, none would have been removed from the selected articles. All quite straightforward.
On closer examination one issue became evident and that is there can be some confusion when a tag you want to Add is shown in the Existing Tags list. In our example this is the tag herbivore.Â
When you notice herbivore in the list you might decide not too include it as a New tag, which would be a mistake. Referring back to the articles and tags summary:
- Cat, Pet
- Dog, Pet
- Cow, Herbivore
you see that herbivore is only in one of the three selected articles, but there is no way to tell this from the Existing Tags list. Because you didn’t include herbivore in New tags, it won’t be added to articles one and two, which isn’t the desired outcome.
To help to resolve this we concluded that you need some indicator in the Existing Tags list which clearly shows which tags are in All of the selected articles and which are not. The outcome is this dialog.
Note the new In All… column, which in this example is completely empty, because there are no tags which are in all of the selected articles. After we press Save the story changes to.
You now see animal and herbivore are clearly identified as being in all of the selected articles. You can group the tags that are in all articles together by clicking on the In All… column heading. Now when you see a tag that you want to add is already in the Existing Tags list and it is In All articles, you can skip it if you want, or you might find it easier just to add it and let Surfulater look after things.
The bottom line is that there really isn’t any point in scrolling through a long list of Existing Tags to see if a tag you want to add is there or not, just go ahead and add it.
Where do we need your help?
First does this all make sense? Can you think of better ways to add and removes tags from a group of articles? Should we have separate Add and Remove processes or does combining them into one dialog deliver a better user experience? If so, does the combined dialog we’ve presented above, work for you?
Do you find the user interface for removing tags intuitive? Could you work out how to use it just by looking at the dialog or is it confusing or difficult to grasp?
Please do give us your feedback and help us make some important decisions on this aspect of tagging and untagging multiple articles at once. All our lines are open. 😉
The Next Pre-Release
I am in the midst of wrapping up another new pre-release which will include the combined Add + Remove Tags dialog as described here. It should be available this week. Keep your eye on the Blog for details.
To be continued…
The Topic for this post says Part 1. We have an alternate combined Add/Remove dialog user interface on the drawing board, which we will present here as soon as it is ready, so stay tuned.
Hi Neville,
The interface sounds more powerful than I would have hoped! Nothing too confusing in there, in fact it all makes sense. Can’t think of any suggestions off the top of my head, but I look forward hearing about the alternative method you’ve come up with.
Taras, thanks for the heads up and the prompt reply.
Is there a benefit in allowing this level of complexity?
I am thinking of something simpler, like the Properties box in Visual Studio. When you select multiple controls to set properties on, the box is filtered to show only those properties that the controls have in common. You then only see the values for those properties if the values are the same. Setting or changing properties affects the controls, but if you dont touch a property, it isnt changed.
I can see the same thing working with tags in the following way. The UI would just be the text box, and it would just show the tags that all articles have in common. Any tags that you add to the box would be added to the articles, any tags you remove would be removed. This doesn’t allow as many different types of changes, but its a much simpler way to get a similar result. For the articles that don’t really share tags would other articles, I would argue that you wouldn’t really want to manipulate the tags on them all at once anyway.
But I only just started reading The Design of Everyday Things today, so I’m no expert yet 🙂
Considering what manipulations of Tags are useful should be placed in the context of what the Tags are being used for.
There are four main organization tools in Surfulator: folders, articles, keywords, and tags. Folders and articles have the benefit that explanatory text and annotations can be included.
SUGGESTION – add the ability to associate some explanatory or definitional text with the keywords and tags (to help guide their usage). Provide viewers and editors for studying and refining the keywords and tags.
So how should keywords and tags be used? Differently? Keywords potentially could be used for content meaning, while tags could be relegated to organizational (structural) tasks (e.g., forming virtual folders for grouping and clustering).
Searching and selecting on keywords could then be followed by tagging of the found set.
Note that keywords and tags are the least expressive means of associating meaning with content. They act like a child saying nouns and pointing. No refined expressions or sentences. Even RDF goes further. So overdesign of the keyword and tag mechanism isn’t warranted.
Dear Neville,
I would strongly suggest to maintain both operation separate. It is the best and more intuitive way for users.
Tagging is used generally to add tags to related articles, or to add tags to “not yet tagged” articles you wrote in a row on a similar subject. And you will want to add tags to all articles of your database, due to their inherent power.
Untagging is more a “Maintenance” operation where you wish to remove tags from unwanted places, or during a reorganization of your tags.
I am actually using a system where tags are used. My “small” everyday database has 620 articles and 106 tags. Every article is tagged with 1 to 3 tags.
But I have friends with working databases of more than 8,000 articles and 400 tags!!! I am pointing towards the same in my work (specialized) database (Philosophy, Cognition, Neuroscience, Language, AI).
I certainly don’t want to make any mistake in this one!!!.
Other detail to be taken in account is that untagging will occur only once in a while, but tagging occurs for every article.
I hardly recall when I needed to untag articles (or bunch of them) as they are consistently tagged in the first place.
Except when an article was mistakenly tagged (very very rare), or when I want to reorganize some stuff. And in this case, I surely prefer to have both operations separate.
Best regards
Tom
As a Technical Communicator with 25+ years experience in development, usability testing, and documentation, I will always have an opinion about UI and human computer interaction (HCI). Thanks for asking.
Along the lines of David’s comment, something that frustrates me about Surfulater is that if I need to see the Comments, Reference, Attachments, See Also, and Tags for a long article I have to scroll down to find them. And since there is no hot key to move back and forth between the tree and the article pane (I’m a keyboarder much more so than a mouser), this becomes doubly frustration. So either a Properties window like David described (which I don’t prefer) or the Article pane scrolling only the Text section and not the other areas (so they would remain visible all the time) would work for me.
I agree with a single dialog “Add/Remove Tags”. I’m fine with auto-suggest but I but I suggest a UI similar to Outlook’s Categories; a textbox above and a checked listbox below. Why? First, this gives the keyboardist (textbox) and the mouser (listbox) their preferred UI element. Second, if you can only type in tags then spelling errors can be introduced. Third, for the Add Tags UI to only have a textbox and the Remove Tags UI to only have a listbox, you create different UI experiences for two (2) processes which are only opposite to each other, not completely different. Fourth, from a developer’s perspective, this textbox/listbox pairing can be modularized (custom control) for easy reuse; one instance for Add, another instance for Remove. Additional to these elements in Outlook’s Categories UI is a button to open the Master Categories list (to edit the database of choices). This would also be helpful for Surfulater.
For either the Remove Tags dialog or a combined Add/Remove Tags dialog, I believe the “Keep?” column should be labeled “Remove” and none of the checkboxes should be selected by default. Why? It’s called Remove Tags. By inverting the logic of the UI and introducing a new word, Keep, it becomes unnecessarily confusing.
For a combined Add/Remove Tags dialog I would add an Apply button which would be equivalent to Save and re-opening the dialog.
That’s all.
Craig
Technical Communicator
craig.prichard@gmail.com
@David,
Thanks for the suggestion. A single text field showing all existing tags is one way to tackle this, but I think it falls down in several areas.
First the quantity of tags could get unwieldy when lots of articles are selected. Second as a method to remove tags this is a lot more effort than unchecking a check box. And if you make a mistake simply checking it again. Third it only shows tags which are in all articles. This could be a plus though. Finally as you point out it doesn’t let you accomplish as much as what I presented above.
@John H,
‘See Also’ links are another important organizational tool.
Keywords are only used in the Bookmark article template and come from the keywords on the Web page. They don’t really tie in with Tags.
I did think about enabling Tags to have descriptions, but in the end decided against it as I felt it would rarely be used and would add more clutter to the UI. This can be revisited given sufficient interest.
@Thomas,
That’s one vote for separate Add/Remove dialogs. I am somewhat on the fence on this, with a leaning more towards the combined dialog.
I see several advantages to the latter. First it lets you see the tags on the selected articles, which maybe useful at times. Second it lets you replace a tag in one step. For example if I wanted to replace Pet with Animal I would uncheck Pet and add Animal. And third it does let you add and remove tags in the one place, for those times when this is what you want to do.
@Craig, thanks for your contribution.
Surfulater Version 3 has a very important new capability which lets you re-arrange Folder and Article rows in any order you want. Will that lessen your frustration?
That’s one vote for a combined dialog. I’m not an Outlook user, but will check out the UI you described. Auto-suggest should help prevent spelling errors. Your point about add & remove being opposite but similar is valid, but tends to favor using two separate dialogs as the solution.
Changing “Keep” to “Remove” has been suggested internally. I don’t feel that strongly either way. However it seemed to me that having checked items indicating these wouldn’t be removed, made more sense.
“Apply” yes I agree. I implemented this and then ran into a problem with some underlying code that prevented me from getting it to work. I’m told this has been fixed now.
That’s all.
Neville
I like your combined dialog, except of course that it would be nice to simplify it even further. One way you could do that is with tri-state checkboxes where blank means ‘remove from all articles’, grey means ‘apply to some articles/no change’ and black means ‘apply to all’. You could keep the ‘intellitextbox’ for new tags at the top, as you propose, or allow new lines to be added to the list of tags, where each new line would be an ‘intellitextbox’ and the checkbox would be restricted to just two states (all or none).
Saltheart, thanks for that. If I understand you correctly you want to enable the “Existing Tags” list to move beyond its current function of removing tags to also enable it to add tags. I find this dual personality troublesome and confusing.
Further if you were to look at the dialog, how would you know what the tri-state, states meant.
I assume the tri-state replaces the current “in All..” column?
If you have a tag in the “Existing Tags” list that “isn’t in all articles” and you want it to be, then in your example you would scroll down through the list until you found it (or didn’t) and then check it black. In the proposed implementation you simply add it to the “New Tags” field and don’t think twice about whether it is in the Existing Tags list or not.
Not sure about your trouble and confusion. To me it’s just an editable list of tags and I think most people could deal with it from that perspective. I admit that embedding ‘intellitext’ controls actually in the list is non standard and may cause some momentary confusion to someone expecting a dropdown. So I withdraw that idea and will patent it instead so you will have to pay me a royalty when you finally realise how brilliantly clever it is. As for the tri-state checkbox, that is not an original idea and I think many people would already be familiar with the concept from working with other products, such as VS, as David points out. And you could always provide a hint/tooltip to make the intent crystal-clear.
Ok, one important point I missed is I take it that you are also suggesting we loose the “New Tags” field and all actions take place in the list. In essence it becomes a Properties style grid as per David’s earlier suggestion.
To add a new tag in this implementation you would add a new blank row to the grid and type in a tag, with the help of auto-suggest (‘intellitext’). The tri-state checkbox would be black, indicating it would be added to all selected articles. It could be made blank, but not gray.
This works, however for quickly adding some new tags it falls down, as it is more mouse clicks and keystrokes than simply typing them into a text box and clicking Save. And I think we all agree with Tom that adding tags is the most common use case.
Further you can’t tell which tags are new (just added) and which already exist, but maybe this isn’t necessary.
Property grids are well known and liked by technically savvy users, but I wonder whether lesser folks would find them as straightforward as either the separate add/remove or earlier combined dialog. Suffice to say we have a very broad range of people using Surfulater, covering the spectrum of PC usage expertise.
The main problem with tagging is keeping control over the vocabulary–preventing the list from becoming too bloated with interchangeable terms and vague shades of meaning. Tagging is a more spontaneous process than formal approaches to classification like ontology and taxonomy, which makes it all the more important to be able to revise and refine the tags as you go along. Because adding and removing tags are linked activities in the process of refining the tag vocabulary, I think Neville’s dual purpose tag dialogue box is the most appropriate solution proposed so far.
One slight improvement that occurs to me would be to add a “find and replace” function that would find all articles containing a certain tag and change that tag to another one; for instance, to find all occurences of “economy” and change them to “economics”.
A merge function which would allow two or more terms to be replaced with another single term (apple/pear–>fruit) might be nice too, although again it would save only one step if there was a find and replace function.
Joel, thanks for the feedback. You are absolutely right in regard to constraining the vocabulary your use. I also happen to agree with you about the proposed dual purpose tag dialog box.
Re. Tag find and replace and merge. You can do both of these now by renaming Tags in the Tags Tree. ie, Select the Tag “economy” and rename it to “economicsâ€. All articles will change accordingly. Merge works similarly. See the “Renaming Tags” section in the Help Topic: The Basics | Tags and Tagging Articles.
Sorry Neville, I should have read the instructions first! Glad to hear that the find/replace/merge functions are there.
All,
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
Concerning Tag Identity and Naming…
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?
I would also like to second Craig’s suggestion for a scrolling [and, I would add, size-able] text pane for articles, in order to make it easier to access the tags and other fields, and to keep them in view.
I think you should keep the ‘add’ and ‘remove’ as separate tasks. Less confusion of the end-user (usually users want to do one of the two — when you bring up the ‘add’, I assume you pre-populate it with the current set of tags which can be edited to remove tags). Also less implementation effort for you.
@John H, Each row has a rowid which is used for the TagID. This never changes. If you run a query:
select rowid, * from tblTags; you will see this.
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.
@Joel.
>I would also like to second Craig’s suggestion for a scrolling [and, I would add, size-able] text pane for articles, …
How about you or Craig adding this to the ‘Suggestion Box’ in the forum. Thanks.
hi nev – i’m agnostic as to whether the add/remove UI’s should be combined or separate. One thing I would suggest (if its not already mentioned above) is: For the “in all” column, why not make that a checkbox too?
Dear all,
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