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

Add some special fields as default columns #7286

Merged
merged 2 commits into from
Jan 11, 2021
Merged

Add some special fields as default columns #7286

merged 2 commits into from
Jan 11, 2021

Conversation

tobiasdiez
Copy link
Member

So that users find these features more easily.

  • Change in CHANGELOG.md described (if applicable)
  • Tests created for changes (if applicable)
  • Manually tested changed features in running JabRef (always required)
  • Screenshots added in PR description (for UI changes)
  • Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

So that users find these features more easily.
@tobiasdiez tobiasdiez added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Jan 4, 2021
Copy link
Member

@koppor koppor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not remove the citationkey as I am used to have the table sorted by the key and search using the key (or am I not any more?)

Why is linked_id removed? Isn't that the URL and DOI thingy?

@tobiasdiez
Copy link
Member Author

The citation key is removed as it contains mostly redundant information that is already displayed (in the default configuration it is author + year). The linked doi column is removed since this has only limited use cases in my opinion. Jabref is usually able to get bibliographic infos and the fulltext automatically, so there is no need to go to the journal website. Of course both columns have their uses and some users will readd them, but I don't think they need to be shown by default.

@koppor
Copy link
Member

koppor commented Jan 10, 2021

I think, my thoughts were that in .tex documents, entries are linked using the key. This key is different from the label put in the bibliography printed at \printbibliography. Students do not know that easily. Thus, my idea was to show the key prominent somehow so that they are reminded of that fact. - I think, I can live without the citation key column as default.

In the context of Cloud computing, more and more references are Web pages. This research field is still an important one. - If I recall correctly: With that icon, it was easy to jump to the web site. Just a single click. This was possible, because we merged DOI and URL into a single field. We did not merge URL and file into a single column, because we wanted to distinguish between local files and remote resources. I wonder why we prefer local resources over remote ones with this PR. I would not remove the file column even though one could also see in the tabs that a file is linked.

@koppor
Copy link
Member

koppor commented Jan 10, 2021

Maybe, we could merge the internal and external links into one "smart" link column. I just checked my personal library.

I have links only if I don't have a local copy. Thus, my preference would be:

  • display file link
  • display DOI link
  • display web link

grafik

@tobiasdiez
Copy link
Member Author

Yeah, I guess it strongly depends on your subject. In physics and mathematics, it's still pdf-first. I think, the last survey showed that this is our largest target group. But yeah, we sadly don't have good data for how many people click on the linked files / urls. So it's somewhat of a guessing game, partly based on our own experience.

@Siedlerchr
Copy link
Member

As I said earlier, just add the new fields and keep the original fields

@koppor
Copy link
Member

koppor commented Jan 10, 2021

I think, this depends on #6601 to have easy configurable columns.

@koppor
Copy link
Member

koppor commented Jan 10, 2021

Discussion with @stefan-kolb:

CitationKey

Against removal: We are still a BibTeX management tool. The most important thing of a BibTeX entry is the bibtex key. When we remove that, we might seem not a BibTeX tool any more

Pro removal: With the default BibTeX key generator, the author and year is


Discussion on special fields:

  • Star rating is very useful, because after reading a paper, one can certainly assign a star rating
  • Do we really need "printed" in the year 2021? Are the "modern" researchers not more screen-reader ones?
  • I as user should remember whether I read a paper or not (read status).
  • Priority is a very special case and certainly not the main use case.

Special fields may pollute the interface - not a "clean interface".

It is questionable whether all features fit the table. Maybe, therefore the proposal was to remove the BibTeX key.


URL column:

  • For quality assurance, the functionality to go to the web site is ofen used.
  • The field width is small.
  • @Misc often used the URL. For instance, for a facebook thing.
  • Searching in the current entry editor for the URL field is cumbersome
  • Should NOT be merged with the file column, because files are something different than external URLs

Discussion on other fields:

  • Most users will need
    • PDF
    • Author/Editor
    • Title
    • Year
  • Not absolutely necessary
    • Journal/Booktitle

Summary

  • Remove citation key column
  • Keep URL column
  • Add star rating

@koppor
Copy link
Member

koppor commented Jan 10, 2021

BTW: This reminds me of the Eclipse perspective feature: https://www.tutorialspoint.com/eclipse/eclipse_perspectives.htm

We are discussing there different persepectives

Our aim seems to be to bind interested JabRef users on JabRef. We mostly assume that users longer using JabRef are curious about new features (which I did not persieve).

Each of them requires a dedicated perspective to be productive. Currently, we do not have these perspective explicit, but argue about a perfect one fitting for all

@tobiasdiez
Copy link
Member Author

Thanks for the discussion @koppor and @stefan-kolb! I've now implemented your suggestions. The only things were I disagree are

I as user should remember whether I read a paper or not (read status).

You should also remember what is contained in the paper, and we still have a comment tab where people can put their summary into. Fact is, people forget stuff and it can be handy to keep track of what paper you already read / still need to read.

Priority is a very special case and certainly not the main use case.

Given that there are so many things to read, I would say prioritization is one of the most important features to manage reading lists.

For these reasons, I added these two columns. They should be useful for all "perspectives" (but of course depend on the user's workflow). Can you agree with adding these two columns as well?

@koppor koppor removed status: devcall status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers labels Jan 11, 2021
@koppor koppor merged commit 7f26a3a into master Jan 11, 2021
@koppor koppor deleted the defaultColumns branch January 11, 2021 21:29
Siedlerchr added a commit that referenced this pull request Jan 13, 2021
…dtask

* upstream/master:
  Update guidelines-for-setting-up-a-local-workspace.md (#7339)
  Updates to colored group indicator for cited entries (#7173)
  Add some special fields as default columns (#7286)
  Add a more descriptive path when Directory cannot be found (#7232)
  Bump antlr4 from 4.9 to 4.9.1 (#7327)
  Bump unirest-java from 3.11.09 to 3.11.10 (#7329)
  Bump mockito-core from 3.6.28 to 3.7.0 (#7328)
  Bump antlr4-runtime from 4.9 to 4.9.1 (#7330)
  Bump gittools/actions from v0.9.7 to v0.9.8 (#7331)
  Update to gradle 6.8 (#7324)
  Link to GitHub contributors in about dialog (#7319)
  Fix snapcraft upload (#7263)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants