"Add group" no longer exists in JabRef 5.0 (development version)

[AEgit]

JabRef 5.0-dev--snapshot--2019-04-08--master--3d2d61d0c
Windows 10 10.0 amd64
Java 1.8.0_201

I am not sure whether this can be considered a feature request or a bug report, since this "new feature" was already present in JabRef 3.8.2, i. e. what we see in the current development version is a regression compared to this older version. Nevertheless, for now I have put this issue as a "Feature request" (please modify this assignment accordingly, if it is not correct).

1. Open a database
2. Open the groups panel
3. Select a group in the groups panel and right-click this group
4. Note, that you can "Add subgroup" but "Add group" does no longer exist

In older versions of JabRef you could either add a new subgroup or add a new group. The difference was in terms of hierarchy. A new subgroup would always be one level below the selected group in terms of hierarchy, i. e. it would be a subgroup (as intended). A new group would be at the same level of the selected group in terms of hierarchy, i. e. it would be a new group but NOT the subgroup of the selected group (as intended).
This feature is of relevance for large databases with many groups, especially since you cannot drag'n'drop one group to another group if it lies outside the visible upper and lower boundary of the groups panel. This makes it very difficult to place a group at the desired hierarchy level.

[bernhard-kleine]

You can add a subgroup to the group "All entries". That is a new group. The policy is understandable. All groups are subgroups of "All entries".

[AEgit]

Imagine you have a group with 50 subgroups, i. e. not all subgroups will be shown in the groups panel (there is just not enough space). If you add another subgroup to your main group, it will be added at the bottom of the groups panel, i. e. it will be the last subgroup. But you actually wanted it to be in the middle, let's say at position 26.
Previously you could easily achieve this by using "Add Group". Now the only workarounds are:

1. You create the group as the subgroup of the group of interest and then drag'n'drop it to the position you would like to. Given, that currently the group tree will not move, when attempting drag'n'drop this is unreasonably complicated (the example above with 50 subgroups is a simple one - I have thousands of groups/subgroups).
2. You create the group as the subgroup of another subgroup, which is found at position 25 - i. e. one level lower in the hierarchy than it should be - and then raise its level in the hierarchy (e.g., by using drag'n'drop again).

Both solutions are just workarounds.

[tobiasdiez]

I can understand your troubles (especially given the current bugs), but this option was removed because it was confusing, especially for new users (why are there two different options to add a group? which does which?). Given that there are workarounds for more experience users, I'll close this request.

[AEgit]

Hmmm, I get your point, but this means that JabRef 5.0 will be missing functionality that was available in older versions of JabRef. I understand your suggestion that it is planned to allow drag'n'drop while simultaneously scrolling through the groups table (Can you confirm this please?), but even if that was implemented, the workarounds would still be necessary. It would just be more comfortable using them.
But the fact remains, that it will no longer be possible to directly add a group below another group that belongs to the same hierarchy level, if the latter is a subgroup of a group that contains many subgroups. The user will always have to resort to these workarounds.

Is it worth sacrificing functionality for the sake of make things more understandable? Or are you planning on adding another functionality that will make this request functionally obsolete? Otherwise it might be even necessary to point out this behaviour in the help file (?).

[tobiasdiez]

planned to allow drag'n'drop while simultaneously scrolling through the groups table

yes, that should be possible.

Is it worth sacrificing functionality for the sake of make things more understandable?

A clear: Yes! The only problem of JabRef is that it has to many features for to many (strange) use cases, which makes it thus very hard to learn for new users. Thus, one of the main aims of the UI refreshment was to make JabRef more usable while trying to retain as much features as possible.

(You can make this feature request also for your favorite file explorer. Most of them allow to create sub folders by right-clicking in the tree but not on the same level. Arguably, file trees can be even more complex than your massive group tree 😸. There is a good reason why file explorers do not provide such a feature.)

[AEgit]

First of all, thank you very much - if the drag'n'drop feature will work in the future as described above, that will be a huge improvement (irrespective of the problem discussed here).

Then to the actual problem. I have two suggestions:

1. Make "Add group" available again but do not make it the default option, i. e. the user has to activate this option in the preferences menu.
2. Alternatively forget about "Add group" but modify "Add subgroup" so that the user can specify where in the group tree the subgroup is meant to appear. As an example: If you have a group with 50 subgroups and you want to add another subgroup, make it possible to specify that the new subgroup can be added after subgroup no. 25 (probably it would be better to have the names of the subgroups instead of a numbering scheme). As default you can still leave the bottom of the specific group tree where the new subgroup will usually be placed if the user makes no further specifications.

Having said all of this: Mendeley, for example, allows the user to create groups (using "Create Folder...") and subgroups (right-click on a pre-existing older and use "New Folder"), albeit admittedly it is not as powerful as the old JabRef behaviour, where you could create a new group wherever you wanted (in Mendeley it only appears to be possible at the top level).