Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User interface: Simplify Select Entry type form #6730

Closed
horror-vacui opened this issue Aug 2, 2020 · 13 comments · Fixed by #7485 or #7494
Closed

User interface: Simplify Select Entry type form #6730

horror-vacui opened this issue Aug 2, 2020 · 13 comments · Fixed by #7485 or #7494
Labels
good first issue An issue intended for project-newcomers. Varies in difficulty. type: feature ui

Comments

@horror-vacui
Copy link

Coming from 10+ years in Zotero and then Mendeley where I've always used the web scrappers of the applications, JabRef's Select Entry Type forms seems overwhelming at first sight with all the different article types. A new user wants to create his new entry as simple as possible, and looking at that form gives them the feeling that they have to study these article types first. If a user has trouble to carry out the most basic operation in a program, they will probably abandon it, even if the program has all the features the user needs.

Since in the vast majority of the cases all the data related to an article is already on the web Web search or DOI is used, and probably should be used to avoid typos.

My proposal: by default hide the different entry types and leave only the ID type and ID fields. The rest can be blended out with a radio box, or these could be put into another tab, or put below the ID field and be separated in a visually strong way. This would make it clear that entry through the ID is the best, and advised method for creating entry for an already existing publication.

@Siedlerchr
Copy link
Member

Thanks for your suggestions, We always have to keep the balance between power users and newcomers.

  1. If you have an DOI you can simply paste it on the table and JabRef will automatically create an entry, For other there is already a suggestion: Add "generate bibtex from identifier" button in toolbar #4183
  2. We have another button in the toolbar which is called New article. Our telemetry data showed that 90% of the entry types are articles so we added that.
    A third option is to use the JabRef Browser extension to import directly stuff from the web into the library.
  3. All those entry types in the dialog already have a tooltip explaining their usage (This is a new feature in the current dev version) And the difference between an article and a book should be already n the knowledge domain of the user.
    And it doesn't matter which type you choose at first. You can always do a right clik on the entry and change the type or manually change it in the bibtex source code.

I personally see no reason for further

@horror-vacui
Copy link
Author

Thanks for the prompt answer. There were some new and useful information to me, though I've used jabref a few times and searched and googled how to use it.

Your reply might indicate that there is only article and book type, but I've 19 different document types in the new entry form. Although the entry type can be changed, it is not 100% straightforward which one to choose. Proceedings, inProceedings, inCollection, and Conference are not clearly different, but the latex template might handle them differently. I remember spending few hours to figure out why do I have different typesetting in the bibliography for a paper. Sure, one can look it up in some hard to find bibtex reference, but I do not suggest manual entry to nobody. Also, most of the users are not bibtex/biblatex experts, they just want to ease their reference management for their papers, or just to have a collection. I still think that my original proposal would be useful.

Call me old-fashioned, but I expect to find all functionality of a program in the menus :) I did not spend too much time to familiarize myself with the toolbars yet. About the toolbar text though: I would change "new article" to "new article entry" to emphasize that it is entry as well. Of course you can expect from the reader to figure it out, but it does not require any more space.

These all were feedback about the program. I've used it regularly in the last months, so this was not based on a short 2 minute usage. It is your call as developers whether to change the program.

@tobiasdiez
Copy link
Member

The user interface is indeed way too complicated for the normal workflow. I would suggest to split the entry types into two categories: "common" (or "often used", "recommended") and "others".

@tobiasdiez tobiasdiez added the good first issue An issue intended for project-newcomers. Varies in difficulty. label Aug 3, 2020
@ilippert
Copy link
Contributor

ilippert commented Aug 3, 2020

often used

I like the "often used" and "other/more".
Now the question is, who defines often? I suggest the following:
for a new library, we define a default recommendation. For an existing library, automatise a scan, once a month, to count which entry types are most used in this library and offer the top 5 entry types. And/or, allow to define in the Preferences which entry types to "promote" to be "recommended".

@tobiasdiez
Copy link
Member

Here is the data from our analytics:
image
I would simply take the top 5 as "often used". In the order they appear there, maybe put "Mics" at the end of the list because that should be the last resort and it is generally recommended to choose more specialized types.

@ilippert
Copy link
Contributor

ilippert commented Aug 4, 2020

Thanks a lot for the statistics. good to know. I think this is a good start. Still, as a researcher in a specific field, with specific conventions of which literature gets published/referenced, I still think, that it would be amazing if we could adapt such a list individually. Of course, this is not a priority.

@kennedy-chan
Copy link

Is anyone working on this? I'd like to give this a go.

@tmrd993
Copy link
Contributor

tmrd993 commented Mar 2, 2021

The user interface is indeed way too complicated for the normal workflow. I would suggest to split the entry types into two categories: "common" (or "often used", "recommended") and "others".

Like this? Entry type information (Bibtex or IEEETran) is lost though, is that okay?
newentrywindow

When expanding others:
newentryexpanded

I can't seem to get the window to resize properly though.

@tobiasdiez
Copy link
Member

This looks like a nice improvement indeed. Can you open a PR for it, then we can have a look at the resize issue.

@mlep
Copy link
Contributor

mlep commented Mar 5, 2021

@tmrd993 Thank you for your contribution in the redesign of the window. The redesign is effective in BibTeX mode (and is great). Could you contribute to the same redesign but for the biblatex mode?

@tobiasdiez or @calixtus: please, could you reopen this issue?

For your information, currently, the window looks like this in biblatex mode:
ksnip_20210305-104554

@tmrd993
Copy link
Contributor

tmrd993 commented Mar 5, 2021

@tmrd993 Thank you for your contribution in the redesign of the window. The redesign is effective in BibTeX mode (and is great). Could you contribute to the same redesign but for the biblatex mode?

Sure! Are the top 5 entry types the same for both bibtex and biblatex mode?

@calixtus calixtus reopened this Mar 5, 2021
@tobiasdiez
Copy link
Member

Are the top 5 entry types the same for both bibtex and bitlatex mode?

Yes!

@mlep
Copy link
Contributor

mlep commented Mar 5, 2021

Works great. Thank you @tmrd993!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue An issue intended for project-newcomers. Varies in difficulty. type: feature ui
Projects
Archived in project
Archived in project
Development

Successfully merging a pull request may close this issue.

8 participants