Groups: change "Add group" dialog

[MartinKarim]

Description of Issue	Possible Solution	Warnings
Hierarchical context settings are too complex	Remove settings from group creation dialog (e.g. into the preferences); set one option as a default;	best default is probably include subgroups
Type choices are too complex; options are hidden, so users do not have a good overview	keep first and last type; remove automatic grouping because it is implemented as seen in #4683 ; combine the other two types into one; unfold options of the remaining choices;	the second choice in the prototype might require changes beyond the UI
Description makes the dialog longer; information is often too complex;	remove Description from the dialog	-

[AEgit]

I think the default should remain Independent group, not Include subgroups.

[MartinKarim]

I think you are right that the recommendation of using include subgroups can be doubted.
The thoughts behind this suggestion were that independent group does not actually give any hierarchy. Even though the difference between groups and subgroups is made in the UI, a subgroup has no actual relation to groups higher or lower in the hierarchy. This might confuse the user, as the feature does not perform in the way it appears.
The include subgroups, however, provides an actual relation between groups and subgroups. It treats subgroups as a subset of a larger set of entries, which seemed intuitive to me.

Eventually though, more user data is be required to settle this question, but it would be very much appreciated if you could share a use case, where independent group seems to be the better solution for a default.

[AEgit]

Two reasons:

1. Independent group was the old default, as it was preselected in the menu dialog. People are used to this behaviour and - as far as I can tell (although I might be biased) - no one has complained about this.

2. Example from biology: Groups can (and are) used to capture taxonomy/phylogenetic relationships.
   I. e. I can have a group structure as follows, starting from the highest order (super)group down to the lowest order subgroup:
   Class -> Order -> Family -> Genus -> Species

Quite frequently it happens in biology that it is not possible to determine whether a sampled individual belongs to a species or even a genus. We can only assign it to a family. Similarly, some articles will deal with organisms only at a class, order, or family level but will not go into the details of genera and species.
By having Independent group as default setting for groups, it is easy to distinguish such indeterminate sampled individuals or more general articles from those focused specifically on a genus or species.

If I am interested in the general properties of a family, I am only interested in general articles dealing with those. I do not need the detailed articles specific to certain genera/species. Similarly, if I want to have a look at only the indeterminate individuals I do not need articles of taxa, which could be assigned down to species/genus level. This functionality is provided by having Independent group as the default setting.

If someone then really wants to include all items of the subgroups, they can just select all (relevant) subgroups and by using the "Union" feature display the entries that belong to all the selected groups (N. B.: I am still using JabRef 3.8.2 at work for stability and performance reasons and only check from time to time the current development version - I haven't checked if the "Union" feature is still available. If not, that would need implementation).

[Siedlerchr]

@AEgit Union/Intersection is available directly through an icon-button showing the set-theory symbols for union/intersection.

[AEgit]

@Siedlerchr : Cheers, perfect - so this option is still available. So even more of a reason to keep the previous default, i. e. Independent group.

[MartinKarim]

@AEgit Thank you for the elaborate example. It seems that there is indeed a point in using independent group as it gives more freedom to the user regarding hierarchy. Although the union feature does not seem like a usable alternative to what I envisioned, it is certainly worth looking into.