Better way to add and remove entries from Groups (UI related)

[ror3d]

Is your suggestion for improvement related to a problem? Please describe.
Currently, as far as I'm aware, the only way to remove an entry from a group is by selecting the entry (or a set of entries), right clicking on a group, and checking "remove selected entries from this group".

That is a bit cumbersome, but specially it's not intuitive. The group system is basically a tag/category system (since an entry can belong to many groups at once) and most systems that use tags have a way to manage the tags an entry belongs to from the entry itself, not from the tags.

Describe the solution you'd like
Either a right click on the entry > groups > checking/unchecking the ones it should belong to, or some other way that a list with checkboxes (or similar) can be accessed to manage them, such as a dropdown somewhere that opens the list of groups with checkboxes that that entry has assigned. This option would allow for editing the groups of multiple entries at once.

Another option would be to have these tags also accessible from some tab in the entry editor panel, although that would only allow for one entry at a time to be modified.

Additional context
For example, outlook's solution,

(this one requires right-clicking for every category you want to add or remove, which is not ideal, much better would be that you could select and unselect several with opening it only once)

[koppor]

We somewhere have discussion to do following:

• groups should be tags (which can be categorized)
• new "taxonomy" tree - similar to folders (Dynamic group mirroring the file system. #10930)

The idea is "copied" from TagSpaces: https://www.tagspaces.org/

[koppor]

I need input on following: We had en exhausting debate on the "keywords" field. One opinion: it is from the publisher AND MOST NOT be changed. Other opinion: This is what I categorize entries with - and it should be automatically reflected in the groups ("keyword groups" is one step). -- Maybe the "solution" is to have a "tags" field. groups would be JabRef 5.x behavio, and tags a new JabRef 6.x behavior.

(Side note: We changed the group format in the 3.x line inbetween and that caused confusion -- https://github.com/JabRef/jabref/blob/v4.0/CHANGELOG.md#34--2016-06-02).

[ror3d]

• groups should be tags (which can be categorized)

Ah I see, what would be the changes between groups and tags? It seems to me groups already work basically like tags would. The feature request is mostly about UX of how those are managed.

About keywords, I'm of the first opinion, keywords are set by the paper authors or the editor, and if a bib entry is to be shared with someone it might be best to have that as original. On the other hand, if importing entries, the existing keywords might not be relevant to the tags I have in that library, so keeping those might also not make sense.

[koppor]

Just as note to think of it later.

dret.bib (https://github.com/dret/biblio) has the idea of topics:

topic =     "jsp[0.7] asp[0.7] perl[0.7] cgi[0.7] servlet[0.7] php[0.7]",

It seems that these are "tags" with a matching ratio added.

(Refs https://github.com/JabRef/jabref-issue-melting-pot/issues/421)

[koppor]

Another note: JabRef supports hierarchical keywords (a > b > c). Maybe, we could use that for tags (or taxonomy items), too?

[koppor]

The feature of hiearchical keywords is explained at #628

[andr-groth]

Since the new keyword tag systems #10910 does not supporty hierarchical keywords anymore, I'd would be happy to see this feature #628 restored. This could be hopefully added to the tag systems, by extending the tag box:

On the other hand, the feature #628 is already quite powerful:

• hierarchical groups can be automatically generated from keywords
• entries can be assigned by drag&drop,
• adding new entries will be automatically assigned if one or more groups are selected,
• publisher keywords are merged with the user defined keywords and create new groups,
• ...

But since keywords are not required, they do not immediatly appear on the required tab when editing an entry. This is maybe why the feature #628 is not very well known. Only mentioned in a short paragraph of the documentation on groups (even not mentioned in the keywords section) : https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#nesting-sub-groups

Suggestion

What I would suggest is to make this feature #628 more visible, in the documentation and in the UI. The keyword tags are a good starting point 👍 and maybe they should be made more prominent in the UI:

1. Explain hierarchical keywords in https://docs.jabref.org/finding-sorting-and-cleaning-entries/keywords
2. The keyword field could be made sticky and appear below the required fields.
3. Keyword tags could appear on top of the entry preview.
4. The general tab could be made more prominent.

On the other hand, adding a new tag field might add a new level of complexity and confuse the user. I would keep it with the Occam's razor and the principle of parsimony.

[andr-groth]

And of course I would second the long-term goal #6191. At the moment there are over 30 input fields spread across six different tabs.

[andr-groth]

And of course I would second the long-term goal #6191. At the moment there are over 30 input fields spread across six different tabs.

Please see also my remark on koppor#679.

[InAnYan]

Here are my thoughts on groups in JabRef and bibliography management. WARNING: high probability of overthinking.

Purpose

Let's start at the beginning.

The purpose of groups is to organize/sort/clasify entries.

Current situation in JabRef

The way JabRef groups work... Truly speaking, I can't explain. I think that JabRef actually tries to implement two approaches, that are actually too different in nature.

Ways to organize entries

Here are some concepts that came in my mind when I was thinking about organization of entries:

Folders

1. A folder is a collection of entries.
2. Every entry belongs to some folder.
3. Folders can be nested, so they make a hierarchy.

For convenience, I would also like to add this statement:

4. Every entry belongs to its folder and to all parents of its folder. (This is where this idea differs from folders on a typical file system)

Folders are a way to group entries, they are created manually, an entry can't belong to its sibling folder (only to a parent folder, hope you got the idea).

Also folders should be manually filled, because if we used a search expression, then one entry can be true for two or more search expressions, and so they can appear in different folders, which violates the 4 principle.

Tags

1. Tag is just a marking on an entry. So they are assigned to an entry (in comparison to folders, entries are moved to folders).
2. Tags don't make a hierarchy.
3. Tags can be either manually assigned or assigned automatically with a customizable condition.

So what system does the JabRef has?

It's a kind of a mix between folders and tags.

JabRef groups are similar to folders, because I can make a hierarchy of groups. However they're not folders because I can have an entry in a child group, but it can not belong to the parent group. That's the thing I got very-very confused with.

JabRef groups are similar to tags, because filling groups with entries can be automatized.

In my opinion, folders and tags are different approaches and it's hard to explain how they can be mixed together. The explanation may have many 1) bugs, 2) ambiguities, 3) edge conditions.

How we can solve the problem with groups

I see N ways to improve grouping in JabRef:

1. Make groups behave like folders:
   Pros: easy, predictable, stable, Dynamic group mirroring the file system. #10930 is easy to implement.
   Cons: we lose the feature of automatic assignment. And we also can't have one entry to belong to 2 sibling folders.

2. Make groups behave like tags:
   Pros: maybe easier to implement, automatic assignment
   Cons: no hierarchy.

3. Still, think about how folders and tags can be mixed.
   Pros: we can have a very powerful system.
   Cons: but that system will be complex. This impacts the development (bugs) and user experience.

4. Introduce a new way to organize entries, except folders and tags.

5. Extreme: implement folders and tags in JabRef separately. So we split the group panel in two: one for hierarchy of entries that is filled manually, the other is for tags that are automated way of searching entries.

6. Do nothing.

P.S.

You can see, that I'm a fan of folders, and I don't like tags. So the review is biased. And whenever I assign an entry to group, I, as a beginner user of JabRef, imagine this as moving entry to the group.

How I (as a beginner user) organize entries: I mostly use the 5th approach. There are 2 kinds of groups in my BIB file: one are folders (I categorize papers), the second is utility groups. The utility groups are groups to see 1) which entries don't have a linked file (maybe I forgot to add it), 2) which entries don't belong to group (then I should group them). The 5th approach fits to my workflow. (But I'm only an amateur, and maybe you utilize groups better).

[LoayGhreeb]

However they're not folders because I can have an entry in a child group, but it can not belong to the parent group. That's the thing I got very-very confused with.

If you set the parent group's hierarchy to union, it will display all entries within both the parent and child groups. However, this won't affect the "groups" field in the bib source.

[ThiloteE]

You are right Ruslan, JabRef's groups feature is actually a tags feature, but we call it groups :D

IMHO, the larger your library becomes, the more difficult it is to manage via folders (because it takes long to find entries in deep nested structures; Too much scrolling, too much clicking). Folders are good for small and mid sized libraries, whereas large libraries work better with tags.

Both tags and folders profit immensely from a workflow that revolves around "search" or "search groups", but tags especially, because they easily allow you to find entries that haven't been categorized into groups yet. Categorizing via groups is a second more labor intensive step, whereas many entries already come with existing tags and keywords (and the title or words in an abstract also can be relevant) so less work is required.

[InAnYan]

Okay, I see.

After some thinking, I came to conclusion, that it is faster to make a keyword group for "document management" or "Ukraine", rather than manually moving them...

Then okay. I don't see any problems of changing groups to tags.

But, I have questions:

1. Can tags be nested?
2. Can tags be assigned both manually and automatically?