Tag issues (4.0)

aurimas

Couple problems:

1. Add unique tag to an item (say itemA).
2. Select the tag in tag selector so that only itemA is displayed.
3. Go to Tags tab for that item and remove the tag.

The tag selector now displays "No tags to display" and there are no items shown in the middle pane. You have to switch collections to see the items again. Removing the last instance of the tag from a library/collection, should clear it from the filter list.

The other issue is this:

1. Add tag to an item (or several).
2. Select tag in the tag selector. (might not have to do this)
3. Open the Tags tab for one of the items.
3. Remove the tag from the entire library by right-clicking on the selected tag in the tag selector and choosing delete tag.
4. Tag is cleared from the filter and all items are displayed (yay!), but it is still shown in the Tags tab.
5. Click on the tag to edit it in the Tags tab.

At this point, Zotero turns the tag into "false". Switching tabs does not help, the tag is still displayed as false. What's worse is that attempting to switch collection results in "An error occured. Please restart Firefox." message in the center. Report ID 1799575110

I'll try to break this some more and report back.

aurimas

I think in general, the Tags tab is not updated when tags change. E.g. renaming the tag via Tag selector -> Rename Tag does not update it in the Tags tab. (though color changes seem to take effect)

Also, is there a reason why it's not allowed to assign tags/colors to number keys out of order? I.e. assign first color/tag to 6 instead of 1. I can sidestep this UI restriction by, say, assigning all six numbers and then deleting the first 5.

Renaming a tag with assigned color/number sets that tag to number 1 (but doesn't change color) and removes the other color/number assignments.

Removing a tag with color/number assignment via the Tags tab so that no other items have that tag (i.e. it should be deleted from the library and it does disappear from the tag selector) does not appear to remove it from color/number assignment. Say it was the only tag with color/number assignment, then once it is removed via Tags tab, going to assign color/number to another tag starts off at number 2.

More to come

dstillman

Pretty sure the first issue isn't new in 4.0. The second one might be.

Also, is there a reason why it's not allowed to assign tags/colors to number keys out of order? I.e. assign first color/tag to 6 instead of 1.

Simplicity?

I can sidestep this UI restriction by, say, assigning all six numbers and then deleting the first 5.

You can't, really. Once you close and reopen the Zotero pane (or restart Standalone) the numbers will shift down. This is just a fluke of when tags are actually purged from the database. We don't check for orphaned tags on every item-tag removal for performance reasons. But it's true that this makes things a little awkward with colored tags. Not sure what the best solution is here.

(I can also trigger a "tagIDs.map is not a function" messing with this, which I'll fix.)

aurimas

You can't, really. Once you close and delete the Zotero pane (or restart Standalone) the numbers will shift down. This is just a fluke of when tags are actually purged from the database. We don't check for orphaned tags on every item-tag removal for performance reasons. But it's true that this makes things a little awkward with colored tags. Not sure what the best solution is here.

So why does this have to be limited? If it's just simplicity, there's no reason to shift the tags down. I understand that when you go to assign color, you don't want to try and figure out which number to choose. Can't we just pre-select the first available number (even when they are out of order) without re-arranging the tags?

Once you get used to the numbers, I'm sure people will be frustrated if they suddenly change.

dstillman

Once you get used to the numbers, I'm sure people will be frustrated if they suddenly change.

That's possible, but the counterargument here is twofold:

1) If you have something assigned to a number and delete it, you then have a gap that you can't get rid of without changing a bunch of other tags. If you've removed #3 permanently, why would you want #3 to remain unused and have to remember that it's empty?

2) Related to the above, part of the reason we move the colored tags to the top of the tag selector is so that you can quickly see their positioning in order to use the number keys. We don't show assigned number keys. But if you remove #3 there won't be any indication in the tag selector that there's a gap between 2 and 4.

Even if you're doing things from memory, why keep the gap? If you've removed #3 permanently, it takes you a short while to adjust, and then you get used to the shifted numbers.

dstillman

I do think we should probably disable key navigation for 1-6 even if a single tag color is assigned, though. Right now it only disables for ones that are used. The idea was that we shouldn't prevent keys from working unnecessarily if people hadn't assigned tag colors, but 1) preventing that probably doesn't really matter, because most people won't be navigating via number keys and 2) it's fairly easy to hit the wrong number key when you're trying to assign one, and as it is now there's a penalty (getting moved to some random item in the list).

dstillman

I think in general, the Tags tab is not updated when tags change. E.g. renaming the tag via Tag selector -> Rename Tag does not update it in the Tags tab.

This is working for me. Can you reproduce after restarting Zotero?

dstillman

Renaming a tag with assigned color/number sets that tag to number 1 (but doesn't change color) and removes the other color/number assignments.

I can reproduce this. I'll fix.

aurimas

That's possible, but the counterargument here is twofold

Idk. I understand your argument and I agree with those use cases, but I feel like there will be confusion and frustration for the users. I don't have a great solution right now, but I'll think about it.

Related to the above, part of the reason we move the colored tags to the top of the tag selector is so that you can quickly see their positioning in order to use the number keys. We don't show assigned number keys. But if you remove #3 there won't be any indication in the tag selector that there's a gap between 2 and 4.

I fear that, while I sort of like this intention, it's a bit broken everywhere except for the library root. Since going to a collection removes tags that are not present, directing users to figure out which tag is assigned to which key simply by the order in the tag selector will cause even more confusion.

I think in general, the Tags tab is not updated when tags change. E.g. renaming the tag via Tag selector -> Rename Tag does not update it in the Tags tab.

This is working for me. Can you reproduce after restarting Zotero?

This works ok with color tags, but not regular tags. Actually, even switching collections and going back to the item, does not update it. You have to select a different item and go back.

Few more bugs:
I have a tag "foo", which is green. In the Tags tab, I go to add a tag and enter "foo ". Note the space. The tag is added as "foo" (which is fine), but it is not colored green. If I select the tag to edit it, the space is already stripped off and if I press enter, it becomes green now.

Assigning tags via keys when the Tags tab is showing does not update the list in the Tags tab.

I also would like to bump the tag color/child tag conversation from http://forums.zotero.org/discussion/1787/simple-marking-of-items/ Do you want some more input on that? What bothers me the most right now is that the purples and yellows look very similar and, unless you have them next to each other, it is very difficult (for me anyway) to figure out which one is which (not so much with purples).

aurimas

Just noticed that tag counts in Tags tab no longer work. It always shows "0 tags" for me. Not sure how useful that counter is anyway, so maybe we can remove it altogether.

Gracile

I'm posting here another issue.
I've noticed that if I scroll down a bit (i.e. the scrollbar must not be at the top or the bottom of the item list), select an item, then press a number key to add to the selected item a colored tag, Zotero scrolls down/up so that I can't see the selected item. Could you reproduce that?
(z4.0 from git; win7; FF 19.0.2)

Edit: Debug ID: D1293132044

aurimas_test

I can reproduce. It seems to bump it up by one line. So if you're tagging the top item, it would bump it out of view. I think Dan has mentioned this in another post today, so I think he's aware of this one.

Another bug though:
1. Add tag "1" to an item. Assign it color and number 1.
2. Delete item (along with tag) from collection, empty trash.
3. Add another item.
4. Try assigning tag "1" using the number 1 on keyboard. Does not work as expected.
5. Add tag via Tags tab to the item. Name it "1" again. Tag is assigned and regains its color and number assignment. You can now add it to items again using number 1.

I think this is a bug, though the result is almost a feature. Not sure what you want to do with this.

Also, Dan, I know you're not a big fan about using the github tracker for reporting bugs, but perhaps this would work out nicely there. It would be very easy for you to track and close bugs. And it would be nicely organized. Just saying.

adamsmith

(I thought the reason against using github is just that we don't want it to become a place where people with relatively little knowledge of Zotero report issues that are often clarified/solved quickly on the forum. If I identify something that's clearly a bug I post it to github).

dstillman

Yeah, I'm fine with GitHub for this. (I'll take care of the ones posted so far, though, so don't worry about reposting those.)

dstillman

1. Add unique tag to an item (say itemA).
2. Select the tag in tag selector so that only itemA is displayed.
3. Go to Tags tab for that item and remove the tag.

The tag selector now displays "No tags to display" and there are no items shown in the middle pane.

Fixed (and indeed freshly broken).

I think in general, the Tags tab is not updated when tags change.

Fixed (along with all related issues), hopefully without causing new problems.

Renaming a tag with assigned color/number sets that tag to number 1 (but doesn't change color) and removes the other color/number assignments.

Fixed.

I have a tag "foo", which is green. In the Tags tab, I go to add a tag and enter "foo ". Note the space. The tag is added as "foo" (which is fine), but it is not colored green.

Fixed.

Just noticed that tag counts in Tags tab no longer work.

Fixed.

I've noticed that if I scroll down a bit (i.e. the scrollbar must not be at the top or the bottom of the item list), select an item, then press a number key to add to the selected item a colored tag, Zotero scrolls down/up so that I can't see the selected item. Could you reproduce that?
(z4.0 from git; win7; FF 19.0.2)

Issue created.

More on the other stuff later.

dstillman

I've noticed that if I scroll down a bit (i.e. the scrollbar must not be at the top or the bottom of the item list), select an item, then press a number key to add to the selected item a colored tag, Zotero scrolls down/up so that I can't see the selected item. Could you reproduce that?

Fixed.

dstillman

I fear that, while I sort of like this intention, it's a bit broken everywhere except for the library root. Since going to a collection removes tags that are not present, directing users to figure out which tag is assigned to which key simply by the order in the tag selector will cause even more confusion.

Colored tags now remain until you delete them explicitly even if they no longer have items attached, and they also always show in all views. If they don't match any items in the current view, they're shown with reduced opacity (though the styling may need to be tweaked a little for visibility). This addresses various issues above, and we think it'll make sense for most people's uses of colored tags.

wakingtiger

After deleting an item (as well as clearing the cache on my browser), the unique tag on that item remains in My Library. How do I get rid of an unwanted tag?

Gracile

In the tag selector, right-click on the tag -> "Delete Tag..."

wakingtiger

I already deleted the tag, and it does not appear in the tag selector box. However, when I access my zotero library via browser (not via the Firefox add-on), the unwanted tag is still there (in the tags section of My Library on the bottom left). How can I get rid of this unwanted tag that persists on the web version of zotero?

Gracile

Restart your browser: http://forums.zotero.org/discussion/26071/deleted-tags-not-deleted-in-groups-online/

(and make sure your trash is empty)

aurimas

@Dan,

Doing some more testing with the tags. Mostly nits at this point, I think.

1. If I assign/unassign tags quickly (almost pressing several keys at a time), I sometimes end up with more color squares (have not noticed a case with fewer) than I have tags. You can see this in the screenshot: http://i.imgur.com/4djTML4.png This might happen more easily on slower computers. The squares are fixed if I switch collections.

2. Say you have two tags. Assign both of them to two items in the library. Select both tags in the tag selector, so the two items are showing. Remove one of the tags from the entire library. The tag filter is cleared. I don't think the filter should be cleared. The second tag should still be in the filter.

3. When long tags are added, the tag selector scales width to fit the tags, but there is no horizontal scroll bar, so some short tags become completely hidden. Not sure if that makes sense. E.g. Set the tag selector/collection tree pane width to minimum. Add tags "11" through "20". Add a tag like "something very very very very very very very long".

4. Deleted tags keep being suggested when adding new tags via Tags tab. Have to close Zotero pane to clear them from suggestions. Not a big deal, I can see how this is done for performance reasons.

That's all I have for now

dstillman

Thanks for all this—it's been a huge help. I can live with these bugs for the beta, so if you could create issues for them on GitHub that'd be great, and then we can close out this well-worn thread and continue more specific discussions elsewhere.

aurimas

I'll move these to github, but...

3. When long tags are added, the tag selector scales width to fit the tags, but there is no horizontal scroll bar, so some short tags become completely hidden. Not sure if that makes sense. E.g. Set the tag selector/collection tree pane width to minimum. Add tags "11" through "20". Add a tag like "something very very very very very very very long".

This is actually quite a big issue, since we do sometimes get rather long tags from web translators and I have seen people create pretty long tags trying to compensate for the lack of hierarchical tag feature. I understand that a solution to this might not be very apparent. I just wanted to make sure that #3 got your attention as opposed to the other 3 issues that are very minor.

dstillman

Got it, thanks—I don't think it's new in 4.0 (or anything recent), though.