Review of wireframes from week 2
Hi @conneelyb and @csikari
In week two we focused on the Managing and handling Editors check of the submitted questions and the review process. (User stories and other documentation here)
Dashboard (all roles)
Based on feedback from yesterday's meeting "Managing and handling Editors can be both authors and reviewers" it makes sense to have one dashboard for all roles. Users would see a version of this depending on the content, for example:
- User who is only an author sees "Authored questions"
- User who is author + reviewer sees "Authored questions" and "To Review"
- User who is author + reviewer + managing editor sees the Dashboard as above.
As editors
From the dashboard:
- a managing editor can assign submitted questions to a handing editor. The button "assign handing editor" would either be a dropdown list of names or a modal.
- both managing and handling editor can invite reviewers. How this button functions will depend on outcome of #4 (closed).
- opening a row in the 'Editors questions' section shows this view of a question:
- Here, the same actions of assigning handing editors and inviting reviewers are possible on a the individual question level.
- Similarly, how the 'Invite reviewers' process works will depend on #4 (closed). It may be that a modal from the button is not sufficient, in which case there could be an additional tab "reviewer invitations" to search for and invite appropriate reviewers, and keep a record of information such as the status of the invite (pending/accepted/rejected) and 'reasons for rejecting invite'.
- Editors can also reject the submitted question.
- Chat between Author and Editor is not shown here yet. We'll come back to this functionality
As reviewer
- opening a row in the 'To review' section of the Dashboard shows this view of a question:
- The reviewer must first accept or reject the invitation before it's possible to take the question and survey.
- The reject button may open a modal to provide a reason for rejecting the invitation.
- The functionality of "room for survey" area will depend on feedback in #5 (closed).
- Clarification: Is there a use case for reviewer and handling editor having a discussion (see chat section) after a review has been submitted?
- When reviewer has completed the the review, he submits it, which saved the review in read-only format for the editors and production team to view on this screen:
Other comments
- We've implemented some of your feedback in #3 (closed) for this round. The rest needs further discussion.
- Thanks for the feedback on accessibility too. The majority of it is relevant for the development stage. As mentioned, we'll implement colour and contrast requirements and any other visual requirements later on.
Let me know if there are any questions.