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

Default behaviour of filtering issues is counter-intuitive #22

Open
nmueller18 opened this issue Apr 18, 2024 · 2 comments
Open

Default behaviour of filtering issues is counter-intuitive #22

nmueller18 opened this issue Apr 18, 2024 · 2 comments

Comments

@nmueller18
Copy link

We are using OJS 3.3 with the DNB-plugin vers. 1.5.
By default, the plugin is not showing all issues but only the articles of the current one. Because I only transfer the articles once a year, this always irritates me as very counter-intuitive (believe it or not: I spent one hour in finding the reason why not all articles were displayed in the list. This shows that the respective note is not sufficient). Adding issues to be displayed is not "filtering" in contrast to searching for "deposited" or "not-deposited" articles. So, if the way the plugin works is due to technical reasons (not showing all articles like the datacite-plugin), I would at least rearrange the UI. For example, the "issue"-section could be removed from the "filter"-section and instead permanently displayed.

@ronste
Copy link
Contributor

ronste commented Apr 22, 2024

Hi @nmueller18 ,

thanks for your feedback. Indeed we also had a discusson here internally about exactly this topic when upgrading the plugin for OJS 3.3. Unfortunately OJS 3.3 only offers limited means to modify default components like the list panel used to show the articles. This also includes the filter menu.

We could have removed the issue filter completely, but this would result in potentially very long lists of articles that require quite some loading time. In some of our tests it was unacceptably long (in particular if you only deposit once a year). The way we implemented it was the most acceptable solution.

However, OJS 3.5 (and to some extend already OJS 3.4) will offer better means to create custom UI components and we will certainly reconsider this question with the next upgrade (being scheduled for Q1 2025).

That said, I will leave this issue open and come back to it by the end of the year when I will start to work on the next plugin upgrade. I would be happy to have you in the testing loop when the time comes!

Best wishes,
Ronald

@nmueller18
Copy link
Author

Thank you for your explanation! I am looking forward to the OJS 3.5, and of course, I would be very willing to test the new implementation.

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

No branches or pull requests

2 participants