Groups: general changes

[MartinKarim]

Description of Issue	Possible Solution	Warnings
The All entries group does not match the users' mental model of grouping; the same goes for the fact that every group is a subgroup of All entries;	Remove that group from the UI; use a button to show all entries instead	-
Filtering groups is actually a search; the search bar is often located too far away from the potential results;	Change text to Search for group; place search bar at the top of the group sidebar;	-
Users want features for hierarchic and non hierarchic grouping to exist in parallel	Make two tabs: Manual for hierarchic grouping, Automatic for grouping by a BibTeX field	for the content and structure of the tabs see #4682, #4683

[AtrusRiven]

Three Tabs in the Group Sidebar

As I realized in the actual 5.2 build there still is only one group in the group interface. Are there further plans to implement these suggestions? I'd also find it very useful to differentiate into three different tabs between groups that differentiate in following way:

tab name/title	groups	keywords	special
differentiation according to	metadatum group	metadatum keywords (without special metadata that also appear as keywords)	special metadatum (readstatus, relevance, priority, print status, ranking, qualityassured)
relation	content related	content related	function related
selection type	explicit selection	automatical collection	automatical selection

For people who'd like to have all groups/collections in a single tab there could be a checkbox in the preferences Show all groups/collections in a single tab.

Terminological Conflict

At the moment, there's a terminological conflict which results from a twofold usage of the terminus group: The metadatum group has the same name as the groups in the sidebar. A collection of entries (at the moment titled group) that is based on another metadatum than groups might technically be treated the same way as a collection based on the metadatum groups but is logically not the same as a group related collection. (According to the metadatum groups the collections are content-related and explicitly set, according to metadatum keywords the collections are also content-related by automatically collected, according to special metadata the collections are function related and automatically collected). A user usually thinks more logically/conceptually than technically.

Side Note: It would be even better to substitute the metadatum group with category because the content relation of what is meant by group is better expressed by category. But due to the fact that everyone has already set uncountable entries with the metadatum group it probably wouldn't be practical.

Thus, I simply suggest (in addition to the three tabs) a change of the sidebars name, i.e. to collections (my choice) or categories (sounds a little bit content-related) or classification (sounds more formal resp. function-related) or rubric. The result would be:

• The sidebar could be titled "collections".
• Every tab in this sidebar would be specific type of collections (see table above).
• Every (formerly called) "group" would be a single "collection". (A collection inside the "group tab" is based on the metadatum groups).

If these changes found acceptance I would modifying the documentation.

[AtrusRiven]

I consider this an important step for UI usability and clarity. Should be linked with #4682 and #4683 in a "metaissue".

[AtrusRiven]

Is there planning on working on this? I don't know what the devs are planning but it could be merged with #4682 and #4683 (and other issues related to the topic?).

[koppor]

Screenshot for two groups available at @https://github.com/JabRef/jabref/issues/4683.

[claell]

Not sure whether it makes sense to have tabs distinguishing between manual and automatic groups.

[ThiloteE]

Agree. Tabs for manual and automatic groups seems nice for categorization, but might create problems for workflow. Imagine having a manually created group and then an automatically created subgroup. I don't want to switch tabs just to have a look at the parent group or the subgroup. Maybe there can be a tiny symbol, flag or colour next to the groups to show if manual or automatic? There is a difference between groups automatically being created and manually created groups automatically collecting their entries using a certain search algorithm. A similar (but different) symbol could be introduced to mark manual groups collecting automatically.

Edit: I mean in theory it could be fine:

• [ ] Default: Show ALL groups + tiny symbol for automatically created / automatically collecting; Tracked in #9072
• [ ] Automatic: Show only automatically created groups
• [ ] Manual: Show only manually created groups.

[claell]

Having such an indicator was also, what I thought of.

And if there is a way to display all groups at once, I am also fine with tabs.

However, having specific filters for groups would probably make more sense. One filter property could be whether they are automatic or manual ones. I just don't see the reason why that property is that important to justify creating tabs for it.

[ryan-carpenter]

Would be nice:

• [ ] Sort groups by frequency (article count).
  • A use case of mine is after creating groups from PubMed keywords—a batch of reference can have thousands, many of which occur only once or twice. I use common keywords to drill down on subjects of interest but need to scroll through the many low-count groups when sorted alphabetically. A threshold for group creation could also be helpful, but I could easily delete unwanted groups if sorted by frequency.
• [ ] Option to hide colour bars of individual groups from the entry table. Having too many groups appear there makes it harder to distinguish those of greatest interest.
  • I imagine this in the create/edit group options.
  • default to the selected global option
  • should retain per-group selections if the global option changes
• [ ] Visual indication of intersection type and/or hierarchical context). For instance, the lozenges that show article counts could invert in colour along with the Toggle Intersection button. Unlike the intersection type, I don't believe there is an indication of a group's hierarchical context setting.
• [ ] How about making Toggle intersection slightly more sophisticated by extending to individual groups? Adding per-group negation (i.e., toggle to 'NOT') would be possible without complicated query logic. Selected groups could default to the current option (AND/OR) and toggle to NOT. (Tracked in #9073)