koppor / jabref

Collection of simple for JabRef issues. Please submit PRs to https://github.com/jabRef/jabref/.
https://github.com/jabRef/jabref/
MIT License
8 stars 14 forks source link

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

Open koppor opened 4 months ago

koppor commented 4 months ago

(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:

image

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:

renakollmannsuhr commented 3 months ago

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 commented 3 months ago

@renakollmannsuhr Yes, you understood it right.

Similar to Google Contacts:

image

image

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:

image

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

image


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

koppor commented 3 months ago

My description above as short text: https://github.com/JabRef/jabref/issues/6856#issuecomment-786933957

In the long run, it should appear as https://github.com/JabRef/jabref/issues/6191

Ashwin2397 commented 3 months ago

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

image image image

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 commented 3 months ago

@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 https://github.com/JabRef/jabref/pull/11007)


Another proposal was outlined at https://github.com/koppor/jabref/issues/679#issuecomment-1987355108. 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 commented 3 months ago

Right, so if I understand correctly, your proposal at https://github.com/koppor/jabref/issues/679#issuecomment-1987355108 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 commented 3 months ago

@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 commented 3 months ago

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)

screenshot

The groups are:

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 commented 3 months ago

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:

image

"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:

image

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

koppor commented 3 months ago

The configuration of the tabs is possible in the preferences:

image

andr-groth commented 1 week ago

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/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 commented 1 week ago

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.