Entry Editor: new Content tab

[MartinKarim]

Description of Issue	Possible Solution	Warnings
users associate comment field with Keywords and Groups	Content tab containing the two fields from General and the Comment field	for General see #4689
Abstract is associated with comment field	add Abstract to Content	-
-	-	other changes are found in #4686

[CaptainDaVinci]

I would like to work on this issue.

[matthiasgeiger]

... again I have some objections ;-)

"Content" is for me referring to the actual content of the entry - i.e., something directly to be found in the work. Thus, "abstract" is fine for me. "Keywords" might also be given in the work - but I think most users are not using the keywords from the paper, but define their own keywords for categorization - so this is already dubious.

And "groups" and "comment" is for not a "content" of the entry, but additional information created by the user to help categorizing the entry and to manage knowledge in the database.

(I btw just noticed that "comment" has been changed to "review" recently)

[MartinKarim]

@matthiasgeiger thank you again for the feedback.

I agree that Content might really not fit for all the fields of that tab, but keywords are likely based on the content or topic of the entry, even if they are changed by the user, so it is at least 2/4. I would also argue that comments on an entry are not purely for management, but also relate to the content of the entry, but that is just speculation. The main problem is the Groups field, which really does not fit the name at all.

The grouping of fields is again based on the co-occurences shown in #4689 . From the results, two designs seemed sensible:

1. A Content tab with Abstract, Keywords and Comment. This would leave Groups to be somewhat misplaced.
2. A Metadata tab with Comment, Groups and Keywords. Here, Abstract would not really fit.

Splitting the fields into two tabs seems a bit overkill to me, as is would most likely leave a tab with only one field (like in the current Entry Editor). I still think that the first option is the way to go because the Group interface in the sidebar makes the text field for it less relevant. But I agree that especially the name of the tab is a big point of discussion and can be greatly improved.

[github-actions[bot]]

This issue has been inactive for half a year. Since JabRef is constantly evolving this issue may not be relevant any longer and it will be closed in two weeks if no further activity occurs.

As part of an effort to ensure that the JabRef team is focusing on important and valid issues, we would like to ask if you could update the issue if it still persists. This could be in the following form:

• If there has been a longer discussion, add a short summary of the most important points as a new comment (if not yet existing).
• Provide further steps or information on how to reproduce this issue.
• Upvote the initial post if you like to see it implemented soon. Votes are not the only metric that we use to determine the requests that are implemented, however, they do factor into our decision-making process.
• If all information is provided and still up-to-date, then just add a short comment that the issue is still relevant.

Thank you for your contribution!

[ThiloteE]

I very much like the structure of this tab proposal. The name "content" may be misleading (2/4).

metadata is closer (4/4), but since all entry-data is metadata, this also might be confusing to users.

How about

• Categorization? I think that is (3.5/4). Abstract is slightly off, but could be tolerated. This name assumes that users want to search, categorize and manage entries based on the data within the fields that are in this tab.
• Entry header? (2/4) would be an alternative, but I think it is less good than categorization. Entry header reflects that at least keywords and the abstract are commonly shown together by publishers on the web, and that explains why users associate keywords with "abstract". See here: