OJS Dashboard

From PKP Wiki
Revision as of 09:59, 5 June 2014 by Alec (Talk | contribs)

Jump to: navigation, search

The dashboard is a critical screen for helping users be productive with OJS, providing them with a quick overview of their responsibilities.

Screenshots

Dashboard - Tasks

Dashboard-ed-tasks.png


Dashboard - Submissions

Dashboard-ed-submissions.png


Dashboard - Archives

Dashboard-ed-archive.png


Issues

Issues have been identified regarding the findability of particular submissions, especially when there are multiple submissions available, clarity of the information presented in the dashboard, and the co-relation between task status and email notifications.


Recommendations

Recommendation A (John):

  • Multiple journals: can select journal in Submissions and in Archive
    • Submission and Archive numbers correspond to selected journal
  • Rollovers
    • Article number gives date submission made;
    • Status links gives date submission entered current status;
    • Editors, gives Send Email To.
  • Collapsible and expandable categories, e.g., [+] Unassigned Submissions
  • Sortable by columns

Further thinking on my (john's) Dashboard following Bruno's Design

  • Add scroll bar, which is a great idea under Submissions, and maybe even Archive (although need to consider with potentially 1,000s of entries).
  • Add the dates, although I want to consider having the dates available as rollovers for the submission number, which I propose adding to the dashboard, because I have repeatedly found it very helpful in working with editors for identifying which submission we are talking about, and I'd propose hyperlinking the number to lead back to the submission's Submission stage.
  • Propose as a general UI/UX principle that we consider "visual prominence" or what pops out first (like the information icon below) and what needs to be seen. The author; titles need to be more prominent than the icons; submissions with tasks need to be next, stages need to be next.
  • Propose as a general UI/UX principle ending all underlining for hyperlinking, as it reduces legibility of the hyperlinked item and dates the site.
  • Propose as a general UI/UX principle reducing use of horizontal lines (tables in research publications do not use such lines) and instead create a more continuous textual line to guide the eye (without adding another visual element), emphasizing the dashboard as a list of submissions, like a bibliographic list, rather than a tabulation of data.
  • Propose no hyperlinking of submission titles (as opposed to file titles), as it reduces the legibility of what needs to be carefully read (compared to file titles and Editorial Stages) and including as much of the submission's title as room permits.
  • Propose hyperlinking the Stages to suggest to editors that the link leads directly to the current stage where action is needed or can be reviewed.
  • Propose using the same font throughout, with all-caps for titles, small caps, as shown, and the use of grey-scale to subordinate what is not require immediate attention on each review of dashbaord, such as the the column titles.
  • Propose column order of Editor/ Submit Date / Stage / Task (as this eliminates the empty column in the top half) and using Stage rather than Status as it refers to accepted, declined etc

See: Dashboard Wireframe


Suggestion (Bruno):

Submission lists-1.png

  • Cleaned a lot using the scroll bar as a paging widget (like facebook). I was hesitant to use it anywhere else with more a fixed set of data. I also thought it would be too much work and we had enough with the current paging. But I think that on this case this feature fits well, because users are not interested in the exact page a submission will be. It can be page 2 today and tomorrow page 3, so there is not much point. We plan to use the search with a lot of options, so users can filter submissions there and just navigate using the scroll.
  • Put the tasks next to the stages, hide the content. It can be viewed on click, opening inside a small modal.
  • Authors and title can come in two lines now. More space to authors and the grid in general.
  • Show submit date. We already had users asking for this, so I think it's important to go as clear as possible.
  • Add the row actions (more information and in case of authored submissions, delete).
  • Plan to add the search options at the top. We can add a filter option to search by tasks (only "A decision is needed in review stage" tasks, for example). That would make users that wants to see this specific overview happy. But I think we need to test if it would be necessary.
  • Ideally this would be a submissions and tasks overview. I think we can keep the tasks tab as something personal, "my tasks" only overview. We can use the same amount of submission detail (name, state and date) but adding more about the task itself.


Recommendation B (John - notes from last year):

  1. Add a Submissions grid to the Editor's dash containing all active submissions for the Journal, with an Editor column to indicate who is assigned. Remove "My Authored Submissions" from Editor's dash. (This grid will include the Editor's authored submissions for that journal by definition.)
  2. Move the Section Editor's authored submissions into their "My Assigned Submissions" grid. Remove "My Authored Submissions" from Section Editor's dash.
  3. The "Status" column should be removed from the Unassigned grid

Notes:

  • Most aspects of the dashboards are currently not journal-specific, i.e. the "My Submissions" list shows all submissions authored in all journals on the site. Mixing those into the Submissions list for the specific journal will muddy the waters. Are you proposing making the dashboard's submission lists journal-specific? For example, "My Authored Submissions" is for all journals; if we remove that from the Editor's dashboard, the Editor will no longer have access to submissions they have authored in other journals they do not edit.

THE EDITOR SHOULD ONLY HAVE ACCESS TO SUBMISSIONS FOR THE JOURNALS FOR WHICH THEY ARE ASSIGNED AS EDITOR FOR. If an editor is running two journals (rare), it seems fair for reducing confusion to have a dashboard for each journal so that they working with the people involved in that journal. On the other hand, AN AUTHOR who submits to two journals is, in a sense a member of both journals (as is a Reviewer who reviews for more than one). But even then this would be a rare event, and it would not be expected to be able to log in to one journal and have access to the other. With the Mega-journal model, with many more submissions, we'd still have one journal.

  • How is the "My Assigned Submissions" grid affected in the Editor's case? It overlaps with Submissions as specified above, but I think it's worth keeping as the Editor may want a short-list of submissions the Editor is actually assigned to.

AS THE EDITOR IS RESPONSIBLE FOR THE WHOLE OF THE JOURNAL'S SUBMISSIONS, EVEN THOUGH THEY MAY ASSIGN THEMSELVES TO SOME PORTION oF THE SUBMISSIONS, I THINK IT FAIR FOR THEM TO HAVE TO SCAN THE WHOLE LIST OF ACTIVE SUBMISSIONS, WHILE BEING ABLE TO IDENTIFY their as they see their name under EDITOR.

  • I don't think we've thought out interactions between roles yet (for users who have multiple roles).

THIS will be clear in the TASK tab, but are you thinking of a ROLE column for Submissions when someone has more than one role related to a single journal.


Recommendation C (CDL)

  • Add a search box limited to submissions.

See CDL Report pages 70-71.


Recommendation D (CDL)

  • We recommend that a consistent mapping matrix needs to be created that maps email titles and default communication text to align the wording for dashboard status and task description. Or at the very least, if email titles, dashboard status and tasks descriptions cannot be reconciled by the development team, then users would like a way to edit the email titles and status descriptions themselves.

See CDL Report page 71.


Recommendation E (CDL)

  • Take My Authored Submissions queue and place it in a separate tab in the dashboard construct.
  • Move the pagination mechanism so that it is situated closer to the queue that it controls.
  • Reconcile the way that new submissions are displayed in the Submissions tab so that all new submissions appear in the Unassigned queue first.

See CDL Report pages 71-72.


Recommendation F (CDL)

  • Add a filtering mechanism to allow users to sort between items that had been declined or published. An ability to search the content within this queue would be an effective tool for Editors or Journal Managers in locating known items for troubleshooting questions.

See CDL Report page 72.


Recommendation G (Kevin)

  • To assist with findability, make columns sortable, triggered by a standard icon next to the column heading.

See, for example, this Table Sorter.


Recommendation H (Kevin)

  • On the Submissions page, add a horizontal rule below the pagination tools, to clarify which section it applies to.

Discussion

See "discussion" tab at the top of the wiki page.


Decision

To come.


Prototype

Moving Tasks to Header (Alec)

Tasks prototype 1.png

  • Tasks removed from Dashboard; moved to header drop-down instead
  • Tasks become context-independent (not affected by what press/journal is selected); remainder of Dashboard becomes context-dependent (only content from the current press/journal are displayed)
  • Number of "new" notifications indicated in parentheses
    • Tasks become "new" when created; can be marked read/unread using grid actions.
  • Made the grid one-column (two was clumsy and didn't suit non-submission notifications)

Feedback

User responses recorded here.

Implementation

Bugzilla entry at http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8759