Create a new tab in the entry editor showing all set fields

[koppor]

(META: This issue is reserved for a university course. Please only work on it if it is part of your assignment)

Currently, JabRef devides the fields of the entry editor using categories:

A user needs to click through tabs to see all set fields.

In this task, the tabs "Required fields", "Optional fields", "Other fields", "Comments", "General", and "Abstract" should be replaced by a single Tab "BibTeX" showing the set fields only

After that, it should still be possible to add a new field:

• Variant 1: Two text fields: One with the field name, the other one with the field content - and a plus button. Similar to Google's contact manager. One should be able to use org.jabref.model.entry.field.FieldFactory#parseField(java.lang.String) for creating the appropriate object in JabRef.
  
• Variant 2: Offer a button list to add fields. Then, a new FieldEditor is shown using the selected field. Similar to the dialog when adding a new entry
  

[renakollmannsuhr]

Hello @koppor thank you for setting up this issue for our class!
Could you clarify which "set fields" you mean for us to include in the new single BibTeX tab? Are they the set fields from all the tabs we are replacing with the new tab?

[koppor]

@renakollmannsuhr Yes, you understood it right.

Similar to Google Contacts:

Not asked in the issue, but desired:

List all required fields (as currently happening in JabRef) and add buttons to add optional fields. Google Contacts does that in the edit view:

When pressing "Show more", some more fields are displayed. That could be the Optional2 org.jabref.model.entry.BibEntryType#getSecondaryOptionalFields fields in BibTeX:

---

You can retrieve all set fields by org.jabref.model.entry.BibEntry#getFields.

[koppor]

My description above as short text: JabRef#6856 (comment)

In the long run, it should appear as JabRef#6191

[Ashwin2397]

Hi @koppor, is this an accurate representation of what you’re asking for?

In step 1, we observe that all required fields, set or not, are also displayed along with all set fields. In other words, all fields displayed are either set or required.

[koppor]

@Ashwin2397 You are describing an enhancement of Variant 1, which is OK for me. Go ahead.

In Step 2, the dropdown should contain only fields not being already present

In Step 3: If possible, the order of org.jabref.model.entry.BibEntryType#getAllBibFields should be followed (see also JabRef#11007)

---

Another proposal was outlined at #679 (comment). Similar to your "1.", but "2." is different, because all important optinal fields (org.jabref.model.entry.BibEntryType#getPrimaryOptionalFields) are displayed as buttons. Finally, the add behavior you describe uses org.jabref.model.entry.BibEntryType#getSecondaryOptionalFields as basis.

[Ashwin2397]

Right, so if I understand correctly, your proposal at #679 (comment) denotes the following:

1. Add a button for each optional field to add said field
2. Add a Show More button to display additional buttons for fields that are retrieved from getSecondaryOptionalFields

For both 1 and 2, why do we bother with adding a button to add a field? Isn't that an extra clickthrough? Why can't we have all required and optional fields listed and a Show more button display additional fields?

[Ashwin2397]

@Ashwin2397 You are describing an enhancement of Variant 1, which is OK for me. Go ahead.

@koppor isn't this more like variant 2 though 🤔 ?

My understanding of variant 2 is that we click on a button to then reveal a list of fields to add. Unless you're saying that the list of fields is not hidden behind a button click?

[koppor]

For both 1 and 2, why do we bother with adding a button to add a field? Isn't that an extra clickthrough?

Google's UX experts came up with that UI patterns. I believe that they have thought that well through.

However, I think, I understood Google's design wrong. The buttons of them seem to add group of editing fields.

Maybe you can do that?

Like "Recommended" and "Other" below (no buttons, but the fields as you outlined)

The groups are:

• Required
• Title Details
  • StandardField.SUBTITLE, StandardField.TITLEADDON, StandardField.MAINTITLE, StandardField.MAINSUBTITLE, StandardField.MAINTITLEADDON
• Identifiers
• Others

I don't know about the other 100 fields. The BibLaTeX manual explains all fields, but does not semantically group them.

(Keep the tab "Comments" in JabRef, I think, this should not be integrated)

Why can't we have all required and optional fields listed and a Show more button display additional fields?

Try out and see if its not too overwhelming.

---

Note, you can think what you would expect as user. I assume, you'll also have to write some scientific document (master thesis?) and manage your references somehow...

[koppor]

One more thing - the handling in "org.jabref.gui.entryeditor.EntryEditor#createTabs" is a bit WTF. -- In org.jabref.preferences.JabRefPreferences#setLanguageDependentDefaultValues one sees the default configuration for the tab "General" and "Abstract". "Abstract" is a tab with one field (abstract), whereas General contains interesting things:

"Abstract" should stay. (Because very long)

The fields of "General" should be moved to the new tab (if possible). Especially, a user is interested in doi, keywords, url, file, owner, ...

The following fiels are JabRef's special categorization / tagging of entries:

They can stay in "General" (or moved to "Categorization" until we come up with a better name)

[koppor]

The configuration of the tabs is possible in the preferences:

[andr-groth]

The configuration of the tabs is possible in the preferences:

This is really a hidden gem that I never stumbled upon after years of intensive use of JabRef. Related to my comments on JabRef#11026, the option Custom editor tabs could be improved with some sort of table or some dragable tags so that the user can more easily configure JabRef for their needs.

On the other hand, the above mechanism could also be an option, so that the user can configure their personal tab, which is then saved in Custom editor tabs. That is no add option per entry (which I find cumbersome in Google Contacts) but just to configure the personal tab.

[koppor]

so that the user can configure their personal tab, which is then saved in Custom editor tabs.

We want to have JabRef "knobless". Meaning: The default configuration is close to the best configuration. One way to achieve it is to have all users configuring JabRef as they like and then harvest these configurations and to try to find the best one. I am hoping that this step can be skipped and we can find a good concept in discussions.