interface improvements in next release ?

[piotrr]

Hi,

I work at Cléo/Revues.org, a french platform for digital SSH journals. We use OJS not to publish (we have our own soft for that : Lodel), but to offer our journals a service regarding the workflow management (peer reviewing and copy editing) of articles before publication.

We work with several journals at the moment on our service (http://manuscrits.revues.org) and I made several training sessions on OJS with 10 to 20 persons. From this experience, I noted several problems, especially with the software interface. You’ll find the list down there. I know there is a project under way to redesign OJS interface. So may be my list can be useful to add some points the development team didn’t see ; I’d be very glad to know if the problems I list here will be adressed in the next release or not. Our goal is to identify what we can fix now in the template, and what to set aside and wait for the next release. May be some of the points I mention are caused by my misunderstanding. If it's the case, accept my apologies.

Thank you.


Where --> What

Internal search engine at editor/submissions --> Add a search field to search articles by their Id

editor/submissions/ --> Submissions table doesn’t print properly ; modify default CSS for printing or, much better, add a pdf on the fly generator for the table. The table doesn’t display properly for small screens/low resolution/big fonts in browser. The right side rows are truncated.

editor/submissions --> Submission table should display more information : name or initials of reviewers and their recommandations

editor/submissions --> Submission table : each row should be sortable

/reviewer/submission and reviewer/viewPeerReviewComments --> Should be on the same screen : more than half of reviewers consider their job is done when they have submited theirs comments and forget to choose a recommandation. May be, it would be better to put the recommandation field before the comment field to be sure they choose one. The pop-up should close automatically when they saved their decision.

Email templates REVIEW REMIND AUTO --> Editor should be carbon copied to be noticed when this mail is sent

Email templates --> Have a template for editor decision to authors. I have read discussion of this point in the forum ; and I agree with other users : this feature is abolutely necessary. Presentely, if modifications are required (accepted with modifications), the editor doesn’t have an url to give to the author where a can upload the new version of his article

editor/submissionEditing --> Presently, the copyediting step requires an action from the author. Some journals don’t want that : they want an interaction beetween the copyeditor and the editor (step 1 and 3) and bypass step 2, which is not possible. The process should be unlocked at this level.

editor/submissionEditing --> If copyediting process doesn’t go up to step 3 but stops at 1 or 2, the file can’t be transmited automatically to layout editing. The editor must download, then upload again the file to go to layout. It should be possible to choose with a radio button which version is to be sent to layout, exactly as it is the case when an article switch from reviewing to copyediting

Prepared emails : USER REGISTER --> Journal manager should be carbon copied to this mail

Prepared mails (no template) --> Author notification to editor he submitted a new version of his article : number of article should be in the subject field along with the title

author/submit/ all steps --> A very clear message should be displayed on every screen of submitting process to inform authors they shouldn’t resubmit a new article if they fail or stop the process en route. Presently, many of them resubmit the same article 2, 3, 5, 10 times wich causes a complete mess in editor’s submissions dashboard

author/submissionReview --> Author should be automatically led to author/emailEditorDecisionComment when he upload a new version of his article. More than half of them consider their job is done when they have uploaded their file and the editor will never be informed…

author/submit/ all steps --> In case of multilingual journals, authors don’t understand the language switching system. Usually the system blocks them because they didn’t enter one meta in the default language and they don’t know what to do (except resubmit a new article…grrrr). They should simply have all fields in all active languages on the same screen.

Prepared emails : COPYEDIT COMPLETE --> the editor should be carbon copied to this mail (once again, sorry : may be that comes from our over-control over-centralized french political culture ?)

/manager/reviewForms --> May be it’s a bug in our installation, but when a review form is created and used, it’s impossible to edit or supress it afterwards. All we can do is desactivate but it’s useless because this form is proposed by default each time a reviewer is sollicited.

Dates format --> Dates format should be localized

editor/submissionReview/ --> Reviewing rounds could be folded/unfolded in one click on the same page

Prepared emails : system --> It is possible to create new prepared emails but not to load them. ??? This should be done and implemented in every email form.

Thank you very much for your excellent software. It is very useful to us and the journals we work with. Hope my message will help improve it.

Sincerely,

Pierre Mounier

[asmecher]

Hi Pierre,

Thanks for your suggestions -- the feedback is truly welcome. I'll address each point below:

Internal search engine at editor/submissions --> Add a search field to search articles by their Id

I'm assuming that this is primarily useful for Editors, correct? Adding this would be a fairly simple modification. Do you have any developer resources to contribute? If so, we'd welcome a patch for inclusion in a future release. If not, I'd suggest filing it in Bugzilla as a feature request and we'll implement it when we get the chance.

editor/submissions/ --> Submissions table doesn’t print properly ; modify default CSS for printing or, much better, add a pdf on the fly generator for the table. The table doesn’t display properly for small screens/low resolution/big fonts in browser. The right side rows are truncated.

Unfortunately the current CSS structure is problematic. We're working on a UI overhaul but it won't be rolled into OJS for the next release. We expect the UI overhaul to make use of existing best-of-breed CSS frameworks.

editor/submissions --> Submission table should display more information : name or initials of reviewers and their recommandations

The UI overhaul will introduce a lot of changes to the current set of data -- we've had to work very hard to fit all of the existing information in, unfortunately, so we aren't likely to add this to the default display. However, this is not a very complicated modification to maintain, so if you have a developer I can recommend how to approach this.

editor/submissions --> Submission table : each row should be sortable

This has been implemented in the forthcoming OJS 2.3, which should be released shortly.

/reviewer/submission and reviewer/viewPeerReviewComments --> Should be on the same screen : more than half of reviewers consider their job is done when they have submited theirs comments and forget to choose a recommandation. May be, it would be better to put the recommandation field before the comment field to be sure they choose one. The pop-up should close automatically when they saved their decision.

I'll pass this suggestion along; the pop-up approach we're currently using is good because it's consistent with other comment-based parts of the system, but it might be worth breaking consistency if reviewers find it less confusing.

Email templates REVIEW REMIND AUTO --> Editor should be carbon copied to be noticed when this mail is sent

Agreed, this is probably a good idea -- I'd suggest filing it in Bugzilla as a feature request.

Email templates --> Have a template for editor decision to authors. I have read discussion of this point in the forum ; and I agree with other users : this feature is abolutely necessary. Presentely, if modifications are required (accepted with modifications), the editor doesn’t have an url to give to the author where a can upload the new version of his article

This has been added, but the system does not ship with any templates because we consider it important for the journal to write their own text.

editor/submissionEditing --> Presently, the copyediting step requires an action from the author. Some journals don’t want that : they want an interaction beetween the copyeditor and the editor (step 1 and 3) and bypass step 2, which is not possible. The process should be unlocked at this level.

We have reworked the code in OJS 2.3 to use a different structure to record sign-offs (e.g. copyediting or layout signoffs). This doesn't quite address your suggestion, but in the future we will be making these sections of the code more configurable and the reworked code is the first step in that direction. If you like, have a look at the 2.3 code and consider modifying it for now.

editor/submissionEditing --> If copyediting process doesn’t go up to step 3 but stops at 1 or 2, the file can’t be transmited automatically to layout editing. The editor must download, then upload again the file to go to layout. It should be possible to choose with a radio button which version is to be sent to layout, exactly as it is the case when an article switch from reviewing to copyediting

Agreed -- I'd suggest filing this as a feature request in Bugzilla.

Prepared emails : USER REGISTER --> Journal manager should be carbon copied to this mail

I will discuss this with the team, but I suspect that in most cases that behavior is unwanted. It might result in a very large volume of unwanted email.

Prepared mails (no template) --> Author notification to editor he submitted a new version of his article : number of article should be in the subject field along with the title

Have you tried using the {$articleId} variable in the template?

author/submit/ all steps --> A very clear message should be displayed on every screen of submitting process to inform authors they shouldn’t resubmit a new article if they fail or stop the process en route. Presently, many of them resubmit the same article 2, 3, 5, 10 times wich causes a complete mess in editor’s submissions dashboard

I'd suggest using the article submission checklist (configurable in Journal Setup) to accomplish this. That means the author will have to check a box stating that they are not resubmitting an article.

author/submissionReview --> Author should be automatically led to author/emailEditorDecisionComment when he upload a new version of his article. More than half of them consider their job is done when they have uploaded their file and the editor will never be informed…

Good idea -- Please file in Bugzilla as a feature request.

author/submit/ all steps --> In case of multilingual journals, authors don’t understand the language switching system. Usually the system blocks them because they didn’t enter one meta in the default language and they don’t know what to do (except resubmit a new article…grrrr). They should simply have all fields in all active languages on the same screen.

We've been discussing the confusing UI design of the multilingual forms, but we haven't come to a single clear solution. Suggestions are welcome!

Prepared emails : COPYEDIT COMPLETE --> the editor should be carbon copied to this mail (once again, sorry : may be that comes from our over-control over-centralized french political culture ?)

This email should be CC'd to all assigned editors and copyeditors; would it be possible to make sure your editor is assigned to all submissions as part of the process?

/manager/reviewForms --> May be it’s a bug in our installation, but when a review form is created and used, it’s impossible to edit or supress it afterwards. All we can do is desactivate but it’s useless because this form is proposed by default each time a reviewer is sollicited.

We had to make some interesting decisions to ensure that review forms couldn't be deleted or altered after they became "live" (because that would affect the record-keeping of existing reviews). Have these forms been used anywhere? If not, could you describe the steps to duplicate this problem in further detail?

Dates format --> Dates format should be localized

It's possible to adjust date formats in the config.inc.php configuration file.

editor/submissionReview/ --> Reviewing rounds could be folded/unfolded in one click on the same page

Do you mean to expand or collapse the page to include several rounds of review without having to click on "History"?

Prepared emails : system --> It is possible to create new prepared emails but not to load them. ??? This should be done and implemented in every email form.

Currently it's possible for anyone logged in as a Journal Manager, Editor, or Section Editor to load any email template by passing the "template" parameter to the user's "email" function. For example, you can use something like: http://www.my-journal-name.com/path/to/ojs2/index.php/user/email?template=SOME_TEMPLATE_NAME

Regards,
Alec Smecher
Public Knowledge Project Team

[piotrr]

Dear Alec,

thanks for your answers. Here are mines only on some points. For the others, I'm going to fill bugzilla request as you suggest

editor/submissions --> Submission table should display more information : name or initials of reviewers and their recommandations

The UI overhaul will introduce a lot of changes to the current set of data -- we've had to work very hard to fit all of the existing information in, unfortunately, so we aren't likely to add this to the default display. However, this is not a very complicated modification to maintain, so if you have a developer I can recommend how to approach this.

I'd be pleased to have your recommendations on this point.

editor/submissions --> Submission table : each row should be sortable

This has been implemented in the forthcoming OJS 2.3, which should be released shortly.

Great !

Email templates --> Have a template for editor decision to authors. I have read discussion of this point in the forum ; and I agree with other users : this feature is abolutely necessary. Presentely, if modifications are required (accepted with modifications), the editor doesn’t have an url to give to the author where a can upload the new version of his article

This has been added, but the system does not ship with any templates because we consider it important for the journal to write their own text.

Ok, but how can we implement that feature ? In classes/submission/sectionEditor/SectionEditorAction.inc.php I tried to use :

Code: Select all

$email = &new ArticleMailTemplate($sectionEditorSubmission, 'EDITOR_REVIEW')

line 1823 as indicated here viewtopic.php?f=8&t=3758 . When I send the email, it loads my template but doesn't replace variables such as : {$articleId} - {$articleTitle} with their values. How can I do that ?

Prepared emails : USER REGISTER --> Journal manager should be carbon copied to this mail

I will discuss this with the team, but I suspect that in most cases that behavior is unwanted. It might result in a very large volume of unwanted email.

Ok, forget it, you're right.

Prepared mails (no template) --> Author notification to editor he submitted a new version of his article : number of article should be in the subject field along with the title

Have you tried using the {$articleId} variable in the template?

Unfortunately, I didn't see any email template for this one. The url is : author/emailEditorDecisionComment

author/submit/ all steps --> A very clear message should be displayed on every screen of submitting process to inform authors they shouldn’t resubmit a new article if they fail or stop the process en route. Presently, many of them resubmit the same article 2, 3, 5, 10 times wich causes a complete mess in editor’s submissions dashboard

I'd suggest using the article submission checklist (configurable in Journal Setup) to accomplish this. That means the author will have to check a box stating that they are not resubmitting an article.

You're right and I didn't think about it. Best solutions are simplest !

author/submit/ all steps --> In case of multilingual journals, authors don’t understand the language switching system. Usually the system blocks them because they didn’t enter one meta in the default language and they don’t know what to do (except resubmit a new article…grrrr). They should simply have all fields in all active languages on the same screen.

We've been discussing the confusing UI design of the multilingual forms, but we haven't come to a single clear solution. Suggestions are welcome!

We modified the template to make it display all languages at the same time, and it is more usable. But we don't have examples of journals with more than 2 languages (french and english)

Prepared emails : COPYEDIT COMPLETE --> the editor should be carbon copied to this mail (once again, sorry : may be that comes from our over-control over-centralized french political culture ?)

This email should be CC'd to all assigned editors and copyeditors; would it be possible to make sure your editor is assigned to all submissions as part of the process?

OK, my mistake, I forgot that.

/manager/reviewForms --> May be it’s a bug in our installation, but when a review form is created and used, it’s impossible to edit or supress it afterwards. All we can do is desactivate but it’s useless because this form is proposed by default each time a reviewer is sollicited.

We had to make some interesting decisions to ensure that review forms couldn't be deleted or altered after they became "live" (because that would affect the record-keeping of existing reviews). Have these forms been used anywhere? If not, could you describe the steps to duplicate this problem in further detail?

Yes, we used it once. But it's still a problem because it was a mistake from the journal manager, and she understood the form was wrong when it was used by the first reviewer. Can we just delete it directly in the database ? Do you think we won't break anything doing that ?

editor/submissionReview/ --> Reviewing rounds could be folded/unfolded in one click on the same page

Do you mean to expand or collapse the page to include several rounds of review without having to click on "History"?

Yes : to have an easier and more immediate access to them.

Thanx alot for your answers !

Sincerely,

Pierre

[asmecher]

Hi Pierre,

editor/submissions --> Submission table should display more information : name or initials of reviewers and their recommandations

The UI overhaul will introduce a lot of changes to the current set of data -- we've had to work very hard to fit all of the existing information in, unfortunately, so we aren't likely to add this to the default display. However, this is not a very complicated modification to maintain, so if you have a developer I can recommend how to approach this.

I'd be pleased to have your recommendations on this point.

The Editor's and Section Editor's "In Review" templates are in templates/editor/submissionsInReview.tpl and templates/sectionEditor/submissionsInReview.tpl, respectively. There is a loop in each of those templates that goes through all review assignments for a submission:

Code: Select all

{foreach from=$reviewAssignments item=assignment name=assignmentList}
   ...
{/foreach}

Within that loop, you can use the following to get the reviewer's full name:

Code: Select all

{$assignment->getReviewerFullName()|escape}

To get the recommendation, use:

Code: Select all

{$assignment->getRecommendation()}

Of course, the recommendation is a numeric constant, so you'll have to compare it against the constants defined in classes/submission/reviewAssignment/ReviewAssignment.inc.php:

Code: Select all

define('SUBMISSION_REVIEWER_RECOMMENDATION_ACCEPT', 1);
define('SUBMISSION_REVIEWER_RECOMMENDATION_PENDING_REVISIONS', 2);
define('SUBMISSION_REVIEWER_RECOMMENDATION_RESUBMIT_HERE', 3);
define('SUBMISSION_REVIEWER_RECOMMENDATION_RESUBMIT_ELSEWHERE', 4);
define('SUBMISSION_REVIEWER_RECOMMENDATION_DECLINE', 5);
define('SUBMISSION_REVIEWER_RECOMMENDATION_SEE_COMMENTS', 6);

Ok, but how can we implement that feature ? In classes/submission/sectionEditor/SectionEditorAction.inc.php I tried to use :

Code: Select all

$email = &new ArticleMailTemplate($sectionEditorSubmission, 'EDITOR_REVIEW')

line 1823 as indicated here http://pkp.sfu.ca/support/forum/viewtopic.php?f=8&t=3758. When I send the email, it loads my template but doesn't replace variables such as : {$articleId} - {$articleTitle} with their values. How can I do that ?

Try adding a call to:

Code: Select all

$email->assignParams(array());

...where the email template is initialized, just below the call to:

Code: Select all

$email->addRecipient($authorEmail, $authorUser->getFullName());

Prepared mails (no template) --> Author notification to editor he submitted a new version of his article : number of article should be in the subject field along with the title

Have you tried using the {$articleId} variable in the template?

Unfortunately, I didn't see any email template for this one. The url is : author/emailEditorDecisionComment

My mistake -- that's correct, no template is used for this message. If you like, you can add a template name as above and make sure you use the $email->assignParams(array()); call described above. Or you can modify the existing call to $email->setSubject(...) to include the article ID as well as its title.

Yes, we used it once. But it's still a problem because it was a mistake from the journal manager, and she understood the form was wrong when it was used by the first reviewer. Can we just delete it directly in the database ? Do you think we won't break anything doing that ?

As long as you delete the article and ant review assignments it was used for, that should be fine.

Do you mean to expand or collapse the page to include several rounds of review without having to click on "History"?

Yes : to have an easier and more immediate access to them.

We're working on designing a new UI and code structure for these lists; we'll be introducing it first into OMP (Open Monograph Press) but afterwards into OJS and OCS. It should include things like modals, expand/collapse, and other ways to make it less cumbersome to get the information that's most important while still simplifying the majority of the lists in the system.

Regards,
Alec Smecher
Public Knowledge Project Team