Please consider my suggestions for improving the QuickSubmit Plugin interface.
I recently migrated our magazine to your platform from a regular website.
In doing so, I had to migrate articles from previous issues to your site. https://journal.world-ontology.org
There are more than 500 articles in total. So far only half of the articles have been transferred.
In the course of work I encountered a lot of “unnecessary” clicks (operations), in my opinion, the user.
This slows down the process of mass introduction of articles into the archives, makes it tedious, stretches it for a long time.
Please consider my suggestions and requests:
Add the “Extract and Save References” function from the “Metadata” → “References” tab to the plugin after the “References” block.
In the “Add Contributor” block, check the default checkboxes:
«Author» and «Principal contact for editorial correspondence».
In the “Galleys” block, combine all “Add galley” functions in one window with all options saved with one button (without going to additional windows). See figure.
It is desirable by default to offer a selection in the first field “Article.pdf”,
and “Article Text” in the third.
After that the file is loaded.
All fields and the file are saved with one “Save” button
Add the “Identifiers” block from the “Metadata” tab to the plugin.
Remove the first window and leave only the second one:
Thank you for your feedback. I modified this post to be in the “Feature Request” Category as it is more suited to that.
We are trying to make all first “Feature Request” posts follow same structure to facilitate the understanding of the requests and at same time, will ensure no relevant info is missing.
Could you please edit your initial post following this template:
Describe the problem you would like to solve
Example: Our editors need a way to […]
Describe the solution you’d like
Tell us how you would like this problem to be solved.
Who is asking for this feature?
Tell us what kind of users are requesting this feature. Example: Journal Editors, Journal Administrators, Technical Support, Authors, Reviewers, etc.
Additional information
Add any other information or screenshots about the feature request here.
I would also ask that you indicate the current version (e.g. 3.3.0-13) that you are working rom.
Re-formatting this post to these guidelines will allow our developers to more effectively evaluate your suggestions for inclusion in future iterations of the software.
Our admin and editors need to submit a lot of articles from previous issues of the magazine. The QuickSubmit Plugin is used for this purpose. There is a very large number of operations to enter one article. Please optimize the plugin interface to reduce the number of clicks.
Describe the solution you’d like
Add the “Extract and Save References” function from the “Metadata” → "References" tab to the plugin after the “References” block.
In the “Add Contributor” block, check the default checkboxes:
«Author» and «Principal contact for editorial correspondence».
In the “Galleys” block, combine all “Add galley” functions in one window with all options saved with one button (without going to additional windows). See figure.
It is desirable by default to offer a selection in the first field “Article.pdf”,
and “Article Text” in the third.
After that the file is loaded
All fields and the file are saved with one “Save” button
Add the “Identifiers” block from the “Metadata” tab to the plugin.
Remove the first window and leave only the second one:
These suggestions will simplify the user interface and will reduce the number of clicks by several thousand in case of mass submission of articles.
Who is asking for this feature?
Journal Editors, Journal Administrators
Current version: 3.1.2.4
With respect and gratitude — Olexander Khvostychenko.
Hello @syshan4 . I can totally understand your frustration, because I also have to submit several articles wit numerous attachements via Quick Submit. While I think improving the OJS from within is probably the best solution, right now my team created a script that combine your metadata + galleys and dependent files into a Native XML. It only works on the LTS 3.3, but you can test the code from here GitHub - biblhertz/jats_to_ojs: JATS XML to OJS native XML (even if it say JATS, your input can also be a CSV) or test our demo platform https://cont.humanitiesconnect.online/ . Let me know if this can be useful to you.
That sounds like a really neat tool - thanks for sharing! This might be worth sharing if you have a moment to create a post on the “Community Showcase” category to tell our community a little bit more about this tool.
Thanks for the suggestion! I will do asap, I was unsure if this was considered proper content for the forums, bu now I know where to submit about out tool!
You suggest to put this plugin on version 3.3, but this version in terms of usability and convenience (including the plugin for quick addition of articles) in my opinion (and my colleagues) is somewhat weaker than the previous ones. There, for example, to set DOI, you need to remove the article from publication, then set DOI and then resubmit the article for publication (and this is only one point). So it will be even more difficult to add articles. And this plugin, judging by the description, is in no way intended to improve the original plugin for adding articles. It is an add-on that converts XML documents from JATS XML to OJS XML. But JATS for OJS is orders of magnitude more complicated than just adding an article. It has to be done by hand using special markups, and the process of creating 1 article itself can take up to 1 hour. I don’t see anything in this plugin on the link that could make the work of adding articles easier compared to the standard plugin. All the fields are still there and need to be filled in, making a lot of clicks, which can be eliminated in the finalization.
I’m sure that making the minor changes I suggested to the plugin (connecting ready-made blocks, excluding redundant pop up windows and setting default values) will be highly appreciated by many users.
Maybe I’m a cranky user, but thousands of clicks that can be avoided extinguish the joy of the work…
With respect and gratitude — Olexander Khvostychenko.
We’re aware that the Quick Submit plugin could use some UX work – it also uses a fair amount of deprecated code, which the dev team would otherwise be able to remove. Unfortunately we haven’t been able to prioritize that work just yet.
However, it was never intended to import a huge batch of content. At a certain point it’ll be painful to use a web-based tool, no matter how polished it is. For very large back-issue entry tasks, you might find another pathway to be better suited. It’ll probably take a little bit more time to set up, but will overall save time. If you haven’t already seen it, have a look e.g. at the Import/Export section of the Admin guide.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @syshan4 , I think there is a misunderstanding. For my workflow we have developed it using the Native XML schema for OJS 3.3 for two practical reason: 1st our publications are on a system using this version, 2nd this version is marked for Long Term Support. Since the Native XML schema change very often and is not always clearly documented for all versions, we thought that users that need another version could esily adapt the transformer. Last but not least, our tool is not a plugin to any version of OJS exactly for this reason. It is a standalone php based transformation that you run locally to prepare files to be imported by the official Native XML import/export plugin. Since I am aware that not all my team works with command-line application, we are testing a web based platform that, again, will only prepare files to be imported. I will present the tool as suggested by @rcgillis to clear up the confusion.
This looks brilliant! I think there is a lot of interest in making these types of bulk operations more accessible (for instance not requiring command line), as we were working on this in the Copenhagen Sprint last year.
Could you please link to your post in the community showcase once you’ve posted? It would be interesting to continue a discussion there.
As for the original topic, @syshan4 suggestions seem reasonable to me. Of course agree with @asmecher that QuickSubmit plugin shouldn’t be expected to be able to handle huge batches, but there are probably quite a few small to medium-sized import jobs where setting up a conversion to native XML is too convoluted which would benefit from more streamlined workflow.
Thanks @mannemark , I just posted the work we are doing here JATS to OJS Native XML tool I am looking forward reactions and improvement suggestions.
To be clear, as @syshan4 pointed out, this is not an improvement to the quick submit plugin, but a workaround and I don’t want this post to shift the attention from the OP suggestions!
