Talk:Reviewer File Limitation
I like suggestion 1. Related to the listbuilder to select files for a reviewer, I think that we can use a selectable grid instead. It is already used in other places where you want to set the visibility of the files or want to choose which one will be sent to next stage. It has the advantage of letting the editor donwload and see the file, see notes, etc. The only thing that we should add to the interface is a select/deselect all button, so users can easily interact with many files.
Point taken -- and I wonder if we shouldn't try conserving real estate by putting it in an accordion. It'll be sometimes used in OMP and less frequently in OJS. By default it should include all the files selected for that review round.
I have a strong preference for suggestion 2, maybe because this was what I had already been thinking of, and I think there's real value in using the same kind of patterns throughout the system for users' sake.
Given that the copyediting grid isn't specced out fully, but that there may be substantial room to provide a good general suggestion, I like the Copyediting Suggestion 2 as an overall general solution. I envision this as a "File consideration" grid:
- you have a list of files associated with that particular stage of the workflow, all listed on the grid;
- you can click an "assign" button to assign users (in the most general case, anyone in the system, but this could be controlled to allow eg. only copyeditors, or reviewers, etc.);
- the "assign" button brings up an email notification, along with a list of the files which can be checked (& a "select all" option);
- after a user is assigned, they are listed under each file name they have been assigned to, with a clear indication whether they have responded or not & links to their response (the image for Suggestion 2 at http://pkp.sfu.ca/wiki/index.php?title=Copyediting captures this more or less perfectly).
It would be great to eventually/possibly also include some information in the "Consulted by [copyeditor/reviewer/etc.]" checkbox to express the user recommendation, if one is available. So for example the checkbox might be red if a reviewer recommends rejecting the article; green if accept; yellow if heavy revisions required. In the case of copyeditors, maybe this wouldn't be an option at all -- there's just considered (checked) or not considered (unchecked).
I agree with James when he talks about consistency. But I don't know if review process should be more complicated. Does users need all that power? (single response, text and files, for each file assigned; overall view of each assigned user and it's response state, task notification for each assigned file, etc). If we think that this is going to really help more than complicate, then sure, we should go that way. But if we think that the majority of users will only work with reviewers assignment to the review round, not limiting files viewing or expecting a single response for each file, than I think that suggestion 1 is better, because it allows advanced users do what they want and don't complicate things for the others.
Still thinking in suggestion 1, we can even go further and initially present just an unchecked checkbox with something like this: "Do not allow all files visible to reviewer". If users want to restrict access, they can click on that checkbox and only then the selectable files grid should be visible.
I really like Bruno's last suggestion. Assign reviewers to a review round and use "do not allow all files to be viewable by reviewer" and then choose the files to be associated with the reviewer. There could be a grid row action that lets an editor view which files have been assigned to a reviewer, and edit that list. From a database perspective, it would be a matter of relating files to a particular review assignment, instead of relating them via the review_round_files table.