OJS Dashboard

From PKP Wiki
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.


Dashboard - Tasks


Dashboard - Submissions


Dashboard - Archives



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.


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


  • 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.


  • 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.

Recommendation I (PKP)

  • Dashboard is context specific, only present information for the current context;
  • Bring the issue lists to dashboard;
  • Tabs also show the number of existing items that they represent. The submission tab in special also shows the number of task the current user have.
  • Use grid style and UX based on the feedback from users for grid redesign;
  • Grid search should use autocomplete;
  • Use 1 grid with 4 collapsible grid categories (Unassigned, My Assigned, My Authored and Active). The Active one will show all submissions that are not related to the editor viewing the page (he is not the author, it's not assigned to any task) and that already have an editor assignment. It's there so editors can access and check the editorial process.
  • Start new submission process is a grid action;
  • Remove the expand all grid action that the grid accordion feature introduces (not necessary, only 4 categories, just adds noise);
  • Start grid with all categories opened;
  • Remove grid row actions, no more access to Information Center, delete action it's now at the category row.
  • In Submissions tab, just delete incomplete submissions;
  • In Archives tab, can delete all;
  • Show submission Id to give users a sense of chronology (the higher the id, more recent the submission);
  • Mix author and title into only one column;
  • Add editor column, to show which editor is assigned to each submission;
  • If editor column is not used by the submission category (my assigned and unassigned), the title should use its space.
  • Open a new widget (we can call it light modal) when clicking on the submission ids, with more information about it (complete title, submission date, complete list of authors);
  • Hover the editor abbreviations to get the full name as tool tips;
  • Remove links from titles;
  • Click on stage name to go to the workflow page, inside the correspondent tab;
  • Use an asterisk right next to the stage name to represent a task that needs to be done for the submission for the current user (not only for that particular stage, this is for all stages);
  • Use infinite scrolling pagination, one for each submission category;

Submissions tab normal grid.png

Search options appears when you click the search button:

Submissions tab search.png

If you search for a submission and no result is found, grid should give an option to do the same search in Archives. That way we avoid users not founding submission because they forgot to search in Archives.

Submissions tab search results.png

Example of the hover to show the editor name:

Submissions tab editor hover.png

Example of the light modal to show more info about the submission:

Submissions tab id click more info.png


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


To come.


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)


User responses to Grid redesign recorded here.


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