Groups context menu: Structure remove groups and subgroups

[MartinKarim]

Description of Issue	Possible Solution	Warnings
The button for adding groups is often too remote from the list of existing groups and too inconspicuous	Enlarge the button and place it directly below the list of groups	-
The right click options for groups are too complicated; the menu contains functions, that are misplaced there	Add hierarchy to the Remove group items; Remove items for adding/removing entries	-

[tobiasdiez]

Enlarge the button and place it directly below the list of groups

That's a good idea. But what happens if the user already added a lot of groups and there is no empty space below the list of existing groups? Any recommendations for this case?

[MartinKarim]

While the button should be just below the bottom of the list of groups, it should not be a part of the list. If the space is running out for displaying all groups at once, I recommend to make the list of groups scrollable just above the button. Would that be a solution?

[AEgit]

I am not so sure about the proposed hierarchy for "Remove groups". The old version allows you to remove a group using one click and just moving to the desired option. The newly proposed one, would require you to use a click, move to "Remove groups", wait for the hierarchy to pop up, and then move again to the desired option.
I think this is more inconvenient, if you want to delete several groups. The hierarchy seems unnecessary, given that there are only 2 options anyway.

[Siedlerchr]

I would make it possible to remove them via a keyboard shortcut: DEL and define that default behaviour somewhere

[AEgit]

Ok, that would be an option as well - as long as I can define the default behaviour and have a keyboard shortcut, I am happy with it.

[MartinKarim]

I agree that a menu hierarchy is not necessary based on the amount of options available, neither on the first nor on the second hierarchy level. However, in the removal process there are two decisions to make:

1. What do I want to happen with the group? (remove)
2. What should happen to subgroups? (remove or keep)
   I think that reflecting this two-step process in the menu structure could be helpful.

For a long term solution to remove several groups at once, selecting them and removing them with would be a useful feature to have. But right now it is true that the hierarchy adds an additional step to the removal of groups, which constitutes a trade off between learnability and efficiency.

[AtrusRiven]

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

[apurvachuri]

Thank you @tobiasdiez. We will discuss and get back if we still have any doubts, before starting with the issue.

[apurvachuri]

Just a few more queries and re-confirmation before we get started :)

1. As mentioned in the previous comment, it would be good to have a ‘Add group’ button at the bottom. So, does it mean, we need to remove the ‘+’ button beside Filter Groups? Do we need to remove the ‘+’ sign which is highlighted in red.? And if not, what exactly will be different (functionality wise) in this ‘+’ button which is highlighted and the one that we are planning to add in the bottom.
   

2. The ‘+’ button which we are adding at the bottom, should that button specifically only add a group and not subgroup?

Any guidance would be much appreciated!

[tobiasdiez]

1. Yes, the button next to the "Filter groups" field needs to be removed. The functionality of this button and the newly added one should be the same; only the location changes.
2. Add the moment the button always adds a new group at the end of the groupstree. However, I like the idea that it adds a subgroup if the user has a group selected. If you would like to add this enhancement, please go ahead - but please make this a separate PR.

[apurvachuri]

Hi,

We are trying to implement the part where once a few groups are added in the SidePane, we need to make the "Add Group" button dimmed or less intuitive.

Question: How do we determine this part where after a certain number of groups are added, the button is dimmed?

1. Can we have a constant number, like if the number of groups added is greater than equal to 10 (maybe) then change the color of "Add Group" button.
2. If not the first option, how do we know if the number of group are large enough? Because we thought if the user adds more groups, then a scroll bar will appear and then we can change the color of the "Add Group" button. But again, if the window size changes, this thing does not make sense. So, we are stuck on this point on how to go about working on this part.

Any help/suggestions would be much appreciated!

[tobiasdiez]

Dimming the button after say 10 groups seems to be the easiest solution, and is completely satisfactory in my opinion. The point was to educate a new user "this is how you add groups" and once she understood that, the button can be dimmed.

I like the screenshot!

[apurvachuri]

Hi,

We have created a pull request: #7714

Any suggestions/feedback would be appreciated!

[AEgit]

JabRef 5.3--2021-06-08--9d1c448
Windows 10 10.0 amd64
Java 16.0.1
JavaFX 16+8

Please re-open this ticket, since there are two issues I have encountered so far:

(1) Note, that the new "Add group" button adds groups at the bottom of the group panel NOT below a selected group. So, if your database contains lots of groups (say thousands like in my case) and I want to "Add a group" at a specific place in the group tree, I have to create the group using the "Add group" button, then scroll to the bottom of the group panel, select the newly created group and then drag'n'drop the new group to the place it was supposed to be. Since the group panel does not scroll, when you drag'n'drop a group, you have to scroll to the top of current view of the groups panel, then drop the group, then scroll again to the current view of the groups panel, then drag'n'drop the group again, and so forth until you reach the point where you wanted to have your group.
Fortunately, the "Add subgroups" feature is still included as part of the menu that opens with a rightclick on a group in the groups panel. This somewhat circumvents the problem, since the new group is added as part of its mother group. But the functionality is not the same (imagine if you have a mother group, and so currently JabRef has lost functionality with this new "Add groups" approach compared to older versions.

Suggestion for improvement: If no group is selected, then add the newly created group to the bottom of the groups panel as currently implemented. If a group is selected, then add the new group BELOW the currently selected group.

(2) Is there now keyboard shortcut to delete group in one go as suggested in #4682 (comment)? I tried using DEL but that did not work. As mentioned already here (#4682 (comment)) I was ok with the new behaviour, if a shortcut as alternative was provided to allow deleting groups in one go. Otherwise this implementation is just removing functionality that the old JabRef had.

[mlep]

I agree with @AEgit.

About

Suggestion for improvement: If no group is selected, [...]

Is it possible to have no group selected?
From what I have on the screen, there is always one group selected (at least the group "All entries" is selected).

Some other issues:

• since all user-created groups are subgroups of "all entries", when you had a group, it is always a subgroup of something ("All entries", at least). So, "Add group" should be renamed "Add subgroup". And that will make the button consistent with the contextual menu (right-click on a group), which as a "Add subgroup" item, but no "Add group" item.
• the new "Add group" button can appear de-activated (i.e. in gray instead of blue) while a group is selected. However, it is still functional.

[calixtus]

Thanks for the suggestions. I'll try to sum the remaining issues up:

• New group should be added below currently selected group, if no group is selected, add new group at the end
• Add keyboard shortcut to delete group
• Reword "Add group" to "Add subgroup" --> we keep as is (decision at devcall)
• Distinguish grey of a disabled button from the grey of the not highlighted button.
• Automatic / Manual labels in tabs
• Add show all entries button. DevCall: This was the proposal by Martin. We keep it due to space reasons.
• Add icon tot title of the pane: (see above proposal by Martin)

Did I miss something?
About the wording this is maybe something for the devcall.

[mlep]

@calixtus I could not get "the grey of a disabled button". Unexpectedly, the button is grey while a group is selected: For one of my files, the button is blue with the"all entries" group is collapsed, but becomes grey when this group is expended.

[mlep]

I am now able to make reproducible the issue with the grey button:

1. open the file https://github.com/JabRef/jabref/blob/main/src/test/resources/testbib/jabref-authors.bib
2. click on "Add group", enter a random name, and click OK
   At this stage the "Add group" button is blue
3. click on "Add group", enter a random name, and click OK
   The "Add group" button becomes grey

It occurs when there is more than 9 subgroups displayed under the "All entries" group:

• Collapse "All entries" => the button becomes blue again
• Collapse "By status" => the button becomes blue again

[tobiasdiez]

since all user-created groups are subgroups of "all entries", when you had a group, it is always a subgroup of something ("All entries", at least). So, "Add group" should be renamed "Add subgroup".

While technically true, I think, it better to leave the button text at "Add group" if "All entries" is selected. What about "Add group" if no group or "All entries" is selected; but "Add subgroup" if a proper group is selected?

[koppor]

• Emphasized:
• After often used:

Open discussion: How to introduce first-time users to JabRef and how to educate them. We need to interview users (user studies, ...) to really understand their requirements. Do they always start with JabRef online in 2022?

[koppor]

Add highlighting of the button - similar to search (mouse over - on whole button)

Similar to "add group" button

[AtrusRiven]

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

[koppor]

@AtrusRiven: @calixtus volunteered to work on this issue and handle the checklist presented at #4682 (comment).

#4681 is a rather large one and needs to be handled separately. It is not on our roadmap for this year, though. It could be possible that other volunteers work on it.

[AtrusRiven]

Thanks a lot, @koppor and @calixtus!

[koppor]

@apurvachuri The plus button used to be next to filter as shown here:

We decided to move it away in JabRef 5.3. See https://github.com/JabRef/jabref/blob/main/CHANGELOG.md#removed-2.