Entry Editor: change Optional Fields tab

[MartinKarim]

Description of Issue	Possible Solution	Warnings
Optional information is split between tabs (e.g. deprecated fields,optional fields 2)	unify all information that is not mandatory in the optional fields	if the number of fields gets large, make the liest of fields scrollable or reduce text field size
text fields are too big (height and width) to give a good overview of information	reduce size of text fields	-
dropdown fields look too similar to text fields (month)	make dropdown fields more unique	-
ISBN has a special role;	ISBN and other identifiers are migrated to Web Resources	see #4689
-	-	other changes are found in #4686

[LinusDietz]

Check out BibLaTeX Manual: ftp://ftp.tu-chemnitz.de/pub/tex/macros/latex/contrib/biblatex/doc/biblatex.pdf

[Siedlerchr]

DevCall Decision: Good idea, but be aware between the differences of biblatex and bibtex, e.g. different format numbers.
Also add a tooltip what the field represents (e.g. what is number/series or where to find it)

[ddunig2]

Is this issue taken? If not may I tackle it?

[ilippert]

In
JabRef 5.3--2020-12-28--020cc97
Linux 5.9.16-200.fc33.x86_64 amd64
Java 15.0.1
the layout is still the old.

[ilippert]

And I would love to see this change request implemented in a real version :)

[a1819644]

Hi, just wondering if this issue has been taken by someone? If not can my team have look into it.
about us: Group of 4 from University of Adelaide

[ThiloteE]

Hey @a1819644, yes, this Issue is free for the taking. I would suggest to start with the merger of the "optional fields", "deprecated fields" and "other fields" tabs. Jabref would visually become a lot clearer and more orderly. 👍

Edit: Keep in mind Jabref has Bibtex and Biblatex library modes and this issue covers both. You can switch between the library modes by right-clicking on your library:

As an additional reminder, this issue here is connected to a few others that all try to enhance the entry editor and rework fields and tabs.
The meta issue that mentions the other tab-related issues is here: #4686

[ThiloteE]

Please also consider #8368 when working on the merger. Users struggle with quickly finding the desired fields.

[a1819644]

@ThiloteE not sure whats happening but I missing the "other fields"(please see the image). Feels like someone has fixed it and Im thinking about working on the merging the "Optional fields and Deprecated fields".

Also, cause I haven't started typing up the code, So do you mean by creating "draft pull request " where I can mention that my team is working on this issue?

@JustinNgu18

[ilippert]

Also, cause I haven't started typing up the code, So do you mean by creating "draft pull request " where I can mention that my team is working on this issue?

You mentioned it here, so that is sufficient. Please also notify us, too, if you stop working on the issue.
For a generic intro to pull requests: just to ensure you are aware of the idea, check out https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

[ThiloteE]

The "other fields" tab will show up, if you have customized fields in your entry.

Edit: "Other fields" are basically all fields that do not fit BibTeX or BibLaTeX standard entry types. Whoever is working on this is highly encouraged to check out BibLaTeX documentation pages 7 - 15. Current JabRef follows the BibTeX and BibLaTeX standard, hence this is why the "required fields", "optional fields" and "other fields" tabs exist in the first place.

The "other fields" tab is hidden by default, unless there is a field in your entry that is an "other field".
To see an example, just copy and paste the following into the {} BibTeX source tab:

@Article{LuoEtAl20200523cpa,
  author       = {Mufan Luo and Jeffrey T. Hancock and David M. Markowitz},
  date         = {2020-05-23},
  journaltitle = {Communication Research},
  title        = {Credibility Perceptions and Detection Accuracy of Fake News Headlines on Social Media: Effects of Truth-Bias and Endorsement Cues},
  doi          = {10.1177/0093650220921321},
  eid          = {009365022092132},
  number       = {2},
  pages        = {171--195},
  volume       = {49},
  file         = {:Luo et al. (2020-05-23) Fake news. Effects of Truth-Bias and Endorsement Cues.pdf:PDF},
  publisher    = {{SAGE} Publications},
}

Another example:

@Article{zzz,
  aaa = {1111},
}

If the tab is still hidden, click on another entry and then back on the entry with the "other field", then the entry editor refreshes and the tab should show.

[ThiloteE]

@a1819644 Anoop, are you not working on this issue? I have seen you ask if you can work on multiple issues now, but you have not opened a single pull request. Does this mean you are NOT working on this issue anymore?

[a1819644]

@ThiloteE Ohh I'm sorry for creating misunderstanding, Im working on this issue as well. Cause my group is of 4 people we decided to choose one more issue to participate in if we can. Also ISBN issue #8652 got fixed due to change in priority therefore we decide to to choose one more issue #6448.

make sense I will make pr as soon as possible on this issue first.

[ThiloteE]

Ok, thanks for the clarification! Great then! Yes, sorry for 8652. An unfortunate coincidence that the platform had to close down, which necessitated fast and more complex reaction by JabRef maintainers.

[a1819644]

Not a problem, I completely understand!
ISBN search was pretty broken hahhaha. ;)

[a1819644]

@ThiloteE My team team is almost done merging the fields. Currently we are on the test phase and this is how our merging fields is going to look like. Lemme know if you would like to make any changes before me make pr!.

[ThiloteE]

Hey, nice to hear from you :-)

Yes, try to open a (draft) pull request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback.

By the way, meanwhile, #8783 has been merged, not sure if you have seen that.

• Option A) argument against merging with deprecated fields tab:
  I was thinking a little and by now I am also not sure anymore, if it is actually a good idea to also merge with the deprecated fields tab. Since that tab will be hidden anyway (thanks to 8783), unless there are deprecated fields, it will not disturb and if there are deprecated fields it will be a nice notification that there are some and the user probably should move the data from deprecated fields to supported fields :)

• Option B) argument for also merging with deprecated fields tab:
  Merging will make it so that there are less tabs, which confuse users.
  If so, it would be nice if there were some kind of visual difference between optional fields and deprecated fields. (e.g. colour with tooltip).

Feel free to choose :) Both are fine in my opinion. Option A is probably easier, because you don't have to do anything, so maybe that's better.

Of course, Optional Fields and Other fields tab should still be merged!

[ThiloteE]

What I can see from the screenshot:

For type article the fields Title and author are supposed to be in the required fields tab, not in the (merged) "optional fields" tab.

[a1819644]

What I can see from the screenshot:

For type article the fields Title and author are supposed to be in the required fields tab, not in the (merged) "optional fields" tab.

Hey, nice to hear from you :-)

Yes, try to open a (draft) pull request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback.

By the way, meanwhile, #8783 has been merged, not sure if you have seen that.

* **Option A) argument against merging with deprecated fields tab:**
  I was thinking a little and by now I am also not sure anymore, if it is actually a good idea to also merge with the `deprecated fields` tab. Since that tab will be hidden anyway (thanks to 8783), unless there are deprecated fields, it will not disturb and if there are deprecated fields it will be a nice notification that there are some and the user probably should move the data from deprecated fields to supported fields :)

* **Option B) argument for also merging with deprecated fields tab:**
  Merging will make it so that there are less tabs, which confuse users.
  If so, it would be nice if there were some kind of visual difference between optional _fields_ and deprecated _fields_. (e.g. colour with tooltip).

Feel free to choose :) Both are fine in my opinion. Option A is probably easier, because you don't have to do anything, so maybe that's better.

Of course, Optional Fields and Other fields tab should still be merged!

Sure, Haven't seen this merge yet! Will have a look tomorrow. I will choose option A for the time being but happy to make changes later like option B because I honestly prefer the option B.

[a1819644]

What I can see from the screenshot:

For type article the fields Title and author are supposed to be in the required fields tab, not in the (merged) "optional fields" tab.

Yes, I was testing the merging for so long that forget to change the name, thanks for the heads up. I will make sure to change it before pulling request. Also, will remove the ### articles , authors and title from the field.

[ThiloteE]

For anybody who wants to work on this in the future:

The last pull-request (which unfortunately is insufficient to solve this issue here) received important and relevant feedback. Any further attempts should be aware of the following:

[These] changes are affecting several fundamental concepts of the JabRef entry editor UI [therefore] please provide some rationale for your changes, preferably in an ADR (https://devdocs.jabref.org/adr.html) discussing the pros and cons with proper constraints (can be kept short),

Please mind that biblatex itself is distinguishing between required entry fields and optional entry fields. Yet there are still fields left, that are not used by the entry field description for an entry type (the formerly called 'other fields') and the deprecated fields, that biblatex is not using anymore. I totally agree that using multiple tabs to provide access to the optional fields, the other fields and deprecated fields is not the most intuitive and understandable way. If you decide to merge the tabs for different kinds of fields - what you can do - you still need to somehow distinguish between the different kind of fields for an entry type, so it is clear for the user, which fields are part of the biblatex standard for that field in specific (https://ctan.ebinger.cc/tex-archive/macros/latex/contrib/biblatex/doc/biblatex.pdf) and which are not. Maybe a small heading between the fields is possible or to display them in a slightly different color...