Entry Editor: new Web Resources tab

[MartinKarim]

Description of Issue	Possible Solution	Warnings
Identifiers are split between tabs, although they are similar; URL is associated with the identifiers by the user	create Web resources unifying identifiers from General ,Optional Fields and URL in one tab;	-
button layout is unclear	unified button layout for all fields	More buttons can be added if a function becomes available
-	-	other changes are found in #4686

[Siedlerchr]

In general a good idea, but note that for the entry type online or www the URL field is a required field.
Please keep also in mind that different entry types have different fields (required and optional and some are kept for compatibility)
This applies to the general layout of the entry editor.

See section 2 of the biblatex manual
https://ctan.org/pkg/biblatex?lang=de

[MartinKarim]

Thank you for the notification. The case that Web Resources fields can be required or optional fields as well, is indeed a problem.
It could be solved by creating, for example, two URL fields, one in the Required Fields and one in Web Resources, which might, however, confuse the users, if they notice that the field exists twice. To avoid that, the URL as an information and as a resource could be split into two differently named fields. Regarding interaction with the resource, I would only place buttons in the Web Resources tab and not make interaction possible in the Required Fields to help the users associate the Web Resources tab with resource interaction more clearly.

The fact that required and optional fields are different for each entry type is less problematic, I think. Although some Web Resources are only available for certain entry types (e.g. ISBN for books), the fields could be dynamically generated, as is already the case with the required and optional fields.

Regarding the general layout of the entry editor, I think it is possible to deviate from the structure given by biblatex, especially in classifying fields. The manual itself states,

that the ‘required’ fields are not strictly required in all cases

and that

bibliography styles which come with this package can get by with as little as a titlefield for most entry types

Users are also not bound as heavily by the rules of biblatex, but more by the rules of the citation style which they use. I think that Other Fields and Deprecated Fields (or Optional Fields 2) can be dismissed because the classification into required and optional fields might be sufficient for the users' needs and at the same time it is easier to have less tabs and fields to consider.

[CaptainDaVinci]

I would like to work on this issue.

[matthiasgeiger]

As much as I like most of your proposals @MartinKarim, I'm not really fond of this proposal here.

At least the term "Web resources" is misleading for me: Only URL is real "web resource" - and maybe also the DOI, as it can be used to determine the official site assigned to the paper.
But ISBN for me is just an identifier for books and Crossref is a reference to another entry in the database - so not related to Web resources at all.

My first idea would be to rename the tab to "Entry identifiers" - but crossref is not really matching here and also the "URL" is not really an "identifier" for the entry itself...
And I do not know whether this term is really understandable for the normal user... Maybe "Links and Identifiers" would be an option?! But also this denotation is not really convincing for me...

Moreover, also the general design of the content with the buttons next to the fields is not really appealing to me.

And for me also the current (tooltip) labeling of the buttons ("Lookup DOI" and "Get Bibtex data from DOI/ISBN") is more clear than the "Search" and "Get Info" you proposed.

I'm not sure what the other @JabRef/developers are thinking about this?

@CaptainDaVinci Thanks for your interest in supporting us here - but I would suggest to wait for an agreement of how to proceed here.

[tobiasdiez]

The current grouping of the entry fields mostly feels like a random assignment and I really welcome @MartinKarim 's work to give it a more coherent structure. On the other hand, I also agree with most points raised by @matthiasgeiger. Thus, I would propose to discuss (and brainstorm) about the general layout of the entry editor etc. in the upcoming devcall.
Until we have a clear decision on these matters, I remove the "good-first-issue" label from this (and the other related issues).

[MartinKarim]

@matthiasgeiger thank you for your feedback, I think there are some important points to adress here.

1. The Web part: It is right that not all of the fields in this tab are web-based. But as you stated, the URL is definitely web based and as the DOI has digital in its name, it would also fit here. Crossref was always described to me as an ID of the project found at crossref.org, but I might be misinformed on that matter.
   Apart from these cases, ISBN and ISSN are surely not web based, but the reason to call the tab Web Resources anyway was the following: While some of the listed fields are not originally dependent on the web, the user is given the possibility to interact with them like that. The automatic search for an ISBN or the update of an entry through it is done by connecting with the web. So while the information in the field is independent from the web, the interaction with it is not.

2. Include Identifiers in name: As you said, it would be possible to just make an Identifier tab by excluding the URL (and possibly crossref?) and this was actually my first approach to the problem. But in a card sorting task, most of the time participants grouped the URL with the identifiers (see figure with co-occurences at bottom), making the current solution more fitting.
   While the URL could also be grouped with the file field, this would have interferred with the design of the Attachments tab (see Entry Editor: new Attachments tab #4691 ). But a redesign in that matter would be possible, of course and maybe more clear to the users.

3. The button layout/design: I am not enirely sure if your problem is only with the layout of the buttons or their design as well. The design of the buttons is of course something than can be changed to better fit the theme of JabRef and should just be consistent throughout the application. I would just not advise to make the buttons completely flat (i.e. no color, no shadow) or to make them too small.
   The layout for the buttons was mainly a way to show a clear pattern of possible interactions with the available fields. For this it is not necessary that the buttons are outside of the text fields, but I am not sure if placing them inside the text field is helping the user or looking more appealing.

4. Text on buttons/tooltip: I am convinced that using icon-only buttons should be limited to cases where an icon has a clear and completely unambiguous meaning in a certain context and that text should be the default if possible. This does, however, not concern the tooltips at all. I never meant to remove or even change the tooltips and I believe that they are a great additional guidance for the user. So that should not be a problem.

@tobiasdiez I also think that discussing that matter in the devcall would be a good idea, I will try to be there. And I can of course update the issues for the entry editor, if changes are "approved".