Restructure fields and tabs displayed in the entry editor

[koppor]

How should a restructured entry editor look like?

The structure of tabs and fields in the entry editor are quite outdated. We should find a better one.

Refs #2448 #730 #1101

Currently, the logic handles optional fields 2. This is not good. Optional fields to should be a UI issue only.

[tobiasdiez]

I would even propose to restructure the entry editor completely. The current distinction in required and optional does not always reflect the importance of fields. For example, I almost always assign a file and keywords to an entry but these fields are not required. Moreover, information that is related (e.g. journaltitle, pages, issue etc. ) is split into two tabs since some fields are required and some not.

Hence I would propose to group fields into two tabs "main information" and "details".

[lenhard]

I think we have reached a point where restructuring the entry editor has become a viable option again. It is far more stable now.

So how should a restructured entry editor look like? For biblatex? For bibtex? Which tabs should it contain? Opinions are very much welcome :-) @JabRef/developers Is everyone happy with Tobias' suggestions?

[koppor]

At the details, I would even add a button for adding more fields. Meaning: Not all empty fields should be shown as default, but one should be able to add own fields by his own...

A user should NOT be given the opportunity to key in the field name by hand. JabRef should still now the possible fields in advance. Thus, the proposal with a button.

For an excellent solution, JabRef should know the bst files and know which fields are supported. For instance, LNCS supports different fields than LNI and IEEEtran. -- The user should be able to configure that. If we don't it, maybe our bibtexvm can be of help... Then, the task is on my side :)

[tobiasdiez]

I like the idea of @koppor but the UI needs a bit of thought. A simple drop-down menu for selecting the field does not work if JabRef suggests over 20 possible fields (eg. for biblatex). Maybe break the choices down in categories (commonly used, person-related, journal-related, other stuff).

When we are at "wünsch dir was", I really like the editor of Papers 3. They don't show a bunch of text fields but nonetheless allow the user to very quickly edit the data. However, this is a lot of work to get right...

[Siedlerchr]

I currently like it as it is so far. agree with @koppor that the key field should not be visible by default.
The required and optional fields are coming from the biblatex standard. They more or less state the fields for an entry type.
Maybe a default "Article" for new Entry would be useful. We maybe should better ask your users...

[mlep]

Whatever the design, I found it very useful to be able to identify quickly the required and optional fields.

[fspreng]

Since no consensus about the reconstruction of the entry editor has been found yet and reworking it will take some effort, would it be a good temporary solution to give the user at least the possibility to hide unwanted tabs? This may already help in preventing the user from being distracted from the important information by unimportant one, for instance the duplications of fields appearing as part of the tab "deprecated fields".

[Siedlerchr]

@fspreng I don't have this deprecated fields tab. I have Required, Optional 1 and Optional 2 in the curretn dev version in biblatex mode
It may depend on what you have defined in Options -> Setup General fields (fields for all entry types)
This is my layout:
https://help.jabref.org/en/GeneralFields

Abstract:abstract
Comments:comment
General:crossref;keywords;file;groups;owner;timestamp;printed;priority;qualityassured;ranking;readstatus;relevance

[fspreng]

Thanks for the prompt feedback @Siedlerchr. You are right, this behavior changed since the latest release version. Many thanks for the hint and sorry for the inconvenience! So, forget about the example I gave in my previous post. However, the possibility to hide certain tabs may still be advantageous to the user. For example (hopefully a better one than last time), we introduced an additional tab dedicated to our reference library, which should be visible to our librarian only. Of course, one can remove the definition of this extra tab from the general fields menu (as you mentioned), but the additional fields belonging to this tab are displayed under "other fields" as well. This is at least the case with the current development version when running the database in bibtex mode, which is the setup I used for testing.

[koppor]

Extension of the idea written at: #2790 (comment)

A new field can be added by just typing the name and a cool auto completion.

Example sketch (field order reversed)

As tabs there should be "bibliographic data" and "meta data" (containing abstract and keywords. @MartinKarim) and "PDF" (containing the attached files and #2838).

[MartinKarim]

A suggestion for restructuring the Entry Editor can be found in #4686

The details for the changed, removed and newly created tabs can be found in #4687 #4688 #4689 #4690 #4691

[LinusDietz]

superseded by https://github.com/JabRef/jabref/projects/6