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.