Moved Add group button between Groups title and filter search field

[dimitrisdimos00]

I have moved the Add group button between the Groups title and the filter search field in the groups side pane

Before

After

Fixes #8398

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[calixtus]

Refs #4681

Thanks for you contribution, although i'm not yet sure if we should merge this change. UI changes should be discussed before merging, especially since we had a big scientific usability study a few years ago that established some principles for the UI.

[Siedlerchr]

I am in favor of adding this. A small step which improves usability

[dimitrisdimos00]

Whatever you say

[ThiloteE]

There HAS BEEN a discussion in #4682. Sorry, I was not aware of this thread. Funny enough, the thread started with #4682 (comment) advocating for locating it somewhere at the top, but somewhere along the way, it ended up being at the bottom of the group nevertheless.

I think the trigger was #4682 (comment), which argues for differentiation between the state "no/a few groups existing" and "many groups existing". Remember, new users have "no/a few groups existing", so for them it would be more intuitive to have the add groups button closer to the top.

[calixtus]

Oh sorry, i just saw this PR and remembered #4682, so i posted the reference here

[calixtus]

maaaaan, #4681 and #4682, this is difficult today.

[ThiloteE]

Actually i am glad this was discussed before. There were some good points. Probably the worst case scenario would be

1. for the add group button to be within the scrollable group tree as is. If there are 500 groups, nobody would want to scroll down to the last group just to add a new group.
2. also problems with collapsing/expending the group tree. "You do not want the panel to enlarge/shrink each time.", as Mlep mentioned here: Move 'Add group' button somewhere closer to groups #8398 (comment).

So as long as these two points are avoided, a decision based on aesthetics, clarity and the ability to catch peoples eye should be possible. :)

[ThiloteE]

Also:

Two ideas for having button below last group:

I think having the button below the last group could maybe work?

• Idea 1:
  Let the groups panel remains its current size even when groups are added or removed and there is some mechanism that detects when the button hits the wall of the web search and libre office/open office panels. Maybe take screen size into account.
• Idea 2:
  Let the groups panel remain its current size, even when groups are added or remove and have the button below the last group if there are 10 groups/subgroups/sub...subgroups or less and have it at the bottom of the groups panel if there are 11 or more, but i fear this will not take screen size into account and will at one point create a weird "jump".

These two options would be the obvious compromise: For both states "no/a few groups existing" and "many groups existing", add group would be at the bottom of groups AND it would also be close to the other group related buttons.

Of course, theoretically, these two would probably be possible and even though it might be a good compromise, i am not sure if worth the effort and also if it is technically possible the way i imagine it...

What dimitris implemented in #8462 (comment) seems good enough 👍 . At least in my opinion.

[tobiasdiez]

I think the current order of first having the filter text box, then the list of groups and only afterwards the add buttons makes sense. You select more often a group then adding one, so the groups tree is more important then the add button and thus should come first. Filtering usually is on top of the things that are filtered, so should be above the tree.

[dimitrisdimos00]

Also:

Two ideas for having button below last group:

I think having the button below the last group could technically work.

• Idea 1:
  Let the groups panel remains its current size even when groups are added or removed and there is some mechanism that detects when the button hits the wall of the web search and libre office/open office panels. Maybe take screen size into account.
• Idea 2:
  Let the groups panel remain its current size, even when groups are added or remove and have the button below the last group if there are 10 groups/subgroups/sub...subgroups or less and have it at the bottom of the groups panel if there are 11 or more, but i fear this will not take screen size into account and will at one point create a weird "jump".

These two options would be the obvious compromise: For both states "no/a few groups existing" and "many groups existing", add group would be at the bottom of groups AND it would also be close to the other group related buttons.

Of course, technically these two would probably be possible and even thought it might be a good compromise, i am not sure if worth the effort...

What dimitris implemented in #8462 (comment) seems good enough 👍 . At least in my opinion.

Thanks much!

[Siedlerchr]

You can always do right-click -> Add subgroup
TO vote click on the option

[koppor]

DevCall result:

The proposal my @MartinKarim at #4681 (comment) is good:

• The button is below the groups
• The button is NOT separated by a space between the groups, right below

[dimitrisdimos00]

So the right path would be to have the add group button right below the filter groups option, just like it was before, just without the huge space between them. Is that correct?

[ThiloteE]

The option proposed by devcall is not on the voting list xD (This is the one i would have gone for, if it were and if it were technically possible.)

[dimitrisdimos00]

The option proposed by devcall is not on the voting list xD (This is the one i would have gone for, if it were and if it were technically possible.)

Yeah.. agreed, I think that's better too

[dimitrisdimos00]

We better add the devcall option to the poll too, I suggest

[koppor]

Since we do not reach the mass of the users, the poll is not representative. The poll results were condidered at the DevCall. Just put the button below the group list without the large white space. This is also described at #8462 (comment).

[dimitrisdimos00]

Can someone merge this?

[ThiloteE]

I tried to test your pull request before merging, but I can't access it via git and it also does not show up at https://builds.jabref.org/pull/

[Siedlerchr]

@ThiloteE It's because it's from a user fork and not on the main JabRef-Repo.
If you want to try it out via git you can use github's cli tool https://cli.github.com/

[Siedlerchr]

@dimitrisdimos00 We first review before we merge. Please update your screenshot in the description

[Siedlerchr]

For me it looks like:

[ThiloteE]

dito :/

[dimitrisdimos00]

I fixed the height bug in the library, now it looks like this:

I used VBox to contain the filter search HBox and the button Hbox and set it on Top

[ThiloteE]

There is just one more tiny legitimacy problem (apart from testing): This position neither goes along with the results of the poll, nor the decision of the dev-call. I personally think it looks fine 👍 (Apart from my personal preference of having Group and Websearch left aligned, but whatever xD) I personally would not mind merging this, but since this is a community project, I am willing to refrain from placing my preference above that of the community that has so readily and in large numbers voiced their preferences and maybe so can you 😅. (50+ people that participated in this poll that did not even have all the options? Respect!)

[ThiloteE]

LOL. I just realized one can click on the poll as often as one wants. It allows users to be counted multiple times. Ok this poll is NOT representative at all. Democracy my *** xD

[dimitrisdimos00]

Ok I now realized it is different from the devcall. I will try to fix that.

[ThiloteE]

Closing this. It has been a while and there does not seem to be a proper fix yet.

If anybody wants to work on this again: Dev Call decision in #8462 (comment) describes the way forward.